[Carpet] getting dt for the finest grid

[Erik Schnetter]

On Aug 28, 2007, at 13:01:19, Yosef Zlochower wrote:

> Hi,
>
>   So if I want to evolve a geodesic or a curve normal to the timeslice
>  (or something else which depends on the ADMBase vars),  then I'll
> have to schedule the evolution of the curve in the PostEvol bin?

Let's assume that you want to evolve it independently of MoL.  In  
this case I suggest the POSTSTEP bin, which is called after  
restriction, so that the necessary interpolation will get the best  
possible values.

> Yosef
>
> Erik Schnetter wrote:
>> On Aug 28, 2007, at 11:55:09, Yosef Zlochower wrote:
>>
>>> Hi,
>>>
>>>  Can you clarify one point for me? Suppose I schedule a local  
>>> routine
>>> in a schedule group "mygroup" and a global routine after "mygroup"
>>> but in the same schedule bin (and perhaps even within the same  
>>> group),
>>> can I force the global routine to be called after carpet finishes
>>> calling
>>> the local routine on all the appropriate levels using the AFTER  
>>> keyword?
>>
>> No, that is very unfortunately not possible.  The schedule is  
>> executed
>> by the flesh, not by Carpet, and this happens in level mode.  Global
>> mode means only to skip some calls that would otherwise happen, i.e.,
>> to ensure that this routine is only called once per time step.  It
>> will be called together with the first or the last level mode routine
>> in a particular bin, depending on the bin.  If there is interest, I
>> can implement new options such as GLOBAL_FIRST and GLOBAL_LAST, or
>> GLOBAL_COARSEST and GLOBAL_FINEST, which would do what you intend.
>> Ultimately the Cactus scheduler needs to be made more flexible and
>> taught about the recursive evolution.
>>
>>
>>
>> Consider the case where one wants to evolve some additional equation
>> together with the main evolution system, e.g. some geodesic or some
>> global quantity, and which is coupled with the main evolution system.
>> Let's call this quantity Q.  That means that e.g. the BSSN gauge RHS
>> depends on Q, and the RHS for Q depends on the metric via an
>> interpolation or reduction.
>>
>> With mesh refinement, it is not trivial to make this happen
>> correctly.  If you schedule the evolution for Q after the metric
>> evolution, then the metric evolution doesn't have access to Q.  And
>> vice versa.  Similar to the spacetime/hydro coupling, you want to
>> evolve Q at the same time as the BSSN equations.  If you look at how
>> the BSSN evolution proceeds -- it is quite non-monotonic in time --
>> then you'll find that you have to evolve first Q a large step into  
>> the
>> future, then undo that for the next finer level and evolve it by
>> several smaller steps.
>>
>> If you just evolve Q in many fine steps, then you cannot access a  
>> good
>> value for Q for the first coarse grid BSSN step, since that BSSN step
>> is the first thing that happens in the Berger-Oliger scheme.
>>
>>
>>
>> Unless you come up with a clean scheme, you can only achieve
>> independent time evolution, which means a first order coupling  
>> between
>> Q and the BSSN quantities.  The error will be first order in the
>> coarse grid time step, which can be significant.
>>
>> If you can guarantee that Q depends only on the finest grid, and that
>> only the fine grid evolution depends on Q (e.g. if it has  
>> something to
>> do with excision), then you can evolve Q together with the finest
>> grid, achieving easily first order accuracy in the fine grid dt, or
>> (if you use MoL for Q) also e.g. 4th order coupling with BSSN.
>>
>>
>>
>> If Q is a pure analysis quantity (which does not influence the RHS of
>> the BSSN system), then you are lucky.
>>
>> -erik
>>
>
> _______________________________________________
> developers mailing list
> developers at lists.carpetcode.org
> http://lists.carpetcode.org/listinfo/developers
>


-- 
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/20070828/2d93a5f3/attachment.pgp