[Users] Exact meaning of prolongation tags

Erik Schnetter schnetter at cct.lsu.edu
Fri Oct 30 14:00:59 CDT 2015


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 at 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 at einsteintoolkit.org
> http://lists.einsteintoolkit.org/mailman/listinfo/users
>
>


-- 
Erik Schnetter <schnetter at cct.lsu.edu>
http://www.perimeterinstitute.ca/personal/eschnetter/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.einsteintoolkit.org/pipermail/users/attachments/20151030/4f16a7fe/attachment.html 


More information about the Users mailing list