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 <[email protected]> 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 > <[email protected]> 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 <[email protected]> > wrote: > >> > >> 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/ > > > > -- > Erik Schnetter <[email protected]> > http://www.perimeterinstitute.ca/personal/eschnetter/ >
_______________________________________________ Users mailing list [email protected] http://lists.einsteintoolkit.org/mailman/listinfo/users
