Roy and Niels

Roy and Niels
Showing posts with label Linux. Show all posts
Showing posts with label Linux. Show all posts

Sunday, January 22, 2012

The Quick and Dirty Guide for Parallelizing FLUKA

(Single PC version)

Imagine you got a desktop or laptop PC with 4 or perhaps even 8 CPU cores available, and you want to run the Monte Carlo particle transport program  FLUKA on it using all CPU cores.
The FLUKA execution script rfluka however was designed to run in "serial" mode. That is, if you request to repeat your simulation a lot of times (say, 100) issuing the command rfluka -N0 -M100 example, each process is launched serially, instead of utilizing all available cores on your PC.

A solution can be to use a job queuing system and a scheduler. Here, I'll present one way to do it on a Debian based Linux system. Ubuntu might work just as well, since Ubuntu is very similar to Debian. A feature of the method presented here, is that it can easily be extended to cover several PCs on your network, so you can use the computing power of your colleagues when they do not use their PCs (e.g. at night). However, this post will try to make it very simple, namely set it just on your own PC. In less than 10 minutes you'll have it up and running...

The idea is to use TORQUE in a very minimal configuration. There will be no fuzz with Maui or similar schedulers, we will only use packages we can get from the Debian/Ubuntu software repositories.
In order to be friendly to all the Ubuntu users out there, all commands issued as root are here prefixed with the "sudo" command. As a Debian user you can become root using the "su" command first.

First install these packages:

$ sudo apt-get install torque-server torque-scheduler 
$ sudo apt-get install torque-common torque-mom libtorque2
and either
$ sudo apt-get install torque-client
or
$ sudo apt-get install torque-client-x11

after installation we need to setup torque properly. I here assume that your PC hostname cannot be resolved by DNS, which is quite common on small local networks. You can test whether your hostname can be resolved by the "host" command. Assuming your PC has the name "kepler", you may get an answer like:

$ host $HOSTNAME
Host kepler not found: 3(NXDOMAIN)

this means you may need to edit the /etc/hosts file, so your PC can associate an IP number with your hostname. Debian like distros may have a propensity to assign the hostname to 127.0.1.1 which will not work with torque. Instead I looked up my IP number (which in my case is pretty static) using /sbin/ifconfig, and edited the /etc/hosts accordingly, using your favourite text editor (emacs, gedit, vi...)
My /etc/hosts file ended up looking like this:

127.0.0.1 localhost
#127.0.1.1 kepler.lan kepler
192.168.1.108   kepler

If your hostname of your PC can be resolved, you can ommit the last line, but under all circumstances you must comment out the line starting with 127.0.1.1.


Once this is done, execute the following commands to configure torque:
$ sudo echo $HOSTNAME > /etc/torque/server_name
$ sudo echo $HOSTNAME > /var/spool/torque/server_name
$ sudo pbs_server -t create
$ sudo echo $HOSTNAME np=`grep proc /proc/cpuinfo | wc -l` > /var/spool/torque/server_priv/nodes 
$ sudo qterm
$ sudo pbs_server
$ sudo pbs_mom

(Update: If qterm fails, you probably have a problem with your /etc/hosts file. You can still kill the server with $killall -r "pbs_*".)

Now let's  see if things are running as expected:
$ pbsnodes -a
kepler
     state = free
     np = 4
     ntype = cluster
     status = rectime=1326926041,varattr=,jobs=,state=free,netload=3304768553,gres=,loadave=0.09,ncpus=4,physmem=3988892kb,availmem=6643852kb,totmem=7876584kb,idletime=2518,nusers=2,nsessions=8,sessions=1183 1760 2170 2271 2513 15794 16067 16607,uname=Linux kepler 3.1.0-1-amd64 #1 SMP Tue Jan 10 05:01:58 UTC 2012 x86_64,opsys=linux

and also
$sudo momctl -d 0 -h $HOSTNAME

Host: kepler/kepler   Version: 2.4.16   PID: 16835
Server[0]: kepler (192.168.1.108:15001)
  Last Msg From Server:   279 seconds (CLUSTER_ADDRS)
  Last Msg To Server:     9 seconds
