Hello Jordan,
I took a quick look and Llama's schedule.ccl runs Coordinates_SetInverseJacobian which sets volume_form_state and also volume_form but only based on the Jacobian so does not take the grid spacing into account or overlapping cells.
Thornburg04 then schedules its own routine afterwards which overwrites those results.
volume_form_state = store_volume_form [...] if (store_volume_form /= 0) then call calc_det3 (Jac, detJ)
! TODO: The volume form d^3x is defined as ! d^3x = da db dc * det(dx / da) * M, ! where M is the mask storing the nominal cell volume volume_form(i,j,k) = detJ end if
Yours, Roland
[CAUTION: Non-UBC Email]
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-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
-- 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 .