Integration of nuclear networks

[jolatechno]

Added the Nuclear Network submodule:

• Made sure that it would be included in the Cmake build process.
• Made sure that SPH-EXA would still compile without the nuclear network submodule.
• Started adding the nuclear data container to simulation data.
• Some boiler plate nuclear propagator and nuclear energy observable.

[jolatechno]

Edit: my bad about the formating, I didn't know what the right clang formating was.

[sekelle]

I don't think we need to bother with a regular grid init for the SPH part when using nnet. This option is only there to run a minimal example if HDF5 is absent for some reason. This is never useful for more elaborate workload, such as when using nnet.

[jolatechno]

Ok I will remove the grid propagator then.

[sekelle]

This is still pending.

[jolatechno]

When I remove the grid propagator I always get an error, do you mean that the glass propagator is not needed ? I don't properly understand the difference between the grid and glass propagators.

[sekelle]

Don't you want to register the new nuclear_observable in the factor in this file?

[jolatechno]

There is no real nuclear test case so I don't know where to reference nuclear_observable in the factory, but it will be done in the future. I don't think IO is the first thing to do in the integration.

[sekelle]

As a general remark, I would not put the NuclearData class inside the nnet submodule. Instead, in physics/nnet you could have two folders, one for the submodule, and another one for the interfaces to the submodule. NuclearData is, effectively, one of those interfaces, as it is modeled according to the requirements of the SPH-EXA application front-end and has header dependencies on the Cornerstone library.

If you have a choice, I would not introduce this dependency on Cornerstone into your nnet code. As an example, you can look at the gravity solver Ryoanji. We don't pass ParticlesData, or any Octree class from Cornerstone to Ryoanji. Instead, we pass the coordinate fields, masses and the tree as elementary arrays of floating point or integer types. This allows as to swap it out for something else if we need to, as long as the storage format stays the same. And we enable somebody else to call Ryoanji
who might not be using ParticlesData or Cornerstone to build octrees.

Another analogy could be BLAS matrix-matrix multiplication (dgemm). Rather than a custom matrix class, the interface accepts floating point arrays in a specific format: column or row major.

[sekelle]

I've updated this branch to include the latest version in the develop branch and updated the submodule version of the SPH-EXA-nnet repository.

The main problem is still that all of the nuclear-network code is included via headers into the compilation unit of the SPH-EXA main function. At the level of the propagator, the call to sphnnet::computeNuclearReactions should be made through a library interface.