On 6 Oct 2016, at 14:35, Roland Haas <[email protected]> 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
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ Users mailing list [email protected] http://lists.einsteintoolkit.org/mailman/listinfo/users
