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?
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/