[Dmoore]

Hello!

I am working to use snappyHexMesh to mesh and simulate a 3-D .stl file of a channel flow contraction in openFOAM v2.2.0 to be run on a 24 core machine using a parallel approach and the simpleFOAM solver. So far I have successfully set up a blockMesh backround mesh, extracted surface features using surfaceFeatureExtract, decomposePar to decompose the case into the proper set of domains. But when I execute:

mpirun -np 24 simpleFoam -parallel > log &

I receive errors saying:

[1] --> FOAM FATAL IO ERROR:
[1] Cannot find patchField entry for contraction_contraction
[1]
[1] file: /home/teamsoh/OpenFOAM/teamsoh-2.2.0/run/sohWind/bigBlock/processor1/0/p.boundaryField from line 26 to line 45.
[1]
[1] From function GeometricField<Type, PatchField, GeoMesh>::GeometricBoundaryField::readField(const DimensionedField<Type, GeoMesh>&, const dictionary&)
[1] in file /home/opencfd/OpenFOAM/OpenFOAM-2.2.0/src/OpenFOAM/lnInclude/GeometricBoundaryField.C at line 154.
[1]
FOAM parallel run exiting


I have found the offending code line "contraction_contraction". It exists only in the processor files after decomposePar is executed, casefile/processor#/constant/polymesh/boundary (ie it does not exist in the original casefile/constant/polymesh/boundary file). But I have yet to see a problem with the format/syntax/code structure etc...

Is there anyone who might suggest a strategy for resolving this error? Or perhaps a better method for simulating a channel flow (with a contraction and expansion)? Any input is much appreciated! Thank you

[niklas]

does it work for a single run, ie non-parallell run?

thats the first thing to check

[Dmoore]

Yes, but very slowly. It is a rather large domain.

[JR22]

Check your 0 directories under your processor directories. The decomposePar might not be copying the files (your error is telling you it can't find the "p" file). If this is the case, you can either copy the files using the "cp" linux command or reconstructing (using "reconstructPar" and "reconstructParMesh -constant") and decomposing once more.

Check the post before the last in the thread; I wrote the Allrun file that goes through the cycle to solve the problem:
http://www.cfd-online.com/Forums/ope...-parallel.html

[Dmoore]

Thank you! I will look into that. Is it also possible that paraView is not seeing the .stl surface that I am trying to snap to? I cannot seem to open it independently through paraView. The only way I can see it is to execute surfaceFeatureConvert to move the eMesh file to a .obj (like the tutorials) and then view it.

[JR22]

If you created your STL on your own, I would go back to your CAD program and play around with the STL export options until you get it to open in paraView. Paraview's STL import is pretty robust, and if your STL has problems it is likely to create problems for you in the near future. If you can't remake the STL, then you can try adjusting it with one of the STL mesh repair programs that are usually used for 3D printing and prototyping. Two come to mind:

• NetFabb has a free version that works.
• MeshLab is the most commonly used Open Source Mesh Repair software. It has a lot of options, but if you google it, you will find tutorials that tell you what filters to use to repair STLs