PyNE in a State of Decay

[Anthony Scopatz]

Hello PyNErs!

At the risk of conjuring up visages from "Love in the Time of Cholera," we need to talk.  It is about decay. Motivated strongly by the demands of the cyclus dev community, I have spent the last couple of sleepless nights writting a decay() function for pyne for your reviewing pleasure.  Please ses #614 for the code. 

This decayer encapsulates a few ideas I have been kicking around for the past couple of years. Namely, 

• Unroll all decay chains ahead of time,
• Reformulate bateman equations to be compute to be computer friendly
• exp() -> exp2()
• combine all possible constants
• throw the entire atom frac vector on the stack
• switch between nuclides

The end result is that it is fast., 5 - 20 μs fast.  This includes converting from/to Materials.

Upsides / Downsides That Need Discussion

With Cameron's guidance on what would incite rebellion and what would be acceptable, I now have the following statistics:

• Source file (decay.cpp) at 14 Mb, down from 54 Mb
• Source file at 69k lines, down from 122k lines
• Compile times between 1 - 2 min, down from infinite
• libpyne.so down to 23 Mb, down from 100+ Mb.
• decay.cpp only takes ~2 sec to generate.

Many of these reduction come from taking spontaneous fission decays out. Others come from some programming tricks (nested switched balanced with unreachable functions). Further reduction are possible if we are willing to get rid of obscure problem species, like Es-247 which has 1015 unique non-SF decay chains.

So what do we do? I have not checked this file into the PR. The way I see it we have a few options. We can check the file in, we can generate the file at build time, and we can make it live in a separate lib*.so.

If we don't want to add this file into the repo and want to generate it during build, then we run into a boot strapping problem since this file requires nuc_data and relevant pieces of pyne. If we do add it to the repo, then our repo size goes up by that amount.

A similar trade off is also seen with startup times and whether we stick this in libpyne.so or only load it when needed.

Also what API would folks like to see? Right now I just have a method on Material and a raw composition map function.

Compiler Flags

In case you were wondering, yes, I did play with compiler flags. A lot. I apply these only to the decay.cpp file. Here are the results:

	GCC		Clang
Extra Compile Flags	User Time [s]	System Time [s]	User Time [s]	System Time [s]
-O0 -fno-gcse -time -std=c++11	82.74	1.43	64.9636	3.3732	Note that for clang -time was replaced with -ftime-report
-O0 -fno-gcse -time	93.94	1.42	71.1664	3.5783
-O0 -time -std=c++11	80.41	1.15	67.6784	3.5175
-O0 -time	83.6	1.7	65.0206	3.5052
-O1 -fno-gcse -time -std=c++11	194.57	3.56	179.5034	3.2921
-O1 -time -std=c++11	193.49	5.73	182.0293	3.3066
-fno-gcse -time -std=c++11	275.35	3.42	191.71	3.0524	presumably -O2

It only gets worse once you go beyond -O0.  This is a little non-intuitive that performing global subexpression elimination is faster, but I guess this is because there ultimately less to assemble.

But Does it Work?!

I have put together a benchmark study that you can find here. This notebook is in the sandbox repo along with a notebook that generates the origen benchmark. However, you'll probably just want to download the benchmark data from http://data.pyne.io/origen-benchmark.h5

I think that this shows that the method here really works.  

Like any good benchmark or code-to-code comparison, this has brought into relief some issues elsewhere in pyne (and possibly in origen) mostly related to branch ratios and half-life data.

From here, I'll be writing up a theory manual entry which hopefully can also become a short paper. But I wanted to get a sense of what the next steps are for this to be included in pyne proper. So please, discuss!

/scopout

[Anthony Scopatz]

Hello All, 

Please note that I have now added a theory manual entry to the to PR.

Be Well

Anthony

[Anthony Scopatz]

Also, 

As per the discussion of distribution, Cameron noted that we could zip the decay.cpp file and it goes down to a mere 1.4 Mb or so. This wouldn't be unreasonable to add to the repo.  I still fret about adding medium sized binary blobs, possibly a holdover from svn.  I propose the following alternative strategy:

0. check to see if decay.cpp already exists

1. try downloading the zipped version during build, 

2. if not connected to the internet and pyne is already installed, then run decay-gen.py  locally (would I need to refactor out the jinja?)

3. if not online and pyne is not installed, continue build and warn the user that they may need to build again after nuc_data_make to install decay.

(3) could go away if we ever decided to run nuc_data_make as part of normal install.  Then we could always rely on bootstrapping. 

Be Well

Anthony

[Cameron Bates]

Hi Anthony,

Having anything in the repo that isn't plaintext also gives me an unpleasant feeling, but I'm not sure this is based on realistic concerns. I like the idea now that setup.py is more manageable though to add an option to build nuc_data_make during install that could enable the bootstrapping. Perhaps if options 0-1 don't work setup.py could exit and recommend the nuc_data_make + bootstrapped build flags.

-Cameron

