Issues with mapFields

ripudaman · April 10, 2014, 12:05

Update on the above message:

mapFields is giving me a similar error for various other cases.

In some cases mapFields randomly does not give me an error but in others it does.

1. Using a coarse blockMesh does not solve the problem
2. Using no region refinement using snappy does not solve the problem.

I ran a first case with a single STL file of a plane in my coarse blockMesh grid and solved my equations.
Then I mapped the results onto a grid of the blockMesh but with two surfaces (inside the blockMesh) snapped to grid using SHM. I was still able to solve my case and the results were mapped from the previous case to the current case.
I ran into an error when I tried doing this for a third grid with three surfaces snapped using SHM. This time I ran into an error using mapFields which was very similar to the error mentioned in the post above :

Code:

--> FOAM FATAL ERROR:
Plane normal defined with zero length
Bad points:(-137.15995 129.54 -7.6199818) (-137.15995 129.54 1.2356772e-05) (-137.15995 129.54 7.6200008)

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&) in "/opt/OpenFOAM/OpenFOAM-2.3.x/platforms/linux64GccDPOpt/lib/libOpenFOAM.so"
#1  Foam::error::abort() in "/opt/OpenFOAM/OpenFOAM-2.3.x/platforms/linux64GccDPOpt/lib/libOpenFOAM.so"
#2  Foam::plane::calcPntAndVec(Foam::Vector<double> const&, Foam::Vector<double> const&, Foam::Vector<double> const&) in "/opt/OpenFOAM/OpenFOAM-2.3.x/platforms/linux64GccDPOpt/lib/libOpenFOAM.so"
#3  Foam::tetOverlapVolume::tetTetOverlapVol(Foam::tetPoints const&, Foam::tetPoints const&) const in "/opt/OpenFOAM/OpenFOAM-2.3.x/platforms/linux64GccDPOpt/lib/libmeshTools.so"
#4  Foam::tetOverlapVolume::cellCellOverlapMinDecomp(Foam::primitiveMesh const&, int, Foam::primitiveMesh const&, int, Foam::treeBoundBox const&, double) const in "/opt/OpenFOAM/OpenFOAM-2.3.x/platforms/linux64GccDPOpt/lib/libmeshTools.so"
#5  Foam::meshToMeshMethod::intersect(int, int) const in "/opt/OpenFOAM/OpenFOAM-2.3.x/platforms/linux64GccDPOpt/lib/libsampling.so"
#6  Foam::cellVolumeWeightMethod::setNextCells(int&, int&, int&, Foam::List<int> const&, Foam::List<bool> const&, Foam::DynamicList<int, 0u, 2u, 1u> const&, Foam::List<int>&) const in "/opt/OpenFOAM/OpenFOAM-2.3.x/platforms/linux64GccDPOpt/lib/libsampling.so"
#7  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&) in "/opt/OpenFOAM/OpenFOAM-2.3.x/platforms/linux64GccDPOpt/lib/libsampling.so"
#8  Foam::cellVolumeWeightMethod::calculate(Foam::List<Foam::List<int> >&, Foam::List<Foam::List<double> >&, Foam::List<Foam::List<int> >&, Foam::List<Foam::List<double> >&) in "/opt/OpenFOAM/OpenFOAM-2.3.x/platforms/linux64GccDPOpt/lib/libsampling.so"
#9  Foam::meshToMesh::calcAddressing(Foam::polyMesh const&, Foam::polyMesh const&) in "/opt/OpenFOAM/OpenFOAM-2.3.x/platforms/linux64GccDPOpt/lib/libsampling.so"
#10  Foam::meshToMesh::calculate() in "/opt/OpenFOAM/OpenFOAM-2.3.x/platforms/linux64GccDPOpt/lib/libsampling.so"
#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&) in "/opt/OpenFOAM/OpenFOAM-2.3.x/platforms/linux64GccDPOpt/lib/libsampling.so"
#12
in "/opt/OpenFOAM/OpenFOAM-2.3.x/platforms/linux64GccDPOpt/bin/mapFields"
#13
in "/opt/OpenFOAM/OpenFOAM-2.3.x/platforms/linux64GccDPOpt/bin/mapFields"
#14  __libc_start_main in "/lib/x86_64-linux-gnu/libc.so.6"
#15
in "/opt/OpenFOAM/OpenFOAM-2.3.x/platforms/linux64GccDPOpt/bin/mapFields"
Aborted (core dumped)

