umat: Correct H, but wrong his(:,:) and therefore wrong paraview history output

[ryan]

I encountered an interesting problem during the implementation of a umat. After having apparently wrong paraview history variables output, I backtraced the cause to the point, where I have (1) indeed a correct H output in the O file (issued by SHOW H) from the one side. But, coming from the other side, (2) a wrong his(:,:) field arrives in p_paraview.f leading to the wrong paraview output. After learning from pparaview.f that his(:,:) is passed over by hr(np(305)) I decided to raise a short post here with the question, whether similar problems are already known and suggestions, where to look next in the code to continue backtracing the problem. Any recommendations are highly appreciated.

[Prof. S. Govindjee]

What version of FEAP are you using?

Also what element are you using with your user material?

Have you set the number of history variables that your user material uses in the variable n1 inside your umatiXX.f?  n1 should be set to the number of history variables per gauss point.

Last question.  Does your umatlXX.f routine set the time t_n+1 history values in the h1(*) array?

[ryan]

Sorry for not providing additional information in the previous question.

The answers:

- It is FEAP 8.5.
- The element is a plane strain 3 node triangle.
- The number of history variables is set by n1 inside the umatiXX.f.
- h1 is written at the end of the umatlXX.f.

Question from my side: I transfer the hn(*) field to an additional field as values at time t. This additional field will be updated by overwriting the current t values by the computed t+dt values and transferred back to the h1(*) field eventually. This might be problematic, if FEAP's understanding of hn(*) and h1(*) storage would be pointer based. Is there any pointer operation involved?

[Prof. S. Govindjee]

The storage space is explicit.

The basic process should be as follows:

1. Use the hn( : ) data as the time t_n values

2. Compute the time t_n+1 values and store them in h1( : )

That is all that needs to be done.

[Prof. R.L. Taylor]

The integers in hr(*) or mr(*) are integer*8 [ or integer (kind=8)  ::].  The ones in your local arrays should just be integer (which is by default integer*4 -- unless you compile as *8.

They are not pointers, just long integers.

[Prof. S. Govindjee]

I think you meant to say that the integers in NP(*) are integer kind=8, so that the arguments to HR(*) and MR(*) are kind=8.
So in reference to the original question, NP(305) is a kind=8 integer.

But the arguments to H1(*) and HN(*) only need to be integer kind=4.

[ryan]

I'm sorry to say that looking into the sourcecode was unfortunately pointless. The problem was a somehow wrongly wired mesh that originated from gmsh. Nevertheless, a job with the incorrect mesh ran without problems under a linear elastic constitutive model. Therefore, there was firstly no doubt on my side that the input deck must be correct and the umat faulty. That was unfortunately the wrong conclusion!

[Prof. S. Govindjee]

If you are using FEAP elements you can check for mesh errors using the CHECk command which looks for incorrect nodal ordering on elements.  If you are using your own elements then you need to program the check yourself for isw.eq.2.

Note that FEAP tries to internally correct problems found by CHECk.  To confirm whether and identified error has been found you can run CHECk a second time.