[Users] Possible performance issue with some codes

[Roland Haas]

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 262 bytes
Desc: OpenPGP digital signature
Url : http://lists.einsteintoolkit.org/pipermail/users/attachments/20110817/f26b3155/attachment.bin