[Users] Boundary conditions in diagnostics with compute_every

[Gabriele Bozzola]

Hi Erik,

thank you very much for your assistance and explanations!

I'll try to implement this and see what happens.

Best,
Gabriele

On Mon, Mar 8, 2021 at 8:38 AM Erik Schnetter <schnetter at cct.lsu.edu> wrote:

> Gabriele
>
> No, I think prolongation="copy" would choose the spatial prolongation
> operator. InterpNumTimelevels = 1 might be the right choice. If you
> declare and allocate only a single time level, then the code will
> automatically fail if it tries to use older time levels.
>
> -erik
>
> On Mon, Mar 8, 2021 at 10:32 AM Gabriele Bozzola
> <bozzola.gabriele at gmail.com> wrote:
> >
> > Hi Erik,
> >
> >> 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".
> >
> >
> > Do I achieve this by setting the tags prolongation="copy" and
> InterpNumTimelevels = 1
> > in the declaration of the grid function in the interface.ccl?
> >
> > Thanks again,
> > Gabriele
> >
> > On Sun, Mar 7, 2021 at 10:05 AM Erik Schnetter <schnetter at cct.lsu.edu>
> wrote:
> >>
> >> 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/
>
>
>
> --
> Erik Schnetter <schnetter at cct.lsu.edu>
> http://www.perimeterinstitute.ca/personal/eschnetter/
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.einsteintoolkit.org/pipermail/users/attachments/20210308/eee414c3/attachment.html