How does ARMI couple software to realize data transfer

[Scienkiller]

Hello, I am very glad to meet you, and ARMI is a very interesting thing. These days of study has given me a general understanding of the functions and usage of ARMI, but there are still many unclear points about the software coupling. If possible, can you explain to me the operation steps of ARMI in software coupling, it is best to have an example combined with explanation. Thank you very much for your contribution in the nuclear industry, and I am honored to have the opportunity to communicate with you.

[ntouran]

Hi thanks for the question. ARMI facilitates software coupling using the hub-and-spoke data architecture. In other words, by writing interface code that maps to/from each individual physics/analysis code to a common data model on the ARMI reactor model, you only need to have N interface codes to couple N codes all with each other. This is a big improvement over writing N² coupling interfaces.

So like if you have 10 codes that compute fission power you can write 10 interfaces that load their results onto the ARMI reactor model in the power data parameter. Then if you have 2 thermal/hydraulic codes that take power and compute temperature. From the T/H codes' perspectives, they don't know where the power came from. So you can do sensitivity analysis or code-to-code benchmarking or data sharing or whatever now using all those tools.

That's the basic idea at least.

[Scienkiller]

Thank you very much for your answers, but I have another question. I saw in the ARMI manual that ARMI has a standardized interface. So, where is the standardized interface? What is the role of the cccc agreement?

[jakehader]

The CCCC interface files are generally produced by reactor physics codes and are helpful for communicating data between codes. The ARMI data model has the nuclearDataIO package that includes several Python modules to read this data into memory. Once the data is read into memory you can apply that data to the ARMI data model or do other types of calculations with it.

For example, say you have an RTFLUX file that came out of a code like DIF3D which specifies the scalar flux. There may be other codes that can pick up this file directly but other codes may not. Instead of passing the RTFLUX file around as the "interface file" for scalar flux there may be value in applying that data to the ARMI data model. Doing this will allow you to track scalar flux in many different core configurations or at different points in time without having to carry around multiple RTFLUX files. Additionally, once the data is stored on the data model it is much more convenient to access than in the original RTFLUX file format.

If you haven't already, I recommend looking through the ARMI documentation and going through the tutorials. We also have a few examples in the "gallery" section that may help give you some more ideas of how the framework can be used. Also, we have 2 more advanced examples available for how to make your own plugins:

• https://github.com/terrapower/dragon-armi-plugin
• https://github.com/terrapower/armicontrib-dif3d

[Scienkiller]

Thank you very much for your answers, it will be a very interesting and meaningful thing.

[jakehader]

@Scienkiller let us know if you're having any specific issues or points of confusion and we can help further.