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
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
Hi Erik,
thank you very much for your answer.
Just a clarification: what is 'boundary' exactly in this context?
Also, is it a problem if I don't worry about the boundaries If I want to interpolate the constraints onto a sphere?
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
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
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/
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/
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/
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/
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/
users@lists.einsteintoolkit.org
-
Erik Schnetter -
Gabriele Bozzola