CFD Online Discussion Forums

CFD Online Discussion Forums (https://www.cfd-online.com/Forums/)
-   OpenFOAM Pre-Processing (https://www.cfd-online.com/Forums/openfoam-pre-processing/)
-   -   Issues with mapFields (https://www.cfd-online.com/Forums/openfoam-pre-processing/81780-issues-mapfields.html)

BlackBoatNavArch November 6, 2010 11:03

Issues with mapFields
 
Hi all.

I'm trying to use the mapFields utility to go from a coarser mesh to a finer one. I'm interested in refining the mesh around a body and have been using refinement regions in snappyHexMesh. The surface refinement on the body isn't changing at all, so the body meshes should be ~identical.

After solving my coarser mesh to 1000 steps, I run the mapFields two different ways and get two different problems.

Using -consistent, I get a target folder at the correct time in my new finer mesh. The interpolation has some issues but seemingly not near regions that are newly refined. Namely, I get small regions decreasing velocity to 0, which isn't ideal, but I think running the solution should get rid of them. The problem is I also get negative values of omega at those regions. This trips the bounding omega in the log file when I try to solve and the solver crashes. The error message has a lot about turbulence models and FPE's but I certainly don't find it particularly helpful.

Using the mapFieldDict method, I get the following output.

Code:

xxx@XXX-linux:~/OpenFOAM/xxx-1.7.1/run/domain_1b$ mapFields ../domain_1a
/*---------------------------------------------------------------------------*\
| =========                |                                                |
| \\      /  F ield        | OpenFOAM: The Open Source CFD Toolbox          |
|  \\    /  O peration    | Version:  1.7.1                                |
|  \\  /    A nd          | Web:      www.OpenFOAM.com                      |
|    \\/    M anipulation  |                                                |
\*---------------------------------------------------------------------------*/
Build  : 1.7.1-320803922ee1
Exec  : mapFields ../domain_1a
Date  : Nov 07 2010
Time  : 01:30:07
Host  : XXX-linux
PID    : 13179
Case  : /home/xxx/OpenFOAM/xxx-1.7.1/run/domain_1b
nProcs : 1
SigFpe : Enabling floating point exception trapping (FOAM_SIGFPE).

// * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * //
Source: ".." "domain_1a"
Target: "/home/xxx/OpenFOAM/xxx-1.7.1/run" "domain_1b"

Create databases as time

Source time: 1000
Target time: 1000
Create meshes

Source mesh size: 1130080    Target mesh size: 1824109


Mapping fields for time 1000


End

Again the times line up, and the meshes are correct. But the fields aren't interpolated at all and I do not get a new folder for time = 1000. I think it might be my mapFieldDict file, but I've followed the advice of other threads and the OpenFOAM manual.

Code:

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

patchMap       
(
    inboard inboard
    outboard outboard
    inlet inlet
    outlet outlet
    bottomAndTop bottomAndTop   
    hull_BL_A_O hull_BL_A_O
);

cuttingPatches 
(
   
);


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

The mapFieldsDict method runs through all the interpolate fields if I have already run -consistent, but the second interpolation doesn't change the values at all. I'm using OpenFoam 1.7.1 which doesn't require a target field as was noted in at least one other thread and attempting to put one in gives an argument error as expected.

So, I'm not entirely sure what to do. Obviously, not having to solve the whole 1.8mil mesh would be nice since its just a mesh refinement. I'm finding this problem is intermittent. Sometimes I am able to use -consistent and don't get the negative omega values. It varies with the mesh refinement that I am starting with and what I add to it. Which is all very frustrating.

mvoss January 13, 2011 05:09

hi,

i am having the same problem. mapFields running without error but also without creating something.

Did you found a solution?

McCarra January 16, 2011 13:12

In my case it works executing:

mapFields directory_example/case_directory -sourceTime latestTime

I left patchMap and cuttingPatches subDicts blank in the mapFieldsDict, but I created beforehand the temporal directory.

Have a look at your time directory named "100" (latest time) because it should exist. Your simulation should reach the latest time to map the results and write it. If it is not created check the writing interval in controlDict.

In my case the mesh size is the same but the geometry is different because it is a dynamic mesh problem. I have not tried with meshes of other sizes.

mrshb4 February 12, 2011 14:24

Hi
Is it possible to map all the time directories of a case, to another one?!
I mean map data from directories 0, 0.01, 0.02, 0.03, ..... of case 1 into directories 0, 0.01, 0.02, 0.03, ..... of case 2, all with one command?!!

msbealo April 12, 2011 13:07

Did you ever solve this? I'm having exactly the same problem. If I use -consistent I get negative omega values and my solver gives up, if I use mapFieldsDict (with blank entries) I don't get an output.

I'm trying to map between a coarse and a medium mesh where the mesh density has only been changed by upping the values in blockMeshDict before running snappyHexMesh.

I've tried:

Code:

mapFields ../Coarse -consistent
(negative values and solver problems)
Code:

mapFields ../Coarse -sourceTime 10
(no output, "10" is the last time step)
Code:

mapFields ../Coarse -sourceTime 0
(nothing)
Code:

mapFields ../Coarse -sourceTime latestTime
(nothing)

For each of the the cases I get a similar shell output of

Code:

Build  : 1.7.x-131caa989cd3
Exec  : mapFields ../Coarse -sourceTime latestTime
Date  : Apr 12 2011
Time  : 18:01:07
Host  : msbealo-desk
PID    : 7678
Case  : /home/msbealo/OpenFOAM/msbealo-1.7.1/run/Medium
nProcs : 1
SigFpe : Enabling floating point exception trapping (FOAM_SIGFPE).

// * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * //
Source: ".." "Coarse"
Target: "/home/msbealo/OpenFOAM/msbealo-1.7.1/run/" "Medium"

Create databases as time

Source time: 10
Target time: 10
Create meshes

Source mesh size: 274765    Target mesh size: 495044


Mapping fields for time 10


End

My mapFieldsDict looks like:

Code:

patchMap ( );

cuttingPatches  ( );

I've also tried explicitly stating which patches to copy using (inlet inlet etc) with not change.

Any help please? I know it's probably something pretty silly.

Mark

McCarra April 12, 2011 14:26

maybe mapFields is not able to interpolate between meshes of different sizes. I'll try to figure it out.

mrshb4 April 13, 2011 08:14

Hi

I think you should make a temporary folder in the case and initial files of fields you want to map should be there.
For example:
if you want to map field omega from time 5 of coarse mesh to omega field from time 5 of fine mesh you should:

1- make a directory of time 5 in fine mesh case.
2- in that folder you should have a dictionary of omega that indicate boundary conditions ( the same as dictionary that you write in your 0 dictionary)
3-In your controlDict of case fine, change startTime to 5.
4- run the command "mapFields ../Coarse"

It will map field omega from folder 5 of case coarse to folder 5 of case fine.

Thats it!
Mohammadreza

msbealo April 13, 2011 08:58

Mohammadreza

Thanks! That seems to be working. I'm currently running something in the background so I can't test it fully but it does run using your suggestions.

Regards,

Mark

Opxah June 10, 2011 10:24

Yes, it seems mapFields works (only) when the source time and target time are the same.

ic3wall February 10, 2012 11:18

Quote:

Originally Posted by BlackBoatNavArch (Post 282441)
Using -consistent, I get a target folder at the correct time in my new finer mesh. The interpolation has some issues but seemingly not near regions that are newly refined. Namely, I get small regions decreasing velocity to 0, which isn't ideal, but I think running the solution should get rid of them.

Did you figure out the problem ?

I have exactly the same issue, I have many regions where mapFields attributes 0 values which is really bad... I guess it's a question of interpolation, but did anybody find a solution ?

ic3wall February 14, 2012 08:22

No one found why mapFields outputs 0 values ?

msbealo February 14, 2012 12:52

ic3wall,

For me, I followed Mohammadreza advise (above) and it works fine. I guess the obvious question is are you mapping the right time directory from the source to the target? You're not mapping the '0' folder?

Make sure your target controlDict has the startTime of the last time of the source case. So, if you ran the first simulation to 10 seconds and then want to map this to the next case, copy the '0' time to '10' (to set up the right files), change the startTime to 10 in the target case and run mapFields.

Post the output of mapFields if you still get something strange.

Mark

mturcios777 February 14, 2012 14:58

Quote:

Originally Posted by Opxah (Post 311493)
Yes, it seems mapFields works (only) when the source time and target time are the same.

You can map inconsistent geometry as is documented in the user manual, which is what cuttingPatches and mappingPatches entries are for. When the new mesh is within the domain of the old one you still have values from which you can map fields and patches (the cavity tutorials in the manual show this clearly), but if your new domain has parts that are outside your old domain, then the default value mapFields gives those regions is 0.

I've experienced stability issues when refining meshes and wrote a utility to deal with it. The basic algorithm is:

1) Create a field with uniform value 1 in the mesh you want map FROM, call it "mark" or something
2) Create a field with uniform value -1 in the mesh you want to map TO, with the same name ("mark" in this general example)
3) Do your mapping inconsistently, and now
4) Now run through the the new "mark field", and whenever you find a cell (I restricted myself to cells) that has mark == -1, you should replace all field values (U, T, etc) for that cell with interpolations from valid nearby cells (those whose value of "mark" is 1)

