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.

Please use this forum for bug reports only. Look in the documentation or on the main forum.

I pushed a fix to 1.6.x so it now runs as before without copying the stl files.
Thanks for reporting.

Mattijs

Thanks, I will give it a try today

cheers

PO