Community
cancel
Showing results for 
Search instead for 
Did you mean: 
Highlighted
Beginner
62 Views

CLOSE error on an unused unit

Hello,

I am programming user subroutines in Fortran into ANSYS Autodyn (numerical  simulation, computational dynamics), and I am generating and saving quite a lot of data throughout the program. A simulation consists of the computation of a number of time steps (several thousands), performed with the ad_usersubDP_F_F.exe. At the first time step, a number of output files are created. For each time step, an identical computation is done. Depending on the output file, it is opened, read, extended and closed at regular intervals during the computation. I am not posting the code itself: I would need to post several hundreds of lines. I can put up some parts later if needed, of course.

I can compile my code without any errors or warnings. On some occasions, not always, I get the run-time error shown in the attached screen capture.The main thing that puzzles me is: I am not using the UNIT 45 identifier in my code.

There seems to be no logic behind the occurence of the error. I have been over it many times and  I can't find any sytem behind the timing of the errors, no link between the cases when it does or does not occur. 

The error never occurs at the start of a simulation, only after a few hundreds/thousands of timesteps. 

Sometimes, I run batched simulations (several simulations consecutively, without restarting the code) and the error only occurs after a few correctly completed  simulations.

In some cases, I run several instances of the program at the same time, working on different simulations (no parallel computing, I mean). In that case, the error will occur in all simulations at approximately the same time (i.e. same actual moment in time, not the same time step in the computation).

I hope this is enough information to start with. Any help/suggestions would be very welcome.

Bram

0 Kudos
15 Replies
Highlighted
Black Belt
62 Views

Such errors are usually difficult to diagnose and repair. It is not a recipe for success to focus your efforts on the last symptom that surfaces or is evident. Such symptoms are often the result of your program (or the compiler's runtime) having crossed the brink of sanity, and the real cause of the problem may remain well-hidden.

If possible, create a "reproducer" by removing all references/dependencies on third party packages such as Ansys -- especially specialty packages that require licensing and time-consuming installation. Zip the source, data and build files of the reproducer and attach the reproducer to your response.

0 Kudos
Highlighted
New Contributor II
62 Views

Would it be worth including code to INQUIRE on the status of unit 45 ? If it is open at any stage, then report the file name and other open properties. It may give a clue as to what may be using this unit and if your code is clashing with the status of this file. Also, it is not impossible that you are changing the status of some variables in memory, especially if using some undefined array subscripts, which you have assumed were valid.
0 Kudos
Highlighted
62 Views

It would also be helpful to build with traceback enabled so you can see where in the program it is failing.

0 Kudos
Highlighted
Beginner
62 Views

Thanks all for the quick replies. I will be adding trackback and INQUIRE for the erroneous unit and wil keep you posted.

@mecej4 : unfortunately, that won't be possible. My code depends too much on the ANSYS framework to unplug and still maintain a working application ... 

0 Kudos
Highlighted
Beginner
62 Views

UPDATE:

I have enabled traceback, but this did not change the contents of the error message: routine, line and source are still listed as unknown for all lines.

I have INQUIREd this unit 45 in all parts of my subroutine: it exists, but is not named and cannot be read ... 

I deduce from this that this unit originates from the core code,  into which my subroutines are plugged, and which I can not acces, let alone change ... 

Any other tips?

best regards, Bram

0 Kudos
Highlighted
Valued Contributor III
62 Views

It seems unlikely that you will find a solution here. It looks like a problem in ANSYS, you would be better on an ANSYS forum or tech support.

0 Kudos
Highlighted
62 Views

What I would do if I were in your position would be to assume their might be a possibility of the error being data pendent on the running of ad_usersubDP_F_F.exe. As such, if not already, I would snapshot the input data (and command arguments) that would be used on the launch of ad_usersubDP_F_F.exe. Then to a post-mortem examination of the data. Maybe something will show up, and you might be able to take action by altering the input data. Have you checked this data to assure you do not have a

NaN

or

*****     (for number won't fit into edit descriptor field)

Jim Dempsey

0 Kudos
Highlighted
Valued Contributor III
62 Views

Given you can run several variations on the simulation simultaneously and they all bomb at about the same  real (as apposed to sim step) time it would suggest a bug in the simulation  code itself. A guess would be the system is opening and closing unit 45 to save data but because  windows is "IO busy" at some instant Windows has not actually finished closing the file before the application tries to open it again. Unless the application is coded to trap and wait and such an instance it will crash.... This seems to be quite a common fault  that gets reported here.

0 Kudos
Highlighted
Valued Contributor III
62 Views

For what it is worth a quick google suggests unit 45 is used for the "CMS" file

CMS (component mode synthesis) transformation file
0 Kudos
Highlighted
Beginner
62 Views

andrew_4619 wrote:

It seems unlikely that you will find a solution here. It looks like a problem in ANSYS, you would be better on an ANSYS forum or tech support.

Indeed, I am currently running an inquiry through ANSYS tech support as well. Keeping you posted on the outcome.

0 Kudos
Highlighted
Beginner
62 Views

jimdempseyatthecove wrote:

 Have you checked this data to assure you do not have a ...

Hello Jim, I did actually check that. There seems to be no problem there. Furthermore, it has occurred that a simulation run fails due to the mentioned error, but that a rerun, with a 100% identical input configuration, does not ... 

0 Kudos
Highlighted
Beginner
62 Views

andrew_4619 wrote:

For what it is worth a quick google suggests unit 45 is used for the "CMS" file

CMS (component mode synthesis) transformation file

That would be the case for the ANSYS APDL solver, if I am not mistaken. I am however working with ANSYS Autodyn, wich I am running outside the "traditional" ANSYS workbench. The regular ANSYS FEM executables (solver, pre- and postprocessing) don't intervene in my case.

Apart from that, where did you find that reference? Your Googling skills seem to be better than mine :-).

0 Kudos
Highlighted
Beginner
62 Views

andrew_4619 wrote:

A guess would be the system is opening and closing unit 45 to save data but because  windows is "IO busy" at some instant Windows has not actually finished closing the file before the application tries to open it again. 

I am looking in that direction as well for now. I hope to find out what UNIT 45 stands for in the Autodyn solver (from Ansys tech support), and see if shortcutting it is an option.

0 Kudos
Highlighted
Valued Contributor III
62 Views

Unit 45/CMS  came from http://ansys.net/?mycat=tnt_sheldon22

 

0 Kudos
Highlighted
Beginner
62 Views

More or less SOLVED:

I got confirmation from ANSYS: Unit 45 is a data output file (.his, for the afficionados) which enables collecting date from the regular (non-subroutine) part of Ansys Autodyn. This file is updated at the end of each computational step, immediately after the generation of output in the subroutine part of the code. Since the latter generates large files (100-200 MB per file), the error is probably due to a read-write conflict, where the updating of the different files sometimes, not always, interferes . No solution there.

However: I can do perfectly well without this .his file, and can switch off the routine that generates it. While this is by no means a general solution, it is good enough for me and will be for the final version of my code, in which the huge subroutine output files will no longer have to be generated.

Thanks for all the suggestions and support!

bram

0 Kudos