[Users] Multiple time levels

Steven R. Brandt sbrandt at cct.lsu.edu
Tue Jan 5 15:34:15 CST 2016


On 01/05/2016 03:23 PM, Erik Schnetter wrote:
> If you have n time levels, then it is natural to set
> prolongation_order_time = n-1.
Originally, the error message occurred for a variable named mask, which 
had a single time level. I guessed that since the error message showed a 
single, wrong value, that having two time levels to choose from might 
make it work. So I gave mask two time levels and started copying in 
CCTK_PRESTEP. The error then showed up in eta, which always had 2 
timelevels (because it's evolved with RK3).
>
> When does the error occur? Does it happen during initial data setup,
> or during evolution? Applying boundary conditions for the initial
Iteration 0 prints, so evolution.
> conditions also requires prolongation. Depending on your initial data
> scheme, you may even be applying boundary conditions to past time
> levels for the initial conditions.
Not sure I follow what you're saying here. I calculate all data for time 
= 0.

Cheers,
Steve
> -erik
>
>
> On Tue, Jan 5, 2016 at 4:11 PM, Steven R. Brandt <sbrandt at cct.lsu.edu> wrote:
>> OK, so copying data in CCTK_PRESTEP seems to work.
>>
>> My next question is, I think, trickier... My par file looks something like
>> this
>>
>> Carpet::time_refinement_factors = "[1,1]"
>> Time::timestep_method = "given"
>> Time::timestep = 0.05
>> Carpet::prolongation_order_time = 0
>> ...
>>
>> Unfortunately, when I try to run the code I get this:
>>
>> WARNING level 0 from host 18-5e-f-12-9b-2a.wlan.lsu.edu process 0
>>    while executing schedule bin (none), routine (no thorn)::(no routine)
>>    in thorn CarpetLib, file
>> /home/sbrandt/cactus/CactusFW/arrangements/Carpet/CarpetLib/src/gdata.cc:375:
>>    -> Internal error: extrapolation in time. variable=FUNWAVE::eta  time=0
>> times=[0.050000000000000003]
>> cactus_sim:
>> /home/sbrandt/cactus/CactusFW/arrangements/Carpet/Carpet/src/helpers.cc:269:
>> int Carpet::Abort(const cGH*, int): Assertion `0' failed.
>>
>> It's trying to get data from the same time level, but it seems to only have
>> the wrong one.
>>
>> My theory is that prolongation_order_time = 1 is going to give me what I
>> want, because it's going to prolong to one of the endpoints (the code runs,
>> at least). Does this mean that prolongation_order_time = 0 is broken?
>>
>> Cheers,
>> Steve
>>
>>
>> On 01/05/2016 01:06 PM, Erik Schnetter wrote:
>>> Steve
>>>
>>> If a grid variable has multiple time levels, then it will be cycled at
>>> the beginning of every time step. You need to copy the past to the
>>> current time level after time level cycling to preserve the previous
>>> behaviour.
>>>
>>> -erik
>>>
>>>
>>> On Tue, Jan 5, 2016 at 1:46 PM, Steven R. Brandt <sbrandt at cct.lsu.edu>
>>> wrote:
>>>> In the code I'm working on, I have a set of variables living at a single
>>>> timestep. For various reasons, I want to shift to having them at two
>>>> timelevels, but simply making the change in interface and schedule
>>>> results in failure to run old test suites. Is there a recipe I should be
>>>> following to make this work?
>>>>
>>>> Cheers,
>>>> Steve
>>>> _______________________________________________
>>>> Users mailing list
>>>> Users at einsteintoolkit.org
>>>> http://lists.einsteintoolkit.org/mailman/listinfo/users
>>>
>>>
>
>



More information about the Users mailing list