Intel® Fortran Compiler
Build applications that can scale for the future with optimized code designed for Intel® Xeon® and compatible processors.
28385 Discussions

value being NaN and (+-)infinity in fortran

Qingqing_Z_
Beginner
4,252 Views

Hi there,

I'm running my abaqus .inp file with UMAT( modified by fortran). Due to some errors, the job can not complete successfully. After using write(*,*) to output some variables I've defined. I've found that some are being NaN and some are infinity. How can I solve this?( the stress is zero initially and being the denominator. Thanks.

Regards,

Vicky

0 Kudos
1 Solution
Greg_T_
Valued Contributor I
4,252 Views

Hello,

If all the material input values from the Abaqus input file are zero, then in the UMAT subroutine it is probably not surprising for a calculation to give a NaN result due to division by zero.  I think it would be a good addition to the UMAT subroutine to check for invalid input values, like a value of zero, before doing any calculations.  If there are invalid input values, then the subroutine should raise an error to stop the analysis.  I believe there are Abaqus utility routines that can be called from the user subroutine to raise the error.

Is it valid for your model to have material input values equal to zero?  For example, in a finite element structural analysis material properties like the Young's modulus of elasticity, the density, the yield strength and the tensile strength, etc. would all need to be positive values to have a valid analysis.  If those material input values were being used for a calculation in a UMAT subroutine, then it would be good to check those inputs before doing the calculations.

If this is one of the first Abaqus user subroutines that you have implemented, one approach is to begin by implementing a simple calculation to reproduce an existing option already available in Abaqus.  That way you can run the analysis with and without the UMAT and should get the same result.  That would at least confirm that the analysis can be run with a user subroutine.  Then work on the new calculation in the user subroutine to test that it works correctly too.

If you have not successfully been able to run any Abaqus analysis with a user subroutine, there may be some problem with the compiling or linking of the Fortran user subroutine to the Abaqus libraries at run time.  I think that the Fortran environment is initialized by Abaqus using a batch file, perhaps "ifortvars.bat", but I'm not sure about that.

One of the simpler user subroutines is DLOAD for applying a distributed load (pressure load) to element faces, which is a good choice to test that running Abaqus with a user subroutine is working correctly.  For example, a simple mesh of a few elements with pressure applied to a few element faces can be given with existing syntax in the Abaqus input file.  Then create a DLOAD subroutine to apply the same element pressure loading.  If the results are the same that should at least confirm that running with a user subroutine is working.

Regards,

Greg

View solution in original post

0 Kudos
4 Replies
Greg_T_
Valued Contributor I
4,252 Views

Hi Vicky,

Sounds like division by zero could be a cause of the invalid NaN and Infinity values in the UMAT subroutine.  You could add "if" statements to check for invalid values passed from Abaqus to the UMAT subroutine before doing any calculations.  Since you are using Abaqus, I expect you are modeling a physical system, so you could check for non-physical input values and skip the calculations and return an appropriate value like 0.0, etc.  If no invalid inputs to UMAT are expected, it is possible that there is some invalid data in the input file that Abaqus is running that could be checked too.

The are also intrinsic functions like ISNAN that you can use to check for NaN values while running the program, but I think it is better to trap the invalid inputs before getting to a calculation that would give NaN.

Regards,

Greg

0 Kudos
Qingqing_Z_
Beginner
4,252 Views

Hi Greg,

Thanks for your reply. If I enter all 0 for the material input, my job can complete but with some calculation value being NaN. Does it mean I need to check my inputs?

 

Regards,

Qingqing

0 Kudos
Greg_T_
Valued Contributor I
4,253 Views

Hello,

If all the material input values from the Abaqus input file are zero, then in the UMAT subroutine it is probably not surprising for a calculation to give a NaN result due to division by zero.  I think it would be a good addition to the UMAT subroutine to check for invalid input values, like a value of zero, before doing any calculations.  If there are invalid input values, then the subroutine should raise an error to stop the analysis.  I believe there are Abaqus utility routines that can be called from the user subroutine to raise the error.

Is it valid for your model to have material input values equal to zero?  For example, in a finite element structural analysis material properties like the Young's modulus of elasticity, the density, the yield strength and the tensile strength, etc. would all need to be positive values to have a valid analysis.  If those material input values were being used for a calculation in a UMAT subroutine, then it would be good to check those inputs before doing the calculations.

If this is one of the first Abaqus user subroutines that you have implemented, one approach is to begin by implementing a simple calculation to reproduce an existing option already available in Abaqus.  That way you can run the analysis with and without the UMAT and should get the same result.  That would at least confirm that the analysis can be run with a user subroutine.  Then work on the new calculation in the user subroutine to test that it works correctly too.

If you have not successfully been able to run any Abaqus analysis with a user subroutine, there may be some problem with the compiling or linking of the Fortran user subroutine to the Abaqus libraries at run time.  I think that the Fortran environment is initialized by Abaqus using a batch file, perhaps "ifortvars.bat", but I'm not sure about that.

One of the simpler user subroutines is DLOAD for applying a distributed load (pressure load) to element faces, which is a good choice to test that running Abaqus with a user subroutine is working correctly.  For example, a simple mesh of a few elements with pressure applied to a few element faces can be given with existing syntax in the Abaqus input file.  Then create a DLOAD subroutine to apply the same element pressure loading.  If the results are the same that should at least confirm that running with a user subroutine is working.

Regards,

Greg

0 Kudos
Hadi_M_1
Beginner
4,252 Views

Dear Greg,

following your works on finite element method, it seems that you are a professional in this issue. In fact my question is exactly the same for appearing NAN. during compilation. I have written some subroutines before for Abaqus, but in recent special case, I do not understand why the code does not work. I got NAN. value for DSTRAN after some iteration and it is really strange, because as far as I know abaqus generates itself these kind of values, such as STRESS and STRAN at the begining of an increment. However, I put a run with this code and the job is completed, but when I track the compilation procedure using WRITE(*,*) statement, in the text file, I recieve some zeros and  after some iterations the values changed to NAN. for sure, I also printed inputs, such as E11,E22, Nu_12 , .... they all pass into code with non zero values. I also update STRESS and Jacobean matrix within UMAT code which is mandatory.


My question is that, if I am sure that my system does not have any problem with Abaqus subroutine compilation, also inputs are non-zero, and also the other defined variables have zero values till DSTRAN is zero and after changing its value to NAN, all of them changed to NAN. , what should be the possibility for this problem. 

On the other hand it should be noted that for variables declaration, as far as I know, all variables found in the header of UMAT are 'real', unless NTENS, NDI, NDHR. according to this fact, I declared new variables in   real form.

It would be really appreciated if you can give me some tips  in this matter.

Thanks,

Hadi

0 Kudos
Reply