work only – Dilettante

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

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.

nse out, now bibtex

I sent my prof. my version of the manuscript. Now I’m trying to get the proper citations for Nuclear Science and Engineering with bibtex. I’ve been running into Charles Karney’s physics journal bibtex styles, but I haven’t gotten them working yet. They say to run them through the c preprocessor to get different styles, but I just get errors like:

physics.bst:9:19: warning: missing terminating ‘ character

physics.bst:3484:7: warning: extra tokens at end of #else directive

Ah. This is because cpp has decided that it shouldn’t be used for processing anything besides actual source code. Well, thankfully they left in the -traditional-cpp option. So if you use

cpp -P -traditional-cpp physics.bst nse.bst

It will actually work. That’s excellent. This is nice.

[1] C. Tzanos, E. Gyftopoulos, and M. Driscoll, “Optimization of Material
Distributions in Fast Reactor Cores”, Nucl. Sci. Eng. 52, 84 (1973)

Here’s a nice cheat sheet for VIM. I’m using it to capitalize the first letter of each word in my bibtex.tex file. I’m sure the bibtex style can do this but I’m not bothering.

Here’s the final product: nse.bst

UPDATE: I put double quotes around article and techreport titles, as discussed here.

Also, fonts from my LyX install were really fuzzy when printed. I went into document settings and changed font family to Roman and set font to Latin Modern Roman and now the fonts don’t get fuzzy when you zoom in so I’ll assume they don’t get fuzzy on print either. Let’s hope not.

I also just added a reCAPTCHA plugin to this blog. It works. My simpleCAPTCHA plugin wasn’t showing the image, nor was it even showing up in the plugin list. I renamed the simple-captcha folder in my plugins folder and now recaptcha is in charge.

I need to call Jeff soon to tell him he’s publishing this.

thorium workshop, 2nd iteration

I’m at the thorium workshop here at school. There’s a guy from Thor power in Norway giving a talk. It’s interesting.

Fleming just suggested BeO as a moderator in a Th reactor. It’s diffusion length is just right (more than water, less than graphite), it won’t burn like graphite in air, and it increases your beta-effective with it’s delayed photoneutrons and stuff. I should tell will this.

But I’m actually working on BP stuff. I ran the BP search before the TRU search on the 2nd iteration of case 2. The BP search direction is loading correctly now, but it’s not covering the full power peak. I’m going to get power plots that correspond to the search direction plots now. It was very simple to do with my plotSearchDir2 function. (I have a good library I guess). It’s very useful to see these two together, layered on top of each other with the compiz fusion opacify functionality. Wow.

My mpeg4 povray videos didn’t work on JCLs mac computer. I’ll have to look into that. Ah, mac’s don’t support the avi container. I did this:

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

to convert it to quicktime and sent it to him to see if it would have worked. It did.

There are asymmetries that show up in the 2nd iteration of the v4 case. They’re worse in the 3rd iteration. None help the peaking factor. What the heck. Should have gotten 1/3 core model to work. Must finish manuscript. Will stick with 1st iteration. Damn damn damn.

second iteration, screen magic, new line search

First thing I did this morning was install the AntiBotQuestion mod in my phpBB3 forum for whatisnuclear.com. 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

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

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:

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.
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)
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.

nse

Back to work on the same old. I figured out the grayscale images yesterday, but I still need to generate them for all the new uranium cases that don’t have thousands of kg of Hafnium in them. Additionally, I’m going to add a picture of the adjont source in the 1-D slab. Will need to try to make it eps. On it. Running the analytic oned solution now. I chose search and will see what we get. It’s been a while since I ran this code. OK I got a decent plot out. I used TeX text processing on it and it looks phenomenal. Now to generate the B&W ones for three cases…

In case 1, the 0-th timestep jump parameter is negative, so we need to switch the sense of all search directions. Run.py can handle that now, with the N option, for “negative.” That’s revision 8 in the itd svn repository. Rerunning v6 case with proper sense. Let’s see if we can do better. With improper searching, we started at peaking factor 1.05038 and got to 1.04 by bp search, and to 1.039 by end of BDT. Lame.

Uhh. I just spend 1.5 hours with MCNP crap for a student in my class. Why are we struggling with MCNP when we should be learning reactor analysis? Damn another hour with the class! These guys are killing me.

Well here’s some instructions I just made for doing safety analysis of SFRs in REBUS or MC**2:

<!– @page { margin: 0.79in } P { margin-bottom: 0.08in } –>

Disabling the criticality search in REBUS

by Nick Touran

If you want to perform any kind of basic void coefficient, Doppler coefficient, or temperature coefficient of reactivity estimations in REBUS for fast reactors, you have to disable the criticality search. Here’s how.

Run your regular base case of interest. Look at the output for the final value of the enrichment modification factor. You will find a edit like this near the bottom:

++++++++++++++++++++++++++++++++++++++++

+ +

+ COMPLETION OF FINAL SEARCH PROCEDURE +

+ +

++++++++++++++++++++++++++++++++++++++++

THE ENRICHMENT MODIFICATION FACTOR IS 2.36759E-01

THE BURN STEP TIME IS 2.10483E+02 DAYS.

Note the factor. You need to put it into your perturbed file.

Make a new rebus and MC**2 case with the perturbations you wanted. Decrease the sodium density, decrease the fuel density, eject a control rod, whatever.

In that new rebus input, go to the A.BURN card 4. You should see a 1.000 representing the desired k-eff at EOC. After that, there is a convergence criterion, probably set to 0.0001 or so. Change it to 1.000. This disables the criticality search.

The last two numbers in that same line are the first and second guesses of the new enrichment modification factor. Change the first one to the factor noted from the previous output file. Keep in mind that you can only put this number between certain columns. Check the manual to see which ones. Be careful with this!

If there is a burn cycle time search enabled as well, disable it in the same manner (on card 3 though) and insert the burn step time manually!

Now criticality search is off and you’ve manually set the critical class 1 enrichment. You’re ready to run. Run your new rebus case and compare k-effs with those from the base case.

Notes:

If you change a density somewhere, make sure it changes in the cross section library calculation too! The energy self shielding can vary wildly with different densities.

This method of calculating safety parameters should be taken with a grain of salt because it does not account for any anisotopies that you may see in real rod ejection accidents, etc. Diffusion theory is only an approximation of transport! Try using some perturbation theory codes like VARIANT if you want better results.

Have fun!

OK. What else? The new line search behaved very well. But in v5, the big case, the reactivity swings are all miniscule! 1.001 at BOC? Say what? Investigating. The core is breeding plutonium. It’s a breeder. Ah! Well the plenum had the wrong material, it looks like. I fixed it in the CORTANA input maker to agree nicely with the Hill cases of old and am now re-running just the first rebus case. This large case requires a very low guess of the enrichment modification factor.