- changed status to open
- removed comment
add higher order restriction parameter to cell-centerd Carpet
Issue #945
closed
the attached patch adds a 3rd order accurate restriction operator to Carpet.
It is used only for cell-centered runs, for grid functions whose prolongation operator is not ENO or WENO (ie. non matter variables only).
It should be completely invisible if CarpetLib:use_cc_o3 is false (which of course is the default).
It offers third-order accurate restriction operators for cell centered grids when use_cc_o3 is set. This interpolation is done for samples at the cell centres (so this is not a ppm scheme or anything like that). It really only fits a polynomial of the form \sum_{i,j,k=0}^3 a_{i,j,k} x^i y^j z^k to the fine cells and evaluates at x=y=z=0. So it is good for the metric, but bad for matter (since it will destroy the conservation). Because of this it is not used for grid functions whose transport operator is not WENO or ENO which hopefully excludes all matter variables.
I also attach a patch for a modified WaveToyMoL thorn that I used for testing. When test_restriction is set, then it puts a 3rd order polynomial (with some random coefficients) into phi and the differences between the restricted value and what should be there into psi.
The wavetoymol thorn right now inherits from CarpetEvolutionMask since I am also working on making this functional again (seems to be ok now).
Finally attached is a parameter file to test it. You should find a region inside of reflevel 0 of psi where psi is exactly zero. This is where the restriction works as expected.
Further improvements would be to not have the selection for 3rd order done by a global carpetlib parameter but instead by a grid function tag (or a global carpet paarameter). This change could also be made to the eno/weno operators which contain special logic to use ENO for prolongation_order_space = 3 and 5 both.
Ok to apply (or are there large scale changes to Carpet that are currently private)?
Keyword: CarpetLib
Comments (8)
-
reporter
-
reporter
- changed status to resolved
- removed comment
Erik says "This looks godd" (private communication). Applied as hash 8baed9ee6149 "CarpetLib: add preliminary support for higher order restriction" (without the WaveToyMoL of course).
-
- changed status to open
- removed comment
Actually, let's keep the ticket open, we should look at the code again and clean it up:
- The parameter "use_cc_o3" should instead be "use_higher_order_restriction" or similar. The actual restriction order should then be the same as the prolongation order (up to what is available). - The code in dh.cc needs to be cleaned up. This concerns the way in which the source domain for the operator is enlarged to ensure that the restriction stencil fits. I am not convinced that the current code is correct in all cases. - The implementation of the actual operator could be modernised (although this is not necessary). - The documentation of the stencil that is given above in this ticket should go into the source code.
There is a remark regarding synchronisation. However, there is no code to synchronise. Is Carpet's current behaviour regarding synchronisation already correct?
-
reporter
- removed comment
Ah Erik beat me to it. His looks good was actually unrelated... Well we have 6 months to clean it up.
All points are very valid and should be addressed (by me... soon... once I have time on my hand...).
Carpet already does the right thing. There is s SyncGroups call in CallRestrict which is precisely what we need (but seems to be superfluous in the old code since refstriction happened everywhere not just the interior).
-
reporter
- removed comment
The first two and the last point should be taken care of. The source region for the operator is now computed by shrinking each source box by the one sided stencil size minus one. Since the region is afterwards intersected with the interior of the destination, no unnecessary restrictions are performed.
For point 3 I have the suspicion that it should be possible to coerce the existing vertex centered prolongation operators into service as cell centered restriction operators.
-
reporter
- changed status to open
- removed comment
-
reporter
- changed status to resolved
- removed comment
Why did I set this to review??? Given that I will not likely have time to go in a beautify the code, I will only do so when being encouraged to do so. Closing this ticket.
-
reporter
- edited description
- changed status to closed
- Log in to comment
- Assignee
- –
- Type
- Priority
- Status
- closed
- Component
- EinsteinToolkit thorn
- Milestone
- –
- Version
- –
- Votes
- 0
- Watchers
- 0