This is a huge bottleneck for my research. mapFields was also one of the important reasons I chose to use openFOAM for my purposes.

Any help will be hugely appreciated.

Amjad Asad · May 29, 2014, 15:42

Quote:

Originally Posted by Tobi

Always I am using mapFields everything is working

Code:

 
mapFields -sourceTime latestTime -case ../coarseMeshSimulationName/

The entries in the mapFieldsDict are empty.!

Works perfekt all the time.

Hallo,
i am trying to get the internal Field values from my RANS simulation to use them as intial internal Field for LES, but the problem I always get uniform 0, can u help me pls?

Drew1 · June 17, 2014, 11:40

Hello!

I am trying to use the mapFields too. My problem is that I don't even get the following in the terminaL:

*---------------------------------------------------------------------------*\
| ========= | |
| \\ / F ield | OpenFOAM: The Open Source CFD Toolbox |
| \\ / O peration | Version: 2.2.0 |
| \\ / A nd | Web: www.OpenFOAM.org |
| \\/ M anipulation | |
\*---------------------------------------------------------------------------*/
Build : 2.2.0
Exec : mapFields /home/Z-DRIVES/s207619/Thesis/cases/noTower_AOA_yplus/k-epsilon/prueba -consistent
Date : Jun 17 2014
Time : 15:31:18
Host : "sow7503f-li.soe.cranfield.ac.uk"
PID : 4730
Case : /home/Z-DRIVES/s207619/Thesis/cases/noTower_AOA_yplus/k-omega/fine_AOA7
nProcs : 1
sigFpe : Floating point exception trapping - not supported on this platform
fileModificationChecking : Monitoring run-time modified files using timeStampMaster
allowSystemOperations : Disallowing user-supplied system call operations

// * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * //
Source: "/home/Z-DRIVES/s207619/Thesis/cases/noTower_AOA_yplus/k-epsilon" "prueba"
Target: "/home/Z-DRIVES/s207619/Thesis/cases/noTower_AOA_yplus/k-omega" "fine_AOA7"

Create databases as time

Source time: 75
Target time: 75
Create meshes

Source mesh size: 360747 Target mesh size: 683832

It gets stacked there; I don't even get the message which says: Mapping fields for time...

I have tried the suggestions in this thread but I haven't solved it yet. Does anyone have an idea or what the problem might be?

Thanks in advance.

perjorgen · November 18, 2014, 06:58

I have a similar problem
I am using SHM to generate a finer mesh contained in the coarse solution
When I run mapFields I it always find a zero normal surface - I have tried to adjust the meshquality in SHM but without success

Did you find a solution to your problem? Or does anyone else have a solution?

Quote:

Originally Posted by ripudaman

Update on the above message:

mapFields is giving me a similar error for various other cases.

In some cases mapFields randomly does not give me an error but in others it does.

1. Using a coarse blockMesh does not solve the problem
2. Using no region refinement using snappy does not solve the problem.

I ran a first case with a single STL file of a plane in my coarse blockMesh grid and solved my equations.
Then I mapped the results onto a grid of the blockMesh but with two surfaces (inside the blockMesh) snapped to grid using SHM. I was still able to solve my case and the results were mapped from the previous case to the current case.
I ran into an error when I tried doing this for a third grid with three surfaces snapped using SHM. This time I ran into an error using mapFields which was very similar to the error mentioned in the post above :

Code:

