Interface for external beam definition

[mnurgaliev]

Dear Cherab team!

I would like to use Cherab framework for synthetic CXRS and BES diagnostics development. Initially, I planned to use the FIDASIM code to calculate the beam penetration into plasma but I did not find the solution for the setting up beam density externally. For the start I can use the SingleRayAttenuator() but in perspective it would be great to have distribution of excited beam states, fast ion, and halo atoms, which are calculated in FIDASIM. What is the best way to make some sort of interface between FIDASIM output files (HDF5 format, [x,y,z] grid) and Cherab?

Thanks, Maxim Nurgaliev

[Mateasek]

Hi @mnurgaliev,

I would like to expand the beam models in near future and adding the possibility to add the beam distributions from external sources is on the list. I hope I can get to it in next few months. The fast ions and beam halo distributions are probably better to be defined through plasma species I would say. Cherab can support arbitrary 6D distributions, not only Maxwellian, so it can cover fast particles.

[mnurgaliev]

Hi @Mateasek!

Thank you for the answer. Hope to see this feature soon. I agree about fast ions and beam halo, they can be defined through plasma species.

[Mateasek]

I'm coming back to this issue, because it rose in other discussions. I think that to allow the external sources of beam properties, a rewrite of the beam architecture is needed, which might lead to backwards incompatibility.

The limiting factor now is I think the entanglement of the Beam class with the BeamAttenuator class and the _generate_geometry method. I would like to change the architecture to make it closer to how the Thomson Scattering laser description now works.

The changes I propose are:

• Separation of the Beam class from any relation to spatial properties of the beam
• Creating a new class BeamProfile, which would take care of all the beam related properties as energy, density etc.
• BeamProfile would use DistributionFunction to describe the beam distribution in 6D
• BeamProfile would specify the beam primitives, based on its actual shape (which allows better encapsulation of the beam)

The impacts I see are

advantages:

• It will in my opinion offer a much simpler way to creating new beam models both general and ones tailored to specific usage, it will also allow to expand the possible levels of detail of beam description and emission models.
• It will be much simpler to get a new beam model in Cherab, for example MultiRayAttenuator.
• It will be possible to use external definition, because users would have to deal only with the proposed BeamProfile class.
• Using DistributionFunction would allow BeamModel to have different level of accuracy based on how they would treat the energy distribution of the beam, e.g. A crude model assuming narrow beam spectrum and working only with DistributionFunction.bulk_velocity.
• Defining new simpler DistributionFunction could be also achieved through ScalarFunction3D and VectorFunction3D, which would simplify the procedure and give way to a broader range of experimentation with beam profiles.

disadvantages

• I think we won't be able to maintain backwards compatibility if we want to apply the proposed changes properly
• We would need to rewrite the current SingleRayAttenuator and move it into BeamProfile and convert it to DistributionFunction
• We would have to apply necessary changes to the beam models (CXRS, BES)

I personally think that this is a good step, the current stat of the beam does not offer much versatility, but I would like to hear the opinion of the rest of the TMC members (@jacklovell , @vsnever , @CnlPepper @mattngc )

[vsnever]

Thanks for sharing your ideas, @Mateasek, I like the new architecture.

Regarding backwards compatibility, can we use the __future__/__past__ approach following the PEP497? Before the Cherab 2.0, anything that breaks backward compatibility is imported from cherab.__future__ and starting with Cherab 2.0, the deprecated features go to cherab.__past__.

[Mateasek]

It would be nice to hear opinion of @CnlPepper and @jacklovell about the __future__ / __past__ idea. I like the idea of users being able to adjust their codes with __future__ before the breaking change is applied.

[jacklovell]

PEP497 was rejected, so I don't think we should be following this route. I think if the benefits of the change are significant enough then it may be worth breaking backwards compatibility at a major version change. The impact can be mitigated by providing a migration guide, either in the documentation with an accompanying demo or though a wrapper function if feasible.

On the subject of __future__, we do have a Cherab-experimental sub-module for unstable implementations which are not yet ready for integration into the core module: this new beam model could live in that sub package and be available as an alternative import until its API is stable and we've investigated how to minimise the degree of breakage.

[Mateasek]

The new beam architecture will be added as particle_beam which will allow its existence alongside the currently used beam

The deprecation warnings will be added to beam and it will be removed when we switch major version.