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