HomeDirectory:          /var/spool/torque/mom_priv
MOM active:             280 seconds
LogLevel:               0 (use SIGUSR1/SIGUSR2 to adjust)
NOTE:  no local jobs detected

Now setup a queue, which here is called "batch".
$ sudo qmgr -c 'create queue batch'
$ sudo qmgr -c 'set queue batch queue_type = Execution'
$ sudo qmgr -c 'set queue batch resources_default.nodes = 1'
$ sudo qmgr -c 'set queue batch resources_default.walltime = 01:00:00'
$ sudo qmgr -c 'set queue batch enabled = True'
$ sudo qmgr -c 'set queue batch started = True'
$ sudo qmgr -c 'set server default_queue = batch'
$ sudo qmgr -c 'set server scheduling = True'

[update: you may want to increase walltime to 10:00:00 so jobs dont stop after 1 hour]

and start the scheduler:
$ sudo pbs_sched

The rest of the commands can be issued as a normal user (i.e. non-root).

Let's see if all servers are running:
$ ps -e | grep pbs
 1286 ?        00:00:00 pbs_mom
 1293 ?        00:00:00 pbs_server
 2174 ?        00:00:00 pbs_sched

Anything in the queue?
$ qstat
$ 
Nope, it's empty.

Lets try to submit a simple job
echo "sleep 20" | qsub

and within the next 20 seconds you can test, if its in the queue:
$ qstat
Job id                    Name             User            Time Use S Queue
------------------------- ---------------- --------------- -------- - -----
0.kepler                 STDIN            bassler                0 R batch


Great, now were ready to rock 'n roll! This is really a minimalistic setup, which just works. For more bells and whistles, check the torque manual.

All we need, is a simple FLUKA job submission script: rtfluka.sh
#!/bin/bash
#
# how to use this
# change to directory with the files you want to run
# and enter:
# $ qsub -V -t 0-9 -d . rtfluka.sh
#
#PBS -N FLUKA_JOB
#
start="$PBS_ARRAYID"
let stop="$start+1"
stop_pad=`printf "%03i\n" $stop`
#
# Init new random number sequence for each calculation. 
# This may be a poor solution.
cp $FLUPRO/random.dat ranexample$stop_pad
sed -i '/RANDOMIZE        1.0/c\RANDOMIZE        1.0 '"${RANDOM}"'.0 \' example.inp
$FLUPRO/flutil/rfluka -N$start -M$stop example -e flukadpm3

Update: Note that your RANDOMIZE card in your own .inp file must match the sed regular expression above, else you may repeat the exact same simulation over and over again...


Let's submit 10 jobs:
$ qsub -V -t 0-9 -d . rtfluka.sh

And watch the blinkenlichts.
$ qstat
Job id                    Name             User            Time Use S Queue
------------------------- ---------------- --------------- -------- - -----
15-0.kepler               FLUKA_JOB-0      bassler                0 R batch          
15-1.kepler               FLUKA_JOB-1      bassler                0 R batch          
15-2.kepler               FLUKA_JOB-2      bassler                0 R batch          
15-3.kepler               FLUKA_JOB-3      bassler                0 R batch          
15-4.kepler               FLUKA_JOB-4      bassler                0 Q batch          
15-5.kepler               FLUKA_JOB-5      bassler                0 Q batch          
15-6.kepler               FLUKA_JOB-6      bassler                0 Q batch          
15-7.kepler               FLUKA_JOB-7      bassler                0 Q batch          
15-8.kepler               FLUKA_JOB-8      bassler                0 Q batch          
15-9.kepler               FLUKA_JOB-9      bassler                0 Q batch 

Surely, this can be improved a lot, suggestions are most welcome in the comments below. One problem is for instance, that the random number seed is limited to a 16 bit integer, which only covers a very small fraction of the possible seeds for the RANDOMIZE card.
Update: There is also a very small risk that the same seed occasionally is used twice (or more often). Alternatively one could just add a random number to a starting seed after each run. (Any MC random number experts out there?)

