[Users] Boundary conditions in diagnostics with compute_every

[Erik Schnetter]

On Sat, Mar 6, 2021 at 1:58 PM Gabriele Bozzola
<bozzola.gabriele at gmail.com> wrote:
>
> Hi Erik,
>
> thanks for your response: it is very useful.
>
> > > Also, is it a problem if I don't worry about the boundaries If I
> > > want to interpolate the constraints onto a sphere?
> >
> > Yes it is. Interpolation requires a stencil, which requires boundaries.
>
> I suspected so. Then, going back to the question in the first email, you
> said that I am essentially forced to compute the diagnostic at
> each timestep. The diagnostic I want to compute is very expensive,
> and it would slow down dramatically the evolution, so I really want to
> compute it only when I am going to output it. What I had in mind was
> to copy grid function to the previous timelevels by setting _p and _p_p.
> If I copy the same values as the one at the current time, this would
> essentially disable time interpolation. But, if I output only when all
> the refinement levels at the same time, this should not be a problem,
> because there shouldn't be a need for time prolongation, right?

In this case, you can declare the grid function to use 0-th order time
interpolation, and allocate only a single time level. This would do
the same thing. I think the respective time prolongtation operator is
called "copy".

-erik

> Thanks again for your help,
> Gabriele
>
> On Sat, Mar 6, 2021 at 7:45 AM Erik Schnetter <schnetter at cct.lsu.edu> wrote:
>>
>> On Fri, Mar 5, 2021 at 8:01 PM Gabriele Bozzola
>> <bozzola.gabriele at gmail.com> wrote:
>> >
>> > Hi Erik,
>> >
>> > thank you very much for your answer.
>> >
>> > Just a clarification: what is 'boundary' exactly in this context?
>>
>> "Boundary" in the context are all grid points where the constraints
>> cannot be calculated directly, i.e. by evaluating finite differences.
>>
>> > Also, is it a problem if I don't worry about the boundaries If I
>> > want to interpolate the constraints onto a sphere?
>>
>> Yes it is. Interpolation requires a stencil, which requires boundaries.
>>
>> Cactus interpolation supports taking derivatives during interpolation.
>> You can thus interpolate the ADM variables and their derivatives onto
>> a sphere, and calculate the constraints there. You won't need to take
>> derivatives on the sphere since you interpolated all derivatives, so
>> evaluating the constraints on points on a sphere is then a point-wise
>> operation. The horizon finder does this (calculating the expansion,
>> not the constraints, but both have equivalent requirements).
>>
>> -erik
>>
>> > Thanks,
>> > Gabriele
>> >
>> > Erik Schnetter <schnetter at cct.lsu.edu> writes:
>> >
>> > > Gabriele
>> > >
>> > > If you do not use the constraints, then you do not need to set
>> > > the
>> > > boundaries. That would simplify many things; for example, you
>> > > can
>> > > calculate them at any time, and you do not need to worry about
>> > > time
>> > > levels. However, you then need to be careful about visualization
>> > > and
>> > > reductions: You need to ensure that you don't accidentally
>> > > visualize
>> > > the boundaries, and you cannot perform vertex-centred reductions
>> > > in
>> > > Carpet because they need some boundary values.
>> > >
>> > > If you do need boundaries, then you need three time levels to
>> > > allow
>> > > prolongation on boundaries, and you are essentially forced to
>> > > evaluate
>> > > the constraints at every iteration. I recommend the schedule bin
>> > > "MoL_PseudoEvolution" for this, which runs once per time step,
>> > > after
>> > > MoL's loop, at the right time (i.e. before restriction).
>> > >
>> > > -erik
>> > >
>> > > On Fri, Mar 5, 2021 at 11:01 AM Gabriele Bozzola
>> > > <bozzola.gabriele at gmail.com> wrote:
>> > >>
>> > >> Hello,
>> > >>
>> > >> suppose (for clarity) that I want to write a thorn that
>> > >> computes the constraint violations
>> > >> as grid functions. Since this is a diagnostic, I don't need to
>> > >> compute it at every iteration,
>> > >> so I will add a parameter "compute every" and I will schedule
>> > >> the computations in
>> > >> CCTK_ANALYSIS. Then, I will be careful and make sure that
>> > >> compute_every is a
>> > >> multiple of when all the refinement levels are synced up.
>> > >>
>> > >> How are boundary conditions handled in this case?
>> > >>
>> > >> I can call Boundary_SelectGroupForBC every "compute_every" and
>> > >> schedule the
>> > >> corresponding functions in the scheduler. But, do I need to (1)
>> > >> allocate multiple timelevels
>> > >> for my grid functions, (2) do anything about filling previous
>> > >> timelevels?
>> > >>
>> > >> I am looking at WeylScal4 as an example. The thorn has
>> > >> parameters "compute_every",
>> > >> the grid functions have 3 time levels, and
>> > >> Boundary_SelectGroupForBC is called
>> > >> every "compute_every", but nothing is done to fill the previous
>> > >> timelevels. How does this
>> > >> work?
>> > >>
>> > >> Assuming that the boundary conditions are 'flat', is there any
>> > >> way to just work with one
>> > >> timelevel?
>> > >>
>> > >> Thanks,
>> > >> Gabriele
>> > >>
>> > >>
>> > >> _______________________________________________
>> > >> 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/



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