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