Reading of core power distribution files and plotting

[conantaj]

I am not sure what version of Serpent implemented this, but with "set cpd" in the input you can obtain assembly- and pin-level powers, which can be turned into peaking factors. It would be a useful feature to be able to plot the peaking factors, potentially even overlaying with the geometry.

I attached an example file "...coreN.m" and some plots that I made with python.

prob_3_1_1_serpent.inp_core0.zip

[drewejohnson]

Thanks for bringing this to our attention @conantaj. I think this could be a really great addition to the project. The two main features I think we should shoot for with this reader should be accessing and plotting power distributions for an arbitrary level (e.g. pin wise in assembly 5). The plotting could very easily rely on the accessing method, and one or both could support returning peaking factors as you have plotted.

The biggest challenge to be resolved will be placing the data in some meaningful array because all we have are pin indexes, not positions. This may require some user information like "all my assemblies have shape (4, 4)" or "assembly 5 has shape (2, 8)" to fit with your example files.

I'm open to having a discussion here on implementation stuff as well. If anyone wants to claim this let me know, otherwise I'll get to it eventually

[ybilodid]

Hi! Just wanted to remind developers about *core0.m file reader - @conantaj is not the only one who will appreciate that feature. Plotting would be awesome. Sure, you will need information about the type and size of the core lattice and type and size of the assembly lattice.

[drewejohnson]

@ybilodid Thank you for re-upping this. I assure you it is on my task list.

Would you or @conantaj be able to provide examples of typical workflows you would like supported? I've yet to use this file seriously and any insight would be greatly appreciated.

I'm curious about the strength of the assumptions we'll be able to make. If we make the assumption that every assembly has the same number of pins, then things are a lot easier. Even more so if the assemblies have the same arrangement. This might work for a good number of use cases, but looking at what @conantaj provided, that won't always be the case

[ybilodid]

First thing which could be done without assumptions - a reader which gets a file name and gives back numpy.arrays. about workflow and assumptions: In my case, I was simulating PWR and VVER cores - where assumption about the same lattice in each assembly is true. My typical workflow is to open file in matlab, normalize powers, (optionally) avarage powers of symmetrical assemblies or multiple runs and get statistics such as st.dev., save powers in plain text format for comparison with other codes or visualization with external tools.

[drewejohnson]

@ybilodid thank you for this insight. I will keep these suggestions in mind when I start working on this feature. No timeline at this point, unless someone picks it up

[vivian-salino]

Hi everyone,

I would like to add my voice to this wish. I intend to do exactly what @ybilodid describes. However, my only real expectation regarding SerpentTools is to parse the Serpent output. I don't think it's absurd to ask the user of SerpentTools to take care of the remainder: normalize, average on a given symmetry, perform statistics on independent executions, etc. At least, not for a first attempt.

Also, I take this opportunity to thank you for SerpentTools. I use it very simply and you will - of course - be duly cited and thanked again in my papers for this. From the very beginning, it worked directly, in a flash, without any hiccups or need to change or install anything. Very impressive!

[drewejohnson]

@vivian-salino thank you for the feedback and especially for the kind words. If you'd like, feel free to submit a pull request adding publications to docs/publications.rst that use serpentTools :slightly_smiling_face:

To the issue at hand, this hasn't left my mind and I hope to have a simple version included in the next substantial release - 0.10.0. This version will likely just read the file and provide back the arrays, likely in a dictionary. I'm open to including plotting and other bells and whistles at a later point. Most of my hesitation is due to my own in-familiarity with the file and the potentially complicated data structure

P.S. your PhD repo is fantastic. I love seeing more research projects get opened to the public

[vivian-salino]

Hi @drewejohnson, @ybilodid,

I would like to retract my request for this development, as I have discovered that this output from Serpent is very limited - even misleading.

The power distribution given here by Serpent considers only fissions (the (n,gamma) reactions do not deliver any energy, for example, even though it may release a lot of energy in reality), and even then, by a very approximate means. It is considered that all fission energy is deposited locally at the fission site - even the kinetic energy of the outgoing neutrons. The fission energy is also unrealistic, based on that of uranium 235 (whatever the fissioning isotope).

It is much wiser to "set edepmode" to 2 or 3, combined with -80 detector response (dr), as suggested in their recent paper (see below). Note that it requires specific ACE files, with additionnal KERMA data, but in the end, it's the only way to get realistic power distributions.

By the way, this means that you would still use - as I do - SerpentTools to extract information from the detectors ;)

I will submit the idea to VTT to remove this file - or at least add a very large warning that will repel users away from "set cpd".

Here are some references for those who may want to go deeper:

• https://doi.org/10.1016/j.anucene.2019.02.003
• http://serpent.vtt.fi/mediawiki/index.php/Input_syntax_manual#set_edepmode
• https://serpent.vtt.fi/mediawiki/index.php/ENDF_reaction_MT%27s_and_macroscopic_reaction_numbers

[drewejohnson]

@vivian-salino I understand your retraction. I believe this is still a file we should support as there are many interested parties. But to your point, using detectors is a viable and likely better option than set cpd.