Flag for proton and neutron number

[n01r]

Here is another topic concerning multiple species and ionization.
This PR adds a _flag for proton and neutron number_ of the ion species.

In detail:

• flags protonNumber and neutronNumber
• flag atomicNumbers
• traits GetProtonNumber and GetNeutronNumber
• trait GetAtomicNumbers
  (this contains a static_assert which is thrown if someone tries to get these numbers from, say, electrons)
• ionization algorithm has been edited to ionize until chargeState = protonNumber
• ionization is now always active if ions are enabled (deactivate by deleting the flags)

### The last commit has not been runtime-tested due to the current maintenance
(everything until Make proton/neutronNumber a float is safe)

[n01r]

Happy dismembering 🔪
😁

[ax3l]

very attractive, I'll have a look 👍

[ax3l]

@see ... at the next line pls

[ax3l]

I like it already very much.

the mass/charge refactoring might be a good idea for a follow-up pull request.

[psychocoderHPC]

Is there any future case were we can have only NumberOfProtons or NumberOfNeutrons?
If not and every time both numbers must be set than it might be better to join both flags to one.

e.g.

alias coreElements;

struct Helium
{
  static const float_X protons = 2.0;
  static const float_x neutrons = 2.0;
};

//add  `coreElements` to the flag list
bmpl::vector<
  coreElements<Helium>,
  ionizer<particles::ionization::BSI<PIC_Electrons> >
> ParticleFlagsIons;

[ax3l]

absolutely, that's what I thought, too.
that's why I mentioned the same for charge and mass.

since they are const, setting neutr/prot. to zero is also still an
option. (e.g. for protons or pure neutrons)

Axel

[ax3l]

I would actually even shuffle it more up and add charge / mass directly.

The only thing we have to think about: how to put them transparently, that species 1 can have "protons" fixed but species2 uses "protons", cloned from species 1, as a non-const attribute?

[n01r]

👍
With a big-ass lookup table one would just give the identifier of the element to the flag list of the species and by bmpl::deselect<vector...< > > one could specify which attributes not to take as const from the table.
The user would just take the basic data of everything from the table ... or set it manually.

[ax3l]

yes, basically the deselect must be able to work for const -> non-const attributes.

the "element" name was just given as an example, I think our users should be able to read periodic tables to set helium1 and helium2 in there simulation (or something totally different) :) of course, we can write a nice list of examples in our wiki or elsewhere, too :)

[ax3l]

just to clearify: "coreElements" is not an ideal name. we should just provide an environment to build what every type of particle/atom a user wants. the user should be able to call it however they like (e.g., they shall be able to create a neutron species, a tripple proton-no neutron atom and neutrinos).

[psychocoderHPC]

coreElements is only a example. But we need a fixed name that all algorithms can access this flags to calculate mass and/or charge.
coreElements is only an alias like pusher,ionizer,... and must defined in speciesAttributes.param. It can not changed by the user and must well named by the developer of PIConGPU.

[ax3l]

yep agreed. in that case atomicNumbers would be a good wrapper name.

[psychocoderHPC]

For charge and mass it is not so easy than for proton numbers. Both are in SI unit and must transformed to pic units :-( We should wait that we can use C++11.

[ax3l]

Ah true, too bad.

[n01r]

Again, it compiles but who knows if it runs 😛

[psychocoderHPC]

Is ionization always enabled in the laser wake field example?

[n01r]

Yeah, @ax3l told me to remove the pragma before

[ax3l]

did I? o.0

[n01r]

n01r#6 (comment)

[n01r]

If someone does not want ionization, they can just remove the ionizer flag. But I don't know if this is too inconvenient right now for the current state of ionization.

[ax3l]

yes, what I meant with that was: we do not need a "general" ENABLE_IONIZATION flag since we will just add something like ionizer<particles::ionization::BSI<PIC_Electrons> > (as it is now).

therefore you just need a PARAM_IONIZATION in the single example that is modified to enable/disable the test.

in short: there should be a PARAM_IONIZATION used in examples/LaserWakefield/include/simulation_defines/param/speciesDefinition.param but none in the other files. also, please use the #if(defined ...) statements I showed you earlier.

[n01r]

Ah, I just still had that in mind somehow and didn't look at the file path. My bad .

[ax3l]

great! just remove the last line pls :)

[n01r]

why ENABLE_IONS but no ENABLE_IONIZATION ? don't see the difference

[ax3l]

As already explained, enable_ macros are default controlers and always required. Param_ macros are example-specific.

[ax3l]

ok :)
now where we got all that, just squash that all in a slick commit pls, it's not such a big change set :)

very nice change set :)

[n01r]

Run test also successful 🎐

[n01r]

Oh ... whoops, I just noticed, you meant one commit, @ax3l .
I made three. Still okay?

[ax3l]

still ok, thank you!

[ax3l]

great and slick pull request 👍