Hello Jordan,
Sorry for the delayed response. This dropped off my radar after agreeing to try and respond during the last ET call.
I'm trying to extend our analysis thorn to tackle multipatch grids built with Llama. I want to use Coordinates::volume_form in the computation of volume integrals, by setting the corresponding parameter Coordinates::store_volume_form = yes.
Our standard use case relies on Coordinates::coordinate_system = "Thornburg04", for which it works like a charm. However, except for this system and the analogous Thornburg13 (I have not tested it so far), it seems the variable Coordinates::volume_form_state is not modified nor initialized, whatever the value of the parameter Coordinates::store_volume_form.
That would be a bug in the Llama coordinate systems. They should all at least set up the variable correctly. Would you mind filing a bug report using
https://bitbucket.org/einsteintoolkit/tickets/issues/new
That makes the parameter insufficient by itself to perform checks. Moreover, since the flag is not initialized, we also can't simply check its value, which can be polluted. I have tried to use Carpet::poison_new_timelevels = yes and CarpetLib::poison_new_memory = yes, but it didn't seem to solve the issue.
You can check if a variable has storage using the CCTK_VarDataPtr function call (https://einsteintoolkit.org/referencemanual/ReferenceManual.html#x1-217000do...) but it won't tell you if the values found in there are sensible (admittedly you could abuse poisoning or this).
Hence, I would like to ask if there's another way to check for uninitialized values, a safe way to use the variables I mentioned in a general case, or any information/subtlety I may have missed?
I think you captured the intended behaviour and the bugs present. Should be (one hopes) easy to fix at least in that all coordinate systems should indicate correctly if the volume form is set up or now.
Ultimately, I can directly check Coordinates::coordinate_system, and output a warning/error if it's not of the types mentioned above. That feels a bit unsatisfactory, although I may default to it.
Yes, looking at another thorns parameter is somewhat error prone, in particular if it is a parameter that is private and thus could change meaning at any moment.
Yours, Roland