The JuliaFEM software library is a framework that allows for the distributed processing of large Finite Element Models across clusters of computers using simple programming models. It is designed to scale up from single servers to thousands of machines, each offering local computation and storage.
This is related to issue #94. Purpose of this pull request is to improve postprocessing abilities so that we can do more realistic analysis of results. More or less this involves reading the quantities from secondary fields, like stress, strain, check contact pressures, reaction forces and so on. Key point in here was to create a standard way to do postprocessing after solution of primary field is found and write these results to Xdmf file ready for visual inspection using Paraview.
As a result, we now have new variable postprocess_fields in datatype Problem, where names of optional fields are stored. After that user must define new function postprocess!(problem, time, field_name) and function is automatically run by solver for problem after solution. The idea in action can be seen for example, here and here is test.
Example
We analyze the same splitted unit block as in contact patch tests,
Relevant commands in test file are
push!(upper.postprocess_fields, "strain", "stress")
push!(lower.postprocess_fields, "strain", "stress")
for bc in [bc_upper, bc_lower, bc_sym13, bc_sym23]
push!(bc.postprocess_fields, "reaction force")
end
push!(interface.postprocess_fields, "contact pressure")
Results
Deformed shape is already known
For example, strain and stress component 6, extrapolated from Gauss points to elements:
Parts has different modulus of elasticity, for that reason strain of upper block differs from lower but stress is still constant. Contact pressure:
Reaction force:
Further notes
Modal solver is still using old way to create Xdmf files and needs to be updated also.
Postprocessing of contact pressure is somewhat hard because contact pressure for master elements is 0 (Lagrange multiplier are on slave side). We should add master elements to contact problem somehow different way that adding all elements to problem.elements, i.e. contact.elements = [slave_elements; master_elements]. (When writing contact problem to Xdmf file, we should only include only slave side.)
Coverage decreased (-0.9%) to 90.171% when pulling eff89a0c4bc0170f08e21deffc1c0f64670a2711 on feature/postprocess into 48006a144d27d5b3512c4ebd6ad0fb077624e4ca on master.
Introduction
This is related to issue #94. Purpose of this pull request is to improve postprocessing abilities so that we can do more realistic analysis of results. More or less this involves reading the quantities from secondary fields, like stress, strain, check contact pressures, reaction forces and so on. Key point in here was to create a standard way to do postprocessing after solution of primary field is found and write these results to Xdmf file ready for visual inspection using Paraview.
As a result, we now have new variable
postprocess_fields
in datatypeProblem
, where names of optional fields are stored. After that user must define new functionpostprocess!(problem, time, field_name)
and function is automatically run by solver for problem after solution. The idea in action can be seen for example, here and here is test.Example
We analyze the same splitted unit block as in contact patch tests,
Relevant commands in test file are
Results
Deformed shape is already known
For example, strain and stress component 6, extrapolated from Gauss points to elements:
Parts has different modulus of elasticity, for that reason strain of upper block differs from lower but stress is still constant. Contact pressure:
Reaction force:
Further notes
problem.elements
, i.e.contact.elements = [slave_elements; master_elements]
. (When writing contact problem to Xdmf file, we should only include only slave side.)