<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
<style type="text/css" style="display:none;"><!-- P {margin-top:0;margin-bottom:0;} --></style>
</head>
<body dir="ltr">
<div id="divtagdefaultwrapper" style="font-size:12pt;color:#000000;font-family:Calibri,Helvetica,sans-serif;" dir="ltr">
<div dir="ltr">
<div id="x_divtagdefaultwrapper" dir="ltr" style="font-size: 12pt; color: rgb(0, 0, 0); font-family: Calibri, Helvetica, sans-serif, "EmojiFont", "Apple Color Emoji", "Segoe UI Emoji", NotoColorEmoji, "Segoe UI Symbol", "Android Emoji", EmojiSymbols;">
<p>Hi Roland,</p>
<p><br>
</p>
<p>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!</p>
<p><br>
</p>
<p>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. </p>
<p><br>
</p>
<p>The consistency between setting the parameter <i>Coordinates::store_volume_form=yes</i> and having the code still set
<i>Coordinates::volume_form_state</i><i> </i><i>= 0</i> 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.</p>
<p>I would say that this renders the usage of CCTK_VarDataPtr on <i>Coordinates::volume_form </i>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.</p>
<p><br>
</p>
<p>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.</p>
<p><br>
</p>
<p>Best wishes for the holiday season!</p>
<p><br>
</p>
<p>Jordan</p>
<p><br>
</p>
<p><br>
</p>
</div>
<hr tabindex="-1" style="display:inline-block; width:98%">
<div id="x_divRplyFwdMsg" dir="ltr"><font face="Calibri, sans-serif" color="#000000" style="font-size:11pt"><b>From:</b> Roland Haas <rhaas@mail.ubc.ca><br>
<b>Sent:</b> Wednesday, December 17, 2025 6:04:41 PM<br>
<b>To:</b> Jordan Nicoules<br>
<b>Cc:</b> users@einsteintoolkit.org<br>
<b>Subject:</b> Re: [Users] Safe check of variable Coordinates::volume_form_state</font>
<div> </div>
</div>
</div>
<font size="2"><span style="font-size:10pt">
<div class="PlainText"><br>
CUIDADO: Email de um sistema externo. Cuidado com links, anexos e pedidos de dados/senhas.<br>
CAUTION: Email from an external system. Be careful with links, attachments, and requests for data/passwords.<br>
<br>
Hello Jordan,<br>
<br>
Sorry for the delayed response. This dropped off my radar after<br>
agreeing to try and respond during the last ET call.<br>
<br>
> I'm trying to extend our analysis thorn to tackle multipatch grids<br>
> built with Llama. I want to use Coordinates::volume_form in the<br>
> computation of volume integrals, by setting the corresponding<br>
> parameter Coordinates::store_volume_form = yes.<br>
><br>
><br>
> Our standard use case relies on Coordinates::coordinate_system =<br>
> "Thornburg04", for which it works like a charm. However, except for<br>
> this system and the analogous Thornburg13 (I have not tested it so<br>
> far), it seems the variable Coordinates::volume_form_state is not<br>
> modified nor initialized, whatever the value of the parameter<br>
> Coordinates::store_volume_form.<br>
<br>
That would be a bug in the Llama coordinate systems. They should all at<br>
least set up the variable correctly. Would you mind filing a bug report<br>
using<br>
<br>
<a href="https://bitbucket.org/einsteintoolkit/tickets/issues/new">https://bitbucket.org/einsteintoolkit/tickets/issues/new</a><br>
<br>
> That makes the parameter insufficient<br>
> by itself to perform checks. Moreover, since the flag is not<br>
> initialized, we also can't simply check its value, which can be<br>
> polluted. I have tried to use Carpet::poison_new_timelevels = yes and<br>
> CarpetLib::poison_new_memory = yes, but it didn't seem to solve the<br>
> issue.<br>
<br>
You can check if a variable has storage using the CCTK_VarDataPtr<br>
function call<br>
(<a href="https://einsteintoolkit.org/referencemanual/ReferenceManual.html#x1-217000doc">https://einsteintoolkit.org/referencemanual/ReferenceManual.html#x1-217000doc</a>)<br>
but it won't tell you if the values found in there are sensible<br>
(admittedly you could abuse poisoning or this).<br>
<br>
> Hence, I would like to ask if there's another way to check for<br>
> uninitialized values, a safe way to use the variables I mentioned in<br>
> a general case, or any information/subtlety I may have missed?<br>
<br>
I think you captured the intended behaviour and the bugs present.<br>
Should be (one hopes) easy to fix at least in that all coordinate<br>
systems should indicate correctly if the volume form is set up or now.<br>
<br>
> Ultimately, I can directly check Coordinates::coordinate_system, and<br>
> output a warning/error if it's not of the types mentioned above. That<br>
> feels a bit unsatisfactory, although I may default to it.<br>
<br>
Yes, looking at another thorns parameter is somewhat error prone, in<br>
particular if it is a parameter that is private and thus could change<br>
meaning at any moment.<br>
<br>
Yours,<br>
Roland<br>
<br>
--<br>
My email is as private as my paper mail. I therefore support encrypting<br>
and signing email messages. Get my PGP key from <a href="http://pgp.mit.edu">http://pgp.mit.edu</a> .<br>
</div>
</span></font></div>
</body>
</html>