Output data can be processed in regular ways, using flair
Alternatively you may use some of the scripts in the auflukatools package, which for instance can do the merging of USRBIN output with a single command. Auflukatools also includes rtfluka.sh as well as a CONDOR job submission script rcfluka.py, which is better suited for heterogenous clusters.

Finally, here is a job script for SHIELD_HITxxA, (which is even shorter):

#!/bin/bash
#
# how to use
# change to directory you want to run
# $ qsub -V -t 0-9 -d . rtshield.sh
#
#PBS -N SHIELD_JOB
shield_exe  -N$PBS_ARRAYID

Enjoy!

Totally unrelated: englishrussia.com just posted some nice pics from the Budker institute for Nuclear Physics in Novosibirsk, Russia. Certainly worth visiting, have a look at:
http://englishrussia.com/2012/01/21/the-budker-institute-of-nuclear-physics/
 :-) Heaps of pioneering accelerator technology was developed there, such as electron cooling, the first collider, lithium lenses (e.g. for capturing antiprotons), and they supplied the conventional magnets for the beam transfer lines to the LHC at CERN. I visited the center many years ago but my pics are not as good. :-/ The German wiki about Budker himself, is also worth reading.


Friday, July 1, 2011

Antiproton Radiotherapy Experiments at CERN

In this moment we have a week of antiproton beam at CERN for radiobiology and dosimetry experiments. The main experiment is to measure the relative biological effectiveness (RBE) of antiprotons. As an endpoint we use clonogenic survival of V79 Chinese hamster cells (in vitro).

What makes this experiment so complicated, is :
  • we only have narrow beam geometry available at CERN
  • antiprotons are rare, we only get app. 1 Gy / hour
  • beam is highly pulsed, i.e. a 500 nanosecond spill every 90 seconds.
Therefore, we invest a lot of effort in performing precise dosimetry with multiple redundant systems. This is a long story, which I will tell more about another time. Here, let me just show a few pictures...

The antiproton beam line with a water phantom for dosimetry.
The entire experiment is located in an experimental zone at the antiproton decelerator (AD) at CERN. We share our zone with the AEgIS people, who want to find out if antiprotons fly up or down in the gravitational field of the earth. :)

Franz-Joachim Kaiser messing with the water phantom. Behind him the AEgIS beam line.
Three ionization chambers (ICs) are visible here, from the left to the right: a custom made "Advanced Roos" chamber, a Markus chamber and the MicroLion liquid ionization chamber. All by PTW.
Gafchromic EBT film irradiated with antiprotons. Beam spot is about 1 cm FWHM. The narrow beam geometry makes us very vulnerable to positioning errors...

... and therefore we also monitor the beam from spill to spill with a Mimotera detector.
We are usually 2-4 people on a shift. Tonight I will do the night shift with Franz-Joachim (to the left). Stefan will leave soon. Usually, I would do night shifts with Roy Keyes, but he couldn't be here this year.
I build this little box for the experiment: it interfaces the antiproton decelerator with the printer port of our data acquisition computer. No need for expensive IO cards or fancy LabView. Basically it is just some TTL logic and optocouplers. On the server side, a daemon listens to the parallel port if a new spill of antiprotons is coming in.
Once triggered, the server takes care to read out all data systems, such as beam current transformers, ionization chamber and scintillators.
Client programs, here running on the laptop to the left, can connect to the server, and change various settings of the readout procedure.

Again, this is home-brew. Earlier, the data acquisition was some libncurses based stuff, this year is the first time we had a traditional GUI for the client and a clear client/server separation. I wrote the client in C++/QT4 and compiled it for linux and win32. Stefan did a package for mac. Server is pure C, linux only. Sometimes, I think the most valuable course I had when I was a student at our Physics department in Aarhus, was a C-programming course.  (And that course was only offered once! What a shame!)

Fiona from the Belfast QUB group is in charge of the film scans, and making sure there are enough sweets for all of us.
Entire experimental zone in the AD hall, seen from above, where our non-existant counting hut would be..
A bit off topic, but just over our heads, there is a positron beam line, which delivers the positrons to the anti-hydrogen "bottle" of ATRAP. Positrons go from the right side to the left.

