ENH COE BranchCollector could also include user variables about serpent-tools HOT 7 OPEN

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?

from serpent-tools.

@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

• https://serpent-tools.readthedocs.io/en/master/generated/serpentTools.xs.BranchCollector.html#serpentTools.xs.BranchCollector.states
• https://serpent-tools.readthedocs.io/en/master/examples/Branching.html#user-control

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

from serpent-tools.

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

from serpent-tools.

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?

from serpent-tools.

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.

from serpent-tools.

@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

from serpent-tools.