1.6.x -> snappyHexMesh in parallel fails ...
Hi,
I'm experiencing some difficulties when trying to run snappyHexMesh with mpirun and 2 cpus / I have tried the same case under 2 different machines and have the same error. Note that the same case was working well under 1.5.x. Here is the message : Pstream initialized with: floatTransfer : 0 nProcsSimpleSum : 0 commsType : nonBlocking SigFpe : Enabling floating point exception trapping (FOAM_SIGFPE). // * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * // Create time Create mesh for time = 0 Read mesh in = 0.11 s [1] [1] [1] Cannot find file "" in directory "constant/triSurface" [1] [1] From function Time::findInstance(const fileName&, const word&, const IOobject::readOption) [1] in file db/Time/findInstance.C at line 148.Overall mesh bounding box : (-22.5 -40 -0.0001) (22.5 40 18) [1] FOAM parallel run exiting [1] Relative tolerance : 1e-08 Absolute matching distance : 9.3536109e-07 [0] [0] [0] Cannot find file "" in directory "constant/triSurface" [0] [0] From function Time::findInstance(const fileName&, const word&, const IOobject::readOption) [0] in file db/Time/findInstance.C at line 148. [0] FOAM parallel run exiting [0] -------------------------------------------------------------------------- MPI_ABORT was invoked on rank 1 in communicator MPI_COMM_WORLD with errorcode 1. Best regards, PO |
As a workaround softlink or copy the constant/triSurface directory to the processor directories for now.
|
ok, yes, the softlink works
|
Hi,
another strange thing is that I cannot use decomposePar on a blockMesh which was refined with refineMesh / I never had this problem before. Regards, PO |
sorry not to start a new thread for this / since I'm discussing meshing "challenges", I guess it's appropriate to re-use this thread ...
I believe that db/Time/timeSelector.C is causing problems whith checkMesh, it does not find the "constant" folder when no time steps are available. |
Just create a dummy time directory; mkdir 0.
|
Yes, that is what I tried yesterday.
Also, it appears that my problems when it comes to decompose a refined mesh are caused by the "-overwrite" flag; I found out that not using this flag and moving the new mesh in constant/polyMesh does not cause problems. I also have issues with the same flag when using snappyHexMesh, that is why, for now, I will not use it and will always move the polyMesh folder. PO |
Assign flow fields to decomposed mesh?
Relevant to "snappyhexmesh in parallel" topic stream, is there a way to assign the flow fields to the decomposed mesh that was built using snappyhexmesh in parallel?
Essentially, I am working with a 32 bit machine and I am pushing the OS memory limit on the size of mesh by using snappyhexmesh in parallel. After the decomposed mesh is built, I need to assign the flow fields to it, but obviously I am not able to first reconstruct the decomposed mesh. Any ideas on how I can tackle the issue, without having to buy a 64bit machine? Thanks. Cem |
Regarding the -overwrite : remove the polyMesh/pointLevel, cellLevel and refinementHistory files. They should be consistent with the snappyHexMesh generated mesh so if you've regenerated a blockMesh they are no longer valid. I'll push a check into 1.6.x so at least you'll get an error message.
|
Quote:
|
Quote:
Thanks for reporting. Mattijs |
Thanks, I will give it a try today
cheers PO |
All times are GMT -4. The time now is 08:09. |