when using amr_derefine_refine, there is no rules to check it's praent's refinement, which exists in the old version. If no such rules, it will refine, derefine, refine, ...
Logged In: YES
Can the person that submitted this bug report please give more details and a working example of how things are failing for you.
Logged In: YES
I am having the same problem, with Paramesh 4.0 and 4.1. I have written a small program that will demonstrate this. The case is two-dimensional, and has a 1d shock placed near the middle of the domain, such that some parent blocks will see the shock while their children will not. As we step through iterations (with no transport --- so the solution does not change), the number of blocks oscillate from step to step between 37 and 53. If I print out the results from the test refinement subroutine on the larger mesh,
REFINE: 4 2 3 0.25000000E+02 0.50000000E+02 T F
REFINE: 5 4 4 0.25000000E+02 0.37500000E+02 F T
REFINE: 6 4 4 0.37500000E+02 0.50000000E+02 F T
REFINE: 7 4 4 0.25000000E+02 0.37500000E+02 F T
REFINE: 8 4 4 0.37500000E+02 0.50000000E+02 F T
The first number is lb, second is parent(1,lb), third is lrefine(lb), the next two are the x-direction bounding box, then refine(lb) and derefine(lb). You can see clearly that blocks 5-8 are calling to be derefined, however, their parent (block 4) is calling for refinement. This should cancel the derefinement, however, after refine_derefine, these blocks are removed anyways.
Sign up for the SourceForge newsletter:
You seem to have CSS turned off.
Please don't fill out this field.