Closed makeclean closed 11 years ago
Correct. The new version of this accounts for this. Nonetheless I will leave this open.
Has the new version already been pushed? If so apologies, I need to pull the newest version!
No not yet, sorry. These new version will be a wrapper for some PyNE functions I am implementing. I am putting the finishing touches on it this Winter Break.
I can make the place-holder changes to mats2ALARA.py tonight if needed. (I have more robust MCNP parsing code from my time at LANL...)
@makeclean is there an immediate need for this improvement? @erelson: I would be happy to make the changes (if there is an immediate need) since it is my code to begin with.
I like I said I have a bulletproof version of this in the pipelines, but there is a lot of overhead to finishing it up because it is being done in PyNE.
Alright I have a PyNE version of this written which I will put forth soon. Quick question:
So far we have been using a custom ALARA isolib with names that look like h:1, fe:56, etc. Would anyone object if we scratch this format and switch to H1, FE56, etc.? The motivation is that this output format already exists within PyNE and I don't see a strong need to introduce another format.
I personally have no preference, however it's a lot harder to perform text manipulation operations on fe56 than the delimited form. Do you know if this change necessitates a change in alara?
Never mind, the semicolon is actually used by ALARA. I will just put everything in fe:56 format.
I just pushed the PyNE version to svalinn/r2s-act. It prints like "fe:56". It is dependent on PyNE functions that just got committed today, so you will need to pull from pyne/pyne and rebuild.
It seems that when using mats2ALARA.py when the script encounters a material of the form
M1 1001.21c 0.3 2004.21c 0.2 c 3006.21c 0.3 2005.21c 0.5
The script fails to read the entries after the comment line. Dangerous!