- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi,
I am converting a UMAT to VUMAT for ABAQUS 6.7.1. I am getting strange behavior. When I do not write anything in log file or sta file, the "Explicit packager" itself aborts and issues a "system error code 5". When I put some write statements in VUMAT subroutine (at the very begining before I call any other subroutine) it starts working and it gives me correct solutions. I checked MSDN regarding error code 5 and it simply says "Access Denied". On my other forum they are saying it's realted to memory issue. They recommended to increase the memory size (I already have 4Gb - 8GB virtual memory and 2GB physical memory).
I think it's related to the memory access by VUMAT (since in one case it runs, in other it doesn't)...but I am not able to pin point the cause of the problem. Can somebody suggest me any compile time option that will help me in figuring out the cause (I have already tried /CB /Qfpstkchk /warn:all /fpe:0 /warn:interfaces /gen-interfaces). None of these options say anything during compilation.
Any help is grately appriciated.
Thanks
I am converting a UMAT to VUMAT for ABAQUS 6.7.1. I am getting strange behavior. When I do not write anything in log file or sta file, the "Explicit packager" itself aborts and issues a "system error code 5". When I put some write statements in VUMAT subroutine (at the very begining before I call any other subroutine) it starts working and it gives me correct solutions. I checked MSDN regarding error code 5 and it simply says "Access Denied". On my other forum they are saying it's realted to memory issue. They recommended to increase the memory size (I already have 4Gb - 8GB virtual memory and 2GB physical memory).
I think it's related to the memory access by VUMAT (since in one case it runs, in other it doesn't)...but I am not able to pin point the cause of the problem. Can somebody suggest me any compile time option that will help me in figuring out the cause (I have already tried /CB /Qfpstkchk /warn:all /fpe:0 /warn:interfaces /gen-interfaces). None of these options say anything during compilation.
Any help is grately appriciated.
Thanks
Link Copied
2 Replies
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hello,
That is interesting that it works better when writing values to a file. Is your VUMAT user subrotine complicated with many calculations and even calls to other functions and other subroutines? I think that Abaqus recommends writing values to the message (*.msg) file, and the user's manual specifies the unit number for that file. Have you tried writing values to the *.msg file instead? Any difference?
It sounds like you have already tried several compile options, so maybe it is a run time problem that the compiler does not catch? If you think it is related to memory use, do you have allocatable arrays in the user subroutine? If yes, perhaps adding the STAT parameter in the ALLOCATE command would help capture a useful error code if there is a problem when allocating large arrays. Then write the STAT value to the *.msg file. Would there be any reason to not use fixed size arrays, at least for a comparison? (I'm speculating here.)
Have you also written a program that can run the VUMAT routine separately from Abaqus? When using Abaqus user subroutines written in Fortran, I have often found it very useful to run the the user subroutine from a testing program. Sometimes that will help in tracking down problems like you describe. I recommend calling the user subroutine in a loop in the testing program so that you can send a variety of values to and from the subroutine. Perhaps loop through a range of input values, incrementing the values for each call. If you don't get the error from the testing program, that may help you narrow the problem to something in Abaqus.
Then do you have a simple test model to run the user subroutine? I have often used a mesh with a single element or just a few elements to run more tests on the user subroutine. If this small model can reproduce the error, then I recommend progressively simplifying the user subroutine by removing some of the calculations, calls to other functions or subroutines, until eventually the return value is set to a constant (no calculations in the user subroutine). Hopefully that helps track down the location or line of code causing the error. This is a bit tedious, but should hopefully lead to more information about where and what is causing the error.
It is also worthwhile comparing the call statement to the information in the Abaqus user subroutine user's manual since the call statement can change between versions. Perhaps you have already done this. A changed call statement has been the cause of problems for me when porting to a newer version of Abaqus.
It sounds like you are using an older version of Abaqus. Are you using the recommended version of the Fortran compiler for that version of Abaqus? I usually try to, and am not sure if it makes a difference.
These general suggested steps have helped me to track down and correct problems with Abaqus user subroutines in the past. I will be interested to hear what you discover.
Regards,
Greg
That is interesting that it works better when writing values to a file. Is your VUMAT user subrotine complicated with many calculations and even calls to other functions and other subroutines? I think that Abaqus recommends writing values to the message (*.msg) file, and the user's manual specifies the unit number for that file. Have you tried writing values to the *.msg file instead? Any difference?
It sounds like you have already tried several compile options, so maybe it is a run time problem that the compiler does not catch? If you think it is related to memory use, do you have allocatable arrays in the user subroutine? If yes, perhaps adding the STAT parameter in the ALLOCATE command would help capture a useful error code if there is a problem when allocating large arrays. Then write the STAT value to the *.msg file. Would there be any reason to not use fixed size arrays, at least for a comparison? (I'm speculating here.)
Have you also written a program that can run the VUMAT routine separately from Abaqus? When using Abaqus user subroutines written in Fortran, I have often found it very useful to run the the user subroutine from a testing program. Sometimes that will help in tracking down problems like you describe. I recommend calling the user subroutine in a loop in the testing program so that you can send a variety of values to and from the subroutine. Perhaps loop through a range of input values, incrementing the values for each call. If you don't get the error from the testing program, that may help you narrow the problem to something in Abaqus.
Then do you have a simple test model to run the user subroutine? I have often used a mesh with a single element or just a few elements to run more tests on the user subroutine. If this small model can reproduce the error, then I recommend progressively simplifying the user subroutine by removing some of the calculations, calls to other functions or subroutines, until eventually the return value is set to a constant (no calculations in the user subroutine). Hopefully that helps track down the location or line of code causing the error. This is a bit tedious, but should hopefully lead to more information about where and what is causing the error.
It is also worthwhile comparing the call statement to the information in the Abaqus user subroutine user's manual since the call statement can change between versions. Perhaps you have already done this. A changed call statement has been the cause of problems for me when porting to a newer version of Abaqus.
It sounds like you are using an older version of Abaqus. Are you using the recommended version of the Fortran compiler for that version of Abaqus? I usually try to, and am not sure if it makes a difference.
These general suggested steps have helped me to track down and correct problems with Abaqus user subroutines in the past. I will be interested to hear what you discover.
Regards,
Greg
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi Greg,
Thanks for the reply. The original UMAT was written some 3-4 years ago, which I debugged for the current 6.7 version. Now I was trying to convert it into VUMAT since all the major calculations are being done in seperate subroutines. I am testing this VUMAT using the single element model (pure shear test). I checked the code several time and I could not find any suspecious statement. That's why I was puzzeled (it's mother UMAT is working beautifully). I am using Intel Fortran 9.1 (which is listed in system requirement in all 6.7 to 6.9).
Anyway, I will try to write a separate exe file for debugging. I will let you know if I discover anything interesting.
Thanks again.
Thanks for the reply. The original UMAT was written some 3-4 years ago, which I debugged for the current 6.7 version. Now I was trying to convert it into VUMAT since all the major calculations are being done in seperate subroutines. I am testing this VUMAT using the single element model (pure shear test). I checked the code several time and I could not find any suspecious statement. That's why I was puzzeled (it's mother UMAT is working beautifully). I am using Intel Fortran 9.1 (which is listed in system requirement in all 6.7 to 6.9).
Anyway, I will try to write a separate exe file for debugging. I will let you know if I discover anything interesting.
Thanks again.
Reply
Topic Options
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page