Month: April 2009

commands to do stuff in linux

Here are some nice commands.

Combine lots of pdf files:

gs -dNOPAUSE -sDEVICE=pdfwrite -sOUTPUTFILE=combinedpdf.pdf -dBATCH 1.pdf 2.pdf 3.pdf

Convert eps files to eps files with perfectly fitting bounding boxes:

epstool --copy -b file1.eps newfile.eps

Pull pages out of a pdf (more):

pdftk A=one.pdf B=two.pdf cat A1-7 B1-5 A8 output combined.pdf

Make a quicktime movie with ffmpeg:

ffmpeg -f mp4 -vcodec mpeg4 -i case3-flyby.avi case3-flyby.mov

Encode lots of jpgs to avi:
mencoder mf://hexes???.jpg -mf fps=10:type=jpg -ovc lavc -lavcopts vcodec=mpeg4 -oac copy -o output.avi

Convert pngs to jpg:
mogrify -format jpg -quality 90 hexes???.png

Shrink a bunch of jpgs:
convert -resize 20% IMG_2704.JPG sm_IMG_2704.JPG

Pull audio out of a video file:
ffmpeg -i was014.dv -ab 128 -ar 44100 was1.mp3

Play audio faster or slower without changing the pitch
mplayer -af scaletempo was1-fixed-up.mp3 . Use [ or ] to change speed.
(Note: you have to have a more modern version of mplayer to do this https://launchpad.net/~rvm/+archive/mplayer)

Run povray with 100 frames on the clock:
povray -W1200 -H1000 +kff100 hexes.pov

mc2 up and running, now europium case

OK! MC**2 is up and running on my VM. In comparing the results with those from new-down, I discovered that getting the side-by-side diff mode in VIM is really easy, and I don’t need that cream program anymore. Just use

vim -d file1.txt file2.txt

Then, use Ctrl+w to control the windows:

  • C+w C+w switches windows
  • C+w = makes the windows equal size
  • C+w < or > change the window sizes

Awesome. Here’s a screenshot of this great tool:

Using vim diff mode to see differences in MC**2 results
Using vim diff mode to see differences in MC**2 results

As you can sort of see, the results from my VM and the results from new-down match very well. Enough for me to use lappy laptop for lattice physics of fast reactors. It’s about 10 times faster than new-down, which is a 10 year old SPARC Solaris machine with a 450 MHz processor and 512MB of RAM. Processor info on this sun machine found by executing:

/usr/platform/sun4u/sbin/prtdiag

It’s snowing hard right now. There are about 3 new inches piling up. I had to wear ski goggles to work today.

As for the Europium case, I’ll need to deal with the fission product MC2 template. It has Eu151 through Eu157 as FPs, which I know from experience with Hf will cause problems when I try to add in more Eu at the top of the input. The question is two-fold: 1. How much of the Eu chain would we like to model explicitly? and 2. Should we disregard Eu as a fission product if we use it as a BP? The answer to the second might be easiest. If we are loading in Eu, the amount we load will be significantly higher than the amoun that would build up from fission, so yes, it is a good approximation to ignore fission production. As for the first question, Eu-151 and 153 are naturally occurring and the others all have short half lives on the order of 5-10 years. I’ll start by modelling up to 154, with absorptions above that going to the lumped fission products. All beta decays will also go to lumped fission products that Gadolinium is a member of (LFP41). With that in mind, I’ll eliminate all Eu except 155 through 157 from the fission product list in mc2FP.template.

The sfrCalc script is running nicely on the new VM MC**2 server. I’ve modified the templates to work with the Eurpium. Still working kinks out of sfrCalc script. Spent some time with 442 students and with Maru doing Origen stuff for Ewing’s class. The rebus run failed initially because the MC2 files had ZR  I and FE  I instead of ZIRCI and IRONI. I changed the table in the imd file for fuel-loading-eu in the templates folder to give the proper labels (t0 maintain compatibility with other templates I’ve used). After regenerating the cross sections, rebus runs.

Oddity: My nexenta distro has the wrong time.

compiling and installing MC**2 and dif3d in linux or windows

I thought the search engines were lacking in this topic that I have some experience in, so I figured I better do my part. I have installed MC**2-2 on a windows computer and on a linux computer using similar methods. The XS libraries I obtained differed from the results from my SPARC machine in the later decimal places, and global calculations were nearly identical. I haven’t tested all features, but it seems to work. I’ve also been running DIF3D 8.0 on my Ubuntu machine through a very ridiculous method. It runs in windows under Cygwin nicely.

MC**2-2 on a modern computer

MC**2 is a nice lattice physics code mostly used for fast reactors. It uses ENDF-V data and has excellent treatment of the unresolved resonances and stuff. According to my friends at Argonne National Lab, MC**2-3 is coming out soon, and it will compile easily on PCs. That’ll be nice, and it will make this discussion irrelevant. It’s going through verification right now. Anyway, until then, here’s the general idea. Get VMWare server and install Solaris 10 for i386 on it. This comes with the f77 compiler that MC**2 can actually use. Once you have that all installed, go in there and extract the MC**2 source. Edit the mcc.f file. Make these code changes:

  1. on line 12029 change REAL*16 to REAL*8. x86 architectures don’t support quad precision
  2. on lines 32858 and 32859, do the same.
  3. starting on line 32900, uncomment the lines with DEXP and DLOC and comment out QLOG and DLOG for a total of 4 changes ( 2 uncomments, 2 comments).
  4. Same on line 32937, but only one swap this time.
  5. Add an extra space before the text on line 44534. This is some error in the RSICC distribution.

I’ve done this on Solaris 10 with great success, and now I’m trying it out on OpenSolaris, on my new external hard drive. I had to give it 1GB of RAM or it was crazy slow. OK it works in opensolaris too. Here are the steps:

  1. gunzip and untar p350tar1.gz
  2. edit exec_compile.mcc.sun script and change the lib and jobdir variables to where ever.
  3. make the code changes to mcc.f as discussed
  4. run a copy of the script with the uncompress and copies commented out so it doesn’t overwrite your changes (I did this a few times)

I had to turn optimization in the script from O3 to O2, or else I got a core dump on compiling mcc. f. If all goes well, you should have the MC2 executable.

Now you have to make the libraries. The code to convert libraries needs similar code changes. Change All REAL*16 s to REAL*8, the QLOG to DLOG, and the QEXP to DEXP. It will compile now. I added the cwd to my path and the script ran nicely. Notice that when you change the code, you can’t just re-run the script as is because it uncompresses the original files each time. I made a copy of the script and commented out all the uncompresses after running it the 1st time.

My last pitfall was that there was a write-protected ISOTXS file in the directory I was trying to run in and MC2 dumped the core on execution. I deleted this file and reran with wonderful success.

I witnessed one of the guys who lead the development team of Windows 3.1 try to compile MC**2 once with the intel ifort compiler. He got it compiled, but it failed at runtime with memory allocation errors. That’s the story of my life.

DIF3D8 on a modern PC

DIF3D 8.0 compiles with G95. I followed instructions I found here to do it. I did run into a problem, however, with memory allocation when running on Linux. In Windows XP, under Cygwin, the instructions work perfectly. I am able to run in Linux by using the Cygwin-compiled executable through WINE. This is, conceptually, extremely ridiculous as it is using an emulator to run a program which is emulating the platform that I’m on. Go figure. The bottom line is that it works and it runs quite quickly — moreso than on the ancient solaris machines I used to run on. I think it should be quite easy to get it working natively on linux using G95 with a little effort, so let me know if you figure it out.

Cross section libraries

When transfering XS libraries from one machine to another, it is important to do so in ASCII, or BCD (binary coded decimal) mode. When I run MC**2, I get a binary ISOTXS file that will not transfer nicely to other computers. I use a utility to convert this to ISOBCD, which I then convert back to ISOTXS on the computer I’d like to run on.