1% Performance assessments 2% Helfer Thomas; Jean-Michel Proix 3% August 20, 2014 4 5# Benchmarks made in the `PLEIADES` platform 6 7## Fuel performance codes based on the `Cast3M` finite element solver 8 9Numerous performances assessments were made within the PLEIADES 10platform : replacing fortran implementations by their `MFront` 11counterparts led to significant improvements, from \(30\%\) to 12\(50\%\) of the total computational times of some fuel performance 13codes developed in the platform. 14 15This improvements were mainly due to fact that the behaviour 16integration schemes changed from explicit Runge-Kutta schemes to 17implicit ones. The main benefit of `MFront` was to grant users an easier 18access to the implicit schemes. 19 20## `Cyrano3` fuel performance code 21 22Relying on the specific modelling hypotheses supported by this code, 23namely axisymmetrical generalised plane stress and axisymmetrical 24generalised plane strain, highly specialised and efficient 25implementations of mechanical behaviours were developed in `Cyrano3` 26fuel performance code [see @thouvenin_edf_2010] for both isotropic and 27orthotropic materials : numerical integration boils down to solving a 28scalar non linear equation in both cases and provides the consistent 29tangent operator. 30 31The figure below compares the total computational times of a native 32implementation of a cladding behaviour to its equivalent `MFront` 33implementation: the last one appears to be competitive with the native 34implementation (the average computational time using the `MFront` 35implementation is sightly lower than the average computational time 36using the native implementation). 37 38 42 43# Benchmarks based on the `Code-Aster` finite element solver 44 45--------------------------------------------------------------------------------------------------------------------------------------------------------------------- 46 Behaviour and test description Algorithm Total computational times Graphical illustration 47 (`Code-Aster` vs `MFront`) 48------------------------------------------------------------------- ------------------------- ------------------------------- ------------------------------ 49Visco-plastic and damaging for steel `Implicit` \(17mn 43s\) vs \(7mn 58s\)  50[see @mustata_creep_2005;@edf_comportement_2012] 51- 3D Notched specimen 52implying large deformation 53 54Damaging for concrete `Default` \(45mn\) vs \(63mn\)  55[see @mazars_new_2014;@edf_modeendommagement_2013], 563D beam bending 57 58Generic Single crystal viscoplasticity `Implicit` \(28mn\) vs \(24mn\)  59[see @meric_single_1991;@edf_comportements_2013-1], 603D aggregate, 300 grains 61 62FCC single crystal viscoplasticity `Ìmplicit` \(33m54s\) vs \(29m30s\)  63[see @monnet_orowan_2011@edf_comportements_2013-1] , 642D specimen with displacement boundary conditions 65from EBSD experiment 66 67FCC homogeneized polycrystals 30 grains `Runge-Kutta 4/5` \(9s67\) vs \(8s22\)  68[see @berveiller_extension_1978;@edf_comportements_2013-1], 69 unit testing 70 71Anisotropic creep with phase transformation, `Implicit` \(180s\) vs \(171s\)  723D pipe [see @edf_modecomportement_2013] 73----------------------------------------------------------------------------------------------------------------------------------------------------------------------- 74 75Table: Some benchmarks comparing the implementation generated through 76`MFront` to the native implementation provided by the `Code-Aster` 77finite element solver. Graphical illustrations shows that the results 78obtained with both implementations are indistinguishable. 79 80Developers of the `Code-Aster` general purpose finite element solver, 81made independent extensive tests, comparing their own native 82implementations to the ones generated with `MFront`, generally using 83an implicit scheme in both cases. Without discussing the very details 84of each test performed, several general conclusions can be drawn: 85 86- native implementations offers superior performances in the case of 87 simple explicit behaviours (Mazars damaging behaviour 88 [see @mazars_new_2014]) in the case of isotropic behaviours that can be 89 reduce to one scalar equations [see @chaboche_integration_1996]. For 90 explicit behaviours, the difference will be reduced by the 91 development of an optimised treatment of `MFront` behaviours. In the 92 second case, the difference can be explained by the fact that the 93 Code-Aster implementations uses the Brent algorithm 94 [see @brent_algorithms_1973] which clearly outperforms the standard 95 Newton method. The availability of this algorithm in `MFront` is 96 planed. 97- for more complex behaviours, `MFront` implementation are on par 98 or outperforms the native implementations. 99 100For a given behaviour, the development time was found significantly 101lower with `MFront`. 102 103# References 104 105<!-- Local IspellDict: english --> 106
