skip to main content.

posts for march 2011.

here’s my project 52 shot for the thirteenth week. the topic was


i found something very beautiful. a black cloud, eating up the sun. well, in fact, that’s not what i found, but what it looks like. it’s a beautiful sunset, taken from the top of the üetliberg, the local mountain of zürich. please click the photo to get a larger version:

technical details: 1/640s, f/25, 400mm, iso 200.

here’s my project 52 shot for the twelvth week. the topic was


this patchwork was made from a huge amount of living wood and leaves, seasoned with a dash of light of a sinking sun. combined from two photos taken while being on the üetliberg, and modified to remove the background and make the light more interesting. please click the photo to get a larger version:

technical details: 1/250s, f/5, 135mm, iso 200; combined with hugin and modified using gimp.

the original combined photo can be seen here:

while doing the glass shot for project 52, i also made the following cork screw shot:

finally, here’s an overview photo of some of the glasses, including the maple leaf bottle used in the glass shot. four of the bottles in the picture are mine, the others belong to a friend of mine. if you want, you can start guessing :-)

here’s my project 52 shot for the eleventh week. the topic was


i decided to photograph something which reminds me of fall 2006, when i first visited canada. one thing to bring with you for good friends is maple syrup, for which canada is famous. in touristy places, one can get it in very nice bottles, shaped like a maple leaf. i really like these bottles, and yet, i still just own one of them. anyway, here’s a nice glassy excerpt from the bottle:

technical details: 30s, f/20, 105mm, iso 200.

another less glass related shot from the same bottle is the following. it depicts a part of the cap, with some maple syrup leftovers sticking to it, with a nice curly golden band which is especially beautiful when viewed in this size. on the right, you can see a white ribbon with red maple leaves (i.e. the canadian flag) on it which is tied to the golden band.

technical details: 30s, f/32, 105mm, iso 200.

here’s my project 52 shot for the tenth week. the topic was


this topic could be so easy if archive photos would be allowed. like in the last year, i visited many stunning places which i’d love to see again right now:

the photos were taken near vikajärvi, haines junction, keno and mayo, and yellowknife (from left to right, top to bottom). the message of these photos is plain and simple: i’d like to be far, far more north! somewhere near the arctic circle, or even north of it.

unfortunately, i couldn’t make it north. instead, i went south, and up by train, to recover a photography combining two aspects of northern travel: snow and railways.

technical details: 1/1000s, f/8, 32mm, iso 200.

(this photo is in fact older than the topic. originally i wanted to near to that place again, to take more photos, also for use for project 52. unfortunately, i was too busy and too sick to do this.)

this afternoon i did a quick trip to the üetliberg.

eventually i was able to watch a very beautiful sunset. here are some excerpts:

does anyone knows how the ulimit bash (or whatever shell you like) command works? i’m currently running a few instances of the same program on a big server, and it happened yesterday twice that the programs together ate up all available memory (some of the instances using much more than others). there was a hard ulimit set on memory, and the result was that all these processed were killed. not just the one violating the memory limit in that moment.
this sucks pretty much, since this destroyed some cpu days of work. does anyone knows why ulimit is doing this? i assume that the rationale is to stop fork bombs, but in this case this is really, really annoying. killing one of the processes would have been perfectly enough…
so, if anyone has good documentation on how ulimit works, whether it is possible to change this behaviour, and whether this is actually intended or a bug, i would like to hear about it…

posted in: computer

tonight i attended a performance of the trans-siberian orchestra here in zürich, where they played their 2000 album beethoven’s last night in its entirely, and some more songs, among them one of my favorites, grieg’s hall of the mountain king. it was an awesome show, really worth its money. i’m still surprised that i didn’t heard about this band before… i took a few pics with my mobile phone; the quality sucks, but you can get an idea of how it looked like:

interestingly, there are already the first recordings online on youtube:

[[for legal reasons, i do not want to include youtube videos here anymore. please click on this link to watch the video at youtube.]]

unfortunately, jon oliva couldn’t make it for this tour…

in the last weeks, i had to compile several libraries for our ultrasparc machine running solaris (sunos 5.10). in particular, these libraries were gmp, atlas, iml, ntl and boost. i wanted to use the sun studio c/c++ compiler (cc has version 5.8, CC has version 5.9) instead of gcc/g++. moreover, i need 64 bit versions of everything, since my programs need a lot of memory. (the machine has around 140 gb of ram anyway, so it makes a lot of sense.)

since it was somewhat troublesome to get everything running (atleast running enough so that i could use what i needed), i want to describe the process of compiling everything here. maybe this is useful for someone…

i compile everything into my home directory, /home/felix. i also use stlport4 instead of the sun studio standard c++ stl, since i couldn’t figure out how to compile boost with the usual stl. the code generated will not be portable, but should be fast.


for configuration and compilation, i did the following:

$ export CC=cc
$ export CXX=CC
$ export CFLAGS=’-m64 -fast -xO3 -xarch=native64 -xchip=native -xcache=native’
$ export CXXFLAGS=’-m64 -fast -xO3 -xarch=native64 -xchip=native -xcache=native -library=stlport4′
$ ./configure –prefix=/home/felix
$ gmake
$ gmake check
$ gmake install
$ gmake distclean

i didn’t add the –enable-cxx switch for configure, since this didn’t work and i didn’t need it. note that i chose the optimization level -xO3 instead of -xO4 or -xO5 since otherwise some of the checks failed. you can try a higher level, but i urge you to run gmake check and reduce the level when checks fail.


