[Aurelien Thinat]

Leong,

I have rebuilt my case folder from scratch :
- the parallel meshing is working but the feature edge handling option is not,
- the serial mode is working with the feature edge handling option.

I will check my case next week, but I think the feature edge handling is only for a serial use for now.

Thank you for your help.

Aurélien

[airfoil]

Hi Aurélien,
I already manage to run snappyHexMesh in parallel with edges handling option on OpenFOAM-2.0.x. I not sure what could be your problem as I just follow the motorbike tutorial and applied the same concept on my case. The model that I am working on is cross flow fan. In my opinion, the geometry is quite complex.

Leong

[Aurelien Thinat]

You are using the command :
"surfaceFeatureExtract -includeAngle 150 constant/triSurface/mygeometry.stl mygeometry"

???

When I check the mesh I get in parallel with OF 2.0.x, it doesn't seems to be the same than with the feature edge handling option.

Are you copying the folder extendedFeatureEdgeMesh in the processor* folder after the decomposition ?

[airfoil]

Aurelien,
I am using below script.

#!/bin/sh
# Source tutorial run functions
. $WM_PROJECT_DIR/bin/tools/RunFunctions

runApplication blockMesh
runApplication surfaceFeatureExtract -includedAngle 150 -writeObj constant/triSurface/mygeometry.stl mygeometry
runApplication decomposePar
runParallel snappyHexMesh 12 -overwrite
runApplication reconstructParMesh -constant


You can view mygeometry file whether it has the point for edges or not. If not then, your the edge handling is not working. The file is located on the master folder.

I do not copy the folder extendedFeatureEdgeMesh in the processor*.

I am using hierarchical decomposition. Below is my decomposition file.

/*--------------------------------*- C++ -*----------------------------------*\
| ========= | |
| \\ / F ield | OpenFOAM: The Open Source CFD Toolbox |
| \\ / O peration | Version: 2.0.0 |
| \\ / A nd | Web: www.OpenFOAM.com |
| \\/ M anipulation | |
\*---------------------------------------------------------------------------*/
FoamFile
{
version 2.0;
format ascii;
class dictionary;
object decomposeParDict;
}

// * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * //

numberOfSubdomains 12;

method hierarchical;
// method ptscotch;

simpleCoeffs
{
n (4 1 1);
delta 0.001;
}

hierarchicalCoeffs
{
n (3 2 2);
delta 0.001;
order xyz;
}

manualCoeffs
{
dataFile "cellDecomposition";
}


// ************************************************** *********************** //


Do you have this option in your snappyHexMeshDict

features
(
{
file "mygeometry.eMesh";
level 3;
}
);



Hope this help.

Leong

[Svensson]

I also had this problem and solved it by changing fvSchemes and fvSolution, as shown below:

/*--------------------------------*- C++ -*----------------------------------*\
| ========= | |
| \\ / F ield | OpenFOAM: The Open Source CFD Toolbox |
| \\ / O peration | Version: 2.0.1 |
| \\ / A nd | Web: www.OpenFOAM.com |
| \\/ M anipulation | |
\*---------------------------------------------------------------------------*/
FoamFile
{
version 2.0;
format ascii;
class dictionary;
location "system";
object fvSchemes;
}
// * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * //

gradSchemes
{
}

divSchemes
{
}

laplacianSchemes
{
}

// ************************************************** *********************** //

and:

/*--------------------------------*- C++ -*----------------------------------*\
| ========= | |
| \\ / F ield | OpenFOAM: The Open Source CFD Toolbox |
| \\ / O peration | Version: 2.0.1 |
| \\ / A nd | Web: www.OpenFOAM.com |
| \\/ M anipulation | |
\*---------------------------------------------------------------------------*/
FoamFile
{
version 2.0;
format ascii;
class dictionary;
object fvSolution;
}
// * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * //

solvers
{

}

// ************************************************** *********************** //

[airfoil]

Hi,
I had since move forward with SHM. It has nothing to do with other setting. From my experience, as long we got the correct setting then everything is fine. I am using pt-scotch and scotch to mesh now. I also manage to mesh complex components. I am using SHM to mesh air-condition indoor unit with cross-flow fan. My model consist of two regions which are stator and rotor. The setting for parallel and serial are the same. At least for my case.

Thanks,
Leong

[Saxwax]

Hi Aurelien,

I seem to be having a similar issue when running snappyHexMesh (sHM) with feature edge handling in parallel on a cluster using OF 2.0.x. I noticed that you also are running on some variety of cluster (--hostfile machines).

On the cluster I am able to run the flange tutorial (in series) and the turbineSitting (in parallel) without any problems. When I try to run the flange tutorial in parallel on the cluster I experience the same problems that you have highlighted. I can run the flange tutorial in parallel without issues on my stand-alone PC. It is also interesting to note that if I run sHM with feature edge handling in parallel on just one of the PCs in my cluster I experience the same issues as you.

In summary,

CLUSTER:
-sHM NO feature edge handling series/parallel OK
-sHM feature edge handling series OK
-sHM feature edge handling parallel FAILS (same error as Aurelien)

Stand-alone PC:
-sHM NO feature edge handling series/parallel OK
-sHM feature edge handling series OK
-sHM feature edge handling parallel OK

Based on the above results I am under the impression that the architecture of the cluster may be in some way responsible for the error. I would be curious to hear what your setup consists of. My specs are as follows:

OS: Ubuntu 10.04 LTS
OF: 2.0.x
PCs/Nodes: 3x PCs with Two 4-core processors each. Gb Ethernet connection.
OF files in /opt/OpenFOAM; run directory in ~/OpenFOAM. Both of these directories are shared via NFS. The home directory uses software RAID5.

Do you have anything similar to this? I am concerned that something funny may be happening with the network sharing or the RAID setup (these are the only things that are different between my cluster and the stand-alone PC). I will try to change how I have my home and /opt/OpenFOAM directories mounted and see if that makes a difference to sHM in parallel with feature edge handling. At least then I will know that the install of OF is OK and my problem lies with the cluster setup in some way.

I'll keep you posted,

D.

[Saxwax]

I got rid of the RAID5 and the NFS but that didn't help either. I got the same issue as before when running the flange case in parallel as a stand-alone PC. I might try to recompile OpenFOAM and see if that fixes the problem.

Regards,

D.

[Aurelien Thinat]

Hi,

To be honest I gave up about this problem.

I was running on OpenSuse system (stand alone PC), it was faster to mesh in serial than to fix the problem...
Anyway, I was able to mesh in serial with the feature edge handling option or in // without it. Even with the ".eMesh" files and the good SHMDict, the output was different in serial and in //.
I made my test on OpenSuse system (stand alone PC) and on a cluster. You will find the cluster specifications here http://www.cfd-numerics.com/IMG/pdf/...uise_Ships.pdf.

The tests were run in June or July. I didn't test it again since the last release of August.

Aurélien

[Saxwax]

Aureilen,

Thanks for the reply. I switched over to the Ubuntu OpenFOAM 2.0.1 package and had the same issues. I'm not sure what is going on - I'll probably just stick to meshing on the stand-alone PC.

D.

[Toorop]

Hi,

I would like to make a little snappyHexMesh sample case which can run in serial and parallel if the system has multiple cores. In serial mode the case reaches the solver phase (the goodness of the boundary / solver setup is another question).

The parallel mode gives the first error at the splitMeshRegion, somehow there are incorrect values in the processor folders. The boundary decomposition fails, it doesn't distribute the correct values per patch (how many faces / patch), instead writes 0 everywhere.

I made the swapping of the decomposition methods (ptscotch / scotch) and added changeDictionary as well. The blockMesh and processor patches are in the processor* folders but without the changeDictionary the surface generated by sMH wont show up. The turbineSiting case has the "procBoundary.*" as well in the changeDictionary, don't know why is that necessary - frankly, why all that is necessary?

Allmake script:

