Sources are in SI, but initial conditions are normalised

[mikekryjak]

BOUT++ needs the function field in the input file normalised. This is what sets the initial condition for variables. However, to make it easier on the user, in Hermes-3 we made sure that the source field in the input file is in SI units.

This is confusing, and we should discuss ways to make it less confusing. I've gotten used to it and don't think about it anymore but every now and again a new user encounters this gotcha!

The ideal way would be to make function in SI units, but I'm not sure how feasible that is - @ZedThree, what do you think?

[ZedThree]

We've sort of run into similar issues with the coordinate variables x, y, z in the input files being in some fixed coordinate system, and not necessarily the normalised coordinates used elsewhere.

It's absolutely a good idea to reduce gotchas!

I'm not sure of the best design, I can think of a few different ways of doing it:

1. Just make it SI -- "easiest" but perhaps more likely to break things? Certainly introduces some backwards compatibility fun
2. A separate input like function_SI -- less ergonomic, involves some machinery to check which has been set, etc
3. A separate switch like inputs_SI or inputs_normed -- somewhat ergonomic? Some arguments about "spooky action at a distance"
4. Introduce unit parsing like 4 eV -- most ergonomic? Way more machinery involved, significant amount of work!

[mikekryjak]

I guess ideally BOUT++ wouldn't need to touch any units. Hermes-3 already has metadata with the correct normalisation factor and even a string to tell you what the SI units are, so ideally we would somehow intercept whatever is parsed from function before it gets passed to BOUT++. I don't think there is any need for unit parsing.

I like the idea about a separate input, because it raises the opportunity to rename it something that is actually intuitive, e.g. initial_condition.