Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

ENH COE BranchCollector could also include user variables #489

Open
ybilodid opened this issue Aug 2, 2023 · 6 comments
Open

ENH COE BranchCollector could also include user variables #489

ybilodid opened this issue Aug 2, 2023 · 6 comments

Comments

@ybilodid
Copy link

ybilodid commented Aug 2, 2023

Hi!
serpentTools features a very useful BranchCollector. I use it to post-process Serpent .coe into XS-library for a diffusion code.
e.g. my branching in Serpent looks like:

coef 12 0.0  0.1  0.5  1.0  3.0  5.0  7.0 10.0 12.0 14.0 17.0 21.0
5 ro09 ro08 ro07 ro06 ro05 
3 cb0 cb1000 cb2000
3 tf500 tf900 tf1800
2 no_spa zirc
1 no_cr

Serpent allows to define a variable to each branching, and those values are printed in .coe, e.g:

1 1080 1 90 1
5 ro09 cb0 tf500 no_spa no_cr
9 VERSION 2.2.1 DATE 23/07/21 TIME 13:27:55 DMO 900 BOR 0 TFU 500 SPA 0 CR 0 CRNAME NONE

The BranchCollector attributes contain lists of states and burnup but not those variables assigned to states.
So in a post-process script I have to provide them again, although they are included in .coe

It would be handy if I could get them from the BranchCollector object.

Thanks,
Yuri

@ybilodid ybilodid changed the title COE BranchCollector could also include user variables ENH COE BranchCollector could also include user variables Aug 2, 2023
@ybilodid
Copy link
Author

ybilodid commented Aug 3, 2023

a small follow-up about the branches order in the collector.
the Serpent branching card is shown in the previous message.
and collector.states are:

(('ro05', 'ro06', 'ro07', 'ro08', 'ro09'),
 ('cb0', 'cb1000', 'cb2000'),
 ('tf1800', 'tf500', 'tf900'),
 ('no_spa', 'zirc'),
 ('no_cr',))

As you see, the order is different from the Serpent input card, which is especially not convenient in case of fuel temperature.
As far as I understand, the order in collector.states coincide with order in collector.xsTables.
Would it be possible to keep the original branching order as in Serpent input?

@drewejohnson
Copy link
Collaborator

@ybilodid thank you for the kind words about this project. I'm glad it's working well for you!

Regarding the additional state variables, I think we do have a way to grab them using collector.states or collector.stateData

I haven't used this feature in a long time, but I believe you are encouraged to define variables to be converted to integers / floats via the branching.floatVariables setting

>>> from serpentTools.settings import rc
>>> rc['branching.floatVariables'] = ['BOR']
>>> rc['branching.intVariables'] = ['TFU']
>>> rc['xs.getB1XS'] = False
>>> rc['xs.variableExtras'] = ['INF_TOT', 'INF_SCATT0']
>>> r1 = serpentTools.readDataFile(branchFile)
>>> b1 = r1.branches['B1000', 'FT600']
>>> b1.stateData
{'BOR': 1000.0,
 'DATE': '17/12/19',
 'TFU': 600,
 'TIME': '09:48:54',
 'VERSION': '2.1.29'}
>>> assert isinstance(b1.stateData['BOR'], float)
>>> assert isinstance(b1.stateData['TFU'], int)

would something like this work for your use case?

For the ordering issue, would you mind opening that in a separate issue? Then it's easier to keep discussion focused on "unique" bugs/feature requests

@ybilodid
Copy link
Author

ybilodid commented Aug 8, 2023

in my case (serpentTools 0.9.5) there is no collector.stateData in collector
I guess I could parse all branches in the reader and collect the stateData. But, once again, the order will be different from the order in collector.
From my point of view, it would be convenient to have a corresponding attribute in collector object, something like

collector.userVars
({'DMO':(500,600,700,800,900)},
 {'BOR':(0, 1000, 2000)},
 {'TFU:(500, 900, 1800)},
 {'SPA':(0, 1)},
 {'CR':(0)})

@drewejohnson
Copy link
Collaborator

That should be the expected behavior based on my reading of our examples and our documentation. The following works with serpentTools 0.9.5 on our serpentTools/data/demo.coe file

>>> r = serpentTools.read("./serpentTools/data/demo.coe")
>>> r["nom", "nom"].stateData
{"VERSION": "2.1.29", "DATE": ..., "TIME": ...}
>>> r["B1000", "FT1200"].stateData
{"VERSION": "2.1.29", "DATE": ..., "TIME": ..., "BOR": "1000", "TFU": "1200"}

where one of the branches has state data / user variables assigned to it, specifically "BOR": "1000" and "TFU": "1200"

Maybe there's a disconnect between what we do and what you are looking for. Are you expecting to have something like

r = serpentTools.read("demo.coe")
r.stateData
{"DMO": (500, 600, 700, 800, 900),
"BOR": (0, 1000, 2000),
...
}

where all the states are collected on the primary reader, across all branches? In addition to each branch having it's own state data?

@ybilodid
Copy link
Author

Probably I didn't explain my idea clearly.
I can read COE file with serpentTools.read() and I get all the branches, with corresponding xs data and statedata.

import serpentTools 
coe = serpentTools .read(coefile)

I could go through all branches and collect the data needed for my diffusion code.
But I do not need to do so, since serpentTools has vary convenient serpentTools.xs.BranchCollector:

collector = serpentTools.xs.BranchCollector(coe)
collector.collect()

which collects all the data into multi-dimensional tables.
so I can get xs from collector.xsTables and I know how they are arranged from collector.states and collector.axis, I can also get burnup points from collector.burnups.
The only thing which is IMHO missing here - the user variables table, which corresponds to collector.states.
Yes, I can fish out that information from the reader, but it would be more convenient to have it directly in the collector.

@drewejohnson
Copy link
Collaborator

@ybilodid you made yourself very clear, the confusion is from me. We have too many Branch* things and I got the reader, collector, and container confused.

I understand the request now, and it makes a lot of sense to store user variables in additional to state data

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants