Writing x y z grids?

[mrhardman]

I am looking at making a manufactured solutions test in a geometry where is is more convenient to work directly with some x y z coordinates and metric coefficients that are specified from the BOUT.inp file. The output netcdf file from BOUT does not appear to write the x y z grids out, but instead only writes dx dy dz. Is there a fundamental reason for this? Could the grids be added to the output?

[dschwoerer]

x, y and z as you can use them in an expression?
That is probably not that exciting for most uses, beyond MMS. And even for MMS that may not be what you want.

It could certainly be added, but I would not see to point. I would even be in favor of removing dx etc, as they are constants (for FCI) or are anyway in the grid.

If you want x etc, you can just generate such a field yourself and add it to your dump file, if that is useful for you.

[mrhardman]

Yes, I want to have x, y, z available without having to reconstruct them. In the case that I want to work with, the metric and grids are specified simply from the BOUT.inp file, there is no grid file. From my point of view, it would be better to have all information used by BOUT to be written out to reduce chances of error on the user side.

I can always try to work out how to dump x, y, z myself in my main.cxx, but I wondered why it wasn't written anyway.

@mikekryjak @johnomotani FYI in case you have an opinion on this topic.

[mikekryjak]

I guess it boils down to what balance you want to strike between ease of post-processing / minimising mistakes and keeping the output files slim. I guess I am always going to be strongly biased towards the former, because A) I am used to CFD software which does this, B) I haven't lived through the pain of 3D turbulence modelling, and C) I have spent endless weeks getting confused with things like normalisation and reconstructing things in post-processing. This includes the grid reconstruction stuff which is simple in principle but has a few gotchas that make mistakes easy.... it has cost me probably over two weeks of wasted time in total across SD1D and Hermes-3 1D and 2D.

In Hermes-3 we do have the radial, poloidal and toroidal lengths calculated in post-processing and the user doesn't have to do any further reconstruction apart from calculating the parallel connection length, so in principle we are not in a bad place. I am close to having all of the relevant lengths/etc calculated in xHermes.

Now when it comes to what's available in the code, not having lengths is a problem for 1D where it is convenient to supply profiles of magnetic field or sources as a function of Lpar. We have a PR that resolves this by doing the Lpar reconstruction within the code and adding it to the state for this purpose: bendudson/hermes-3#232