Request toolbox compatibility LS-Dyna

[jfriedlein]

@adtzlr
I currently implement user material models in LS-Dyna with Fortran. Luckily, I found your tensor toolbox to be able to implement our tensor-based models.
Firstly, thank you so much for giving us such a well-written toolbox with, most importantly, a great documentation.
I found some minor issues when trying to use your toolbox in the Fortran version of LS-Dyna, as described below. Nevertheless, I use it now successfully. I also added some additional functions (volumetric part, deviatoric fourth order tensor, ...).
I was wondering whether I could contribute to your repository, so we get a toolbox for Abaqus, Marc and LS-Dyna.

ttb in LS-Dyna:
LS-Dyna probably uses an older Fortran version than Abaqus and Marc. When I include the toolbox, the following error results

.\ttb/libdiv.f(57): error #5286: Ambiguous generic interface OPERATOR(/): previously declared specific procedure DIV_10 is not distinguishable from this declaration. [DIV_10_R4] function div_10_r4(T, w)
... (for all functions ending with r4)

By simply deleting all the module procedure *r4 in ttb_library.f all errors disappear and we can use the toolbox (of course without the r4 variants). Is this because this fortran version cannot yet distinguish between data type-"templated" functions?

proposols:
Maybe we use a new ttb_library.f with the above modification or can incorporate this into a single file. The additional functions (vol, I_dev, ...) could be added to existing and new files.

If you can make time and give me an answer, I would appreciate it.

[adtzlr]

Hi @jfriedlein glad you like it!

I'm sorry that the toolbox didn't work for you out of the box. Unfortunately I can't delete all module procedure *_r4 lines because otherwise a tensor (always double precision in this module!) multiplication with a single-precision scalar does not work.

Example without the *r4 procedures:
2.0*T (assume T is a Tensor) --> Error
2.d0*T (assume T is a Tensor) --> OK, because the scalar variable is defined as double.

And I would like to have both lines working. Which Fortran version are you using? Strange - I never encountered that kind of error.

I'll see if it is possible do implement some IF-ELSE statements but I'm not really sure if FORTRAN allows that in the interface section. Otherwise I would have to create a second ttb_library_kind8.f file with only supporting double precision. Will report back what is possible.

Regarding the 4th-order deviatoric projection tensor: I did not implement it because there is a distinction between a physical deviatoric and a mathematical deviatoric projection tensor, e.g. the physical one related to the PK2-stress S and the right cauchy green tensor C:

Eye = identity2(Eye)
P4 = (Eye.cdya.Eye) - 1./3.*(invC.dya.C)

whereas the mathematical deviatoric projection tensor is just:

P4 = (Eye.cdya.Eye) - 1./3.*(Eye.dya.Eye)

And, finally, as it is totally easy to generate P4 with the Kronecker Delta Eye I did not implement P4 inside the toolbox. I would like to keep things simple to maintain.

What do you mean by your vol function? Is it just the trace (in a mathematical sense: double contraction with kronecker delta) or do you mean the spherical tensor 1./3.*(Eye.dya.Eye)? Again, I tend not to make specific functions for that stuff. The trace is of course part of the toolbox.

Last but not least: I'm open for code improvements and extensions. Feel free to contribute!

Best regards,
Andreas

[adtzlr]

@jfriedlein Okay, I did some experiments with precompilation flags #define, #ifdef but so far I had no success. My (failed) solution was something like

#define tensordyna
use Tensor

and inside the Toolbox

#ifndef tensordyna
module procedure dot_40_r4
...
#endif

and renamed files to ttb_library.F (uppercase file extension to ensure precompilation)

