Pinning ionization energies to the particle species

[n01r]

Currently the ionization energies and related values are stored in ionizationEnergies.param and are still somewhat hard-coded and non-generic. To add an array of ionization energies for an additional species, one would just create one under a different name.

As this is information that is closely connected to the species anyway it should also be pinned to it and implemented generically.

[n01r]

Probably only the ionization energies should be pinned to the particles and the field strengths necessary in the BSI model should be calculated by the model itself from these very energies.

[bussmann]

Dear all,

We will have to devise a performant mechanism on accessing atomic data in general. Storing data per particle or even per species will quickly eat up all our memory. Better think of indexing a large data base.

Best, Michael

[psychocoderHPC]

@bussmann You are right storing data per particle is to expensive. @n01r means pinning a reference to data (no C++ reference) or a functor which describe how to get data on a species.

[n01r]

I'm feeling the need to express my concerns about ionization energies or atomic data in general again and I really don't like that there is still no self-consistent container for atomic data, yet. Currently I am encountering this problem in #922 again and there are several conventions in our code that make this matter challenging.

These are:

1. No explicit numbers in .unitless files are allowed - only unit conversion
2. No float_64 numbers (unless really necessary) are allowed on device side:
   so in principle normalizing to atomic units (which are absolutely the units I want to calculate ionization rates in) on device is also not very nice
3. .param files should contain SI units which should then be converted later

C++ restricts the use of constant vectors on GPU and even though PMACC_CONST_VECTORs provide a workaround I then cannot dynamically convert the entries of this vector to atomic units. If I do it by hand and define a new vector in .unitless I violate coding convention nr. 1 of the above mentioned. If I would want to do it on GPU I violate convention nr. 2 and I run into problems as soon as I want to do it for more than one species in the simulation because the ground state ionization energies are not identified unambiguously with the species they belong to. There are nasty workarounds but it always eats up a lot of time to redo it because we didn't decide on a consistent way to do this, before.

I can imagine an update to struct Hydrogen, like

in speciesDefinition.param

struct Hydrogen
{
    static const float_X numberOfProtons  = 1.0;
    static const float_X numberOfNeutrons = 0.0;

    /* ground state ionization potential(s) in SI units */
    struct IonizationPotentials;
};

in ionizationEnergies.param

namespace picongpu
{
namespace SI // ? ? ?
{
struct Hydrogen::IonizationPotentials
{
    PMACC_CONST_VECTOR(float_64, 1, IONIZATION_ENERGY,
    2.18e-18
    );
};

struct Carbon::IonizationPotentials
{
... // I need to name this one differently and give it 6 values
};
} // namespace SI
} // namespace picongpu

but how exactly (if at all) should that be embedded in the SI namespace when I declare Hydrogen[Carbon]::IonizationPotentials only in picongpu namespace?
Do I have a master thread on GPU use this to for-loop over the entries and write all of the values into __shared__ during every time step of the simulation and in every block?

What is the best way to do this? Or at least a better way before I devise a half-a**ed solution, again, that needs changing after a week, again.

I would really appreciate some detailed ideas here.
@psychocoderHPC , @ax3l , @Heikman

Does this new PMACC_STRUCT from #972 provide any solution, perhaps?

[ax3l]

to answer the core questions online, the rest offline (to save time):

C++ restricts the use of constant vectors on GPU and even though PMACC_CONST_VECTORs provide a workaround I then cannot dynamically convert the entries of this vector to atomic units.

If we do not have a way to simply multiply each entry of a PMACC_CONST_VECTOR with a value yet, then we will need that functionality. @psychocoderHPC can you help with that or is @n01r missing something? Sounds solvable to me.

If I do it by hand and define a new vector in .unitless I violate coding convention nr. 1 of the above mentioned.

No, you don't violate that. Simply name your conversion factors, see for example the way we convert ratios to BASE_CHARGE or keV input that we convert, one simply defines a constant conversion factor with a documentation (not a * 2.18e-18 which is a magic number for other readers). That's all.

If I would want to do it on GPU I violate convention nr. 2 and I run into problems as soon as I want to do it for more than one species in the simulation because the ground state ionization energies are not identified unambiguously with the species they belong to.

"Nr. 2": float_64 discouraged because it can be avoided and wastes a factor of 3x in speed. nevertheless, a first draft can always use it.
"more than one species": I don't understand the deeper implementation problem here, probably caused by something run-time-ish.

More reading: results of offline discussion

[bussmann]

We should discuss this offline next week. I think Marco's comments are important and we should have a consistent way to approach them.

[ax3l]

solved and documented in the PR.