Hi Roland,


Thank you very much for your message! I had seen the shorter version of your reply in the minutes indeed, but thank you for giving a more detailed answer!


When I come back from the holiday season, I will gladly file the bug report. I would also say that this should be straightforward to fix, at least about initializing the variable to 0 by default. 


The consistency between setting the parameter Coordinates::store_volume_form=yes and having the code still set Coordinates::volume_form_state = 0 depending on the actual implementation of the volume form -- if it's even needed -- might be a different question though. For instance, I think that technically the system Thornburg04nc should have the volume form computed, but it doesn't. I suppose that the consistency could be handled at ParamCheck for example. Please tell me if that would require another subsequent bug report or not.

I would say that this renders the usage of CCTK_VarDataPtr on Coordinates::volume_form still insufficient because its storage relies on the parameter value, although I get your point about abusing poisoning there. However (from the top of my head), I remember that when I used poisoning with Llama (and MLBSSN), the norm2 of the Hamiltonian constraint was NaN, so I had to turn it off.


Let me know if you'd like me to help on the implementation. I'm not sure about how the process goes and what is the corresponding involvement, so I don't want to make promises, but I'd happy to contribute to these (hopefully easy) fixes, if it saves you more time than it wastes.


Best wishes for the holiday season!


Jordan



From: Roland Haas <rhaas@mail.ubc.ca>
Sent: Wednesday, December 17, 2025 6:04:41 PM
To: Jordan Nicoules
Cc: users@einsteintoolkit.org
Subject: Re: [Users] Safe check of variable Coordinates::volume_form_state
 

CUIDADO: Email de um sistema externo. Cuidado com links, anexos e pedidos de dados/senhas.
CAUTION: Email from an external system. Be careful with links, attachments, and requests for data/passwords.

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-217000doc)
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

--
My email is as private as my paper mail. I therefore support encrypting
and signing email messages. Get my PGP key from http://pgp.mit.edu .