On 6 Oct 2016, at 17:39, Roland Haas <[email protected]> wrote: > Hello Ian, > >> 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. > Correct. The current default is "safer" it seems. The "relaxed" setting > I have never seen used myself. > >> I would have >> expected Carpet to initialise variables to poison, so I should be >> seeing poison. > That is also what I would have expected. Have you set both > posion_new_memory and poison_new_timelevels turned on?
Hmm. I thought that I had, but now I see in my parameter file: Carpet::poison_new_timelevels = no Carpet::check_for_poison = no which is a bit surprising. This might come from the old issue of the intersection between outer boundaries and interpatch boundaries not being correctly initialised by the combination of Interpolate2 and McLachlan. Last time I checked though, this may have been fixed. If you don't use poison, does Carpet zero the variables, or leave them uninitialised? In which case, does the OS zero them? Presumably new memory from the OS is zeroed (for security/privacy reasons), but if the memory has been malloc/freed already by the cactus process, then maybe it is random. >> 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. > Well it's kind of what you have to do. You should be able to just > initialize in basegrid all the time, since the basegrid values will be > overwritten during checkpoint recovery as far as I remember. Aha! Interesting. Good. So I can just move the initialisation to basegrid and remove my 'initialised' flag. This way, the variables will be initialised, and then only overwritten from the checkpoint file if the thorn was active in the previous segment. Now, another related question. Is it possible to change the number of CarpetRegrid2 centres during evolution? The num_centres parameter is non-steerable, and indeed CarpetRegrid2 only looks at the centre parameters initially (otherwise every recovery would overwrite the dynamical centre variables with the parameter values). Ideally, I would have set num_centres to a larger value when I started the run, but I didn't. We just need to make sure that CarpetRegrid2 runs INIT_CENTRE (from initialise.cc) on any newly added centres on recovery. This is done in WRAGH, and then similar to the previous issue, overwritten by recovery. So this should just 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
