You can set the prologation type of "mask" such that it is never prolongated, then you don't need a second time level.
I'll need more details to investigate. Do you receive warnings at startup about prolongation? -erik On Tue, Jan 5, 2016 at 4:34 PM, Steven R. Brandt <sbra...@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 <sbra...@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 <sbra...@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 >>>> >>>> >>>> >> >> > -- Erik Schnetter <schnet...@cct.lsu.edu> http://www.perimeterinstitute.ca/personal/eschnetter/ _______________________________________________ Users mailing list Users@einsteintoolkit.org http://lists.einsteintoolkit.org/mailman/listinfo/users
