Allow Beam models to take a list of allowed atomic processes

[cgwade]

When simulating beam emission and attenuation, cherab requires data specifying how the beam interacts with all the species in the plasma, and falls over when it can't find it. In some ways this is sensible - it removes the possibility of neglecting important interactions. However, I think it would be better to have explicit control of the interactions considered. This is especially important because some interactions don't make good physical sense. Eg, when the plasma contains neutral deuterium, cherab seeks a charge exchange coefficient between two neutral atoms. A quick fix is would be wrapping line 334 (ish) in "charge_exchange.pyx" and line 298 (ish) in "singleray.pyx" in try-except structures. This allows the code not to fall over when it can't find the data, but doesn't give explicit control.

[mattngc]

Hey Chris,

I think you should be able to solve this with the flags in the Atomic Data provider class. e.g.

atomic_data = OpenAdas(missing_rates_return_null=True)

The default design behaviour in CHERAB is that all physics assumptions should be explicit where possible. So in this case it should always try to find all rates for all processes unless you explicitly tell the code to skip them. Let me know if this doesn't fix it for you.

[CnlPepper]

I think we probably should filter out neutral-neutral interactions in the CX model. The null rates option will still be needed for other, valid combinations.

[Mateasek]

I think that filtering out neutral neutral interaction in general is not a good approach because you can still have stripping collision even between two neutrals. This is important in beam ducts for example where neutrals are the dominant species.

[mattngc]

Yeah, I agree with @Mateasek, there are some important neutral-neutral interactions that you may want to take into account in more general models. The general principle of CHERAB is to be as general as possible and then strip back to a more specific model through customisations. So OpenAdas(missing_rates_return_null=True) should be sufficient for this model.

@cgwade, can you confirm this fix worked for you?

[CnlPepper]

I was working under the assumption the neutral-neutral process wouldn't fit in the existing CX mathematical model. If that isn't the case, then indeed, I agree we shouldn't filter them out.

[mattngc]

Charge exchange is literally the exchange of an electron between two species, so it could happen between any species as long as one of them has an electron.

When beams pass through neutral gas it is possible for the beam neutrals to exchange an electron with the background neutrals, although I believe the cross section is low for the default observation lines. There may be some cases where you worry about the background emission in the duct, or want to model it. Or if you generalise away from fusion plasmas to generic beam - slab interactions such as in linear devices you may want it included. It is a legitimate physical process, just likely to be insignificant for CVI observations on typical fusion plasmas.

[Mateasek]

If it is just about the CX between neutrals of the same element, then maybe you can after all neglect it. What changes might the particles undergo in the collision? There might be cx to non-ground state, due to high energy of the neutral, which can lead to emission, but then how do you separate this event from the colisional excitation?

[mattngc]

ah yeah, I see what you mean. I'm being a bit dim. Indeed, on more reflection you could exclude the CX emission rate for neutral - neutral charge exchange. But you would definitely want to leave it there for all the others. In the case of beam attenuation, neutral - neutral interactions are extremely important. Martin O'M estimates this could be a 5-10% effect on MAST for example and might explain some discrepancies.

Looking back through the original question from @cwade, I think he is suggesting we make this a more explicit input to the class. It could default to all available rates, but it might be more convenient if users like @cgwade and @Mateasek could pass a dictionary or tuple of explicit processes to include in the calculation. This would be fairly easy to implement, I'll discuss it with @CnlPepper tomorrow.

[cgwade]

Thanks everyone for the discussion here. I've run out of time this week, but I will check if "OpenAdas(missing_rates_return_null=True)" stops the code falling over on Monday.

However, I would be in favour of a solution which allows the user to pass a list of processes that they want to consider (as @mattngc describes). That way you could answer questions such as "how much of the signal (or attenuation) comes from process A rather than process B" more cleanly.

[cgwade]

"OpenAdas(missing_rates_return_null=True)" worked as intended.

[mattngc]

Great, ok we will keep this issue open as its clear we need to add a new interface feature to the class. We will track the proposal here.