...but I get compilation errors in gfortran (can't test Intel Fortran at home).

[adtzlr]

I found a solution which works in gfortran. I had to change the include statement from include 'NAME' to #include "NAME". Will test the change with Intel Fortran in Marc and report back.

Edit: Solution works! Will update source and docs tomorrow.

[adtzlr]

@jfriedlein please download again, adapt your code from

include 'ttb/ttb_library.F'
...
use Tensor
...

to

#define NOR4
#include "ttb/ttb_library.F"
...
use Tensor
...

and save your files with UPPERCASE file extensions (filename.F). Now all *r4 procedures are excluded from compiling and it should work now. Please let me know.

BR Andreas

[jfriedlein]

Hi Andreas @adtzlr,
thanks for the quick reply and already implementing the extension.
The #ifndef-construct works for me too. Some more r4 variants were hiding in the interface assignment (=) that require the same construct. I added these two if in the attached `ttb_library.F' (at round line 400). ttb_library.txt (I haven't yet figured out how the pull request business works, so it's simply attached.)

LS-Dyna Fortran Version:
I am not absolutely sure, but it think LS-Dyna uses Fortran 90 (using Visual Studio 2017 and Intel Parallel Studio XE 2017). Which version does Abaqus use?

module procedure *r4
I never came across this error, when computing e.g. ´2.*T`, maybe it's due to the older Fortran. Nevertheless, as you say, it should work for both variants, so at least in the newer Fortran version, we need the *r4 templates.

Fourth order deviatoric tensor:
I use the mathematical deviatoric tensor that "filters" the deviatoric part out of a tensor. I mainly use it for the tangent moduli. Yes, it is simple to generate, but still more error-prone to implement it by hand. Moreover, isn't it easier to maintain "one line" of code in the toolbox, instead of having to read it up in a book and implement it in a 100 UMATs individually? Maybe I am just too used to having every operation, transformation and standard tensor at my fingertips from deal.II (https://www.dealii.org/). Honestly, I didn't even know that their are different deviatoric tensors doing different things, but that's what a documentation should tell a user, so they use the correct function for their task.

Volumetric part of a tensor:
Yes again, it is quite simple 1/3*tr(tensor)*Eye, so vol(tensor)+dev(tensor)=tensor. I just like having functions that do even tiny tasks for me and are guaranteed to be correct. Less to care about when debugging (e.g. the above sloppy integer divison 1/3).

Next:
I will improve my code, rework my design and see which functions are left. Currently, it looks as if I also use some functions that are LS-Dyna specific (vectorisation, data stored as lists, ...). When I cleared that up, I will give you a pull request and you can decide what to add.

To sum up, we could close this issues. Thanks again.

Best regards,
Johannes

[adtzlr]

@jfriedlein Thanks for the missing _r4 lines. I already updated it - I closed this issue.

Do you think it would be possible to generate a minimal (and tested) working UMAT example for LS-Dyna which could be included in the docs section? I think that would help other users a lot. For Marc I think the Neo-Hookean or the St.-Venant-Kirchhoff HYPELA2 (that's the name for UMAT in Marc) serves as a reference example.

I think you did not get an error because somehow constants like 2. are forced to be double precision. Maybe there is some compilation flag active through the call of LS-DYNA. Glad we found a working solution!

For the deviatoric fourth-order projection tensor: What name would be appropriate for that? dev is already reserved for the deviatoric part of the tensor. I think something like devproj4 or dev4 would be a good name as I already used identity4 for the fourth-order-identity tensor. Anyway, I'm still thinking of outsourcing such functions to a new TensorHelpers module. Then there would be only the essential basics in the Tensor module like (double)-dot products and all the dev, identity4 stuff in an extra module TensorHelpers or TensorMechanics. On the other hand a single include and use statement is shorter than two :).

Will have to sleep some nights until I make a decision :)

[jfriedlein]

@adtzlr
LS-Dyna UMAT example:
An example is a good idea, a toolbox needs to be well documented. I will see what I can do. Currently, I could offer small strain elasto-plasticity with linear isotropic hardening (and the tangent; just to give you an impression: usrmat plasticity (still raw)) to e.g. show some functions (dev, norm). Alternatively, something minimal as linear elasticity.
FYI: I work on a documentation on some basics (kind of a beginner's guide, https://github.com/jfriedlein/usrmat_LS-Dyna_Fortran), because others in my project also need to implement material models in the future. Hence, I want to collect things I stumbled over (still lots of work).

Deviator tensor:
I like the convention to end functions with '4' to indicate they consider fourth order. So something like dev...4 (e.g. maybe dev_I4, deviator_I4, 'I' for unit in 'deviatoric fourth order unit tensor'; Which one is more common 'projection tensor' or 'unit tensor'?).

Helper modules:
I think that's it. As in C++ or Python, one could load the desired modules. So we have the essentials toolbox with all data types, standard tensors and operations to handle tensors in general. And then separate modules can be added for the specific use case (kinematics with as many helpers as one desires, left Cauchy-Green, Pull-back, Push-forward, ...; separate specifics for fluid mechanics, electro... you name it). Additionally, I could imagine an LS-Dyna module with functions like storing tensors in lists and retrieving vectorised data types (so stuff that is only needed and works like that in LS-Dyna).

I'm glad to help where I can, so just tell me where I can contribute. I will send you the LS-Dyna example UMAT this or next week.

[jfriedlein]

Hi Andreas @adtzlr,
I added a pull request with the LS-Dyna example example: ttb use in LS-Dyna.
Additionally, I tested an approach to extend the toolbox by modules, so we could move the discussion over there: How to extend the tensor toolbox.