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@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@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@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@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@einsteintoolkit.org > http://lists.einsteintoolkit.org/mailman/listinfo/users