Feature idea: read csv files in input file

[mikekryjak]

While our analytical expression driven input file is quite flexible, it has several limitations, for example:

• It is not possible to separate the PFR and core regions. So if you want to set an anomalous diffusion coefficient profile with a transport barrier within the separatrix but fast transport outside (very common in 2D runs), or even if you want to set a core source, then you need to put the field in the grid file which is awkward. It's also very prone to user error - need to write the fields in a particular way and you end up with lots of grid files with different field variations, but which may or may not have the same grid... it would be very useful to have more separation of concern here, this has tripped me up many times.
• Doing the above for 1D models is even more awkward as the grid file is usually defined in the input file itself, so you would need to create a grid file to store any additional fields. But once again, you would need to mix "constant" parameters like a flux expansion profile and "changeable" parameters such as a power source history.
• Analytical functions are not always ideal for capturing the evolution of a variable. For example, a series of linear ramps / holds in a power source would require a complex expression with lots of Heaviside functions. There will be other instances where it is much more practical to describe the evolution using Python instead.

I propose that we implement a feature to read 1D and Field2D profiles from a csv file. Just implementing the 1D part would be very helpful to start with.

[dschwoerer]

Would it not be much easier to use a netcdf file? I have made bad experience with reading text data for 3D, and this feature would also be useful for 3D slab simulations, where the grid is defined in the input file, but you want to add e.g. some filament perturbation.

I think that would allow reusing the file-io we have already, and just add a new wrapper for opening/closing ...

[mikekryjak]

@dschwoerer sure, why not. It still means people have to fiddle with data types and could make mistakes, but we could document that better in Hermes-3 / BOUT++ and/or write a wrapper for it in xHermes or xBOUT.