Hello,
could anyone tell me a few details regarding the Carpet prolongation operators? It appears there's no real documentation about them. Looking at Carpet source code I can see these operators are available:
none sync restrict copy Lagrange ENO ENOVOL WENO TVD Lagrange_monotone STAGGER011 STAGGER101 STAGGER110 STAGGER111
The "polynomial" ones (Lagrange, ENO, etc) appear to be self explanatory, more or less. I'm particularly interested in the exact behaviour of "none", "sync" and "copy". "none" and "sync" are the same thing apparently. I find the "restrict" operator very confusing, since these are supposed to take care of prolongation.
I'm asking because in a thorn I'm working on, a certain GF has prolongation set to "None". This resulted in buffer zones on finer grids not to be initialized (full of NaNs) when switching on mesh refinement. Although I think I found a workaround, I'd like to take care of this by using some already provided mechanism, if available.
Thank you very much, Federico Guercilena
none: Do nothing during synchronization, prolongation, or restriction; the respective grid points remain untouched, and if not otherwise defined, remain undefined. This is commonly used e.g. for integer values that are calculated or determined pointwise.
sync: Synchronize only, do nothing for prolongation or restriction. This is similarly useful e.g. for integer data.
restrict: Only synchronize and restrict from coarser to finer grids, do nothing during prolongation. For vertex centred data where restriction is an injection, this can also still be used for integer values. Otherwise this may be useful for data that are not needed in prolongation regions, but where the coarse grid has data worse than the fine grid, e.g. for constraints.
copy: Copy from the nearest neighbour instead of interpolating. This can likewise be used for integer data.
All other settings define actual prolongation operators.
-erik
On Mon, Oct 26, 2015 at 11:51 AM, Federico Guercilena < guercilena@th.physik.uni-frankfurt.de> wrote:
Hello,
could anyone tell me a few details regarding the Carpet prolongation operators? It appears there's no real documentation about them. Looking at Carpet source code I can see these operators are available:
none sync restrict copy Lagrange ENO ENOVOL WENO TVD Lagrange_monotone STAGGER011 STAGGER101 STAGGER110 STAGGER111
The "polynomial" ones (Lagrange, ENO, etc) appear to be self explanatory, more or less. I'm particularly interested in the exact behaviour of "none", "sync" and "copy". "none" and "sync" are the same thing apparently. I find the "restrict" operator very confusing, since these are supposed to take care of prolongation.
I'm asking because in a thorn I'm working on, a certain GF has prolongation set to "None". This resulted in buffer zones on finer grids not to be initialized (full of NaNs) when switching on mesh refinement. Although I think I found a workaround, I'd like to take care of this by using some already provided mechanism, if available.
Thank you very much, Federico Guercilena
-- Federico Guercilena Institut für Theoretische Physik Johann Wolfgang Goethe-Universität Max-von-Laue-Str. 1 60438 Frankfurt am Main, Germany Telephone: +49 69 798 47887 Email: guercilena[at]th.physik.uni-frankfurt.de
Users mailing list Users@einsteintoolkit.org http://lists.einsteintoolkit.org/mailman/listinfo/users
Hello all,
On 2015-10-30 20:00, Erik Schnetter wrote:
none: Do nothing during synchronization, prolongation, or restriction; the respective grid points remain untouched, and if not otherwise defined, remain undefined. This is commonly used e.g. for integer values that are calculated or determined pointwise.
Please note though that current Carpet will not let you actually use this operator since it caused to much confusion it seems. In SetupGH.cc line 2455 all requests for "none" are replaced by "sync" (which as Erik explained is the same but for the fact that doing a SYNC one a GF with "none" prolongation would not have exchanged ghost zones, but a SYNC on a "sync" grid function does exchange ghost zone information.
Yours, Roland
On 30 Oct 2015, at 20:00, Erik Schnetter schnetter@cct.lsu.edu wrote:
none: Do nothing during synchronization, prolongation, or restriction; the respective grid points remain untouched, and if not otherwise defined, remain undefined. This is commonly used e.g. for integer values that are calculated or determined pointwise.
sync: Synchronize only, do nothing for prolongation or restriction. This is similarly useful e.g. for integer data.
restrict: Only synchronize and restrict from coarser to finer grids, do nothing during prolongation. For vertex centred data where restriction is an injection, this can also still be used for integer values. Otherwise this may be useful for data that are not needed in prolongation regions, but where the coarse grid has data worse than the fine grid, e.g. for constraints.
copy: Copy from the nearest neighbour instead of interpolating. This can likewise be used for integer data.
All other settings define actual prolongation operators.
So really we should think of the "prolongation" tag as a more generic "how to treat this group during mesh refinement operations"? Would it make sense to introduce a new name for this tag, to avoid confusion? We would of course continue to accept the old name, for backward compatibility.
Hi everyone,
thanks for the answers, this clears some misconceptions on my part. The "copy" operator seems to be what I need, I'll give it a try.
Bye, Federico
2015-10-30 20:33 GMT+01:00 Ian Hinder ian.hinder@aei.mpg.de:
On 30 Oct 2015, at 20:00, Erik Schnetter schnetter@cct.lsu.edu wrote:
none: Do nothing during synchronization, prolongation, or restriction; the respective grid points remain untouched, and if not otherwise defined, remain undefined. This is commonly used e.g. for integer values that are calculated or determined pointwise.
sync: Synchronize only, do nothing for prolongation or restriction. This is similarly useful e.g. for integer data.
restrict: Only synchronize and restrict from coarser to finer grids, do nothing during prolongation. For vertex centred data where restriction is an injection, this can also still be used for integer values. Otherwise this may be useful for data that are not needed in prolongation regions, but where the coarse grid has data worse than the fine grid, e.g. for constraints.
copy: Copy from the nearest neighbour instead of interpolating. This can likewise be used for integer data.
All other settings define actual prolongation operators.
So really we should think of the "prolongation" tag as a more generic "how to treat this group during mesh refinement operations"? Would it make sense to introduce a new name for this tag, to avoid confusion? We would of course continue to accept the old name, for backward compatibility.
-- Ian Hinder http://members.aei.mpg.de/ianhin
users@lists.einsteintoolkit.org
-
Erik Schnetter -
Federico Guercilena -
Ian Hinder -
Roland Haas