Yes, that would be a good idea and would make the behaviour clearer. However, as the number of time levels is chosen via a parameter, the prolongation type also needs to be a parameter. Currently, Carpet changes the prolongation type internally if there are not enough time levels, and then outputs this warning.
-erik
On Thu, Feb 10, 2011 at 12:19 AM, Bruno C. Mundim bcmsma@astro.rit.edu wrote:
Ok, that seems fair enough, but shouldn't we then tag those groups with "prolongation=none"? that would avoid the warning messages when looking at 3D output. What do you think?
Thanks, Bruno.
Erik Schnetter wrote:
Bruno
This depends on whether you want the mesh refinement boundaries of the constraint variables be interpolated from the next coarser grid, or remain undefined/set to zero. In principle, these boundaries are not important if you are looking for 3D output, but if you want to look at reductions then you will need time interpolation. However, this requires in addition that the constraints be calculated at every iteration, and is thus expensive both in terms of memory requirements and computing time requirements. Most people are therefore fine with undefined prolongation boundaries and only look at e.g. 1D output, ignoring the ghost and boundary points.
-erik
On Wed, Feb 9, 2011 at 5:34 PM, Bruno Coutinho Mundim bcmsma@astro.rit.edu wrote:
Hi,
I am receiving the messages of the following kind in my simulation with McLachlan:
(line 1084 of ./Cactus/arrangements/Carpet/CarpetReduce/src/reduce.cc): -> Grid function "ML_BSSN::H" has only 1 time levels on refinement level 0; this is not enough for time interpolation
and it is indeed true that the constraint variables has 1 time level only:
CTK_REAL ML_Ham type=GF timelevels=1 tags='tensortypealias="Scalar" tensorweight=0' { H } "ML_Ham"
I was wondering if we shouldn't be using 3 time levels instead.
Thanks, Bruno. _______________________________________________ Users mailing list Users@einsteintoolkit.org http://lists.einsteintoolkit.org/mailman/listinfo/users