Add scalar Function6D framework to Cherab

[Mateasek]

Is it worth adding Function6D into Cherab?

DistributionFunction.evaluate is close to what a Function6D.evaluate would look like in Raysect's function framework. Adding Function6D to Cherab would allow us to add an arbitrary DistributionFunction implementation initialised with Function6D and Function3D framework (generalisation of what is now partly done in Maxwellian). It would also move us closer to covering non-Maxwellian features in radiation.

I think that implementing it in Cherab would be a good choice, since 6D is too domain specific for Raysect.

I briefly looked into how function framework is implemented in Raysect and it seemed to me the whole procedure would be largely copy-paste job, although I could be mistaken.

I'm opening this issue to initiate some brainstorming and discussion whether it is worth it or not. I would definitely welcome comments from @jacklovell and @vsnever.

[jacklovell]

DistributionFunction is the only place I can think of where this would be useful. So I don't see the utility in having a separate Function6D class. How would you instantiate that any differently to instantiating a 6D distribution function?

Are there any examples of non-Maxwellian distribution functions which couldn't in principle be subclassed from the existing DistributionFunction class?

[jacklovell]

I guess maybe a Bi-Maxwellian distribution (probably the next most common use case) could be fairly easily accommodated by providing Distribution.__add__ to enable some rudimentary distribution composition. I don't think we need everything in the Function framework though: it makes no sense for example to divide one distribution by another.

[Mateasek]

I understand and I wanted to avoid making this issue as much as possible, since it is a lot of work to add Function6D, but I came to the conclusion that it is the cleanest way forward, if we want Cherab to include other than Maxwellian plasmas.

I think that adding any mathematical operations working with DistributionFunction is not the way forward here. If you look at the class, the methods are:
DistributionFunction:

• double evaluate
• Vector3D bulk_velocity
• double effective_temperature
• double density

You can probably come up with a way how to work with the density and evaluate methods when performing some mathematical operations (e.g. addition) but effective_temperature is defined only for a Maxwellian distribution. Also how would you robustly define bulk_velocity for a combined distribution? Last but not least, there should be way how to tell the current emission models (expecting a Maxwellian distribution) that the distribution function is non-Maxwellian and that they should not add any radiation, because they could produce wrong results. You would have to automatically set the methods to return 0. This step, I think, should be done explicitly when a DistributionFunction is instantiated and not during an operation on top of it.

If we implement the Function6D part of the framework, then we allow the users to build their six-dimensional distribution functions and then use these to build a DistributionFunction. This way you avoid all the problems I tried to line up above because you let the mathematical operations to be performed on Function6D where they are well defined. DistributionFunction can then be created with Function6D and work in a simmilar way as now Maxwellian does.

I agree that more complicated distribution functions will inevitably require users to fall back to implement their own functions in cython. Then you are right that the same procedure can be done with DistributionFunction. What can't be done in an efficient and simple way is combining different Function6D to build a DistributionFunction. Instead of a simple python code you would always have to implement it in cython. Another disadvantage is that not many users actually reach the level at which they can implement their own DistributionFunction. This will lead to piling up special implementations and thus will pile up code even in worse places than cherab.core.math.function.float.function6D.

[vsnever]

Thanks for raising this, @Mateasek.

In openadas.rates.beam.BeamCXPEC we have an example of constructing a higher-dimensional function from lower-dimensional functions. Given that DistributionFunction may have some symmetry that reduces its dimensionality, would it be sufficient to add only Function6D without having also Function5D and Function4D?

Is the analytical or semi-analytical method of building the distribution function useful for ECE, #471? If we have to rely on numerical data generated by other codes anyway, we could implement InterpolatedDistributionFunction which will interpolate given 6D data. But if the analytical method is really useful, e.g. the Maxwell distribution with some small analytically specified addition, then without extending the functional framework to higher dimensions, it will be hard to implement something like that.

[vsnever]

I guess maybe a Bi-Maxwellian distribution (probably the next most common use case) could be fairly easily accommodated by providing Distribution.add to enable some rudimentary distribution composition. I don't think we need everything in the Function framework though: it makes no sense for example to divide one distribution by another.

For this I would prefer a separate subclass.

[Mateasek]

Hi @vsnever ,

First I will try to answer your questions.

Given that DistributionFunction may have some symmetry that reduces its dimensionality, would it be sufficient to add only Function6D without having also Function5D and Function4D?

Yes, I have implementations of DistributionFuncion which is suited for #471, because it includes some runaway electron population. I exactly use semi-analytical approach to go from available information (isomaps, RE energy distribution, mapping, etc.) to get a DistributionFunction in 6D. Problem is that any time you want to try something different, you need to reimplement your DistributionFunction from scratch, because it is impossible to reuse code from other implementations. If there was Function6D, it should be possible to wrap individual building blocks of a DistributionFunction into Function6D and then combine them via the framework. This would in my opinion lead to less code pile up.

Is the analytical or semi-analytical method of building the distribution function useful for ECE, #471? If we have to rely on numerical data generated by other codes anyway, we could implement InterpolatedDistributionFunction which will interpolate given 6D data.

As I said above, the idea is to allow building of DistributionFunction with analytical, numerical approach and combination of both. For example, analytical expressions will give the possibility to use #471 for inversions of basic RE properties. Incorporating code outputs via interpolators will give the possibility to validate RE transport simulations and predictive simulations for diagnostics.

Now my opinion about adding a Bi-Maxwellian distribution.

For this I would prefer a separate subclass.

This is in my opinion a wrong approach. Adding a Bi-Maxwellian DistributionFunction means adding a class into framework which is actually very specific and has very low applicability. If we add Function6D into the framework, any simpler alternative of DistributionFunction can be realised with Function6D, Function3D and Vector3D functions, if we add a single class which is initialised in a simmilar way as Maxwellian is. Also, it will allow most of the users to experiment on their own without the need to touch cython code. This is advantageous even for more skilled users, for example during testing and allows more efficient development of features.

Looking at the DistributionFunction now, to me it actualy is a bit diconnected from the framework. Adding Function6D would help to close the gap.

[vsnever]

Thank you for the explanation, @Mateasek. Since the Function6D framework can already be used in #471 and, moreover, makes customization of DistributionFunction easier, I am in favour of adding it. I think having only scalar 6D functions should be enough, right?

[Mateasek]

I think having only scalar 6D functions should be enough, right?

Yes, I would like to add only scalar functions. I don't see any usage for 6D vector functions now. I will edit the issue title to make it clear. Thanks @vsnever.

[Mateasek]

closed with #478