One of the limitations of CalculiX is that it can only output averaged nodal stresses in .frd files. If you need them at the integration points (where they are originally calculated and most accurate) you can use .dat file output but that’s not very handy with larger models. Fortunately, ParaView can help with this. It features a whole group of filters called Quadrature Points. Here’s what you can do with them, in order:
Generate Quadrature Scheme Dictionary - uses a built-in library of Gauss points (unfortunately, only full integration linear and quadratic elements of the following types are supported at the moment: triangle, quadrilateral, tetrahedron*), necessary for subsequent filters
Interpolate to Quadrature Points - as the name suggests, this filter interpolates the nodal data to integration points
Generate Quadrature Points - generates integration points so that you can visualize them and make measurements using point selection tools like Hover Points On
For better visibility, increase the Point Size a bit (you can also render them as spheres) and show the results of the Interpolate to Quadrature Points Filter with Representation set to Wireframe or some Opacity.
*Linear tetrahedron elements in CalculiX have a single integration point while ParaView assumes 4 integration points for this type of element. Of course, ParaView doesn’t account for CalculiX-specific expansion of 2D elements to 3D ones. So it might be best to use this functionality for quadratic tetrahedrons for now. Fortunately, they are the most commonly used elements in PrePoMax.
Showing the integration point values is an interesting feature.
Yet, I guess that the integration point values displayed as described above aren’t the true IP values, because they are back-interpolated from averaged nodal values if you don’t suppress the averaging.
You will most likely have different values in ParaView and in the dat file. In particular, in ParaView you still can have IPs with the equivalent stress exceeding the yield stress, whereas in the dat file this should not happen.
To avoid this, you need to output the nodal values for each element separately. How to do this has been discussed in other threads here. I made a python script for this purpose.
Of course, this is just an interpolation of averaged nodal stresses from the .frd file to integration points. It’s a simple workaround if someone wants to generate those points (they are actually created and displayed) and make measurements at them. Their coordinates can be displayed as well. More accurate solutions require scripts (also in ParaView). It would be best if a user could choose the way stresses are written to the .frd file by CalculiX using keywords. For example, Abaqus provides the following options:
I understand that the FRD file format generally isn’t capable of handling integration point variables. Yet, with the separation.py approach you get the precise IP values in Paraview assuming that the interpolations on ccx and ParaView side are equivalent. No need for additional scripting inside ParaView.
For Prepomax, it might be an option to use the dat file values (with assumed locations of the IPs. Based on the dat file, all the options you listed from ABAQUS would be available in the postprocessor.
I wonder if the Python script can affect the computational time, compatibility with other SPCs or MPCs like rigid bodies, and whether it works for shell elements. I think this approach would be nice when two materials share the same mesh. Using the procedure, the material domains could be split and correct nodal values obtained.
So a universal solution would be to use .dat file to get IP values and then use the post-processing set by the user. I am only afraid that this would work only for smaller meshes since the .dat file will be huge.
In principle, the computation time should not be affected too much, because the number of dofs does not change. However, the amount of data changes massively, because internal nodes of the mesh are split into 8 nodes in a structured hex mesh.
As to the materials: It is on my todo list to create the split not by element but by element set. That would prevent averaging over set boundariesm much like ABAQUS doesn’t average over different materials. Should not be too complex to do. Perhaps one could call separate.py with the mesh file and some additional set definition files (e.g. .nam files from CGX). Inside Prepomax you could offer this for materials by default.
Recently I tested the approach for plane strain elements and it seems to work, except for the node numbering depencence, where separate.py is not to blame. So it might work also for shells but I didn’t test it.
