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:


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.

second iteration, screen magic, new line search

First thing I did this morning was install the AntiBotQuestion mod in my phpBB3 forum for Spam bots were getting in so I had to shut them down. Unfortunately it didn’t stop guest posts, but I went to the forum and found an extra few lines to add and now it seems to work. Only issue: if you get the captcha wrong, the anti-spam question doesn’t show up in the re-try page. I’ll try to narrow that down later.

I got a nice plot of the 2nd iteration search direction for case 3. It didn’t yield any improvement, however. That’s too bad, or good. Apparently my linesearching is phenomenal. Maybe I should run a few cases of CORTANA BEFORE doing BDT.

Concerns about the BP search not doing anything persist. As expected, the class 1 enrichment increases each time I add BPs. This increase obviously counteracts the effects of the BPs, but it should at least bring the peaks at BOC and EOC closer together. Ope, I noticed the HF concentrations are all identical. Let’s make them natural. Which Hf isotope is the best absorber? Off to the NNDC. According to my chart of the nuclides, Hf-174 is 0.16%, 176 is 5.%, 177 is 18.%, 178 is 27.&, 179 is 12%, and 180 is 35.% Here are all their cross sections:

Hafnium isotopes absorption cross sections
Hafnium isotopes absorption cross sections

Jeff talked about Europium a lot. Here’s a comparison of The two natural isotopes with some of the better Hafnium ones:

Absorption cross-sections of Hafnium and Europium
Absorption cross-sections of Hafnium and Europium

Yeah that Eu-151 is pretty rocking. Given more time, I would put that in. For now, I’ll either admit that the BP searches didn’t do anything, or leave them out completely.

Time to give Professor his slides. If you import EPS into GIMP, make sure to turn the anti-aliasing filters on. OK sent them off. I went up and talked them over with him and he gave me a few tasks:

  1. Switch TRU enrichment one high means add and low means take out. I thought this was done already. Check negative jump. Yeah, in positive jump parameter cases, the search direction is switched by the line search, but the plots will still be wrong. Need to swap them in plotting too for intuition.
  2. Do a fly-by animation. YES! This is going to be hilarious. It’s rendering now. I’ll put it on youtube soon. (here it is)
  3. Remove empty hexes in the core map image.

While doing this, I realized that the BP search and TRU searches shouldn’t be switched from each other. It just worked out that way because they’re both accomplishing the same work. It’s on the 2nd iteration that the BP search might make more sense. All I have to do is work on my line search parser, making it that it reads old controls and updates them rather than making a whole new set each time. hmmmm. Exciting. This also explains why the BP search isn’t doing much. It’s not changing things in the right places. Let’s design a new line searcher

New Line Search Ideas

Currently, we have binned regions based on search directions to have values centered around 1.0, with min and max of  0 and 2. Additionally, the BP line search has the capability of setting any value less than a certain cutoff to zero. Both TRU enrichment modification factors and BP EF priorities get set directly to whatever is in these bins. This makes good sense for the first iteration, where everything is set to 1.0. But in subsequent iterations, these values should represent percent changes in the current value. So if we have a 1.05, increase the current value by 5%. That’s pretty easy.

I’m starting these changes on revision 10. Will start with BP search because it doesn’t work well anyway. Hmm, it’s not so simple as to just doing this multiplication though, because if I want to just increase the size of the feed each time, I don’t want the priority distribution changing. Obviously, I want to separate increase feed size into a different function. Duh.

Linux screen utility wonder

I did learn that I’ve been using screen wrong the whole time. You should only start a screen session once! Not once for each window. Press Ctrl+a, A to name your window, Ctrl+a, c to react a new window, Ctrl+a, ” to list all windows…. etc. How great is that. Productivity just increased. Here’s where I read about it.