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.