How you do the interpolation is up to you. Because the differences in geometry are so small in our case, we just directly copied valid field values. If the differences are larger you should do some kind of weighted interpolation.

ic3wall February 14, 2012 15:14

Quote:

Originally Posted by mturcios777 (Post 344426)
You can map inconsistent geometry as is documented in the user manual, which is what cuttingPatches and mappingPatches entries are for. When the new mesh is within the domain of the old one you still have values from which you can map fields and patches (the cavity tutorials in the manual show this clearly), but if your new domain has parts that are outside your old domain, then the default value mapFields gives those regions is 0.

I've experienced stability issues when refining meshes and wrote a utility to deal with it. The basic algorithm is:

1) Create a field with uniform value 1 in the mesh you want map FROM, call it "mark" or something
2) Create a field with uniform value -1 in the mesh you want to map TO, with the same name ("mark" in this general example)
3) Do your mapping inconsistently, and now
4) Now run through the the new "mark field", and whenever you find a cell (I restricted myself to cells) that has mark == -1, you should replace all field values (U, T, etc) for that cell with interpolations from valid nearby cells (those whose value of "mark" is 1)

How you do the interpolation is up to you. Because the differences in geometry are so small in our case, we just directly copied valid field values. If the differences are larger you should do some kind of weighted interpolation.

