On Wed, Aug 17, 2011 at 10:09 PM, Frank Loeffler knarf@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@einsteintoolkit.org http://lists.einsteintoolkit.org/mailman/listinfo/users