Initial Implementation of IncidentProton

[SamPUG]

This issue is added in response to a requirement from @Shimwell and @ukaea.

Initial IncidentProton functionality has been requested so that proton data from ACE or ENDF libraries can be read and plotted.

I plan on implementing an initial IncidentProton class which reads only cross section data, ignoring any distribution data. This will include the implementation of the following methods:

• from_endf
• from_ace
• export_to_hdf5
• from_hdf5

Development of the IncidentProton class will be based on the existing data.IncidentPhoton and data.IncidentNeutron classes.

I also plan to make the necessary developments to plotter.py to allow the proton data to be plotted.

[paulromano]

Out of curiosity, what is the intended use of incident proton data?

[shimwell]

Out of curiosity, what is the intended use of incident proton data?

One of the reasons is that there are proton induced tritium producing reactions that might just help with a bit of tritium production for those spherical reactors with small breeder blankets. The ability of OpenMC to conveniently make materials and extract the material cross section is a useful feature for examining potential proton induced reactions and allows us to make use of a lot of existing infrastructure. Another reason is if OpenMC is going to consider supporting the transport of protons for machines with big magnets like accelerators (e.g. IFMIF which is a fusion materials testing accelerator) and perhaps edge cases in fusion magnet heating, then a good place to start is reading the cross section data. Perhaps a final reason is that it was seen as easy enough to implement with in the contract time frame and allows us to grow the community. Identify accessible tasks 1 year before they would be done that the existing community is not already considering is tricky and this was perhaps the worst task of all the 13. So in general the task all have a combination of: fusion relevance, unlikely to be done otherwise, easy enough to guarantee it can be done in the time frame, not so difficult that it deterred potential applications. I hope to be ambitious with the tasks in the future if there is a similar activity. In addition to the actual 13 tasks it is the positive experience of the process and contributors experience that helps us demonstrate the future applicability of this wonderful code for fusion with ability to implement features being something that OpenMC leads the market in 😀

[paulromano]

Well put; thanks @Shimwell!

[simondrichards]

Now it's my turn to be curious: Are there any plans for OpenMC to support transport of charged particles in magnetic fields?

[shimwell]

Now it's my turn to be curious: Are there any plans for OpenMC to support transport of charged particles in magnetic fields?

Looking forward to the answer for this one,

Just to add some additional speculating here, I guess most neutronics codes tend to expand with time (criticality then fixed source then multi particle). I am just guessing here but I guess OpenMC likes high quality PRs which add awesome well tested and documented features without having detrimental effects on the rest of the code. What do you think @py1sl @SAnsell @kbat @makeclean would you like to see protons in a modern, well tested, well documented opensource code?

[paulromano]

Oh, yes, there are absolutely plans. As soon as @Shimwell sends his millions across the pond, we'll have it done in no time :money_with_wings: :wink: In all seriousness, there are no plans in any of the projects that I am involved in currently. I think the easiest place to start would actually be electrons/positrons because we already partially handle them through a thick-target bremsstrahlung treatment in order to get photon production in coupled n-γ calculations right; they are just not transported (which would require a condensed history method). Once electron/positron transport is in, extending to protons should presumably be fairly straightforward (I think?). Also, I should say that these extensions would probably not involve transport in the presence of external electromagnetic fields. Including that opens another can of worms.

From your perspective (@Shimwell @makeclean @simondrichards whoever else wants to chime in), if there were support for charged particle transport in, let's say, static EM fields, how would you envision those fields being specified? Or another way of saying this would be -- in codes that do support such a thing, how are they represented? I'm assuming you would want/need something beyond just uniform unidirectional fields.

[makeclean]

For codes that support EM fields there are typically simple ways to define a global field constant field, however they usually then leave open a generic user function where one could determine the field by analytic equation, or some other function to read the field from file for example. One may choose to calculate the B field through an FEM package and then it would likely a be a an unstructured tet or hex mesh, then one would need to lookup the b field vector by a kd-tree or something like that. With structured meshes its obviously much easier since spatial lookup is much easier.

[paulromano]

@makeclean For your typical use cases, a constant field would not be adequate, correct? I'm just trying to ascertain whether implementing constant fields as a first step is useful, or if one might as well bite the bullet and include a way of having a spatial dependence to the field on the first shot. Of course, this is all hypothetical because no one has hard plans to do any of this!

[makeclean]

For normal use a uniform field is of no value, other than for validation, I would say the first shot should include non-uniformity.

---

From: Paul Romano notifications@github.com Sent: Thursday, March 12, 2020 3:22:03 PM To: openmc-dev/openmc openmc@noreply.github.com Cc: Davis, Andrew andrew.davis@ukaea.uk; Mention mention@noreply.github.com Subject: Re: [openmc-dev/openmc] Initial Implementation of IncidentProton (#1517)

@makecleanhttps://github.com/makeclean For your typical use cases, a constant field would not be adequate, correct? I'm just trying to ascertain whether implementing constant fields as a first step is useful, or if one might as well bite the bullet and include a way of having a spatial dependence to the field on the first shot. Of course, this is all hypothetical because no one has hard plans to do any of this!

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHubhttps://github.com/openmc-dev/openmc/issues/1517#issuecomment-598247916, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AASTUSSKSLKMC3I27WE5FLTRHD4ZXANCNFSM4LE44XGA.

[simondrichards]

Well that turned interesting :grin:!

My question was in response to @Shimwell's comment about "if OpenMC is going to consider supporting the transport of protons for machines with big magnets like accelerators (e.g. IFMIF which is a fusion materials testing accelerator) and perhaps edge cases in fusion magnet heating...". I was basically thinking "What... wait... are they really considering that?".

It's a long time since I actively worked in magnetic confinement fusion but I've got to agree that spatial non-uniformity and anisotropy would need to be considered early on for this to be useful for that community. I also agree that, whether or not electron/positron transport is any easier to handle than proton transport (I'm guessing it probably makes little difference) they would probably be the more useful thing to implement first for the majority of users.

It's ambitious, and probably hypothetical for now. But it's good to think about things like this, and I guess that if someone wants it enough they can crack on and do it!