[Paul Wilson]

Hi Anthony,

Maybe I'm being thick, but I'm not sure how I could even take a look at the generated decay.cpp...

When I try installing PyNE from your branch, it fails on finding decay.cpp.  Is there an install option that skips this for a first install so I can boostrap?  Or do I need to install for another branch first, then somehow generate decay.cpp?

Paul

--

---
You received this message because you are subscribed to the Google Groups "PyNE" group.
To unsubscribe from this group and stop receiving emails from it, send an email to pyne-dev+u...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

-- 
-- ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ --
Paul Wilson ~ UW-Madison ~ 608-263-0807 ~ cal: http://bit.ly/pphw-cal
Professor, Engineering Physics. ~ http://cnerg.engr.wisc.edu
Faculty Director, Advanced Computing Infrastructure

[Anthony Scopatz]

Hi Paul, 

Sorry, I didn't give great instructions here because I wanted feedback on what the right thing to do was.  But if you do want to look at decay.cpp right now, please:

$ cd pyne/src

$ python decay-gen.py

This requires jinja2 (which you probably have because of sphinx).  I have only tested it with python3 so far, but it should work with python2.

Be Well

Anthony

[Andrew Davis]

Im trying this, from a freshly clone repo, checking out branch decay and doing

$ cd pyne/src

$ python decay-get.py

I get

%> Traceback (most recent call last):

  File "decay-gen.py", line 14, in <module>

    from pyne.utils import QAWarning, toggle_warnings

ImportError: cannot import name QAWarning

[Andrew Davis]

I should be clear, from your freshly cloned repo, checking out branc dec

To unsubscribe from this group and stop receiving emails from it, send an email to pyne-dev+unsubscribe@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

-- 
-- ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ --
Paul Wilson ~ UW-Madison ~ 608-263-0807 ~ cal: http://bit.ly/pphw-cal
Professor, Engineering Physics. ~ http://cnerg.engr.wisc.edu
Faculty Director, Advanced Computing Infrastructure

--

---
You received this message because you are subscribed to the Google Groups "PyNE" group.

To unsubscribe from this group and stop receiving emails from it, send an email to pyne-dev+unsubscribe@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--

---
You received this message because you are subscribed to the Google Groups "PyNE" group.

To unsubscribe from this group and stop receiving emails from it, send an email to pyne-dev+unsubscribe@googlegroups.com.

[Anthony Scopatz]

Hi Andy, 

There is still the bootstrapping problem to deal with.  Do you have pyne installed?  You need pyne to be able to run decay-gen.

Be Well

Anthony

To unsubscribe from this group and stop receiving emails from it, send an email to pyne-dev+u...@googlegroups.com.

[Anthony Scopatz]

Hello All, 

I have implemented limited common subexpression elimination (CSE), at Paul's mention.  This was on the list of things that I originally wanted to do, but was lazy.  It turns out the that most (90+% I guess) bang for your buck is to combine just the 2^at terms, so that is all I have done.  Yes this is relatively simple compared to what sympy or a compiler might give you, but it is more than enough.

After playing (and debugging and rebenchmarking) this evening, I have gotten the file size down to 8.6 Mb, the build time down to 45 sec (!), and the run times marginally faster - order 1 μs, if that.

I have also added some important CLI args:

• users can select their short half-life threshold, default 1e-8
• users can opt to include spontaneous fission, default off
• upload to rackspace.

So on that note, you can now download this at http://data.pyne.io/decay.tar.gz without having to build it yourself.

I am too sleepy right now to want to dive into adding this to the build system.  All the changes mentioned are on the PR.

Be Well

Anthony

[Anthony Scopatz]

Hello All, 

I have now made the appropriate changes such that my branch / this PR is now installable.

Be Well

Anthony

[Mark Jackson]

Apologies for resurrecting an old post...

Does the decay module in PyNE account for pathways via metastable states? For example, I-131 can decay directly to Xe-131 or to Xe-131 via Xe-131m.

From my initial testing it would appear that the metastable path is not produced when you use the decay method on a material consisting of I-131.

Mark

To unsubscribe from this group and stop receiving emails from it, send an email to pyne-dev+u...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

-- 
-- ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ --
Paul Wilson ~ UW-Madison ~ 608-263-0807 ~ cal: http://bit.ly/pphw-cal
Professor, Engineering Physics. ~ http://cnerg.engr.wisc.edu
Faculty Director, Advanced Computing Infrastructure

--

---
You received this message because you are subscribed to the Google Groups "PyNE" group.

To unsubscribe from this group and stop receiving emails from it, send an email to pyne-dev+u...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--

---
You received this message because you are subscribed to the Google Groups "PyNE" group.

To unsubscribe from this group and stop receiving emails from it, send an email to pyne-dev+u...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--

---
You received this message because you are subscribed to the Google Groups "PyNE" group.

To unsubscribe from this group and stop receiving emails from it, send an email to pyne-dev+u...@googlegroups.com.