I'm mapping values from a very large field on a smaller one (which is envoloped by the bigger one) with a different mesh resolution. It is an inconsistent mapping. The zero values are scattered in the new field, this is the weird thing. The new mapped field looks like a checkerboard.

I'll try to post a picture.

ic3wall February 15, 2012 09:20

2 Attachment(s)
Here it goes, the first picture is the large field and the second one is the result of the mapping on the smaller one. The yellow rectangle in the first picture shows the smaller domain on which I'm mapping.

As you can see on the second picture, there are several zero values scattered everywhere.

Here's a part of the nonuniform List output that corresponds to the mapped field:

25921
(
0.5
0.5
0.25
0
0
0.5
0
0.5
0
0
0
0.5
0.5
0
0.5
0.5
0.5
0.25
0
0.5
0.5
0.5
0
0
0.39767
0
0
0.0518247
0.00227012
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0.137366
0.248451
0
0
0.488571
...)

ic3wall February 15, 2012 14:22

Problem found!

I was using mapFieldsDict incorrectly, both patches I wanted to map are coincident, so they had to be included in PatchMap(...). CuttingPatches had to be empty.

Basically I was mapping internal fields onto a surface ... which is not I what I wanted.

Thank you for your help!

ignacio May 24, 2013 09:46

Hello all,

I will use this thread to ask another issue with mapFields.

I am using the results from a URANS simulation as initial values for LES. I use mapFields utility for this. Consisten flag on as the geometry and boundary conditions are the same.

1) If I use mapFields with ---> source: Coarse mesh, target: Fine mesh
I get he values that make no sense (Zero pressure, negative k and omega, 1000 velocity...)

2) If I use mapFields with ---> source: Fine mesh, target: Coarse mesh.
Then it works fine!

Can anybody explain me why?? Is is a bug?
I need to use the data from the URANS simulation for LES. Is there any other way I can do it without using mapFields?

Thanks a lot =)
Any idea / comment will be more than welcome

Tobi May 24, 2013 10:57

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.

ignacio May 24, 2013 13:27

1 Attachment(s)
Happy to know that it works perfectly for you.

But mine is just so crap at some cells as you can see on the pic

ripudaman April 10, 2014 01:15

Plane normal defined with zero length
 
Hi all,

I am having some problem in using the mapFields utility.
When I map from coarse to fine mesh the utility works fine and gives me a clean result.
However on trying to go from one level of refinement (region refinement using SHM) in one mesh to another level of refinement (refinement close to an imported STL file in SHM) in another mesh mapfields creates problems

Here is when I face the problem:-

I refine a region of my mesh and run my solver. Next I create a different coarse mesh with an STL file in the region of the previous refinement (using shm) and try mapping the results from the latest time of my refined mesh to the coarse mesh. This gives me the following error. I have posted the gdb output here. Please note that the points mentioned in the error output are not near the new STL file.
Code:

