[Users] Possible performance issue with some codes

[Erik Schnetter]

On Thu, Aug 18, 2011 at 10:52 AM, Ian Hinder <ian.hinder at aei.mpg.de> wrote:
>
> 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.

ADMBase copies the previous timelevels of its variables to the current
timelevel. This is (if MoL is used) repeated by MoL. This is a very
fast operation, so it won't cause performance problems.

>> 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.

If this is possible -- yes, definitely. Maybe scheduling in postregrid
and postregridinitial would do this? However, the boundary conditions
also need to be applied in postrestrict and postrestrictinitial, if
the ADMBase variables are restricted (which may or may not make
sense). And if the boundary conditions (including synchronisation) are
ever applied, they should also be applied in postinitial, so that they
are consistent right from the beginning (and don't change after the
first regridding).

-erik

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