Thursday 29 November 2007

Three cheers for Greg

... who has informed me that when KDE crashes and the title bars disappear from the windows (which it seems to do with annoying regularity), you can just type:
kde-window-decorator &
to get them back again. Hoorah.

Disclaimer: Greg just said "This might not be a solution, it's crashing much more after that!"

Wednesday 28 November 2007

More NAG problemos

So, to re-cap, the NAG library wants me to have gfortran 4.2.0 or better. I installed the only ready-built new version of gfortran I could find for linux (since Mandriva doesn't offer a package newer than version 4.1.2), which was 4.3.0. I have the NAG library working fine with this new version of gfortran, and it cries if I try to use the old fortran compiler. To re-cap, I now have two compilers on my computer:
"New"
gcc version 4.3.0 20071121 (experimental)
"Old"
gcc version 4.1.2 20070302 (prerelease)

So all is splendid (when I use the routine S14BAF to find the incomplete gamma function) after a few angry words about data-types. You must use double-precision variables (not real(kind = 10) or anything) or else it just returns junk. This will only work if I compile with the new gfortran version.

However , (and there's always a "however" with me and linux!), now I try to compile a program which uses the random number routines G05MKF and similar. The new compiler now gets angry:
/opt/NAG/fll3a21dfl/lib/libnag_nag.a(g05mkxn.o): In function `g05mkxn_':
g05mkxn.f:(.text+0xde): undefined reference to `_gfortran_pow_r8_i4'
/opt/NAG/fll3a21dfl/lib/libnag_nag.a(g05mkzn.o): In function `g05mkzn_':
g05mkzn.f:(.text+0xb1): undefined reference to `_gfortran_pow_r8_i4'
collect2: ld returned 1 exit status
This subroutine "_gfortran_pow_r8_i4" is apparently supposed to be in libgfortran.a and many people have solved their problems by explicitly telling their compiler where to look for this when linking, eg.
/etc/irun/bin/gfortran -m32 simtest.f90 /opt/NAG/fll3a21dfl/lib/libnag_nag.a -o simtest -L/etc/irun/lib -lgfortran
But this still doesn't work. Anyway, I added this directory to the path before hand, so this probably is not the problem. I look at the contents of the libgfortran library using the command:
nm libgfortran.a |more
where I've piped it through the "more" doo-dah so it doesn't all flash by at once. There are lots of similar routines to "_gfortran_pow_r8_i4", but no actual version of the one I want. So my compiler is not lying! I have not so far found a new version of the library which contains this, but my old compiler library does! So for all my random number programs, I must still use the old compiler, which seems to work just fine. Perhaps I can add the subroutine from the old library into the new one? Or will there be other issues?
This page is quite helpful about libraries, I found...

Monday 26 November 2007

NAG library- getting the thing to work!

So, I receive my license key, and I've installed the library that I needed (FLL3A21DFL, x86-32, Linux, gfortran compiler, Double Precision) and followed the installers instructions on this page. It installed in:
/opt/NAG/fll3a21dfl/
It's now time to run a test! The User's Note suggests to run an example, like thus:
nag_example e04ucf
...for which I moved to my own directory where I had write permission. However, then I need to tell it where the nag_example script is, so I actually had to run:
/opt/NAG/fll3a21dfl/scripts/nag_example e04ucf
The computer said:
Copying e04ucfe.f to current directory
cp /opt/NAG/fll3a21dfl/examples/source/e04ucfe.f .
Compiling and linking e04ucfe.f to produce executable e04ucfe.exe
gfortran -m32 e04ucfe.f /opt/NAG/fll3a21dfl/lib/libnag_nag.a -o e04ucfe.exe
Copying e04ucfe.d to current directory
cp /opt/NAG/fll3a21dfl/examples/data/e04ucfe.d .
Running e04ucfe.exe with data from e04ucfe.d
./e04ucfe.exe < e04ucfe.d > e04ucfe.r
/opt/NAG/fll3a21dfl/scripts/nag_example: line 58: 12681 Segmentation fault ./${example}.exe <${example}.d >${example}.r
...as it happily seg-faulted. I guessed this is because it called "gfortran" which still refers to the old version of the compiler on my machine (I still haven't worked out how to change that!) But now I guess the correct commands to re-compile it:
/etc/irun/bin/gfortran -m32 e04ucfe.f /opt/NAG/fll3a21dfl/lib/libnag_nag.a -o e04ucfe.exe
Then to run it:
./e04ucfe.exe < e04ucfe.d > e04ucfe.r
And it cried:
./e04ucfe.exe: error while loading shared libraries: libgfortran.so.3: cannot open shared object file: No such file or directory
No matter, I had forgotten to type
export LD_LIBRARY_FLAG=/etc/irun/lib
export LD_LIBRARY_PATH=/etc/irun/lib
...because I still haven't managed to sort this problem out a better way. Perhaps making a symbolic link to the missing libraries as suggested in the NAG Installer's notes might work:
To simplify access to the libraries you may wish to create symbolic links in a system location such as /usr/lib pointing at the installed libraries. They would then be in the default search path of the linker during the link phase, and be available for execution at run time (in the case of shareable libraries).
Anyway, re-compiling and running now works fine. Time to call a routine from my program. Since this is the NAG library (and not the NAG f90 library), I must call functions with strange names like S14AAF. After adding the compilers own libraries to LD_LIBRARY_PATH (see above!), I additionally added the NAG libraries:
LD_LIBRARY_PATH=/opt/NAG/fll3a21dfl/lib:/opt/NAG/fll3a21dfl/acml:
${LD_LIBRARY_PATH}

but really all on one line, and with no spaces. Then...
export LD_LIBRARY_PATH
Such that typing:
echo $LD_LIBRARY_PATH
Gives me:
/opt/NAG/fll3a21dfl/lib:/opt/NAG/fll3a21dfl/acml:/etc/irun/lib
I've no idea if that was strictly necessary. (Edit- it doesn't seem to be!) In my fortran code, I must declare the types of the NAG functions I call, as well as the fact that they are external:
real(kind = 10) :: factorial, S14AAF, S14BAF
external S14AAF, S14BAF
Where factorial is an internal function I wrote myself. Functions are then called as you would expect...
gam = S14AAF(n+1.0,ifail)
or somesuch line. The program is compiled using:
/etc/irun/bin/gfortran -m32 gammatest.f90 /opt/NAG/fll3a21dfl/lib/libnag_nag.a -o gammatest
...since I had to tell the compiler where to find the external functions.

Thursday 22 November 2007

Fun and games with gfortran and the NAG library

I am trying to install the NAG library at work to run with gfortran. The problem is that it won't work with the old version of gfortran (4.1.2), which is the only package available for my version of the Mandriva linux kernel (2007). I had to update gfortran to 4.2.0 or better. First I needed to find out which kernel version I had (32 bit or 64 bit on a 64-bit processor?). I typed:
cat /etc/issue
which seemed to tell me that I have a 32 bit kernel. An alternative is to try:
uname =a
I then downloaded the 32 bit gfortran binaries for Linux, and saved them in a temporary file. I then changed to the directory in which I wished to install them:
cd /etc
Next I un-tarred them:
tar -zxvf $temp_folder_path/gfortran-linux.tar.gz
Typing:
/etc/irun/bin/gfortran -v
told me all about the new version I had installed. When trying to compile my test code, I had to explicitly give the path to the new version, otherwise it used the old version (haven't worked out how to change this yet!)
/etc/irun/bin/gfortran -o test test.f90
So far, so good, but when I tried to run it:
./test
The computer screamed:
./test: error while loading shared libraries: libgfortran.so.3: cannot open shared object file: No such file or directory
Typing:
ldd test
showed me which libraries the program calls, and which (might) be missing. To solve this:
export LD_LIBRARY_FLAG=/etc/irun/lib
and similarly...
export LD_LIBRARY_PATH=/etc/irun/lib
To see what the variables contain:
echo $LD_LIBRARY_PATH
More fun to come, as I try and get the NAG library to work...

Tuesday 20 November 2007

Fortran 95

Here I am, installing Fortran 95 compilers at work on Mandriva One. It didn't seem to be installed, so I just installed the two packages pertaining to Fortran from rpmdrake, and now my file test.f90 compiles when I type:

f95 -o test test.f90

and runs with:

./test

Hoorah for that.

Saturday 3 November 2007

Linux distros, Rosegarden, MIDI files and other jollity.

This is a brief chronicle of my battles with my computer since my last update.

I for some reason I had made a move back to Windows. However, my patience with it was as short lived as most of my houseplants. I'd also recently been using Mandriva Linux at work, which is very yummy indeed. I'd always previously used Ubuntu with Gnome at home, but the wonder of Kile for editing LaTeX tempted me towards KDE. Thus, I spent many evenings installing new distros on my geriatric laptop. First up was Mandriva, but sadly even trying to boot from a live-cd, it hangs before even starting up. I switched again, and tried Fedora. This installed okay eventually, after a few arguments with the disk partitioning. The automatic partitioner failed to wipe the windows partition from the disk, requiring some serious expletives. After a few days, I tired of Fedora as it ran so very slowly on my ancient computer, and was full of all kinds of dowithoutables. Ever faithful to my first linux love, I tried Kubuntu Edgy. It seems to work fine, but is still a little slow. Not the last word by any means- I think I'm going to have to try a tiny version of Linux, but now is not the moment. So, I cope with Kubuntu for the moment.

Now, for various reasons I require a music notation editor. After a little research, I settle for a combination of Rosegarden for the editor, with Lilypond to do my typesetting. I don't recall how I installed them.

Rosegarden seems to work all fine and dandy except one little hitch:

System timer resolution is too low!

...it cries as it opens. Apparently my kernel timer resolution is puny and not good enough to accurately time MIDI files on playback in real time. I could switch to a low-latency kernel, but I can't be bothered. I want a quick fix and instant results. I'm happy for my sound to get a bit squished and crap, any sound will do for the moment. However, apparently I should be hearing my crappy sound even with Rosegarden's little huff. But I have silence. I conclude my problems lie deeper than this. I can't listen to my MIDI file in anyway, Amarok won't recognise it either.

I find this lovely how-to which tells me to install TiMidiy and "freepats" samples. I reproduce some of it's wisdom here for my own benefit:

timidity music.mid

typed in the commandline now lets me here the funky music! Now, I load some modules

sudo modprobe snd-seq-device
sudo modprobe snd-seq-midi
sudo modprobe snd-seq-oss
sudo modprobe snd-seq-midi-event
sudo modprobe snd-seq

and run:

timidity -iA -B2,8 -Os1l -s 44100

on the command line. This loads TiMidity as a midi server and opens 2 midi ports, 128:0 and 128:1 Now Rosegarden makes sounds! Even with it's timing huff. To get TiMidity to do it's stuff on startup, I must edit /etc/default/timidity and uncomment:

TIM_ALSASEQ=true

I also add

snd-seq-device
snd-seq-midi
snd-seq-oss
snd-seq-midi-event
snd-seq

to /etc/modules.

I now remember a neat way to get sheet music- some music editors can import MIDI files and create scores from them. Rosegarden can too, hoorah. So, I boldly import my MIDI file and lo, I can see the music and hear it too! Amarok still doesn't like my MIDI file, but I shall save that battle for another day.