Hello all,
alright, here's my two cents.
On Thu, Aug 18, 2011 at 12:04:45AM +0200, Ian Hinder wrote:
For any code which does not use the ADMBase::[lapse/shift]evolution_method parameters to control their evolution, unnecessary syncs will be performed for the ADMBase variables. Whereas before these parameters seemed to be a superfluous part of the ADMBase infrastructure (after all, why activate your evolution thorn if you're not going to evolve with it?), it now seems that it is essential to extend and use these parameters if you want to use ADMBase, or performance will suffer. The GT evolution code would suffer from this, the last time I looked at it, and other groups' codes might also.
We were affected and have now extended the ADMBase parameters in Kranc2BSSN. We don't use these parameters at all in the code otherwise, they are just set to something other than "none" to make ADMBase happy. And yes, it was an annoying change that required sending out an email to each and every user informing them about the change (and we still have issues where we forget). As far as testing for these things in paramcheck goes: Kranc does not provide this functionality, so one would have to write a hackish XXXHelper thorn the way McLachlan does. One could of course use the evolution method to select eg. the shift evolution method (harmonic, gamma driver etc) but that would break all of our existing parameter files. Also some parameters are simply never used, since eg. we do not even support and a dtlapse evolution method (I think, Ian will actually know better).
I think that is not a lot to request -- ADMBase is the lingua franca that allows all Cactus relativity codes to interact, and it defines a certain standard that is documented, that was thought about hard, and was extensively discussed (publicly). It's not that difficult to use, and errors in a parameter file can be caught in a user thorn's paramcheck bin.
Precisely because ADMBase is used by everyone, it would have been nice if its public interface had not changed :-). Even if the old interface is now considered faulty in some situations.
Please note that I (personally) am not necessarily suggesting to revert the change. I just wish it had never happened :-) We'll likely patch our local codes to do the test Erik suggested in Paramcheck.
Frank's proposed solution of not syncing for the default values for all the evolution methods would seem the conservative choice to me. Then only the (minority?) of users who use Cowling approximation with Carpet and do not use eg Exact's pseudo-evolution have to change their parameter files (unless they already use "static" anyway).
Yours, Roland