Me, checking up on things... :-) I think this is the 8th or 9th time I am working at the ACE experiment.
Alanine is one of the most reliable solid state dosimeters for such exotic beams such as antiprotons. Here a stack of pellets is prepared for irradiation.

Once the pellets have been irradiated with antiprotons, they are shipped for read out to our collaborators at the National Physical Laboratory (NPL) in Teddington, UK.. (The NPL serves also as a primary standard lab for radiation quantities.)


Alright then.. :/

Recursively posting this blog entry.
More pictures here.


Tuesday, October 5, 2010

Pretty Good Privacy and Evolution

This year, the danish government forced all its internet users to use the "NemID" solution for digital communication between the several public institutions, banks etc. The NemID concept is based on regular asymmetric encryption with a public and secret key pair. The developers of NemID realized very wisely that a significant amount of users (if not the majority) won't be capable of storing their secret key safely on their respective computers running windows.

The solution is that a private company "DanID", contracted by the danish government, stores the secret key for the user (imagine this happening in Germany!), and any interaction is realized with a java based login portal and a TAN list.

Without commenting on the trustworthiness of "DanID", this solution obviously does not integrate with typical Linux mailers such as Evolution.

Therefore, my colleague Bjarne Thomsen recently urged me (multiple times, thanks) to encrypt / sign my emails using gpg. Last time I did this was in 2004, but I must admit I cannot remember where I stored my old secret key (it is probably lost), and the revocation file is probably also gone. So, I had to start again from scratch. Here is the recipe:

Fist generate a new key pair. I was very paranoid, and closed down any closed source processes which I do not trust (skype, flash, google earth ...), while generating this key.

$ gpg --gen-key

Let it be valid for 2 years, you will probably loose your secret key, forget your pass phrase and/or your revocation file sooner or later, and there is no way you can delete keys from the key server.
You can also choose between RSA and DSA/ElGamal signing/encryption. I chose RSA, for no specific reason. For the bit length the default is 2048, but I chose 4096 bit, which should be safe until year 2030.

You will get a response akin to:

pub 4096R/xxxxxxxx 2010-10-04 [expires: 2012-10-03]

where the xxxxxxxx value is your public key identifier.

Next, you submit your public key to the key server:

$ gpg --keyserver pgp.mit.edu --send-keys xxxxxxx

And finally I recommend you generate the aforementioned revocation file.

$ gpg --output revoke.asc --gen-revoke xxxxxxxx

Anyone who has this file can revoke your key. You can print the file on paper and store it a safe place, if you wish.

So, now you are ready to go. Fire up evolution, go to your mail account setup. There is a tab which says "Security". In this tab there is a place where you can enter your secret key ID. Don't worry, your key identifier is not secret in that sense, the actual key is protected with your pass phrase.


Now you are able to send signed emails. Evolution will ask for a pass phrase when accessing your key.

But you probably also want to send encrypted emails. In order to do so, you need to import the public key of the recipient. Evolution does not do this automatically, this is a very old bug in evolution which still has not been fixed, see #259665.


Instead, you must manually import the recipients public key. I look up the recipients key id on a key server, such as this one: http://pgp.mit.edu/

$ gpg --keyserver pgp.mit.edu --recv-keys xxxxxxxx

If you are sure you got the right key, sign it:
$ gpg --sign-key xxxxxxxx

Ideally, you meet the person and exchange they key (e.g. at key-signing party)

If you need to sign against a specific secret key, use:
$ gpg --default-key xx(yoursecretkeyID)xx --sign-key xx(keyIDtobesigned)xx

List your keys with:
$ gpg --list-keys


Tadaaa, now you can encrypt the mails in evolution. Note that the email addresses of the public key and the recipient you mail the key to must match.

If you ever need to revoke your key, do:
$ gpg --output revoke.asc --gen-revoke xxxxxxxx
$ gpg --import revoke.asc
$ gpg --keyserver pgp.mit.edu --send-keys xxxxxxxx



