7. Conclusion — Perspective#

During numerical simulations using finite elements, obtaining a raw result is no longer sufficient. The user is increasingly requesting the calculation of spatial error in relation to the mesh. He needs methodological support and advanced « digital-computer » tools to assess the quality of his studies and improve them.

For this purpose, the spatial error indicators a posteriori make it possible to locate, on each element, an error map on which the remeshing tools will be able to rely: a first calculation on a coarse mesh makes it possible to exhume the error map based on the discretized data and solution (hence the term « a posteriori »), the refinement is then carried out locally by prioritizing this information.

The new a posteriori indicator that has just been implemented to post-treat the thermal problems of Code_Aster is based on their local residues extracted from the semi-discretizations in time. Via the option “ERTH_ELEM” in CALC_ERREUR, it uses the thermal fields (EVOL_THER) emanating from THER_LINEAIRE and THER_NON_LINE.

This new indicator complements the code’s offer in terms of advanced tools to improve the quality of studies, their pooling and their comparisons. Indeed, mechanical error indicators and a MACR_ADAP_MAIL [U7.03.02] refining/de-refinement macro are already available. It remains to complete the scope of use of these tools and to expand them, in particular to better manage non-linearities and spatial error/temporal error interactions.

Note:

Zhu & Zienkiewicz stress smoothing estimator (CALC_ERREUR + * ** OPTION “ERZ1/ERZ2_ELEM “[:ref:`R4.10.01 <R4.10.01>`]) and pure residue indicator (” ERME_ELEM “* [R4.10.02]).

Subsequently, the perspectives of this work are of several types:

  • From a functional point of view, the completeness of this indicator could also be improved by taking into account possible non-linear boundary conditions (FLUX_NL and RAYONNEMENT) and exchanges between walls (ECHANGE_PAROI). Ultimately, it would also be necessary to be able to rely on finite structural elements (shell…), pyramids and to be able to deal with convection-diffusion problems (operator THER_NON_LINE_MO [R5.02.04]).

  • From a theoretical point of view, when using new boundary conditions and/or when relying on new models (shell, beam…), a « numerical-functional » study similar to that in this document should be conducted to judge the theoretical and practical limitations (with respect to the*Code_Aster*) of such an indicator and exhume its ad hoc formulation.

Finally, let’s remember that a**myriad of retrospective error indicators are available, * and that quite few have been tested and validated on industrial cases. In order to refine diagnoses, establish comparisons and implement re-meshing strategies by problem class, it would be interesting to expand the list of available indicators. Different residual indicators plus local problem have thus proved to be more effective (but also more expensive) during numerical tests (in elliptical) in N3S [bib5].

Note:

The indicator is the standard for the solution of a local problem, of the same type as the initial problem, but discretized over higher-degree spaces and whose second member is the residue. Depending on the boundary conditions attached to this local problem, different types are distinguished. They thus combine the « hierarchical bases » vision and the « residual » aspects of retrospective error indicators.

The ideal consists in simultaneously discretizing time and space on appropriate finite elements and controlling their « space-time » errors in a coupled manner.**This « space-time » indicator**gives access to a complete control of the error and it makes it possible to avoid unfortunate decoupling in terms of possible refinements/deraffinations driven by one criterion in relation to the other (cf. discussion [:ref:`§4.5 <§4.5>`]). However, it is very cumbersome to set up in a large industrial code such as*Code_Aster. In fact, to be optimal, it requires nothing less than separate management of the time step using finite elements. From the point of view of the architecture supporting the finite elements of the code, this is a real challenge!