[Users] Multiple time levels

Erik Schnetter schnetter at cct.lsu.edu
Tue Jan 5 15:54:12 CST 2016


Carpet seems to want to prolongate to time t=0. I don't know why and
where -- can you find out? This fails, because prolongation always
uses the most recent time level, which at this point has already
advanced by one step to t=0.05. What time integrator are you using? I
assume it does use substeps?

As a work-around you can set the variable's prolongation type to
"copy". This will always copy the current time level when
prolongating. This is in principle equivalent when you set
prolongation_order_time = 0. However, this may lead to large errors at
refinement boundaries during MoL's substeps. Remember, Carpet evolves
each refinement level separately, so that the MoL substeps of the two
levels occur sequentially.

I would set prolongation_order_time = 1.

For the "mask" variable, you can set the prolongation type to "copy",
and then you should need only a single time level.

-erik


On Tue, Jan 5, 2016 at 4:44 PM, Steven R. Brandt <sbrandt at cct.lsu.edu> wrote:
> On 01/05/2016 03:39 PM, Erik Schnetter wrote:
>>
>> You can set the prologation type of "mask" such that it is never
>> prolongated, then you don't need a second time level.
>
> Yes, except, unfortunately, that I need to have it prolonged.
>>
>>
>> I'll need more details to investigate. Do you receive warnings at
>> startup about prolongation?
>
> None.
>
>
> Cheers,
> Steve
>>
>>
>> -erik
>>
>> On Tue, Jan 5, 2016 at 4:34 PM, Steven R. Brandt <sbrandt at cct.lsu.edu>
>> wrote:
>>>
>>> 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
>>>>>>
>>>>>>
>>>>>>
>>>>
>>
>>
>



-- 
Erik Schnetter <schnetter at cct.lsu.edu>
http://www.perimeterinstitute.ca/personal/eschnetter/


More information about the Users mailing list