CFD Online Discussion Forums - Map fields to a parallel target in OF 2.4.0

CFD Online Discussion Forums (https://www.cfd-online.com/Forums/)

- OpenFOAM Running, Solving & CFD (https://www.cfd-online.com/Forums/openfoam-solving/)

- - Map fields to a parallel target in OF 2.4.0 (https://www.cfd-online.com/Forums/openfoam-solving/195095-map-fields-parallel-target-2-4-0-a.html)

Map fields to a parallel target in OF 2.4.0

Dear Foamers,

I really need helps. I want to map fields from a coarse, huge domain to a smaller, finer domain. The coarse domain is created using blockMesh, and the internal fields is listed as a non-uniform list in the "0" directory.I have visualize the fields in the coarse domain and they have no problems.

Then, I created a smaller and finer domain using snappyHexMesh. The geometry is quite complicated, and snappyHexMesh is executed using 8 processors. I am sure that the smaller domain is inside the lager one.

Now, I want to initiate the fields in the smaller domain using the fields of the larger domain. So I go into one of the processor files and type the command:

Code:

mapFields "the root directory of the case of the larger domain"

However, I always get the following error message:

Code:

--> FOAM FATAL ERROR:

Plane normal defined with zero length

Bad points:(835993.7481 816206.248 3) (835993.7481 816206.248 4.562488583) (835993.7481 816206.248 6.124976401)



    From function void plane::calcPntAndVec

(

    const point&,

    const point&,

    const point&

)



    in file meshes/primitiveShapes/plane/plane.C at line 116.



FOAM aborting



#0  Foam::error::printStack(Foam::Ostream&) at ??:?

#1  Foam::error::abort() at ??:?

#2  Foam::plane::calcPntAndVec(Foam::Vector<double> const&, Foam::Vector<double> const&, Foam::Vector<double> const&) at ??:?

#3  Foam::tetOverlapVolume::tetTetOverlapVol(Foam::tetPoints const&, Foam::tetPoints const&) const at ??:?

#4  Foam::tetOverlapVolume::cellCellOverlapVolumeMinDecomp(Foam::primitiveMesh const&, int, Foam::primitiveMesh const&, int, Foam::treeBoundBox const&) const at ??:?

#5  Foam::meshToMeshMethod::interVol(int, int) const at ??:?

#6  Foam::cellVolumeWeightMethod::calculateAddressing(Foam::List<Foam::List<int> >&, Foam::List<Foam::List<double> >&, Foam::List<Foam::List<int> >&, Foam::List<Foam::List<double> >&, int, int, Foam::List<int> const&, Foam::List<bool>&, int&) at ??:?

#7  Foam::cellVolumeWeightMethod::calculate(Foam::List<Foam::List<int> >&, Foam::List<Foam::List<double> >&, Foam::List<Foam::List<int> >&, Foam::List<Foam::List<double> >&) at ??:?

#8  Foam::meshToMesh::calcAddressing(Foam::word const&, Foam::polyMesh const&, Foam::polyMesh const&) at ??:?

#9  Foam::meshToMesh::calculate(Foam::word const&) at ??:?

#10  Foam::meshToMesh::constructFromCuttingPatches(Foam::word const&, Foam::word const&, Foam::HashTable<Foam::word, Foam::word, Foam::string::hash> const&, Foam::List<Foam::word> const&) at ??:?

#11  Foam::meshToMesh::meshToMesh(Foam::polyMesh const&, Foam::polyMesh const&, Foam::meshToMesh::interpolationMethod const&, Foam::HashTable<Foam::word, Foam::word, Foam::string::hash> const&, Foam::List<Foam::word> const&) at ??:?

#12  ? at ??:?

#13  ? at ??:?

#14  __libc_start_main in "/lib64/libc.so.6"

#15  ? at ??:?

Aborted

I am using OpenFOAM 2.4.0. Is there any idea what's wrong?

Many Thanks! Any comments are appreciated.

Dominic

I've never seen a plane normal with zero lenght before, but if you appreciate ANY comments than I might aswell try to help you semi-socratically.

Have you tried removing the mapped BC and replacing them with simpler ones that you know works? It will give you the wrong result, but then you will know if the error lays somewhere in your mesh or in your BC.

It looks like its refering to a very spesific plane. Snappyhex has a tendency to make almost, but not QUITE perfect planes. usually the corners are a bit approximated. Is it possible you are using a BC that is designed for a perfectly plane surface on a surface that isn't?

Thank you for your help.

I have tried setting all boundary conditions to be "zeroGradient" but this doesn't solve the problem.

I found something interesting:
After running "decomposePar" and before running "snappyHexMesh", I tried to go into the processor file and run "mapFields". It works well. I also visualize the result and everything is good. However, if I add my geometry into my domain and run "snappyHexMesh" before running "mapFields", the error message comes out again.

It seems that mapFields cannot handle complex geometry. Do you have experience on mapping fields from a block mesh to a mesh created by snappyHexMesh?

Thanks again.

I dont.

I had a geometry earlier however where teh approximation from snappyhexmesh was to inexact, and I ended up having to mesh everything using Gmsh.

I've found that Gmsh files take a lot of time to make, but are easy to adjust once you get the hang of it. And meshes often need to be adjusted as the project develops.

If you have a unidentified problem tied to your mesh, redoing it in gmsh may be a workaround. If nothing else, it removes the need for using snappyhexmesh.