[RESOLVED] Error during meshing [Solved]« Back to Questions List
Here's what I get.
End of Processing:
########
/*---------------------------------------------------------------------------*\
| ========= | |
| \\ / F ield | OpenFOAM: The Open Source CFD Toolbox |
| \\ / O peration | Version: v1606+ |
| \\ / A nd | Web: www.OpenFOAM.com |
| \\/ M anipulation | |
\*---------------------------------------------------------------------------*/
Build : v1606+
Exec : reconstructPar -latestTime
Date : Jun 22 2017
Time : 02:33:55
Host : "69747be895ce"
PID : 1140
Case : /Users/ricardo/OpenFOAM/docker-v1606+/run/17MO000
nProcs : 1
sigFpe : Enabling floating point exception trapping (FOAM_SIGFPE).
fileModificationChecking : Monitoring run-time modified files using timeStampMaster
allowSystemOperations : Allowing user-supplied system call operations
// * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * //
Create time
--> FOAM FATAL ERROR:
No times selected
From function int main(int, char**)
in file reconstructPar.C at line 215.
########
POST:
########
MWFlow Post-Processing Utility
Case folder: 17MO000
Plotting of forces failed.
FSource folders: []
mSurf folders: []
ptot iso file to check:
Traceback (most recent call last):
File "MFlow_PP_merged.py", line 2387, in
File "MFlow_PP_merged.py", line 400, in HM
File "MFlow_PP_merged.py", line 200, in HX
WindowsError: [Error 3] The system cannot find the path specified: '17MO000\\postProcessing\\surfaces/*.*'
Failed to execute script MFlow_PP_merged
PS: Can we have a bigger text box here?
|
▲ ▼ |
The windows machine had a power outage. No software problem. The OSX machine finished it after some memory tweaking with Virtualbox, seems ok now. The linux AWS VM did it right first time. |
▲ ▼ |
Kind of bad news. As you see the case in general runs. Why it fails on your Windows and OSX machines is unclear. We should wait and see if others report similar problems. |
▲ ▼ |
The aws case is past meshing and running. Still waiting on OSX and windows. |
▲ ▼ |
I have another running on windows and one linux vm at aws. |
▲ ▼ |
No it’s just sitting there. I’ll restart everything and test. Do you know any command I could use to log memory usage in linux? |
▲ ▼ |
I just checked the log files. One time the mesher crashes after 9 and the other time after 18 layer iteration steps. This shows me that it crashes due to a computer issue. I think you do run out of memory. Sometime the mesher is not very good and needs extra memory. But is it possible that your were using the computer for something else during meshing? Even a web-browser can use crazy amounts of memory. |
▲ ▼ |
There was a damn power outage here and the windows run aborted before failing. I did upload the second log set, now done from the GUI and the process lasting over an hour. |
▲ ▼ |
Please yip up the log files of the newly crashed case and send them to me. |
▲ ▼ |
It filed again, I’ll try running in windows. |
▲ ▼ |
Can you send them back to me? |
▲ ▼ |
Did that already ? Will be more careful from now on. |
▲ ▼ |
Make sure to not overwrite your log files |
▲ ▼ |
I’d build it from command line. Trying again from the GUI. |
▲ ▼ |
As the case should actually work, you will have to check a few things. As the case fails during meshing you should check if the log looks exactly the same every time it fails. Does a different case work? You could try changing the number of CPU cores you use. Make sure to check the system/decomposeDict if MantiumFlow really changed something. Prime numbers for example do not get accepted. |
▲ ▼ |
Yep 1606+ on OSX, see my logs below. What can I try? |
▲ ▼ |
The end-plates were only one example. There are a few areas that do not look very nice (the stl tessellation, the car is super cool). I mesh and am now running your case without any problem. So what is different? Are you using OF v1606+? |
▲ ▼ |
Oh you said the endplates, I’ll check |
▲ ▼ |
About that mesh: I have a nicer wing mesh that runs noticeably lower CL on the 2016 version, that’s why it’s being used. |
▲ ▼ |
OK, I have received the files and checked them. |
▲ ▼ |
Meshing ran for a full hour this time, then seems to have crashed again. I’m submitting the geometry and logs on dropbox. |
▲ ▼ |
Yes, same link but please zip it all up into one file this time. |
▲ ▼ |
It’s running on 49.1% of RAM as per top. I’ll let you konw. If it need be, use same dropbox link? |
▲ ▼ |
You case crashed during meshing already. Maybe you can rerun and check if you do not run out of memory. If it fails again you can send the whole case and I will check it. |
▲ ▼ |
Files sent. |
▲ ▼ |
Solver.log: /*—————————————————————————*\ Pstream initialized with: // * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * // Create mesh for time = 0 SIMPLE: convergence criteria Reading field p [0] NOTE: invoking MPI_ABORT causes Open MPI to kill all MPI processes. |
▲ ▼ |
This does not look good. Anyway why is there a reconstructPar command? This is not from MantiumFlow. |
▲ ▼ |
A bit more, from early on processing: –> FOAM Warning : |