[Developers] Evolving grid arrays in time

Erik Schnetter schnetter at cct.lsu.edu
Fri Sep 28 11:10:31 CDT 2007


I am now evolving geodesics with the following work-around:

I use MoL.  Each time the RHS is calculated, I check whether the  
current refinement level is the finest level.  If so, the RHS is  
calculated, otherwise the RHS is set to zero.

The current refinement level is accessed by

interface.ccl:
USES INCLUDE: carpet.hh

#include <carpet.hh>

if (Carpet::reflevel == Carpet::reflevels - 1) // do calculation

This works only from C++.  The RHS calculating routine has to be  
scheduled in level mode.

-erik

On Sep 27, 2007, at 12:54:37, Erik Schnetter wrote:

> I want to evolve geodesics, which are stored in grid arrays.  I'm  
> looking for a way to make this work.  This may have to involve some  
> trickery, such as defining your own time levels.  I'll send more  
> information once I found a good way.
>
> -erik
>
> On Sep 26, 2007, at 18:36:12, Tanja Bode wrote:
>
>> Hi,
>>
>> Has there been any further work done on evolving grid arrays in  
>> time with
>> MoL since the discussion last year?
>>
>> Thanks,
>> Tanja
>>
>>
>>
>> On Mon, 4 Sep 2006, Ian Hawke wrote:
>>
>>> On Tue, 2006-08-29 at 19:19 -0500, Erik Schnetter wrote:
>>>> It is currently not possible to evolve grid arrays in time with MoL
>>>> when using mesh refinement.  At the moment, MoL would evolve grid
>>>> arrays multiple times per time step -- once for each refinement
>>>> level.  I am toying with different ideas to make Carpet, MoL, and
>>>> grid arrays work together.
>>>
>>>> MoL would need additional code to ensure that grid arrays are  
>>>> evolved
>>>> only in global mode.
>>>>
>>>> When grid functions are evolved in time, one cannot access the  
>>>> values
>>>> of grid arrays which are also evolved in time.  This is so because
>>>> their time stepping is non commensurable.
>>>>
>>>> Comments?
>>>
>>> This final point was the thing that made me think that it wasn't  
>>> worth
>>> doing, as there are few tasks that I could think of fitting this  
>>> scheme
>>> that couldn't be done with much less effort by post-processing. I  
>>> would
>>> only see the value if the evolved grid array was going to be used  
>>> in the
>>> evolution, and hence their values will need to be accessed.
>>>
>>> It might be possible to allow this with a careful use of  
>>> timelevels, but
>>> that would require quite a bit of communication between Carpet  
>>> and MoL I
>>> would think.
>>>
>>> Ian
>>>
>>>
>>>
>>> _______________________________________________
>>> Developers mailing list
>>> Developers at cactuscode.org
>>> http://www.cactuscode.org/mailman/listinfo/developers
>>>
>>
>>
>>
>> _______________________________________________
>> Developers mailing list
>> Developers at cactuscode.org
>> http://www.cactuscode.org/mailman/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.
>
>
>
> _______________________________________________
> Developers mailing list
> Developers at cactuscode.org
> http://www.cactuscode.org/mailman/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 : http://www.cactuscode.org/pipermail/developers/attachments/20070928/6e0ad4d8/attachment.bin 


More information about the Developers mailing list