Troubleshooting Access Violation 157

[Rob]

Hello,

I have simulation, where it gives "forrtl: severe (157): Program Exception - access violation" and I am just wondering where to start troubleshooting this. i.e. what are the typical causes I should check first?  I have crossed off the following already:

1. Vents on thin obstructions
2. Vents within obstacles.
3. Not enough RAM. 32gb RAM for 2 million cells, only 15gb is ever being used. CPU at 90% only 5 of 8 cores
4. No obstructions are added or removed at time of crash.
5. No Sudden change in HRR
6. No Cell aspect ratio 2 to 1
7. Windows: energy save mode is turned off
8. Open vents set wrongly: q_pres is always zero so do not think that is the issue

I let it "restart"" and it will sometimes get quite a bit further, sometimes less, does this help in diagnosing the problem?

Also, it spits out which line is the problem, but it is not always the same (840 or 816 or 648 I have remembered to note down so far). For example..

forrtl: severe (157): Program Exception - access violation
Image              PC                Routine            Line        Source
fds.exe            00007FF6D22D473C  PHYSICAL_FUNCTION        2851  func.f90
fds.exe            00007FF6D22C1250  Unknown               Unknown  Unknown
libiomp5md.dll     00007FF9F6532B63  Unknown               Unknown  Unknown
libiomp5md.dll     00007FF9F648E16D  Unknown               Unknown  Unknown
libiomp5md.dll     00007FF9F644B5FD  Unknown               Unknown  Unknown
fds.exe            00007FF6D22ACFB0  Unknown               Unknown  Unknown
fds.exe            00007FF6D1F7FB38  MAIN__                    648  main.f90
fds.exe            00007FF6D1F3F09E  Unknown               Unknown  Unknown
fds.exe            00007FF6D28D6664  Unknown               Unknown  Unknown
KERNEL32.DLL       00007FFA0D097BD4  Unknown               Unknown  Unknown
ntdll.dll          00007FFA0DE4CED1  Unknown               Unknown  Unknown

I also see that this time there are six fds.exe , but there should be five as I have 5 MPI. is that normal? the previous time it was four. I do not always get the above error message, usually it is less verbose.

Also, I see in the manual that there should be a final plot3D file dumped when numerical instability is encountered, then I could see if high velocites are the problem, but I do not find any  .q files in the working directory.

Next I am going to check for:

1. "Exposed" obstructions  that are more than grid cell thick. 
2. High speed flows through small openings: in my model there are some locations where the edges of two obstacles meet (see image), I think these can allow flow to pass, I will remove these and let run again. How can I check for high veolocities directly?
   
3. Anti-virus issues?
4. remove all thin obstructions: i think i read these can cause issues.
   

.

[Randy McDermott]

Can you post the input file?  I can run it in debug mode and see if any more information shows up in the error message.

--
You received this message because you are subscribed to the Google Groups "FDS and Smokeview Discussions" group.
To unsubscribe from this group and stop receiving emails from it, send an email to fds-smv+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/fds-smv/974b6feb-176e-4d68-a27b-e867cd0b0b64n%40googlegroups.com.

[Rob]

I would have to pm it. and it is made with Pyrosim so it is a bit messy and long....but the original seems to be running ok now after several restarts!.... also I found several single mesh-sized cell holes, so I have removed them and will let that run parallel  from the beginning on another machine. Plus I removed lots of thin objects and objects that only meet on the edge (like picture above).

So, I will see if that fixes it first, if not then I will get back to you, thanks for the offer.

But still, how do I find out if too high velocities are present at the time of crash?

[Randy McDermott]

Well, if it is a numerical instability, that will shutdown FDS gracefully and you will have .q files to look at in SMV.

For a seg fault, the only thing I know to do is run with a debug version of the code, and trace back where the access violation occurred.

You can explicitly use 3D slices of velocity, but, I'm sure you know, that can be expensive.

The only other thing that comes to mind is that perhaps we could add a check for these small holes, thin obst,  etc.  It seems to be that these types of errors are popping up a lot recently.

To view this discussion on the web visit https://groups.google.com/d/msgid/fds-smv/30ecd89a-234f-40c4-ae3f-f68c6d87f6c9n%40googlegroups.com.

[Rob]

I have sent the file direct to your gmail. If you want to use it to shakedown some seg faults.

Was run in windows, using latest version of FDS.

[Rob]

Solved :

Ok, I left it running overnight, three seperate runs. I am pretty sure I have found the reason for the crashes. There was one mesh in an area that I did not think was so important, I had cells in this area with an aspect ratio of 2:1, tbh I thought I had corrected this back to 1:1, but one simulation was still running with this 2:1 by accident.

In fact, just to be sure, I  just did some further checking, so it seems I have two exactly identical runs, and the only difference between the two is that one has a 2:1 mesh in one area, the other only 1:1, the 2:1 run has crashed multiple times but can be restarted and always manages to get further, the one with the recomended 1:1 mesh has not crashed once over 12 hours. The machines are pretty much identical set ups, so I can be 90% certain that is not the issue, otherwise everything was identical.