Oh yes, and here is my ASCII armored public key:
-----BEGIN PGP PUBLIC KEY BLOCK-----
Version: SKS 1.1.0

mQINBEyqPwEBEACyDaTA6X7nz6N3rsRtnwnld9McaCRPXhUdex3BqbLIj4eKqwESX9Ynv62v
UG4E/DrMfRAThQRjL9R9KJ44S2+Vobk6PMUy7AL3PtWnOkWa5YtrpoUUVTzFlaMPjwQjCf9V
E9BOssPF/iUc5i8vfxg98BM+7oQVaB6EKKuvBqDM3IdkdKGG6e3lzbeJFHQ2vf4vuyKG3Ssb
X4vBiWWeuIVr9ktkhHAHfeDyXYzDbKY7W1XUOytgGydlTWF1ddFvu+knbPvZJdfpWyBoDNGt
2YzQSjsB0PxQbnh7xkLm09u79US+hVfhAQUzgDQPN/qV41xTb5IlMqmTlPBgNghueOFVzHkD
G4LFrFmTCHhtfnTN2jDsL71UuXVfTG9/Rrv68zOvtzw+nfgIGBXpDcJpHShLRsroc/e3Oxy8
iI+Aek5IJviM/jMMi4Ps4lT3g83VD5UP9etxUPs0k/DFupfQKcaqnd1AZey96AicLUKcjLCQ
X8+yCwQkiQ5nulJeokRP97Qo6XVEhEFYrYkLQ6LW86fDlFK0NjbDD2znqEpsWGXAH/O0XWxM
4rFyNsF1uPbfiKcvv2LEUTW9EJywxJ0FRknFHe9V+68Nw/dSY95nh7TWag9wLYNEOEu16OBw
ewWO7an9/fAkJO1UoLsbUsoU0FoZL59wBSmLCZFviHMRtorEfQARAQABtCJOaWVscyBCYXNz
bGVyIDxiYXNzbGVyQHBoeXMuYXUuZGs+iQI+BBMBAgAoBQJMqj8BAhsDBQkDwmcABgsJCAcD
AgYVCAIJCgsEFgIDAQIeAQIXgAAKCRA7KijjAPhkTxK5D/9Fv/hVoWgHwxBAn36jNFpqyL80
e2g4oWlkQ6Ue8WlzoTi8Qa526GOgvC86XqEPzYC6Xgb/IUwqpEfQFJnXjHy2GnChH67WlfBE
hEzWd9Ygmo8uZs3QdY9jfXySkaDHJGzcBeUyz1L1eLLP76iZI1JAI//AkMgdmlzQ55u5it8d
5+huhiQXLFSKpS6O5WlqLqUs9yWnElP/5xjAZFQcbbJxmAesmyhDgOK4R/Lh+5zqcXidZ3IV
f+6oRIg6ln27rkv2eE4/Pe1VXlO3BbIO41oF2OmzTNZityWhIrx6qvTyS63uL69UzFaY2HZq
zt5tcrAX8NUPyUh4MJ62Hq0AVXnWJWMrm1UUc/dNwwWxI/dYYRbLPWMVSqM8K8DFMefor/18
vxXfeRQktxZfbxaglpklJxaGL9WIWdQpP/aGmbz/k1O8eJG5+Xg5jKHGehdc3gvLBhSHfLyX
vx/bjQBbxUoQGAVJYdY7qzp2NLtGI5EOeGl/QJafiqcZ/G1RMqH/mNVWjzGWLF376CYsJcuO
yb1kH9DlEGws+zTARxzxSlgjwE9OI0OwMZb9i/QhzBpsNsDny9XcBDS3MHK2tY1wCDOser6h
j8Cunu8kA936XhHbvGY5RouJwea4B0SK/w4JqfW0/C7NRPJh9zU1eAvooYrSVi3uamYpvaY4
XwawJIOovrkCDQRMqj8BARAAtwInYERMzmgfocG/tITg+jihK4c6sjr44G2g2uquOAJPYVGq
35CKRDQZPXQlv7NTfY2SJOtEPJhx+gm+8AtpuwcxcpG2L4AgtaXjF6os6DJOdGvI5wjeMbSF
0um9/4mf4+Vxvl33aJ0v3sg6+mVhSBtp+UdvVKG/VPD26qdhXxMnO3G20zduX8ikn1nbhF68
gss9VYsrxsdGqJBtUSm3d+UIpI/ylNCpdk8VUwm+o6Iu6aq53tFnQrPi4xywggQY2n2wwVIv
6Uqk4qRxgw6SNpdrFj+VUu6zv8/l+Q5nstjrlEUofI50k88ouyUEw0+uoj+fVZ1fGkBEhzzw
zpyDUwaP4fZJWA6VbYvoWgAzmEYTAD8EFqnGl3OuHSppeQwXu/Ac/a9sNmPr/7Jkprua1KTO
lHv3SLkGKdhA7gOIhQEVEif8H0QrAq0b1Z93lHA2qrcKLUBg94M/syQFZdxfxscxl73x5ntI
qg1ux4t2VSBT9XToZGe1qx3UoVzG52vTO4hSZU4XkvNkla9vGalfr5z0xJVCcZ+1W8oG7/jf
xng1Dqxdk+EBXl+lW4yuCGLvrtWl0GNP1ZHxCKh6jOGIferd9gPgHmi39IE5oXpbNEPKyWBI
PXHCoL8fTkQNwFm01CNNmiYFLzCZpDJ3NVH6NBpfcgxF8sN4fW1Vu0CQ3osAEQEAAYkCJQQY
AQIADwUCTKo/AQIbDAUJA8JnAAAKCRA7KijjAPhkT1YUEACgjt47I/iPHl7CM4DLuVo0t5JW
w5UVG79BtNH6QcKdYm3iYzBlx2bZj9Ig+vIW2il3WZSUgWo1OFZri53p+L0fXaOKaeLJatiF
up0H2a07SzMWEYPjL6i7cmeeb6eSfIf3hBfWcWctGGJT8cYudINFtazR8BMxpB09B33uYqOc
M4wCS9QHCEXu2pzPtvykisjTy69KEtw9SXRjZVC9zJQG8DmahxDtdGUTI/RHrk/MyuJqqv19
ZzV4I08jpfJeFNsmIWZtf5ssHxJA56MDRg2T7gllWXu3fIvP3SsKiMpAA4x2+tsc4J8ul73k
xr4Frftk2cuM2caL8JZteKf4tTJwZRc/7+lIssnfA2/yvCi1IxVFNUl9UMCq7ZBmdA9mgzVl
dbKTWGGi+7XFF2Uk3dXrlvt7WmNQ3y6fKE3FBBy9AdNUPdGpGP2KVcyX4zH49O6C1zzYYTML
6p+6Q6rah6VIOYmfn+GUQEpv3XpY3rWYDzLOyjYUA/LOdMzAP/kjYldWiUOtGIsoUYoR9CeI
Fm/lzatQWyTQDWf5HRB6/gwL9A4+TbUQzFgJY9l4sNPutYq+i4Uo926gPUs4j47b4xAEQGyS
dxCcE9F7b313f5PcvKh/r7t8yT2qDdWt99W4tLGZ+PErJ+Rv6ICTiQqrO5z7eG7IgZh7Z6aG
QoO36dM9fw==
=L/Hy
-----END PGP PUBLIC KEY BLOCK-----

