Error Code 253

[CAPGuy]

Hi guys,

I'm trying to run a static-step Abaqus job with versions 6.10 and 6.9-EF2 alongside a custom-defined UMAT. The job processes the input file and links to fortran correctly, but as soon as ABAQUS/Standard starts up it aborts with error code 253.

I have pored over SIMULIA answers, status reports, and google searches and have found nothing like this anywhere else. I've seen only one forum post (OldNabble) with an instance where someone got this error code, but the problem was never resolved. Has anyone been hit by this error code before? Does anyone know what it means?

Just some info:
I'm running on a Windows 7 (64-bit) multi-core PC. The log file below is the result of running any job with any geometry/mesh type and with any type of UMAT (I've tried 3 different UMATs).

If this is a UMAT problem, I'd be much happier because I can fix UMAT coding. But I can't find any references as to what error 253 points to. The .dat file and .msg files all check out (no errors, they just truncate when the job stops) and no .sta file exists.

Thanks, all.

------------------------
Abaqus JOB job-1
Abaqus 6.10-1
Begin Compiling Abaqus/Standard User Subroutines
6/25/2010 1:00:03 PM
End Compiling Abaqus/Standard User Subroutines
6/25/2010 1:00:03 PM
Begin Linking Abaqus/Standard User Subroutines
6/25/2010 1:00:03 PM
Creating library standardU.lib and object standardU.exp
Microsoft (R) Manifest Tool version 5.2.3790.2014

Copyright (c) Microsoft Corporation 2005.

All rights reserved.

End Linking Abaqus/Standard User Subroutines
6/25/2010 1:00:03 PM
Begin Analysis Input File Processor
6/25/2010 1:00:03 PM
Run pre.exe
Abaqus License Manager checked out the following licenses:
Abaqus/Standard checked out *hidden* tokens.
<*hidden* out of *hidden* licenses remain available>.
6/25/2010 1:00:04 PM
End Analysis Input File Processor
Begin Abaqus/Standard Analysis
6/25/2010 1:00:04 PM
Run standard.exe
Abaqus License Manager checked out the following licenses:
Abaqus/Standard checked out *hidden* tokens.
<*hidden* out of *hidden* licenses remain available>.
6/25/2010 1:00:05 PM
Abaqus Error: The executable C:\SIMULIA\Abaqus\6.10-1\exec\standard.exe
aborted with system error code 253.
Please check the .dat, .msg, and .sta files for error messages if the files
exist. If there are no error messages and you cannot resolve the problem,
please run the command "abaqus job=support information=support" to report and
save your system information. Use the same command to run Abaqus that you
used when the problem occurred. Please contact your local Abaqus support
office and send them the input file, the file support.log which you just
created, the executable name, and the error code.
Abaqus/Analysis exited with errors

 

[TGS4]

Ask Simulia directly.

 

[CAPGuy]

TGS4,

Thanks for the reply, but I already have asked Simulia on two separate occasions, and they just point me to answers that have to do with other error codes (ones that have descriptors) and other answers that pin the blame on bad linking between Fortran and Standard. I know for a fact that this is not the case, since the program always successfully links with the compiler, and then fails after Standard starts.

Has this error code popped up for anybody else?

 

[LoveHateTheABQ]

CAPGuy:

I have been seeing this error message as well. My analysis is completely different. I have a /Standard analysis (that happens to be a submodel) that I run in 6.10-1 /Standard and import into /Explicit. There's no FORTRAN involved at all. My job dies in /Pre (upon launching the /Explicit job with the *IMPORT definition in it). Simulia has also been utterly unhelpful so far.

Here's what we have in common... Platform. We're both running multi-cpu machines with Windows 7 x64. Your machine doesn't happen to be a new HP 8740w, does it?

 

[CAPGuy]

Sorry about the delayed response; I wanted to check and see if my hardware was conflicting.

No, I don't have an HP; I ordered a custom-built computer just for ABAQUS work.

Just as a note, SIMULIA's response to my question:

"Error code 253 is generally difficult to investigate, since they are unique. I have mostly seen this issue when the User Subroutine is specifying too many internal loops or is using large arrays.

You can try using the suggestions mentioned in Answer 3499, which may help resolve this issue:

Answer Title: Running Abaqus user subroutines and Fortran post-processing programs containing large arrays"

...to which the answer suggested redesigning the UMAT, or doing one of the following two options:

1.) The size of the program is set during the LINK phase of the program/library build process. The default size is only 1 MB, but the Abaqus build environment can be modified to increase this size. Modify the Abaqus link_exe or link_sl parameter to include the /STACK:size parameter, where size is the stack size value in bytes. If the link_exe parameter already includes this setting, you will only need to modify the size value.

2.) Alter the build configuration to place the arrays on the heap.
This method is appropriate for any application that does not use thread-based parallelization. Thread-based parallelization is not used in the following cases:

?Any Post-processing program built using the Abaqus Make utility.
?Abaqus/Explicit user subroutines not running in parallel.
?Abaqus/Standard user subroutines not running in parallel.
?Abaqus/Explicit user subroutines using MPI based parallelization.
?Abaqus/Standard user subroutines using MPI based parallelization on a single machine.
?Abaqus/Standard user subroutines running distributed memory based parallelization using Abaqus 6.5 or 6.6.
For Linux platforms, remove the -auto option from the compile_fortran parameter.

For Windows platforms, remove the /recursive option from the compile_fortran parameter.

Please note that for either Linux or Windows platforms, these options ( -auto and /recursive) must be restored for Abaqus user subroutine jobs when thread-based parallelization is performed for element loop calculations.
-------------------

Gonna try a few of these to see if any result in a successful run.

 

[xerf]

Some recommendations:
1) try to replace your UMAT with a simple built-in material and see if the abort still occurs, if yes contact Abaqus
support again.
2)use the model with a simple UMAT, from documentation
3)use your UMAT with a small model and put printout statements to .msg file (unit 7).
4)run a single cpu, to avoid any potential thread safety/ race conditions issues.