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.
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.
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 ...
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
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
***** (for number won't fit into edit descriptor field)
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.
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.
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 ...
For what it is worth a quick google suggests unit 45 is used for the "CMS" fileCMS (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 :-).
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.
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!