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@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@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@cct.lsu.edu
wrote:
On Sat, Mar 6, 2021 at 1:58 PM Gabriele Bozzola bozzola.gabriele@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@cct.lsu.edu
wrote:
On Fri, Mar 5, 2021 at 8:01 PM Gabriele Bozzola bozzola.gabriele@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@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@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@einsteintoolkit.org >> http://lists.einsteintoolkit.org/mailman/listinfo/users
-- Erik Schnetter schnetter@cct.lsu.edu http://www.perimeterinstitute.ca/personal/eschnetter/
-- Erik Schnetter schnetter@cct.lsu.edu http://www.perimeterinstitute.ca/personal/eschnetter/
-- Erik Schnetter schnetter@cct.lsu.edu http://www.perimeterinstitute.ca/personal/eschnetter/