Closet...
...اینجا می‌نویسم برای اینکه یادم بمونه... تا راحت‌تر فراموش کنم
Tuesday, September 20, 2011
Compiling LAPACK in C++ code in Ubuntu 10.04

I rarely use LAPACK and when I need it to work I usually have bunch of coding and compiling problems! So once for all here is the notes I might need next time:

In the code:
Your are compiling a C++ code, ya? So extern the part that are linked from "C" codes. That is, you need to add something like

extern "C" void   dgemm_(char *transa, char *transb,int *m, int *n, int *k, double *alpha, double *a, int *lda, double *b, int *ldb, double *beta, double *c, int *ldc );

to declare dgemm_ and use it in the code as

dgemm_ (&charN, &charN, &n, &k, &n, &dpone, Acopy, &n, b, &n, &dmone,
bcopy, &n);

[1], [2]

When compiling:
Compile with something like

g++ -Wall -O3 svd_test.cpp  -L/usr/local/lib/ -llapack -lf77blas -lcblas -latlas -lg2c -lm


Note about the g2c library:

In Ubuntu 10.04 LTS, the libg2c library is not included per default. If 'ls /usr/lib/libg2c.*' does not list anything this is the case on your machine. You then want to install the packages gcc-3.4-base and libg2c0 e.g. from  

http://packages.ubuntu.com/hardy/gcc-3.4-base and
http://packages.ubuntu.com/hardy/libg2c0.

After installation, you have to create a symbolic link by
'cd /usr/lib' and 'ln -s libg2c.so.0 libg2c.so'
[3]

Now go back to work!

Labels: ,

Tuesday, September 13, 2011
Every now and then when I run a code that I wrote and it works exactly as I expected, I feel the warmth that makes me keep on doing this shit.

Labels:

Monday, March 07, 2011
Necessaries

PS. Finally I moved to the new system. Let's get back to work!

Labels: , ,

Wednesday, March 02, 2011
My laptop is dying. I don't want to get sentimental but I believe it deserves to be remembered...

I bought it, a Dell Latitude D820, about 5 years ago in Spring 2006 when I got sure that I am going to go abroad for graduate school. On that time it was a powerful laptop/desktop replacement; the tool you have to take with you if you are going to the computation/simulation field of study.
I really appreciated it's Intel Core™2 Duo processor which allowed me to run two instances of my single thread codes simultaneously. Its 16:10 wide display was ideal for displaying coding environment and its keyboard/touch-pad was quite comfortable. Even though It was heavy, it was worth the weight.
Well, I am still stunned that it survived two years of constant heavy runs and downloading while I was doing my masters. That was the reason I didn't even think about getting a new laptop while I came here. Overall I am very pleased that it accompanied me halfway through my PhD.
Sadly, something faulted yesterday while I wasn't home and it got over heated. As a result the graphic card is not working properly anymore. I cleaned the cooling aperture in hope of its return but it didn't work. Also I checked the option of replacing the graphic card but it requires changing the whole mainboard. So, today I reluctantly ordered its replacement. It was hard to find something comparable...

So, my old friend, it's time to let your bits and bytes relax,
Rest in peace.

Labels: , ,

Thursday, February 03, 2011
Some random notes on the art of debugging (of numerical codes) - Part 1

- Consistency is the key. Start small. Write 1D version first, test it and when it was OK move to higher dimension codes. It's much easier to debug in 1D than 2D. Your 2D code should do the exact same thing as your 1D code if you feed it the same emulated 1D data in 2D format. This is the same for 2D to 3D expansion.

- Try the naive test cases before running your big-bang simulation. Zero state, unit state and well-known physical special conditions are good starters. If your method is symmetric, definitely test for the conservation of symmetry on symmetric initial condition. Think about special conditions that only test a special part of your code. Be creative.

- If you are going to test the order of convergence without comparing with exact solution, that is using some sort of three level Richardson extrapolation, test the tester routine with manually coarsen data from some arbitrary fine data before accusing your code of order deficiency. I guess you don't want to measure the Golden Gate Bridge with a 10-cm ruler which takes few hours and then find out the ruler has a half-life of order 10 second and thermal linear expansion coefficient of order 10/°C, do you?

- If running your code line-by-line takes one day, it better to do that instead of 10-day clueless wandering in thousands lines of code.

- Take notes of the debugging procedure and use revision control, period

- If you are coding using GNU tools and you are an Emacs person, learn to use GDB in Emacs, it is incredibly powerful. Add Speedbar and you are on fire.

Labels: , ,

Tuesday, February 01, 2011
The engine of my numerical code is working and it is 2nd order accurate as it should be... finally, yeah! It took me 2 months to write and almost 3 months to debug. That's right, such a crappy coder I am! I don't care that the freaking bug was so primitive that I should have never made a mistake like that. I'm just happy that I found it! Anyway, at least it motivated me to read a bunch of numerical methods books that I would never touched if I weren't that desperate. Fortunately, it didn't kill me, so I suppose I am stronger now!

Well, I really needed this; life couldn't sucked more these days. Time to go home...

Labels: ,

Wednesday, January 05, 2011

When you are done with any project, for YOUR OWN SAKE write a few lines of comments about the process in which the project has been done. I don't mean comments in the code. I mean things like which files are final revisions, which one exactly produced the figures/tables in your report, What happened that made you write another version or why some algorithm/code didn't work. I am saying that because, in few years from now, YOU will be the person who is going to dig up these files to find out what was happening and cursing yourself won't help at all.

I am digging up codes and data files from 2-3 years ago and even though I made fairly enough documentation, in the way I just mentioned, there are parts which take my time to understand what I have done. But overall it is much better than codes without any description!

PS. I am happy with the codes I wrote for that project, though my numerical analysis knowledge was quite limited at that time (Yeah, I am patting myself on the back!). The only reason, that I can think of, is that we tried to write the code the simplest form possible without any algorithmic complexity to make debugging easy. So now when I reread those codes it is like reading a report. Obviously the main code isn't the fastest implementation but is quite robust!

Labels:

Monday, August 02, 2010
وقتی سه-چهار هزار خط کد میزنی، دفعه اول که میخوای compile کنی، انتظار داری که nتا error بده، مگه نه؟… خب نه! حالی داد بس عظیم، تو مایه های اینکه ممکنه همین الان خودمو بازنشسته کنم که در اوج دست از کد زدن کشیده باشم...

پی نوشت: خود جو گیری که میگن همینه! الان اگه run بگیرم خزعبل میده مثله تراکتور.

Labels: , ,

Monday, July 26, 2010
"GNU Emacs comes with ABSOLUTELY NO WARRANTY"... That's why it works!

Labels: ,

Monday, June 28, 2010
Your back hurts; You cannot stop your eyes from dangling in your head and your arms are damn sore... but you found the problem. Then you get the joy of debugging. Now you can expand! Put on the earphones, fire the Pandora and head home...
:]

Labels: , ,