[Users] Meeting minutes

[Bruno C. Mundim]

Hi Erik:

Erik Schnetter wrote:
> On Tue, May 24, 2011 at 11:43 PM, Bruno C. Mundim <bcmsma at astro.rit.edu> wrote:
>> Hi Erik and Ian,
>>
>> Erik Schnetter wrote:
>>> On Tue, May 24, 2011 at 2:11 AM, Ian Hinder <ian.hinder at aei.mpg.de> wrote:
>>>> On 23 May 2011, at 23:49, Bruno Coutinho Mundim wrote:
>>>>
>>>>>> * Bruno still has troubles with RotatingSymmetry180 when using the
>>>>>> development version of ET for the BBH example (parfile is in
>>>>>> subversion)
>>>>>> * will try running without RotatingSymmetry180
>>>>> Just got the results: no problem without RotatingSymmetry180.
>>>> OK good, so we know where the problem is.
>>>>
>>>>>> * convergence in norms is bad, somewhat better in 1D data for a short
>>>>>> time after simulation startup
>>>>> A closer look into the initial data revealed that both the l2-norm of
>>>>> the hamiltonian constraint and its value along the x-axis converge to
>>>>> the expected order, 4th order. This convergence is not observed anymore
>>>>> in the very next coarse step when the comparison is done again.
>>>> The time prolongation is only 3rd order accurate so I wouldn't expect
>>>> convergence at 4th order.
>> Thanks! I missed that...
>>
>>> Time prolongation is second order accurate.
>>>
>> Right. We use three time levels (equivalently three points) to
>> prolongate, so it should be second order, O(dt^2), accurate.
> 
> Yes, it uses three points. Not everybody counts orders the same way I did here.
> 
>>> You can use tapered grids, which avoids all time interpolation except
>>> possibly during regridding. If you are careful about regridding you
>>> don't need time interpolation for this either. This gives you clean
>>> fourth order convergence, except near the outer boundary if you are
>>> cheating there (and we all are).
>>>
>> What do you mean by "If you are careful about regridding you
>> don't need time interpolation for this either. "? You mean besides using
>> tapered grids, only regrid when all grids are aligned (in time), ie in
>> only at the coarsest time steps?
> 
> Not quite. All the grids that are changing need to be aligned with
> their next coarser grids. If e.g. the first three levels don't change,
> then you can regrid much more often than just at full coarse grid time
> steps.
> 
Then the following parameters should help achieving clean 4th order 
convergence:

Carpet::use_tapered_grids = "yes"
CarpetRegrid2::freeze_unaligned_levels = "yes"

and we would end up with a buffer zone = 2 * 4 * 3 = 24 points
(time refinement ratio * # of RK4 algorithmic steps * width of 4th order
centered dissipation stencil) plus the number of ghost zones around each
grid component (3 in this case). Is this counting correct? this seems
quite expensive...

>>> Another issue to consider is how you set up the past timelevels. If
>>> you copy the data from the current time level, then you are
>>> introducing a first order error.
>> Good point. I guess that's how it is set right now:
>> Carpet::init_fill_timelevels     = "yes"
>> InitBase::initial_data_setup_method = "init_all_levels"
> 
> Yes, this will introduce a very large error during time
> "interpolation", because by doing so, you essentially copy the initial
> data to the future times instead of interpolating.
>
yes, but this first order error would be evident only on the buffer
zones, right? and I would expect this error to pollute the solution
later on in the simulation only, not on the first few time steps.

Cheers,
Bruno.

>> If you use the
>>> three-timelevel-initialisation, then you are second order accurate.
>>> Again, these past timelevels are used only for time interpolation, but
>>> they can reduce the convergence order even further if they are not
>>> well initialised.
>>>
>> But to use init_3_timelevels we need to have all time levels on the
>> ratio 2:1 (for example). We can't have as it is set there right now:
>>
>> Carpet::time_refinement_factors = "[1, 1, 2, 4,...]"
> 
> Yes. Sorry.
> 
> -erik
>