Wrong number of grid levels output (system-specific)

[gassmoeller]

I observed a case were the screen output of number of grid levels during initial adaptive refinement was wrong (constant at 9 levels for every initial adaptive refinement), although the mesh was clearly changing to higher levels (visible in visualization output). The number of cells and number of degrees of freedom change correctly. The bug seems to be system specific, I could not reproduce it on my local machine with an identical parameter file (the number of levels changes correctly), but it occurs on our cluster. It could be caused by different deal.II versions (8.4.1 on my local machine works, 8.5.0.pre on the cluster shows the bug), or different locale formats. I do not think triangulation.n_levels() actually returns the wrong number, this should lead to all kind of trouble, instead it is likely something we do in aspect, or something related to the screen output. This is mostly a note to myself to investigate this further in the future.
Parameter file that reproduces the problem is attached.
wrong_n_levels.prm.zip

[tjhei]

1. We were reporting the wrong number of levels, see fix wrong reporting of number of grid levels #893.
2. There is one other curious thing I have seen: use a refinement scheme that produces zero error in many cells (for example "temperature" and have T=0 everywhere), set coarsening fraction = 0.0, and refine adaptively. Sometimes cells get coarsened and it seem to depend on some weird factors (library versions, etc.).

Maybe one of the two things happened?

[gassmoeller]

Yes I have observed 2. as well. For now I think 1. is more likely for my model (I have large regions that remain at coarse levels, so maybe process 0 simply has no finer levels).

[bangerth]

Not sure if that has anything to do with it, but if you have many cells with the exact same error value (zero in your case, but can also happen if the solution and mesh are both symmetric left/right, or similar) then it is in essence up to random factors which cells get refined/coarsened or not. I've never been terribly worried because these cases don't happen in real computations.

[gassmoeller]

I think the interesting thing about the case Timo described was that even if 'Coarsening fraction' is set to 0.0 coarsening might happen. Could this happen if the error indicator in those cells is 0.0 and therefore the fixed error fraction coarsened of course does not exceed 0.0? This would then be a special case of what Wolfgang described.

[bangerth]

In parallel, we do a bisection search to find the threshold below which we have to coarsen. With bisection, you're never going to find an exact value, so we terminate the bisection steps after a fixed number of steps. So you end up with a positive threshold below which we coarsen. I think this leads to the case you describe.

[gassmoeller]

Ah, ok. Would it make sense to introduce a bypass for a coarsening fraction of 0.0? I guess this would change the behavior for quite a few users of deal.II, but the current behavior is somewhat surprising to me (I was relying on the fact that no coarsening is happening if the fraction is set to 0.0)

[bangerth]

It's possible. I think in deal.II we've learned from experimenting with this function many times that it's tricky. But we could do it in ASPECT.

I don't know whether that's your problem, though. You might have to try out.

[tjhei]

Yeah, I was thinking that it makes sense to short-circuit refinement and coarsening fractions of 0.0 and 1.0 inside the deal.II function.

[bangerth]

The deal.II functions make no assumption that all refinement/coarsening indicators are actually non-negative. So I don't think you can treat zero indicators differently.

You could try to treat zero (or one) refinement fractions differently, though. I think that's what you suggest.

[gassmoeller]

The bug is fixed by #893. I will open another issue for the possible bypass of refinement to keep issues separate.