Sunday, September 26, 2010

Cyrillic letters in LaTeX

Currently, I am writing a manual for a Russian Monte Carlo particle transport code SHIELD-HIT. LaTeX is just perfect for this purpose due to its vast amount of capabilities while still, say, "forcing" the user to be well structured and use a clean layout and formatting.

Unlike some years ago, most Linux distributions are now running in a UTF-8 environment, and most applications endorse UTF-8, which I think is a blessing for international minded spirits such as myself. LaTeX documents can be in UTF-8, without the use of awkward escape characters such as \"u for an ΓΌ.

But LaTeX and dvips still need to have the appropriate fonts installed. The aforementioned manual may contain text in Cyrillic letters, so my header is formatted this way:

\documentclass[a4paper,english,russian,10pt]{book}
\usepackage[utf8]{inputenc} % make weird characters work
\usepackage[T2A,OT1]{fontenc} % enable Cyrillic fonts
\usepackage{amsmath}
\usepackage{amssymb}
...


Most editors such as emacs or gedit will recognize the character encoding for you:
However, emacs is also sensitive to the \usepackage[utf8]{inputenc} line in the .tex file, presumably this is a feature coming along with the auctex package. If you specify something which is inconsistent with the character encoding of the file, you will have a terrible mess.

Compiling the .tex file, I was confronted with an error:

