UMAT option in PrePoMax

Feature Requests
1

I have a suggestion regarding some future versions of PrePoMax. It would be great if an option of using user material (UMAT) subroutines in the *Material card was implemented. Usually if I want to use UMAT for my calculations I properly modify the input file using “Edit CalculiX Keywords” option. However, it would be way more convenient to have an option of choosing UMAT in the “Materials” window.

Suppose that we’ve written a UMAT code and then compiled it to a *dll file which is kept in the same folder as ccx.exe. Now, there is a question how this UMAT subroutine will be called by the “Material” card in the CalculiX input file. Suppose that your *dll file containing the UMAT is called CHABOCHE.dll and requires defining 11 material parameters and 19 internal variables (quantities which will be updated during a calculation step and subsequently passed to the next step). Depending on the nature of your UMAT code there are three options here:

  1. If CHABOCHE.dll contains a CalculiX UMAT subroutine (CalculiX’s native interface for defining user’s materials) you write:

*MATERIAL, NAME=@CHABOCHE
*USER MATERIAL, CONSTANTS=11
180000,0.33,114,0,32,60632,572,0.66,
10,92,8
*DEPVAR
19

  1. If CHABOCHE.dll contains an Abaqus UMAT for the small strain formulation (NLGEOM=off) you write:

*MATERIAL, NAME=@ABAQUS_CHABOCHE
*USER MATERIAL, CONSTANTS=11
180000,0.33,114,0,32,60632,572,0.66,
10,92,8
*DEPVAR
19

  1. The last option. If CHABOCHE.dll contains an Abaqus UMAT subroutine which is supposed to be used for the large strain formulation (NLGEOM=on) you write:

*MATERIAL, NAME=@ABAQUSNL_CHABOCHE
*USER MATERIAL, CONSTANTS=11
180000,0.33,114,0,32,60632,572,0.66,
10,92,8
*DEPVAR
19

It should be emphasized that CalculiX allows you to list only 8 material parameters in a single row. If you need to define more material parameters you must start listing the remaining parameters from another line.

So these three options should be included in the window (CalculiX UMAT, Abaqus UMAT for NLGEOM=off and Abaqus UMAT for NLGEOM=on). Then a table for entering the material parameter values (with the limit: eight parameters per row) and finally a bracket for specifying the number of used internal variables (*DEPVAR card).

Regards

2 Likes
2

Subroutines require recompiling CalculiX, right ? Support for them (especially for UMAT which is likely the most common and useful subroutine) in GUI would be really nice but maybe it would be better to implement more of CalculiX’s built-in material models (like hyperelasticity and creep) first. Subroutines require a lot of work anyway and calling them from the *MATERIAL card is the easiest part. However, it’s great that you described it in such detail, discussing different possible scenarios. Such description can be really useful once user-defined material implementation starts taking place.

1 Like
3

All you need to do is to compile the UMAT.f file (Fortran 77 file) to a dll library file. Then you place the *dll file into the same folder as ccx.exe (the solver) and you are ready to go (the way I described it above). You don’t have to recompile the whole solver.

1 Like
4

That’s a good news. Based on the following quotes from the documentation, I thought that recompiling CalculiX is necessary:

To use a user subroutine, replace the dummy routine in the CalculiX distribution by yours (e.g. dflux.f from the distribution by the dflux.f you wrote yourself) and recompile.

After storing umat main.f and umat drucker prager.f, umat drucker prager.f has to be added to the FORTRAN routines in Makefile.inc and CalculiX has to be recompiled, i.e. a new executable has to be generated.

5

I can recall reading something that recompiling the whole program along with the new material file can improve robustness but’ve never tried this.

6

This is the topics i discussed before, a propose to PrePoMax to provide plain text file in GUI or be capable using xml format in material library files.

Currently a Json material library files are fixed to some amount parameter and structured inputs, not free format as plain text This feature are not in priority since keyword editor can handle the task easily.

But, ability to read and save a user material in library files are still good feature to be implemented. Simplify a workflow in simulation for the user.

7

If I understand it curretly yopu are talking about something similar to the utility which is offered by Abaqus. That is: if your installation of Abaqus is linked to a proper version (!) of Intel Fortran Compiler Abaqus will compile your Fortran file (for instance a UMAT) every time you submit a job for the solver.

In CalculiX this can be done using a simpler way (as one fellow user instructed me). I compile my UMAT file to *dll library using a separate compiler (Msys Mingw64) and then (as I wrote above) I place the obtained *dll file into the same folder as ccx.exe and include the dll’s name in the *Material card of the input file.

So personally I would NOT expect from PrePoMax to be linked with a Fortran compiler and be able to compile my subroutines each time I submit a job. I am fine compiling my subroutines manually using Msys Mingw64.

What I propose here is including the option of using a UMAT in the material definition window in GUI. Of course, with several options (CalculiX native UMAT, Abaqus UMAT with nlgeom=off and Abaqus UMAT with nlgeom=on), a table to define the material parameter values and a bracket to define DEPVAR (the number of utilized variables uodated in subsequent computational steps).

8

Not like these, i mean PrePoMax capabilities to read free format of text input material parameters. so make it all material type can be supported.

Regarding to Umat or any advanced material linked to MFront is another task. It can be separated and be done outside PrePoMax, statically linked by recompile or dynamically linked trough Dll’s

However, a direct compilation of umat source files inside PrePoMax is usefull feature also. Even the installation file become large due to the compiler included.

9

As discussed in a private email with Cyprian, the keywords *User material and *Depvar could be added to the current material properties and I think that will save the issue.

The problem with a plain text file is that PrePoMax cannot understand the data written. That is why PrePoMax supports an .inp material data format.

image

But currently the *User material and *Depvar cards are not supported.

2 Likes
10

Yes, exactly that’s what I have on mind. It would be great.

Here I quite can’t understand the idea of PrePoMax reading “plain text files”. As I say, my point is different.

My point is to add some windows/brackets allowing one to define the *Material card in an input file like those exemplary ones which I posted above.

11

Maybe something like addition Costume in material models dialog trees. Then, a text box dialog available there for a user to type free format without fixed cell inputs.

12

I’m fine with fixed brackets. All one’s got to do is to choose the version of UMAT (one of the variants listed above), give the name of UMAT file, provide the material parameter values and finally DEPVAR.

13

Can you please tell me if I can download the compiled YOSHIDA.DLL (UMAT function) somewhere? I don’t know Fortran. Installed MinGW and Codeblocks to compile the file, but no luck.

image
image1540×882 201 KB

source:
https://d-nb.info/1257064762/34

14

as alternative, these material types also available in TFEL/MFront linked library

2024-03-03 06_25_34-Source
2024-03-03 06_25_34-Source828×341 14.3 KB