[Users] Possible performance issue with some codes

[Ian Hinder]

On 18 Aug 2011, at 15:44, Erik Schnetter wrote:

> On Wed, Aug 17, 2011 at 11:30 PM, Roland Haas
> <roland.haas at physics.gatech.edu> wrote:
> 
>> 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.
> 
> It didn't change... You were performing unnecessary work all along
> because both ADMBase and your code evolved the ADMBase variables.
> Since ADMBase came first, your code overwrote this, so no one was
> hurt; and since ADMBase didn't perform any expensive operations, you
> didn't notice.

I don't think ADMBase did any actual "work", it was notionally responsible for evolving its variables, but in practice it did nothing, didn't it?
Nothing that the evolution code did was actually being repeated by ADMBase.  

> We are discussing here whether to keep a known bug in ADMBase's
> default parameter settings to help people save time improving
> performance of private codes that don't follow the ADMBase standard.

We are wanting to keep the current behaviour because peoples' private codes assumed things about the way that ADMBase worked for simplicity which were not in accordance with the ADMBase documentation.  For reference, the information we have about ADMBase is in http://cactuscode.org/documentation/thorns/CactusEinstein-ADMBase.pdf and https://docs.einsteintoolkit.org/et-docs/Einstein_Toolkit_standards (the former should be considered authoritative).  

> ADMBase is a really basic, really important thorn for many people, and
> it needs to be correct and not surprise first-time users. Changing its
> interface requires much thinking, including about users who are not
> vocal on these mailing lists.

I'm not sure I fully understand the change that was made.  For the case in question, when evolution_method = "static", ADMBase now synchronises all the ADMBase variables on every iteration.  From the comment in the schedule.ccl file, it sounds like this synchronisation only needs to happen in certain situations, such as when a new refined grid appears.  Wouldn't it be better, even in the case of the Cowling approximation, for these synchronisations to be performed only in those cases, and not on every iteration?  This would have the side effect that existing, working, tested, non-conforming codes don't have such a performance hit.

-- 
Ian Hinder
ian.hinder at aei.mpg.de