[Carpet] sync vs sync+restrict

Erik Schnetter schnetter at cct.lsu.edu
Thu May 4 17:55:19 CEST 2006


On Apr 27, 2006, at 10:07:51, Bela Szilagyi wrote:

> Can one steer the synchronization + restriction proccess within  
> carpet by
> means of adjusting the appropriate tags table entries at runtime?
>
> To be more precise, I would want that some of my synchronization  
> requests
> would be honored without the additional expense of restriction.   
> Can this be
> done from outside Carpet by tags table entry manipulation?  Or, is  
> it known
> that the most expensive part of combined sync+restriction is mostly  
> the
> syncing?

To be clear, restricting means copying fine grid values to coarse  
grid values.  Synchronisation happens e.g. whenever there is a SYNC  
statement in a schedule item.  Restriction happens at a defined  
point, namely between the EVOL and POSTSTEP bins.  Both are  
completely independent.  I don't know which is more expensive --  
synchronisation is called more often, but restriction has to move  
more data.

You may be talking about prolongation instead.  Prolongation is  
indeed more expensive than synchronisation, and it makes certainly  
sense for certain analysis quantities to not be prolongated.  There  
is a tags table entry for this, but its value is examined only at  
startup.  You cannot change that during evolution.

Are you sure that this is worth the effort?  Are you trying to see  
how much this would improve things, or do you have timing numbers  
showing that this prolongation is indeed worth switching off?

-erik

-- 
Erik Schnetter <schnetter at cct.lsu.edu>

My email is as private as my paper mail.  I therefore support encrypting
and signing email messages.  Get my PGP key from www.keyserver.net.



-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 186 bytes
Desc: This is a digitally signed message part
Url : /archives/developers/attachments/20060504/82c7357e/attachment.pgp 


More information about the developers mailing list