(gdb) r ../frac1 -sourceTime 'latestTime'
Starting program: /opt/OpenFOAM/OpenFOAM-2.3.x/platforms/linux64GccDPOpt/bin/mapFields ../frac1 -sourceTime 'latestTime'
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
/*---------------------------------------------------------------------------*\
| =========                |                                                |
| \\      /  F ield        | OpenFOAM: The Open Source CFD Toolbox          |
|  \\    /  O peration    | Version:  2.3.x                                |
|  \\  /    A nd          | Web:      www.OpenFOAM.org                      |
|    \\/    M anipulation  |                                                |
\*---------------------------------------------------------------------------*/
Build  : 2.3.x-e0d5f5a218ab
Exec  : /opt/OpenFOAM/OpenFOAM-2.3.x/platforms/linux64GccDPOpt/bin/mapFields ../frac1 -sourceTime latestTime
Date  : Apr 10 2014
Time  : 00:05:53
Host  : "ubuntu"
PID    : 9303
Case  : /home/ripuvm/OpenFOAM/ripuvm-2.3.x/multiFrac/cases/Consecutive1Well/frac2
nProcs : 1
sigFpe : Enabling floating point exception trapping (FOAM_SIGFPE).
fileModificationChecking : Monitoring run-time modified files using timeStampMaster
allowSystemOperations : Disallowing user-supplied system call operations

// * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * //
Source: ".." "frac1"
Target: "/home/ripuvm/OpenFOAM/ripuvm-2.3.x/multiFrac/cases/Consecutive1Well" "frac2"

Create databases as time
Case  : ../frac1
nProcs : 1

Source time: 133
Target time: 54

Create meshes

Source mesh size: 68670    Target mesh size: 83482


Creating and mapping fields for time 133

Creating mesh-to-mesh addressing for region0 and region0 regions using cellVolumeWeight


--> FOAM FATAL ERROR:
Plane normal defined with zero length
Bad points:(15.24 -114.3 -22.86) (15.24 -106.68 -22.86) (15.24 -99.06 -22.86)

    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::cellCellOverlapVolumeMinDecomp(Foam::primitiveMesh const&, int, Foam::primitiveMesh const&, int, Foam::treeBoundBox const&) const in "/opt/OpenFOAM/OpenFOAM-2.3.x/platforms/linux64GccDPOpt/lib/libmeshTools.so"
#5  Foam::meshToMeshMethod::interVol(int, int) const in "/opt/OpenFOAM/OpenFOAM-2.3.x/platforms/linux64GccDPOpt/lib/libsampling.so"
#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&) in "/opt/OpenFOAM/OpenFOAM-2.3.x/platforms/linux64GccDPOpt/lib/libsampling.so"
#7  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"
#8  Foam::meshToMesh::calcAddressing(Foam::polyMesh const&, Foam::polyMesh const&) in "/opt/OpenFOAM/OpenFOAM-2.3.x/platforms/linux64GccDPOpt/lib/libsampling.so"
#9  Foam::meshToMesh::calculate() in "/opt/OpenFOAM/OpenFOAM-2.3.x/platforms/linux64GccDPOpt/lib/libsampling.so"
#10  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"
#11 
 in "/opt/OpenFOAM/OpenFOAM-2.3.x/platforms/linux64GccDPOpt/bin/mapFields"
#12 
 in "/opt/OpenFOAM/OpenFOAM-2.3.x/platforms/linux64GccDPOpt/bin/mapFields"
#13  __libc_start_main in "/lib/x86_64-linux-gnu/libc.so.6"
#14 
 in "/opt/OpenFOAM/OpenFOAM-2.3.x/platforms/linux64GccDPOpt/bin/mapFields"

Program received signal SIGABRT, Aborted.
0x00007ffff4260425 in raise () from /lib/x86_64-linux-gnu/libc.so.6

Any help will be highly appreciated.

Thank you.
Regards,
Ripu

ripudaman April 10, 2014 11: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 14:42

Quote:

Originally Posted by Tobi (Post 429834)
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 10:40

mapFields issue
 
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 05:58

Plane normal defined with zero length
 
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 (Post 485257)
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 07: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 04:57

Quote:

Originally Posted by perjorgen (Post 519765)
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 14:24

1 Attachment(s)
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

perjorgen November 22, 2014 05:48

Quote:

Originally Posted by Seroga (Post 520445)
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 12: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 03: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 01: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 11: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 4, 2016 23: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 05: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 12:32

Problem with mapping outlet velocities of once mesh to inlet patch of another mesh
 
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 06: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 02: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 15: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 16:29

Quote:

Originally Posted by slashss4 (Post 804879)
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


All times are GMT -4. The time now is 22:50.