I am in the process of converting an Abaqus UEL (user element) to a CalculiX user element in order to perform calculations on open source software. Unfortunately, I have run into issues during the conversion. Specifically, I receiving the following error “*ERROR in frd: cannot open substructure stiffness file for reading…” when I try running the compiled subroutine on a single element calculation. Does anyone know what might cause this? My initial debugging trial was to fully specify the matrix (assuming a plane-stress quadralateral linear element) so I could troubleshoot other aspects of the user element (it needs 27 constants and at least 8 state variables), but this resulted in the same error message. I’m using the 2D case for unit testing because that was how the original subroutine was implemented.
As I worked through some of the source files, additional questions came up. In ``matrix2userelem.f’', it is stated that it is assumed that there would be 3 (or 6) dofs, not 2 as I provided. Is this causing the issue?
Initially, I was only planning on running 2D calculations (they run significantly faster and I typically deal with planar geometries), but I have read through the documentation and the different forums that CalculiX automatically expands 2D elements into 3D and then uses constraints to enforce plane stress (or plane strain) conditions. Does this mean I need to do this myself in the user element? Note that I was already hoping to write a 3D element as well (in addition to quadratic order elements for 2D and 3D), but I obviously would prefer to start with the simplest case before moving onto the more challenging cases.
Does anyone have some suggestions as I fix the aforementioned issues?
From email discussion with Guido @dhondt, I instead just focused on the 3-D element and am ignoring trying to put together a 2-D user element at this time. Additionally, he realized he forgot to add a line in the user element documentation in CCX 2.22 (and potentially some previous versions?) that a modification needs to be made for each new user element around line 371 in mastruct.c or else it will be read as a substructure.
As troubleshooting the (cohesive) user element continues, my code compiles fine but I have ran into a separate issue. After resultsmech_uczm.f is called, the code fails almost immediately with the error free(): invalid pointer followed by Aborted (core dumped). From looking online, it appears this commonly happens when there are memory issues. I have already turned on -fbounds-check and am using valgrind as well to try and figure out what is going on.
One thing that is different in my user element case is that, for historical reasons, the local matrix and vector are computed at the same time using current node locations. This requires me to save the stiffness matrix to be called later by e_c3d_uczm.f. As a sanity check, I stored the U1 vector using a modified store subroutine and the U1 element still ran, so I don’t think the storage is a problem.
If anyone has helpful hints or thoughts on what might be causing issues, please let me know.
The memory issue was caused by an incorrect iteration over the integration points. If one uses resultsmech_u1.f as a guide for the user element, there is a coding error around line 432 where one loops over the integration points. In resultsmech_U1.f, the do loop goes from 1 to nope, not 1 to mi(1). In the case of U1, there is no issue because the integration points and nodes per element are the same; however, this won’t necessarily be the case elsewhere. In resultsmech_us3.f, the number of integration points is hard-coded.
There has now been partial success. After switching solvers from spooles to pastix, I was able to get the unit tests to converge. Given the results from this thread and that, in general, cohesive-zone model calculations are inherently non-linear, I wondered whether or not I would need to switch to a better numerical solver.
What I was not expecting, however, is that the pastix solver only solves the unit tests when valgrind is analyzing the calculation. Obviously, it is unreasonable to have calculations slowed down orders of magnitude because “debug” mode is required and memory leaks are being tracked. Therefore, unfortunately, the user element is not yet production ready, and I need to continue digging more into the code to see what might be going on within my user element/ccx to cause these problems.
Can you try solving with Intel’s MKL Pardiso? You may need to switch to the Intel Distribution for GDB, which is a superset of the regular GNU GDB, but works much better for pardiso.