-
Notifications
You must be signed in to change notification settings - Fork 320
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
MFront and ElmerFEM: trying to get advance material behaviour the easy way in Elmer #528
Comments
Hi, This would certainly be a nice feature! I think the linking of a material model should be possible without compiling with the utility elmerf90. The following check may not be useful in any way, but how is the subroutine name mangled after compiling libABAQUSBEHAVIOUR.so with mfront? What does the command |
Here is a clean build of everything:
The library defines The Abaqus generated file which would be a valid Abaqus
As can be seen, the functions are the functions in capital letters with MFront also generates a Running
As can be seen, the names of the functions (at the top of the output) are those indicated by MFront. With the method of renaming functions that I indicated in my first message, the output is:
So Do you have any idea of what could be happening? I am using the Abaqus/Standard UMAT interface... |
Just as a quick update. I wanted to see what a compiled UMAT would generate, so I checked one out from when I ran the tests:
As it can be seen, the
The combination of points 3. and 4. make me think that the loading mechanism in ElmerFEM may be expecting the procedure to be the only one in the file or for it to be at the end. This is not true with MFront and it was not true even when I renamed the material law to be the symbol that ElmerFEM wanted. That would explain why, even with the name corrected, it could still not "find" the material law that I had created. Any opinion on this? @mmalinen |
When seeking for procedures, Elmer has used Fortran mangling so that a symbol name has been expected to be in lower case letters and to be appended with one underscore. If you update the Elmer code to get a fresh devel version, Elmer should also perform another attempt to locate the subroutine so that no name mangling is applied in the second try. That is, the symbol name sought should then be as given in the sif file. I think that having several symbols as defined in the code section doesn't cause a trouble. If I add another subroutine (test_add) so that nm says
loading stvenant_kirchhoff is still successful. On the other hand it seems that applying renaming as
is somehow problematic. If I apply this and then change the sif file so that stvenant_kirchhoff2 is sought instead, Elmer halts with
Actually Elmer can still find the procedure with its original name, although nm displays
Anyhow I suggest that you try to use the new devel version so that no attempt to rename might be needed. |
I have just rebuilt ElmerFEM. It is still not working...
The first bit is just the output of
I have also seen that
It seems the library paths are all messed up! Maybe this is an indication of another issue... Probably in the configuration/CMake step... The Apptainer file I used to build the entire setup:
Do you have any ideas/input on what may be wrong here? |
Hi all,
I think this could be a forum post, but since this requires somewhat non-trivial programming knowledge, I will write it here.
MFront/TFEL is a wonderful utility to create advance material behaviours which then can be used in a variety of other mechanical simulation programs, such as Abaqus, ANSYS, Code_Aster, etc. MFront allows for quite complex behaviours and data transfer/parameter dependency between the material behaviour and the simulation data too. Since ElmerFEM has some support for Abaqus' UMAT subroutine, I wanted to see if MFront's Abaqus support could be used directly on Elmer. This would open the possibility to doing quite complex mechanical simulations with Elmer (both in small strain and finite strain), specially when coupled with other solvers.
Anyhow, here is what I have found:
Setup
UMAT_linear_isotropic_2D
as the baseline. I ran the test as is and it works.elasticity.mfront
file (taken from the MFront examples) as the target behaviour. This file mimics what is found in thelinear_isotropic
behaviour law that is called from the.sif
file. Here are its contents:.sif
file so that the material would only have 2 properties defined, the Young Modulus and Poissons' coefficient (I basically took out the density)..mfront
behaviour targeting Abaqus:mfront --obuild --interface=abaqus elasticity.mfront
.sif
file to point to the correct behaviour and function, basically I modified the line:UMAT Subroutine = File "UMATLib" "linear_isotropic"
forUMAT Subroutine = File "./src/libABAQUSBEHAVIOUR.so" "ELASTICITY_PSTRAIN"
.sif
file, this is what I got:Results
Well, as it was somewhat expected, the simulation did not run... Why is it failing?
elasticity_pstrain_
elmerf90
, which probably has all the naming/linking setup required for the use of Fortran code within the solvers.objcopy --redefine-sym ELASTICITY_PSTRAIN=elasticity_pstrain_ libABAQUSBEHAVIOUR.so
which works and was verified withobjdump -x
.ElmerSolver
still generated the errorLoad: FATAL: Can't find procedure [elasticity_pstrain_]
.../fem/src/Load.c
:Conclusion
I do not know if this is interesting to anybody here, but MFront would allow easy, advance and complex material behaviours in ElmerFEM. This could be a very appealing addition to the simulation capabilities of Elmer... And once again, specially when multiphysics are involved (thermo-mechanical or electro-mechanical for example). MFront, as said in the introduction, has several interfaces, one of them, is the generic interface in case this interface, instead of Abaqus' is preferred.
Though I am aware that the mechanical computations that ElmerFEM can do are quite limited (no transients!), but it would be a nice step forward IMHO :)
If you need more info or would like to help with ideas, please, say so!
Best regards,
Fer
The text was updated successfully, but these errors were encountered: