BUG: snappyHexMesh doesn't fully respect the -decomposeParDict option

snappyHexMesh doesn't fully respect the -decomposeParDict option. Crashes half way through when it starts looking for system/decomposeParDict. Looks like it occurs right after the castellation phase. In addition, the -decomposeParDict option on snappyHexMesh doesn't appear to like relative paths (this works with other utilities though).

This is the command I used to run...

mpirun -np 4 snappyHexMesh -overwrite -decomposeParDict /home/graupjj/OpenFOAM/graupjj-plus/run/of/system/decomposeParDict1 -profiling -parallel

This is the error I got...

Doing final balancing

Found 0 zoned faces to keep together. Found 0 separated coupled faces to keep together. [0] [0] [0] --> FOAM FATAL IO ERROR: [0] cannot find file [0] [0] file: /home/graupjj/OpenFOAM/graupjj-plus/run/of/processor0/system/decomposeParDict at line 0. [0] [0] From function regIOobject::readStream() [0] in file db/regIOobject/regIOobjectRead.C at line 237. [0] FOAM parallel run exiting

Could you please upload the case which failed/ mention any tutorial with similar behavior?

I couldn't reproduce the failure using snappyMultiRegionHeater.

Ok, I did some digging. This only occurs when using a distributedTriSurfaceMesh. This is how to reproduce...

The above will produce the error I gave. In addition, please note that I had to give the full path of decomposeParDict1 to snappyHexMesh, it would not accept ./system/decomposeParDict1 like the other applications. I've attached the model.

mesh_bug.tar.gz

Use system/decomposeParDict1 instead of ./system/decomposeParDict1

This should resolve the relative path issue.

Re: distributedTriSurface, it is looking for decomposeParDict

Refer $FOAM_SRC/parallel/distributed/distributedTriSurfaceMesh/distributedTriSurfaceMesh.C, line 839

We are presently reviewing #60 (closed) #267 #268 (closed) along with this to find a better solution.

Reassigned to @Mattijs

Need to adjust to resolve decomposeParDict (in the *.C) to an absolute path, and/or strip off a leading './' from names before passing on further. Eg,

fileName foo = args.optionLookupOrDefault...;
if (!foo.isAbsolute())
{
    foo = args.rootPath()/args.globalCaseName()/foo;
 }

Ok, so maybe snappyHexMesh is looking for the decomposeParDict that was used to decompose the distributedTriSurfaceMesh (surfaceRedistributePar only accepts system/deocomposeParDict #60 (closed) )?

Thanks for the note on the relative path, I will try system/decomposParDict1. I think this should be made consistent with the other utilities though that appear to not have an issue with the ./ relative path.

Reassigned to @mark

Mentioned in commit dfa259be634ea6f6c936bf3dcfa30faa57ba7047

Mentioned in merge request !73 (merged)

Mentioned in commit b1004874

Mentioned in commit fd17d0e0

Need to adjust to resolve decomposeParDict (in the *.C) to an absolute path, and/or strip off a leading './' from names before passing on further. Eg,

fileName foo = args.optionLookupOrDefault...;
if (!foo.isAbsolute())
{
    foo = args.rootPath()/args.globalCaseName()/foo;
 }

It looks like we still didn't catch all of the problems.

Mentioned in commit a2a6473f

Will push updates now , but for testing the previously attached mesh_bug, the following Allrun should be used.

confirmed working.

Status changed to closed