At the application level, the Solver is responsible for computing an approximate solution of the initial equation. The solver iterates over time. At each iteration, the behavior of the solution from the previous iteration (or from an initial guess at cold boot) is checked against too steep variation, as described in [10]. When such variation appears, the checking procedure also computes a tolerance delay, and issues a request for mesh refinement. The tolerance delay is the number of non-linear iterations during which the current mesh can remain in use. Moreover, the checking procedure computes two types of indicators: the first one relates the mesh elements to the quality of the solution, and the second one provides information about computing load on a per-element basis.
When a request for mesh refinement has been issued, the computation continues until the tolerance delay is exhausted. At this point, the new mesh is acquired and the time iterations can go ahead.
Currently, mesh refinements are serialized. For a given iteration, only one domain can ask refinement, and the request must be complete until a new one can issue. Parallelizing mesh refinement requests does not make sense, because the remesh logic is inherently serial. Pipelining is an interesting possibility.