--> FOAM FATAL ERROR:
Plane normal defined with zero length
Bad points:(-137.15995 129.54 -7.6199818) (-137.15995 129.54 1.2356772e-05) (-137.15995 129.54 7.6200008)

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&) in "/opt/OpenFOAM/OpenFOAM-2.3.x/platforms/linux64GccDPOpt/lib/libOpenFOAM.so"
#1  Foam::error::abort() in "/opt/OpenFOAM/OpenFOAM-2.3.x/platforms/linux64GccDPOpt/lib/libOpenFOAM.so"
#2  Foam::plane::calcPntAndVec(Foam::Vector<double> const&, Foam::Vector<double> const&, Foam::Vector<double> const&) in "/opt/OpenFOAM/OpenFOAM-2.3.x/platforms/linux64GccDPOpt/lib/libOpenFOAM.so"
#3  Foam::tetOverlapVolume::tetTetOverlapVol(Foam::tetPoints const&, Foam::tetPoints const&) const in "/opt/OpenFOAM/OpenFOAM-2.3.x/platforms/linux64GccDPOpt/lib/libmeshTools.so"
#4  Foam::tetOverlapVolume::cellCellOverlapMinDecomp(Foam::primitiveMesh const&, int, Foam::primitiveMesh const&, int, Foam::treeBoundBox const&, double) const in "/opt/OpenFOAM/OpenFOAM-2.3.x/platforms/linux64GccDPOpt/lib/libmeshTools.so"
#5  Foam::meshToMeshMethod::intersect(int, int) const in "/opt/OpenFOAM/OpenFOAM-2.3.x/platforms/linux64GccDPOpt/lib/libsampling.so"
#6  Foam::cellVolumeWeightMethod::setNextCells(int&, int&, int&, Foam::List<int> const&, Foam::List<bool> const&, Foam::DynamicList<int, 0u, 2u, 1u> const&, Foam::List<int>&) const in "/opt/OpenFOAM/OpenFOAM-2.3.x/platforms/linux64GccDPOpt/lib/libsampling.so"
#7  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&) in "/opt/OpenFOAM/OpenFOAM-2.3.x/platforms/linux64GccDPOpt/lib/libsampling.so"
#8  Foam::cellVolumeWeightMethod::calculate(Foam::List<Foam::List<int> >&, Foam::List<Foam::List<double> >&, Foam::List<Foam::List<int> >&, Foam::List<Foam::List<double> >&) in "/opt/OpenFOAM/OpenFOAM-2.3.x/platforms/linux64GccDPOpt/lib/libsampling.so"
#9  Foam::meshToMesh::calcAddressing(Foam::polyMesh const&, Foam::polyMesh const&) in "/opt/OpenFOAM/OpenFOAM-2.3.x/platforms/linux64GccDPOpt/lib/libsampling.so"
#10  Foam::meshToMesh::calculate() in "/opt/OpenFOAM/OpenFOAM-2.3.x/platforms/linux64GccDPOpt/lib/libsampling.so"
#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&) in "/opt/OpenFOAM/OpenFOAM-2.3.x/platforms/linux64GccDPOpt/lib/libsampling.so"
#12
in "/opt/OpenFOAM/OpenFOAM-2.3.x/platforms/linux64GccDPOpt/bin/mapFields"
#13
in "/opt/OpenFOAM/OpenFOAM-2.3.x/platforms/linux64GccDPOpt/bin/mapFields"
#14  __libc_start_main in "/lib/x86_64-linux-gnu/libc.so.6"
#15
in "/opt/OpenFOAM/OpenFOAM-2.3.x/platforms/linux64GccDPOpt/bin/mapFields"
Aborted (core dumped)

This is a huge bottleneck for my research. mapFields was also one of the important reasons I chose to use openFOAM for my purposes.

Any help will be hugely appreciated.

perjorgen · November 18, 2014, 08:57

UPDATE: the implementation of calcAdressing has changes in 2.3
In Foam::tetOverlapVolume::tetTetOverlapVol
I would expect that tet's with 3 points on a line should be caught by
if ((tetA.tet().mag() < SMALL) || (tetB.tet().mag() < SMALL))
{
return 0.0;
}

perjorgen · November 21, 2014, 05:57

Quote:

Originally Posted by perjorgen

UPDATE: the implementation of calcAdressing has changes in 2.3
In Foam::tetOverlapVolume::tetTetOverlapVol
I would expect that tet's with 3 points on a line should be caught by
if ((tetA.tet().mag() < SMALL) || (tetB.tet().mag() < SMALL))
{
return 0.0;
}