to build atlas, i proceeded as follows. you can replace mybuilddir with any other sensible name; that directory will contain all build specific files for that machine. note that atlas does some profiling to determine which methods are fastest, so it is better to not have anything else running on the machine while building atlas. i didn’t build the fortran parts of the library (by –nof77), as well as the fortran tests, since i couldn’t get them to link correctly. (one probably has to set FFLAGS or however the corresponding variable is called…)

$ mkdir mybuilddir
$ cd mybuilddir
$ export CC=cc
$ export CFLAGS=’-m64 -fast -xarch=native64 -xchip=native -xcache=native’
$ ../configure –nof77 –prefix=/home/felix –cc=cc –cflags=’-m64 -fast -xarch=native64 -xchip=native -xcache=native’
$ gmake
$ gmake check
$ gmake ptcheck
$ gmake time
$ gmake install
$ cd ..


building iml is rather easy. it needs both gmp and atlas.

$ export CC=cc
$ export CFLAGS=’-m64 -fast -xarch=native64 -xchip=native -xcache=native’
$ ./configure –prefix=/home/felix –with-gmp-include=/home/felix/include –with-atlas-include=/home/felix/include –with-gmp-lib=/home/felix/lib –with-atlas-lib=/home/felix/lib
$ gmake
$ gmake check
$ gmake install


buliding ntl is a bit more complicated. it requires that gmp is already built. the whole process is more complicated since on our machine, a little tool called MakeDesc called at the beginning of the build process hangs. the problem lies in src/MakeDesc.c, when the main program calls DoublePrecision1(one) in order to find out the (internal) precision of double registers. if i replace the line

dp1 = DoublePrecision1(one);


dp1 = dp;

the whole process works perfectly – though maybe some things will not be 100% correct in the end. (but i’m willing to take that risk.)

$ cd src
$ export CC=cc
$ export CXX=CC
$ export CFLAGS=’-m64 -fast -xarch=native64 -xchip=native -xcache=native’
$ export CXXFLAGS=’-m64 -fast -xarch=native64 -xchip=native -xcache=native -library=stlport4′
$ export LDFLAGS=’-R/home/felix/lib -library=stlport4′
$ ./configure PREFIX=/home/felix CC=cc CXX=CC CFLAGS=’-m64 -fast -xarch=native64 -xchip=native -xcache=native’ CXXFLAGS=’-m64 -fast -xarch=native64 -xchip=native -xcache=native -library=stlport4′ LDFLAGS=’-R:/home/felix/lib’ NTL_GMP_LIP=on GMP_PREFIX=/home/felix
$ gmake
$ gmake check
$ gmake install
$ cd ..


finally, i had to compile boost. after a lot of trying and fiddling, i found out that these calls seem to work:

$ ./ –prefix=/home/felix –show-libraries –with-toolset=sun –with-libraries=iostreams
$ ./bjam –prefix=/home/felix toolset=sun –with-iostreams threading=multi address-model=64 link=static install

note that i only build the iostreams library of boost. remove the –with-libraries=iostreams to (try to) build all libraries.


yes, the whole process is pretty much a pain in the ass. just installing the packages with apt-get on some debian-based linux, or compiling them from scratch on a gcc/g++ based linux, is just sooo much easier. but then, if you have a solaris machine standing around, why not use it to crunch some numbers for you? :-) (especially since currently, i essentially have the machine for myself.)
to compile my code, i use

$ CC -I/home/felix/include -m64 -fast -xarch=native64 -xchip=native -xcache=native -c -library=stlport4 object files and so on;

to link, i do

$ CC -m64 -fast -xarch=native64 -xchip=native -xcache=native -L/home/felix/lib -R/home/felix/lib -library=stlport4 -lntl -liml -lcblas -latlas -lgmp -lm -lboost_iostreams -lz object files and so on.

a week ago i attended a concert at the z-7. the first time since over two years. this concert featured five bands, starting at 18:30. i took the train to arrive at the hall at 19:00, and the first band was already done. the second was done pretty fast as well, but nonetheless this wasn’t a good start since the last train was leaving around midnight and i had to plan in a certain time to reach the train station. (in addition, the last train ride which doesn’t involve walking at least half an hour through zürich leaves around 23:00.)
anyway. i didn’t like the second band very much (maybe less than the first, if i’d heard more of the first band…) the third band, psychotic waltz, a progressive metal band from california, was pretty nice. i haven’t heard of them, which isn’t that much a surprise since they disbanded around 1998, and only recently came back together. i guess i have to check out more of their music at some point later.
after psychotic waltz, one of my most favorite bands entered the stage: nevermore. this is the second time i ever saw them. they played for one hour, including many songs from one of my favorite albums, dead heart from a dead world. unfortunately they didn’t continue playing for another hour or so :-) i really miss the good old times when concerts had at most two or maybe three bands, and the bands had much more time to play…
finally, symphony x started playing. i’ve already seen them twice, in 2007 and 2008. unfortunately, i could only listen to maybe half their set, since i had to leave for the train… they played a bit stuff from their upcoming album, iconoclast. let’s see how the whole thing will sound…
this concert was really nice… except that i had to leave before it was done. i really hade this trent to throw that many bands together, and i’m saying this at more and more concerts – since it’s happening really often, and is really annoying. something very positive about this concert is that the z-7 is now smokefree! there’s still a bit of smoke coming in from outside, but the air inside is much better than it was two years ago. this way, going to concerts is much more fun!