#!/bin/sh
cd ${0%/*} || exit 1    # run from this directory

# source tutorial run functions
. $WM_PROJECT_DIR/bin/tools/RunFunctions

nProc=$( grep -c processor /proc/cpuinfo )
if [ $nProc > 1 ]
then
    echo "$nProc processors available for parallel execution"
    execution="parallel"
else
    execution="serial"
fi
#uncomment line below to run in serial
#execution="serial"

# create background hex mesh
runApplication blockMesh

if [ $execution = "parallel" ]
then
    sed 's/$nProc/'$nProc'/; s/$ddm/scotch/' system/decomposeParDict.org > system/decomposeParDict
    runApplication decomposePar
    
    sed 's/$nProc/'$nProc'/; s/$ddm/ptscotch/' system/decomposeParDict.org > system/decomposeParDict
    runParallel snappyHexMesh $nProc -overwrite -parallel
    
    for i in $( ls processor* -d );
    do
        # rename sphere patch
        sed -i 's/sphere_region0/'"sphereSurf"'/g' $i/constant/polyMesh/boundary
        sed -i 's/sphere_region0/'"sphereSurf"'/g' $i/0/cellLevel
        sed -i 's/sphere_region0/'"sphereSurf"'/g' $i/0/pointLevel
    done
    
    runParallel changeDictionary $nProc -literalRE -enableFunctionEntries
    
    runParallel splitMeshRegions $nProc -cellZones -overwrite -parallel
else
    sed 's/$nProc/'$nProc'/; s/$ddm/ptscotch/' system/decomposeParDict.org > system/decomposeParDict
    runApplication snappyHexMesh -overwrite

    # rename sphere patch
    sed -i 's/sphere_region0/'"sphereSurf"'/g' constant/polyMesh/boundary
    sed -i 's/sphere_region0/'"sphereSurf"'/g' 0/cellLevel
    sed -i 's/sphere_region0/'"sphereSurf"'/g' 0/pointLevel
    
    runApplication splitMeshRegions -cellZones -overwrite
fi

# geometry & patch check
runApplication checkMesh -allGeometry -allTopology
runApplication patchSummary -constant

if [ $execution = "parallel" ]
then
    # run
    runParallel `getApplication` $nProc

    # reconstruct
    runApplication reconstructPar
else
    runApplication `getApplication`
fi

# ----------------------------------------------------------------- end-of-file

And the icing on the cake: with the exact same settings sMH didn't make any layers, in serial it's okay.

Thank you!

[Saxwax]

Hi Tibor,

I have always found it useful to start with something that works, i.e. a tutorial, and then change that 1 step at a time until you get what you are after. Why not try to change the windSimpleFoam tutorial case and understand what is required to run sHM in parallel.

It might be possible to run sHM in parallel without some of the utilities that are used in the windSimpleFoam case. However, a more elaborate way of running sHM may have been used to illustrate some of the features available in OpenFOAM. Or not - I'm just guessing

Good Luck,

D.

[Toorop]

Saxwax, thank you for the advise!

I always jump the gun ... I will take a closer look at the turbine case.

I bug report that produces a similar problem as in my case: snappyHexMesh bugs from running in parallel - 'boundary' files & 0 directory files

[TimG]

Hi Aurelian,

i was facing the same problem as you did. In my case, i was able to solve it by changing the internal name of the STL file to the same as the stl file itself.

geometry
{
Mesh.stl
{
type triSurfaceMesh;
name Mesh;
}
}

On a single core, i was able to compute the Mesh with different names, but for some reason in parallel that did not work.

Althoug you already quit trying, i wanted to share my findings

Cheers
Tim

[Saxwax]

Turns out the issues I was having with parallel sHM and what not were solved by updating my Ubuntu 10.04(.3?) via the update manager. I had initially turned these updates off to keep the system more "stable" and prevent issues like XDMCP becoming unsupported due to a gdm package update etc. However, it appears that OpenFOAM has/had some issues relating to the version of Ubuntu I was using.