On Fri, Mar 5, 2021 at 8:01 PM Gabriele Bozzola <[email protected]> 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 <[email protected]> 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 > > <[email protected]> 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 > >> [email protected] > >> http://lists.einsteintoolkit.org/mailman/listinfo/users -- Erik Schnetter <[email protected]> http://www.perimeterinstitute.ca/personal/eschnetter/ _______________________________________________ Users mailing list [email protected] http://lists.einsteintoolkit.org/mailman/listinfo/users
