ForestClaw / forestclaw

Quadtree/octree adaptive PDE solver based based on p4est.
http://www.forestclaw.org
BSD 2-Clause "Simplified" License
58 stars 22 forks source link

Coarsening/refining not symmetric #36

Closed donnaaboise closed 6 years ago

donnaaboise commented 11 years ago

Originally reported by: Donna Calhoun (Bitbucket: donnaaboise, GitHub: donnaaboise)


Refinement uses ghost cell values (to anticipate the need to refine based on neighboring patches) but coarsening does not. This can lead to a situation where a patch is refined in one step and immediately coarsened in the next step, even though the solution hasn't changed at all.

Pathological test : Any initial condition in which a jump in values occurs exactly at a patch boundary, and the solution doesn't change in time (zero velocity, for example). Or, just look at the 'no_solver' example. In this example, nothing happens, but still, grids are alternately coarsened and refined

What I need to be able to do is get ghost cell information from patches neighbouring the temporary coarse patch. But to do this, it somehow has to be recognised by the p4est hierarchy as a shadow patch.


donnaaboise commented 8 years ago

Original comment by Carsten Burstedde (Bitbucket: cburstedde, GitHub: cburstedde):


The paper says we specify both C_refine and C_coarsen, so is this essentially what I was saying at the example of C and C/3?

donnaaboise commented 9 years ago

Original comment by Carsten Burstedde (Bitbucket: cburstedde, GitHub: cburstedde):


With the current status of adaptation issue #28 (that repeats the above proposition but with C/3, and suggests to derefine based on this value alone and not by hypothetical coarsening of patches), this problem would go away. We can add an option on whether to include ghost values in the refinement indicator and test both, then pick what works best.

donnaaboise commented 9 years ago

Original comment by Carsten Burstedde (Bitbucket: cburstedde, GitHub: cburstedde):


Looking at issue #28, would the algorithm proposed there solve these issues? As for the pathological test above, if the ghost cells of a patch are taken into account for a patch-local indicator, there should be no oscillations.

What about using as indicator like for example

norm_infinity(gradient)_over_patch_and_ghost_cells * h_patch,

refine if this is greater than some C and coarsen if it is less than C/2?

donnaaboise commented 10 years ago

Original comment by Carsten Burstedde (Bitbucket: cburstedde, GitHub: cburstedde):


Can coarsening take into account ghost cell values too (the data should be available)?

Maybe we should take a step back and formally define refinement/coarsening criteria that are guaranteed not to oscillate, and only then think about the implementation?

donnaaboise commented 11 years ago

Original comment by Carsten Burstedde (Bitbucket: cburstedde, GitHub: cburstedde):


It seems that refinement/coarsening are partition independent.

It remains to exchange indicators across neighbors to deal with the coarsening issue.

donnaaboise commented 11 years ago

Original comment by Carsten Burstedde (Bitbucket: cburstedde, GitHub: cburstedde):


For consistency of parallel runs, it will be important to guarantee that the refinement and coarsening indicators are independent of the number of processes and the parallel partition. Ideally, a given adaptive computation should produce identical results up to roundoff error independent of the number of cores.

I could think about functions that transfer refinement indicators to neighbor elements to diffuse out the refinement criterion across neighbors, but really partition independence needs to be enforced rigorously in the design of the indicators.

donnaaboise commented 7 years ago

I think this issue has been resolved by introducing coarsening criteria that satisfies tau_c < 0.5*tau_r.

donnaaboise commented 6 years ago

This issue will be discussed in paper.