tetB.tet().mag() has a round off error in the order of SMALL which is what causes the problem for large meshdistances

If I make the mesh finer the problem goes away

Seroga · November 21, 2014, 15:24

Hi everyone!

Does it possible in OpenFOAM to map fields between to computational domain that don't have common points at all? However the domains are topologically similar.
Domain.JPG

perjorgen · November 22, 2014, 06:48

Quote:

Originally Posted by Seroga

Hi everyone!

Does it possible in OpenFOAM to map fields between to computational domain that don't have common points at all? However the domains are topologically similar.
Attachment 35385

If you make a transformation of the coordinates first, then you should be able to do it
if you use ascii the file constant/polymesh/points contain the coordinates - change these in the source geom

Seroga · November 23, 2014, 13:00

Thanks for your answer, but I didn't understand what did you mean, actually...
Both domains are generated with snappyHexMesh utility for example. So the number of computational grid points are different.
Could you please explain your answer in more detail?
Thanks beforehand

perjorgen · November 24, 2014, 04:07

If your 2 domains overlap mapFields should work just fine even though they don't have common point. But not having common points at all I read as they are located in entirely different places in space, and in that case mapFields will not work, for it to work you need to transform your source points so they overlap your target. I am not aware of a tool that does it, so you might have to program it yourself

ripudaman · December 27, 2014, 02:58

Thanks a lot for figuring out the solution to the problem perjorgen.

Like Seroga, I am a little confused about the implementation of your solution.

For your reference here are a few lines from my source and target points files.

Source:

Code:

189558
(
(-300 -300 -3352.84)
(-270 -300 -3352.84)
(-240 -300 -3352.84)
(-210 -300 -3352.84)
(-180 -300 -3352.84)
(-150 -300 -3352.84)
(-120 -300 -3352.84)
(-90 -300 -3352.84)
(-60 -300 -3352.84)
(-30 -300 -3352.84)
(-8.8294375e-20 -300 -3352.84)
(30 -300 -3352.84)
(60 -300 -3352.84)
(90 -300 -3352.84)
(120 -300 -3352.84)
(150 -300 -3352.84)
(180 -300 -3352.84)
(210 -300 -3352.84)
(240 -300 -3352.84)
(270 -300 -3352.84)
(300 -300 -3352.84)
(-300 -270 -3352.84)
(-270 -270 -3352.84)
(-240 -270 -3352.84)
(-210 -270 -3352.84)
(-180 -270 -3352.84)
(-150 -270 -3352.84)
(-120 -270 -3352.84)
(-90 -270 -3352.84)
(-60 -270 -3352.84)
(-30 -270 -3352.84)
(-1.5745528e-19 -270 -3352.84)
(30 -270 -3352.84)
(60 -270 -3352.84)
(90 -270 -3352.84)
(120 -270 -3352.84)
(150 -270 -3352.84)
(180 -270 -3352.84)
(210 -270 -3352.84)
(240 -270 -3352.84)
(270 -270 -3352.84)
(300 -270 -3352.84)
(-300 -240 -3352.84)
(-270 -240 -3352.84)
(-240 -240 -3352.84)
(-210 -240 -3352.84)
(-180 -240 -3352.84)
(-150 -240 -3352.84)
(-120 -240 -3352.84)
(-90 -240 -3352.84)
(-60 -240 -3352.84)
(-30 -240 -3352.84)
(-3.5706191e-19 -240 -3352.84)
(30 -240 -3352.84)
(60 -240 -3352.84)
...

and Target:

Code:

219198
(
(-300 -300 -3352.84)
(-270 -300 -3352.84)
(-240 -300 -3352.84)
(-210 -300 -3352.84)
(-180 -300 -3352.84)
(-150 -300 -3352.84)
(-120 -300 -3352.84)
(-90 -300 -3352.84)
(-60 -300 -3352.84)
(-30 -300 -3352.84)
(1.5276265e-07 -300 -3352.84)
(30 -300 -3352.84)
(60 -300 -3352.84)
(90 -300 -3352.84)
(120 -300 -3352.84)
(150 -300 -3352.84)
(180 -300 -3352.84)
(210 -300 -3352.84)
(240 -300 -3352.84)
(270 -300 -3352.84)
(300 -300 -3352.84)
(-300 -270 -3352.84)
(-270 -270 -3352.84)
(-240 -270 -3352.84)
(-210 -270 -3352.84)
(-180 -270 -3352.84)
(-150 -270 -3352.84)
(-120 -270 -3352.84)
(-90 -270 -3352.84)
(-60 -270 -3352.84)
(-30 -270 -3352.84)
(1.1986395e-07 -270 -3352.84)
(30 -270 -3352.84)
(60.000001 -270 -3352.84)
(90.000001 -270 -3352.84)
(120 -270 -3352.84)
(150 -270 -3352.84)
(180 -270 -3352.84)
(210 -270 -3352.84)
(240 -270 -3352.84)
(270 -270 -3352.84)
(300 -270 -3352.84)
(-300 -240 -3352.84)
(-270 -240 -3352.84)
(-240 -240 -3352.84)
(-210 -240 -3352.84)
(-180 -240 -3352.84)
(-150 -240 -3352.84)
(-120 -240 -3352.84)
(-90.000001 -240 -3352.84)
(-60.000001 -240 -3352.84)
(-30.000001 -240 -3352.84)
(-2.6021587e-07 -240 -3352.84)
(30 -240 -3352.84)
(60.000001 -240 -3352.84)
...

Based on your recommendation the points should be corresponding. Does that mean that the 11th point in my target file should be changed from (1.5276265e-07 -300 -3352.84) to (-8.8294375e-20 -300 -3352.84) ?

And do you recommend writing a program that finds the minimum distance between points in the source and target and replaces the points in the target file with the points of the source file if the distance between points is less than a small number such as 1e-6?

Your clarification here will be extremely useful.

Thank you.
Regards,
Ripu

Astrodan · March 31, 2015, 12:37

I just found this thread because I also had the error and googling brought me here

Code:

--> FOAM FATAL ERROR: 
Plane normal defined with zero length

I had a couple of problems with the mapFields utility of lately, and it seems there have been a couple of changes from OF2.2.x to OF2.3.x.

So my "solution" right now is to temporarily switch to of22x (using alias, compare Using aliases to help manage multiple OpenFOAM versions), map my fields and revert to OF23x.

Another possibility might be to port the old mapFields to OF23x, but I leave that to people who care...

Chanterz · February 5, 2016, 00:26

Hi ripudaman and foamers,

Have you had any development on this probelm? I have mentioned your error in this thread with a proposed solution:
http://www.cfd-online.com/Forums/ope...utility-2.html

I feel as if the problems I am having are very close to the problems described in this thread. I do believe 3.0x has reverted back to 2.2x functionality with mapFields.

potentialFoam · April 25, 2018, 06:32

Dear Foamers,

I also struggled some time with mapFields in version 1606 (and newer) with
- three snappy meshes (of a model scale ship w/o free surface)
- coarse/ medium/ fine, lowRe
- # 14, 25 and 50 million cells.

The problems were that either no fields were mapped (using mapFieldsDict) or that an Error (sigSegv) appeared (with option -consistent).

SOLUTION:
Using the option 'mapMethod'
https://www.openfoam.com/documentati...8C_source.html
The default entry 'interpolate' leads to the error, but both others work:
- mapNearest
- cellPointInterpolate

Important: You need to consider the mapping-interpolation for sure... But hey, at least it works

MaySea · January 24, 2021, 13:32

Hi all,

I have two meshes, one is an extension of another. It's a kind of an inlet fetch for a logarithmic velocity profile to develop properly before it reaches my terrain geometry. An outlet of the fetch, called nnw should deliver U, k, omega for the inlet (sse) of the main mesh. I use OF6.

Now, the fetch mesh refinement levels are different than that of the main mesh. The main mesh is much finer. The outlet of the fetch is exactly in the same place in space as the inlet for target mesh, but it is less refined.

So I have been trying to use mapFields to impose the outlet fields of the fetch mesh into the inlet of the main, fine mesh. I have the mapFieldsDict in my target case:

nnw is the outlet of the coarse fetch, sse is the inlet of the fine main mesh.

Code:

patchMap
(nnw sse);

cuttingPatches  ();

I have all the field dictionaries in my target case; U, omega etc. with fixedValue;
value uniform (0 0 0); at the velocity inlet etc.

The problem is that when I execute
mapFields /path/to/source case/ -sourceTime latestTime it detects all the fields, performs interpolation but after it finishes, nothing changes.
I also tried defining the inlet of the fine, target case as the cutting plane and it performed some bizarre interpolation with multiple zero values (see the screengrabs).
I tried different interpolation types too, didn't help.
Screengrabs:
https://photos.google.com/share/AF1Q...JnVV9sNHlOYWlR

Any ideas how to cope with this problem? thanks.

MaySea · January 25, 2021, 07:18

Well, problem solved. I simply swapped the patch names in the mapFieldsDict's patchMap.
The first one is a target patch, the second one is the source patch.
To my understanding it is contrary to what is written here:
https://cfd.direct/openfoam/user-guide/v6-mapfields/

I hope this helps someone who has the same problem in the future.

PuWang · March 11, 2021, 03:02

hi, I have meet the same problem with you that there is no data wrtitten in the target U file,but i solved this problem by this:
check the coordinate about the domain wheather is correspond to the domain you want, which means you need to ensure the way the map field you want dont need any extra translation or rotation.
for example you want the inlet be mapped,the source geometry is at (-5 0 0) to (0 0 0), the length of x direction is 5, but your target geometry is at (10 0 0) to (15 0 0),although your geometry is totally the same size,but there is no any of coincident mapfield! that's why we won't have any data in our target field.
hope this will help you anyway.
Regards

slashss4 · May 28, 2021, 16:59

Dear MaySea,

I was working on similar problem. Could you share the related cutting plane file? I've also obtained a cutting plane but when I executed the mapFields command my U file does not change.

Kind Regards

MaySea · May 28, 2021, 17:29

Quote:

Originally Posted by slashss4

Dear MaySea,

I was working on similar problem. Could you share the related cutting plane file? I've also obtained a cutting plane but when I executed the mapFields command my U file does not change.

Kind Regards

Hi Slash,

Here nnw is my receiving (target) patch and sse is my source patch. I map the outlet "sse" into inlet "nnw".

The command I use:
mapFields /path/ -sourceTime latestTime -mapMethod mapNearest

Code:

/*--------------------------------*- C++ -*----------------------------------*\
  =========                 |
  \\      /  F ield         | OpenFOAM: The Open Source CFD Toolbox
   \\    /   O peration     | Website:  https://openfoam.org
    \\  /    A nd           | Version:  6
     \\/     M anipulation  |
\*---------------------------------------------------------------------------*/
FoamFile
{
    version     2.0;
    format      ascii;
    class       dictionary;
    location    "system";
    object      mapFieldsDict;
}
// * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * //

patchMap
(nnw sse);
//target source
//mapMethod "mapNearest"
//cellPointInterpolate
cuttingPatches  ();


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

I hope this helps,
Jan

June 17, 2014, 11:40	mapFields issue	#23
Drew1 New Member Join Date: May 2014 Posts: 6 Rep Power: 12	Hello! I am trying to use the mapFields too. My problem is that I don't even get the following in the terminaL: ---------------------------------------------------------------------------\ \| ========= \| \| \| \\ / F ield \| OpenFOAM: The Open Source CFD Toolbox \| \| \\ / O peration \| Version: 2.2.0 \| \| \\ / A nd \| Web: www.OpenFOAM.org \| \| \\/ M anipulation \| \| \---------------------------------------------------------------------------/ Build : 2.2.0 Exec : mapFields /home/Z-DRIVES/s207619/Thesis/cases/noTower_AOA_yplus/k-epsilon/prueba -consistent Date : Jun 17 2014 Time : 15:31:18 Host : "sow7503f-li.soe.cranfield.ac.uk" PID : 4730 Case : /home/Z-DRIVES/s207619/Thesis/cases/noTower_AOA_yplus/k-omega/fine_AOA7 nProcs : 1 sigFpe : Floating point exception trapping - not supported on this platform fileModificationChecking : Monitoring run-time modified files using timeStampMaster allowSystemOperations : Disallowing user-supplied system call operations // * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * // Source: "/home/Z-DRIVES/s207619/Thesis/cases/noTower_AOA_yplus/k-epsilon" "prueba" Target: "/home/Z-DRIVES/s207619/Thesis/cases/noTower_AOA_yplus/k-omega" "fine_AOA7" Create databases as time Source time: 75 Target time: 75 Create meshes Source mesh size: 360747 Target mesh size: 683832 It gets stacked there; I don't even get the message which says: Mapping fields for time... I have tried the suggestions in this thread but I haven't solved it yet. Does anyone have an idea or what the problem might be? Thanks in advance.

March 31, 2015, 12:37		#32
Astrodan Member Timm Severin Join Date: Mar 2014 Location: Munich Posts: 63 Rep Power: 12	I just found this thread because I also had the error and googling brought me here Code: --> FOAM FATAL ERROR: Plane normal defined with zero length I had a couple of problems with the mapFields utility of lately, and it seems there have been a couple of changes from OF2.2.x to OF2.3.x. So my "solution" right now is to temporarily switch to of22x (using alias, compare Using aliases to help manage multiple OpenFOAM versions), map my fields and revert to OF23x. Another possibility might be to port the old mapFields to OF23x, but I leave that to people who care... chengyu and Chanterz like this. __________________ PhD Student at the Institute of Biochemical Engineering at TU München Modelling of fluid dynamics in open photobioreactors. System: OpenFOAM 2.3.x, 64bit, 8 Core Xeon Workstation

February 5, 2016, 00:26		#33
Chanterz New Member Jade Chantrell Join Date: Dec 2015 Location: Newcastle, Australia Posts: 12 Rep Power: 10	Hi ripudaman and foamers, Have you had any development on this probelm? I have mentioned your error in this thread with a proposed solution: http://www.cfd-online.com/Forums/ope...utility-2.html I feel as if the problems I am having are very close to the problems described in this thread. I do believe 3.0x has reverted back to 2.2x functionality with mapFields. Last edited by Chanterz; February 5, 2016 at 00:28. Reason: forgot to mention something

April 25, 2018, 06:32		#34
potentialFoam Member Peter Join Date: Nov 2015 Location: Hamburg, Germany Posts: 57 Rep Power: 11	Dear Foamers, I also struggled some time with mapFields in version 1606 (and newer) with - three snappy meshes (of a model scale ship w/o free surface) - coarse/ medium/ fine, lowRe - # 14, 25 and 50 million cells. The problems were that either no fields were mapped (using mapFieldsDict) or that an Error (sigSegv) appeared (with option -consistent). SOLUTION: Using the option 'mapMethod' https://www.openfoam.com/documentati...8C_source.html The default entry 'interpolate' leads to the error, but both others work: - mapNearest - cellPointInterpolate Important: You need to consider the mapping-interpolation for sure... But hey, at least it works LuckyTran and aow like this.

January 24, 2021, 13:32	Problem with mapping outlet velocities of once mesh to inlet patch of another mesh	#35
MaySea Member Jan Majcher Join Date: Nov 2018 Posts: 39 Rep Power: 8	Hi all, I have two meshes, one is an extension of another. It's a kind of an inlet fetch for a logarithmic velocity profile to develop properly before it reaches my terrain geometry. An outlet of the fetch, called nnw should deliver U, k, omega for the inlet (sse) of the main mesh. I use OF6. Now, the fetch mesh refinement levels are different than that of the main mesh. The main mesh is much finer. The outlet of the fetch is exactly in the same place in space as the inlet for target mesh, but it is less refined. So I have been trying to use mapFields to impose the outlet fields of the fetch mesh into the inlet of the main, fine mesh. I have the mapFieldsDict in my target case: nnw is the outlet of the coarse fetch, sse is the inlet of the fine main mesh. Code: patchMap (nnw sse); cuttingPatches (); I have all the field dictionaries in my target case; U, omega etc. with fixedValue; value uniform (0 0 0); at the velocity inlet etc. The problem is that when I execute mapFields /path/to/source case/ -sourceTime latestTime it detects all the fields, performs interpolation but after it finishes, nothing changes. I also tried defining the inlet of the fine, target case as the cutting plane and it performed some bizarre interpolation with multiple zero values (see the screengrabs). I tried different interpolation types too, didn't help. Screengrabs: https://photos.google.com/share/AF1Q...JnVV9sNHlOYWlR Any ideas how to cope with this problem? thanks.

November 18, 2014, 08:57		#25
perjorgen New Member Per Jørgensen Join Date: Mar 2012 Posts: 20 Rep Power: 14	UPDATE: the implementation of calcAdressing has changes in 2.3 In Foam::tetOverlapVolume::tetTetOverlapVol I would expect that tet's with 3 points on a line should be caught by if ((tetA.tet().mag() < SMALL) \|\| (tetB.tet().mag() < SMALL)) { return 0.0; }

November 21, 2014, 15:24		#27
Seroga Member Seroga Join Date: Dec 2011 Posts: 41 Rep Power: 14	Hi everyone! Does it possible in OpenFOAM to map fields between to computational domain that don't have common points at all? However the domains are topologically similar. Domain.JPG

November 23, 2014, 13:00		#29
Seroga Member Seroga Join Date: Dec 2011 Posts: 41 Rep Power: 14	Thanks for your answer, but I didn't understand what did you mean, actually... Both domains are generated with snappyHexMesh utility for example. So the number of computational grid points are different. Could you please explain your answer in more detail? Thanks beforehand

November 24, 2014, 04:07		#30
perjorgen New Member Per Jørgensen Join Date: Mar 2012 Posts: 20 Rep Power: 14	If your 2 domains overlap mapFields should work just fine even though they don't have common point. But not having common points at all I read as they are located in entirely different places in space, and in that case mapFields will not work, for it to work you need to transform your source points so they overlap your target. I am not aware of a tool that does it, so you might have to program it yourself

January 25, 2021, 07:18		#36
MaySea Member Jan Majcher Join Date: Nov 2018 Posts: 39 Rep Power: 8	Well, problem solved. I simply swapped the patch names in the mapFieldsDict's patchMap. The first one is a target patch, the second one is the source patch. To my understanding it is contrary to what is written here: https://cfd.direct/openfoam/user-guide/v6-mapfields/ I hope this helps someone who has the same problem in the future.

March 11, 2021, 03:02		#37
PuWang New Member anis1984 Join Date: Oct 2019 Posts: 2 Rep Power: 0	hi, I have meet the same problem with you that there is no data wrtitten in the target U file,but i solved this problem by this: check the coordinate about the domain wheather is correspond to the domain you want, which means you need to ensure the way the map field you want dont need any extra translation or rotation. for example you want the inlet be mapped,the source geometry is at (-5 0 0) to (0 0 0), the length of x direction is 5, but your target geometry is at (10 0 0) to (15 0 0),although your geometry is totally the same size,but there is no any of coincident mapfield! that's why we won't have any data in our target field. hope this will help you anyway. Regards

May 28, 2021, 16:59		#38
slashss4 New Member Join Date: Sep 2014 Posts: 8 Rep Power: 12	Dear MaySea, I was working on similar problem. Could you share the related cutting plane file? I've also obtained a cutting plane but when I executed the mapFields command my U file does not change. Kind Regards

Similar Threads
Thread	Thread Starter	Forum	Replies	Last Post
FLUENT Speed Issues on Cluster	cfd23	FLUENT	2	April 4, 2010 00:43
mapFields problems	andrea.pasquali	OpenFOAM	1	February 17, 2010 23:57
mapFields ignores sourceTime for -parallel source	andersking	OpenFOAM Bugs	2	September 2, 2009 11:38
mapFields between inconsistent meshes	nikwin	OpenFOAM Pre-Processing	7	July 30, 2009 05:35
MapFields to New Grid For Extreme Grid Deformations due to Body Motion	albcem	OpenFOAM	0	May 5, 2009 15:17