[Users] Possible performance issue with some codes

[Erik Schnetter]

On Wed, Aug 17, 2011 at 10:09 PM, Frank Loeffler <knarf at cct.lsu.edu> wrote:
> Hi,
>
> 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.
>
> I didn't think of that, right. I see two possible solutions: either do
> use the ADMBase parameters in all evolution thorns (you don't really
> have to use them - extend the parameter and set it to that in the
> parameter file - I know, that's ugly but it works); or we provide these
> syncs in an extra thorn or via a new parameter within ADMBase. Both
> approaches are not ideal imho. The ideal would be if each evolution
> thorn would actually use these parameters, but that is arguably a lot to
> request.

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.

-erik

> Or, wouldn't the following work: evolution_method has 'none' and
> 'static' as meaning 'no evolution is done'. We could use 'none' for
> nothing at all is done and 'static' for real "static evolutions" with
> 'none' being the default. However, this would require 'none' being also
> provided for the other *_evolution_method parameters.
>
> Frank
>
>
> _______________________________________________
> Users mailing list
> Users at einsteintoolkit.org
> http://lists.einsteintoolkit.org/mailman/listinfo/users
>
>



-- 
Erik Schnetter <schnetter at cct.lsu.edu>   http://www.cct.lsu.edu/~eschnett/