[Carpet] cost of repeated calls on CCTK_SyncGroup()

[Bela Szilagyi]

> You can always call CCTK_SyncGroup instead of synchronising with the
> scheduler.  However, this does not make things more efficient.

Yes, I am well aware of this.

>> Given that (as directed by MoL) some of
>> the sync calls prefer no prolongation, the question comes whether this
>> collective syncing function honors the prolongation switch or not.  
>> No major issue here, but perhaps a gain on the syncronization itself.

> I don't know what you mean by "prefer no prolongation".  It is always
> correct to prolongate, it is only an optimisation to not prolongate
> if it is not necessary.  It is in general difficult to know whether
> this optimisation leads to correct results.

What I am referring to is the use of EnableProlongating() from within MoL.

> Yes, the collective syncing function CCTK_SyncGroupsI honours the
> prolongation switch.  All synchronisation functions do.


From what I understand

Carpet::SyncProlongateGroups (const cGH* cctkGH, const vector<int>& groups)

will not be reached from CCTK_Sync* calls.

If so, then can we 

1) modify the flesh CCTK_SyncGroupsI  function to call 
Carpet::SyncProlongateGroups  once rather than calling Carpet::SyncGroup a 
nubmer of times, in case multiple groups are lined up for syncronization

and/or

2) provide a simple (aliased function) interface to 
Carpet::SyncProlongateGroups.

I would expect that 2) is quicker, though 1) is preferred.  I guess "best" 
would be both.

Bela.


-- 
Bela Szilagyi

Max-Planck-Institut für Gravitationsphysik
Albert-Einstein-Institut
Tel: +49 331 567 7632
Fax: +49 331 567 7649