[Users] Boundary conditions in diagnostics with compute_every

[Erik Schnetter]

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/