...
(/usr/share/texmf-texlive/tex/latex/base/omsenc.dfu)))
(/usr/share/texmf-texlive/tex/latex/base/fontenc.sty

! Package fontenc Error: Encoding file `t2aenc.def' not found.
(fontenc) You might have misspelt the name of the encoding.
...

Ok, so I looked into synaptic what file provides the t2aenc.def. But synaptic did not return any results. Then I searched for the "T2A" font. According to synaptic, this is provided by the "cm-super" package. But after installing the 60 MB package the error still persisted.

The trick was to install the texlive-lang-cyrillic package. Then the .tex file could be compiled. This is rather unintuitive, since there is no mentioning of the t2aenc.def file in the texlive-lang-cyrillic package.

Next step is to convert the .dvi file to a PDF file. If you do not have the cm-super package installed, you may end up with:

~/Projects/shieldhit/trunk/doc/tex$ dvipdf ShieldHIT_Manual.dvi
dvips: Font tctt0800 not found, using cmr10 instead.
dvips: Design size mismatch in font tctt0800
dvips: Checksum mismatch in font tctt0800
dvips: ! invalid char 246 from font tctt0800


and a rather empty .pdf file. The cm-super-minimal package may be insufficient, In my case I had to install the full cm-super package.

Conclusion: UTF-8 is good for you, it makes life easier and more enjoyable. So use it whenever you can. :-)

Friday, September 24, 2010

Yet another ssh wonder: SSHFS

SSHFS is a file system which is capable of mounting remote filesystems locally on a computer if the remote system can be accessed by ssh.

This is a very interesting alternative to NFS or Samba based filesystems. First of all, it can be operated entirely from userspace, which is cool. Contrary to NFS, any user can mount any remote directory he or she has access to via ssh.

There are no locking issues with SSHFS, which makes it robust and free of the infamous "NFS stale handles". The speed is inferior to NFS and not recommended for intensive use, but it is perfect for occasional work.

On Debian you merely need to install the sshfs package and its dependencies, e.g.: (as root)

$ apt-get install sshfs

Then you need to add all the users to the fuse group. E.g. the user bassler can be added:

$ adduser bassler fuse

after this, you must logout of the system (entirely, yes. Like exiting your X session, and logging in again. Just closing and opening the terminal window wont be sufficient).
That's it.

Now the (non-root) user you have added to the fuse group can mount remote directories:

$ sshfs example.com:/remote/directory /local/directory

Unmounting can be realized with

$ fusermount -u /local/directory

What I still miss, is an automount solution.

Thursday, September 16, 2010

Downloading a youtube video and extract audio

Ever played a game of the STALKER series? I am not all that fond of ego shooters, but I enjoy movies made by the russian director Tarkovsky, and the STALKER triology is based upon his famous movie of the same name. You can find plenty of movie snippets on YouTube.

Anyway, I also came across this little benchmark test (yeah, there is no visible difference between DirectX10 and 11, but that's not the point here), which had a very catchy tune. A few visitors ask where the music was taken from, but no one replied. Now, it can be rather difficult to search for an instrumental piece of music on the net, when all you have got is the music.
Update: Or you may find the tune in another vid, and actually get a reply. The track above is Dream Catchers by A.L.N.P.S.V from the Tunguska Chillout Grooves vol. 1.

So I searched for a way of somehow extracting the audio in a .ogg file. All my attempts (even trying to use some sort of audio capture) failed, until my friend Alexandru Csete told me about this nifty python script which can download youtube videos.

Unpacking it, and executing it from command line

$ ./youtube-dl http://www.youtube.com/watch?v=6QpAMzTCDpg

which returns a .mp4 file. The audio channel can now be extracted with ffmpeg:

$ ffmpeg -i 6QpAMzTCDpg.mp4 -vn -acodec vorbis -aq 50 audio.ogg

The "-vn" option tells ffmpeg to ignore the video part. If the "-acodec vorbis" is not specified, the audio had some aac format, which e.g. my mobile phone is not capable of handling, so this had to be stated explicitly.

I spent some time to figure out the quality setting. First I tried "-ab 64000" setting, but somehow ffmpeg did all the encoding at about 60 kpbs irrespectively of the -ab setting. The default settings were pretty bad, and especially in this example you can easily hear losses. (If you listen to the faint woodwind-like sounds close to 5:30 you hear they are almost gone on lower quality setting.) Using the "-aq 50" option I got a good result.

I checked with the "file" command to see what format the audio was:

$ file audio.ogg
audio.ogg: Ogg data, Vorbis audio, stereo, 44100 Hz, ~0 bps

Apparently the file command cannot recognize the bps correctly.

I also tried to convert to mp3 format, but even if I had installed the "lame" library, ffmpeg refused to find it. I did not pursue this further, since I am actually quite happy with the ogg/vorbis format.

Wednesday, September 15, 2010

Wonders of chmod: set executeable bit only on directories

On some systems, the default file permissions are rather restrictive. I.e. at our university the policy is umask=002, which means that any new file created or copied from a remote computer will only have owner read/write access enabled and read/write/executable to directories.

This is sometimes annoying when files are being uploaded to the ~/public_html/ directory which were meant to be accessed by external users. Usually one forgets to set the correct permissions, leaving the files inaccessible to general public.

This morning I got an email from my PhD student (he is currently in Australia, which explains why he was up that early) - he had to turn in an exam project via his web page, but he had forgotten to set the permission right.

His WIFI access did not allow ssh (lame!), so he gave me his password so I could fix this for him. Entering his directory, I encountered a large directory structure with several sub-directories and files.

Issue a recursive chmod

chmod -R a+r *

from the base directory would still leave the sub-directories inaccessible.

chmod -R a+rx *

is an ugly thing to do. Sure it works, but messes up auto completion as bash/dash will think all files can be executed. Also on a coloured console this would produce psychedelic output when listing files. Manually setting permissions on all directories would be a very stupid thing to do.

That is when I realized that chmod can also explicitly be told only to set the executable bit on directories using capital X. Awesome, I thought, so here we go:

chmod -R a+rX *

Yeah, this may be trivial, but I was not aware of this option before.

Tuesday, September 14, 2010

Transferring files via tar and a compressed ssh tunnel.

I was confronted with an old AIX computer with a bad network card, and had to secure 60 GB data located on a SCSI disk. We did not have any available SCSI controller, so we could not dismount the disk from the AIX machine. The machine did not have any USB ports either, so the only way to secure the disk was via network.

However, the network card frequently stalled and provided transmission rates of only max. 30-40 kB/second. Copying data by scp via ssh would be way too slow. Initial attempts indicated that the file transfer could take several weeks.

Rsync could be an option, but it was not installed on the AIX machine. Installing rsync was not considered, because no one really dared to touch the AIX machine with root rights.

The solution was to pipe the data via a compressed ssh tunnel. Most data on the AIX machine were CT scans, which can provide a significant compression ratio.
The command line is slightly cryptic though: (it is a one-liner, ignore the line wrapping)


tar cvf - /tp_data | gzip -9c | ssh root@gorm 'cd /target_dir; gunzip - | tar xpf -'


which will place the /tp_data directory inside the /target directory on the gorm computer, running linux.

Result: all data were transferred in less than a week.