CM2 FEM® Engines /release 4.4.0
- May, 2019
- All CM2 FEM® Engines
- Major release of the CM2 FEM® Engines
- Due to changes in the API, client applications must be recompiled against the new headers
- Lib names suffix is
_44for this series.
- New Visual Studio 2019 builds (Win32/64).
- New GCC 7 and GCC 8 builds (Linux32/64).
- Solvers are now OMP-parallelized on macOS.
- Now requires run-time type information (RTTI), i.e. option /GR on Visual Studio.
- Visual Studio < 2010 and GCC < 4.8 are no longer supported (minimum versions raised to Visual Studio 2010 and GCC 4.8).
- The Visual Studio 2019 builds target Windows 7 or later. Windows XP is still supported for the Visual Studio builds ≤ 2017 but deprecated.
- macOS < 10.9 is no longer supported (minimum deployment target raised to 10.9 Mavericks).
- New elasto-plastic laws (only Prandtl-Reuss types based on Von-Mises criterion and isotropic hardening so far):
- Scalar laws:
- 1-D laws:
- 3-D laws (also used in plane-strains and axi-3d models):
- Scalar laws:
- All solvers now manage elasto-plastic states, both from an initial state and to an output state (through the new
fem::FEM_statesclass, see below).
→ Caveat: at present elasto-plastic laws are not thread-safe. You shouldn’t run concurrently several solvers (
fem::solver_static_Newton) that change plastic states in shared laws (or duplicate the laws).
- New class
fem::solver_least_squares(superseding the former deprecated
fem::solver_stress_nodal) to post-process data on nodes.
This new class can smooth stresses but also cumulative plasticity, plastic strains, total strains, Von-Mises stress and heat flows (see below).
- Cumulative plasticity and plastic strains can also be computed on an element-by-element basis with
fem::FEM_statesto gather DOF-indexed solutions (similar to
fem::FEM_matrix), thermal stress managers and internal states (historic plasticity parameters at integration points) required to reproduce (usually equilibrated) FEM states.
fem::FEM_statespublicly inherit from
fem::FEM_matrix(and has a conversion constructor), instances of this new class can almost be used anywhere a
fem::FEM_matrixused to be required.
Thermal static analysis
- New thermal models
fem::model_heat_conduction_3d(scalar isotropic Fourier models).
These new physics models should be associated to the new
fem::numerical_model_heat_conductionand, just like the mechanical model counterparts, to a mesh connectivity matrix (all element types are supported).
- New user-defined thermal matrices:
fem::solver_thermal_static_linearto solve static linear thermal problems.
- Heat flows can be post-processed on nodes with the new class
fem::solver_least_squaresgeneralizing the former
fem::solver_stress_nodalclass (see below).
fem::elementary_serverhas been updated to computes elementary thermal matrices, vectors, temperatures and flows.
fem::solver_condensation_staticcan now condense also thermal models.
For that purpose the new field
fem::solver_condensation_static::settings_type::physics_kindshould be set to
elementary_loadnow accepts also
HEAT_FLOWfield types and works with
fem::loads_mgron both Dirichlet conditions (
TEMPERATURE) and Neumann conditions (
- Supersedes the deprecated
fem::solver_stress_nodalto post-process data on nodes.
This new class smooths stresses as before but now also cumulative plasticity, plastic strains, total strains, Von-Mises stress and heat flows.
fem::law_shell_skylinefor full (skyline profile) user-defined plate/shell elasticity law.
fem::law_solid_skylinefor full (skyline profile) user-defined solid elasticity law.
fem::post_processor_1dcan now work on non-linear beam/rod models.
Note that diagrams are not exact in these cases, especially when the elements are subjected to large displacement/deformations (exact only for 2-node linear thin, non-tapered beams/rods).
fem::solver_z_impedance: now accepts Dirichlet boundary conditions.
Just as Neumann boundary conditions (force & momentum loads), Dirichlet boundary conditions are considered as periodic with pulsation
omega(i.e. forced vibrations).
data_type::output_stepsgiving the number of equilibrated solutions in the
The last converged solution is at column
outputs.col(output_steps - 1)and
output_steps < outputs.cols()in case of convergence error.
output_steps == pseudo_times.size().
fem::context::set_max_total_sizeto set a limit for the total size of the global matrices.
- Port to Visual Studio 2019, GCC 7, GCC 8.
- Minor speed-ups in the computation of external load works.
- Use of OMP
orderedclauses for numerical reproductibility of the assemblies (factorizations and resolutions are still affected by parallel noise).
- Speed-ups with Dirichlet-only boundary conditions on unfixed DOFs (unfixed DOFs with prescribed values are now eliminated just like fixed DOFs).
- Minor speed-ups within the conjugate-gradient solver (called only with multiple load cases + mixed Dirichlet/Neumann conditions).
solver_modal, solver_modal_ldrv, solver_modal_gyroscopic, solver_buckling_Euler
- Minor speed-ups.
- Some crashes in multi-threaded resolutions when out-of-core (OOC) management is activated (i.e. for big models exceeding the value set in
- The P14 (quadratic pyramid) stiffness element was not fully compatible with T10 and W18 elements.
This caused significant numerical errors with quadratic mixed solid meshes.
- The quadrature schemes were inaccurate in W6, PY5, TH10, W18 and P14 elements (mass and stiffness).
For instance, we now use 5 points in TH10 stiffness (instead of 4), 12 points in W6 mass (instead of 6), 21 points in W18 mass (instead of 18).
This can lead to slight increases in computation times.
The quadrature scheme in P5 is also more accurate now (with unchanged number of points).
- Reproducibility issues.
- Serious performance issue with
settings.mass_matrix_kind = cm2::FEM_LUMPED_MATRIXand activated out-of-core (OOC) management.
- Didn’t take external loads into account. This led to inaccurate results.
- Crashed with 3-node beam elements and hard offsets.
- Bug when a problem had multiple load cases and different prescribed DOFs on these load cases.
As stated in the API, only the first load case should have been taken into account.
This wasn’t true. The next load cases could clobber this first one leading to erratic results.
- Could erroneously declare convergence.
- Any convergence error of the conjugate-gradient solver (called only with multiple load cases + mixed Dirichlet/Neumann conditions) was silently discarded leading to unwarned wrong solutions.
- Error on
data_type::Fc(usually wrong sign).
fem::numerical_models_mgr::get_NM, the returned numerical model lost track of its underlying mechanical model if any (i.e. the
fem::numerical_model_base::get_mechanical_model()is deprecated and renamed
fem::numerical_model_base::get_physics_model(). See below.
- Fix physical core count for some CPUs (Intel) and LLC size (AMD).
- The output solutions is now a
A conversion constructor is provided in
fem::FEM_statesto conveniently convert the latter into the former.
However using the new class is recommended wherever needed.
- For solvers with initial solution (almost all solvers) the initial thermal stresses field is removed and is now included in the field
- The input solution fields are renamed
data_type::sols_IDsare still valid but deprecated.
- The output solution fields are renamed
data_type::B_modesare still valid but deprecated.
- The output data
- Deprecated. Please use now
law_plane_strain, law_axi3d_stiff, law_axi_torsion_stiff
You must now use directly the
fem::law_solid_stiffinstead wherever the former laws was required (plane-strain, axi3d and axi-torsion mechanical model constructors and initializers).
- Former class
stiffness_symis now split into two classes:
fem::stiffness_symfor linear unmodifiable models (loosing the callback handler) and
fem::stiffness_sym_nlfor non-linear matrix modifiable through a call-back handler (
This latter class gains two additional handlers (
fem::stiffness_sym_nl::set_state_callback_handler_type) to allow users to manage internal states of elasto-plastic constitutive laws.
- The stiffness handler can now be called with
code_KFE = 0(i.e. none of the stiffness matrix, internal work vector or elastic energy is requested). In these cases, the
stiffness_sym_nlobject should consider the current solution
U_locas balanced (i.e. no longer virtual) and save internally its current (plastic) state. This happens at each Newton and Newmark step.
contact_plane, contact_cyliner, contact_sphere
- To help convergence of the Newton-Raphson algorithm, the stiffness law is now based on a Hill-sigmoid function instead of the former (not derivable) Heaviside march function.
The new parameter
lambdacontrols the slope near the
e = 0point (the larger, the stiffer the slope).
The default (
lambda = DBL_MAX) reduces the sigmoid to the former Heaviside function.
lambdaparameter can be negative. This has the effect of reversing the direction of contact (but only positive
radiusare now accepted).
fem::solver_condensation_static::data_type::Fcis now a
cm2::DoubleMat(to be consistent with
Used to be a
- The DOF stride is now 9 instead of 6.
This change shouldn’t have any impact if you use the
fem::DOFs_mgr::DOF_STRIDE()member as required (note however that this member is now deprecated, use
fem::numerical_model_base::get_mechanical_model()is left for compatibility but deprecated.
get_min_penalty_factor). And the behaviour changed.
The default penalty factor was used whenever the regular penalty factor (product of the raw penalty factor with the model’s characteristic stiffness) was 0.
This happened when the model had no sub-models associated to a mesh (only springs, links, punctual masses for instance).
Now, the minimum penalty factor is used as a lower bound for the regular penalty factor (even when this regular penalty factor is not 0).
The default value for this minimum penalty factor is still
1E12(like the default value for the former default penalty factor).
fem::context::memory_managementis deprecated. Please use
fem::context::set_max_incore_sizeinstead (with same parameters).
- New files in the API and changes in old filenames.
These changes shouldn’t have any impact if you include the main file
- Changes in
physics_typeenums (used in
- Changes in values of enums in
- Now built on Windows with
UNICODEencoding setting (used to be
This may impact functions taking a filename as argument such as