[Users] Uninitialised variables

[Ian Hinder]

On 6 Oct 2016, at 14:35, Roland Haas <rhaas at illinois.edu> wrote:

> Hello Ian,
> 
>> In this case, there is no final error message and abort, unlike in
>> the case of partially-read gridfunctions.  Is this a deliberate
>> decision,
> Yes, this is deliberate to allow thorns to be activated in ongoing
> simulations. There is a level 2 warning about the non-read in variables
> so it should not go unnoticed (in theory at least).
> 
>> because for partially-read gridfunctions the results are
>> definitely wrong, whereas not reading variables at all might be OK?
>> In my particular case, the variables are scalar integers.  What value
>> would the variables have in this case?  Does Carpet initialise
>> variables to 0?  I seem to see 0, but haven't checked carefully.
> They would be whatever Carpet or the memory allocator initialized them
> to. CCTK_Initial does not run (normally) during checkpoint recovery. You
> can have CCTK_Initial run *before* checkpoint recovery (with values in
> the recoverd variables overwritten by the recovered values) by setting
> Cactus::recovery_mode to "relaxed" (see flesh/src/param.ccl). This may
> be what you had in mind.

Aha, that's interesting.  Though I guess it would probably confuse a lot of thorns, so I'm not sure how useful it in in practice.  The initial data solver would run again, for example.  I would have expected Carpet to initialise variables to poison, so I should be seeing poison. What I am doing now is initialising the thorn in basegrid, and checking an "initialised" Cactus variable.  If this is 1, then I don't do anything.  If it's anything other than 1 (poison, zero, etc) then I assume the thorn has never been initialised.  This is probably not an approved, elegant solution, but I expect it will work.

--
Ian Hinder
http://members.aei.mpg.de/ianhin

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.einsteintoolkit.org/pipermail/users/attachments/20161006/25909569/attachment.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 204 bytes
Desc: Message signed with OpenPGP using GPGMail
Url : http://lists.einsteintoolkit.org/pipermail/users/attachments/20161006/25909569/attachment.bin