[Carpet] cost of repeated calls on CCTK_SyncGroup()

[Bela Szilagyi]

The original issue of syncronzing with or without prolongation is now off the 
table.  Esentially I've got my excision thorn work using MPI calls (e.g, get 
all data onto a work CPU, excise, apply the result).

However, during the "seek for solution" Jonathan got across this routine of 
yours, and the idea came that one could reduce the evolution algorithm's 
syncronization expense by calling your routine directly rather than placing 
"SYNC" lines into the schedule.ccl .  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.

Bela.

On Wednesday 28 June 2006 07:48, Erik Schnetter wrote:
> Béla,
>
> the flesh has a function CCTK_SyncGroupsI, which allows you to
> synchronise several groups at once.  (Whether this is implemented
> efficiently by the flesh or by Carpet is another question, the answer
> being no.)  But wasn't the original motivation to be able to
> synchronise without having to prolongate the boundaries?  Is the
> existing functionality with EnableProlongating and QueryProlongating
> good enough for you?
>
> -erik

-- 
Bela Szilagyi

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