When I map fields from one case to another, are the cutting patches defined as "fixedGradients" read and mapped also? I mean, will my new case have fixedGradient at those boundaries, set exactly to the same values as the "old" case?

Please if possible, give directions on how would I discover that myself, so I dont bother you in the future with other questions

For what it is worth, mapFields is documented a bit in:
http://www.opencfd.co.uk/openfoam/doc/userse25.html

Apart from that, why not look at the field files themselves and see what the new case inherits from the old case? The syntax is easy to understand:
http://www.opencfd.co.uk/openfoam/doc/userse12.html#x19-1030004.2.7

Hope this helps, Chris

Hi Crhis,
It does not map grad boundary values. But in Jasak Thesis, if I am not mistaken, it is mentioned that one can map gradients at boundary (chapter about adaptive mesh refinement).
Is there any easy way to do that?
Regards,
Luiz

[carl_troeng]

Another question regarding mapFields:

Is it possible to change the interpolation scheme mapFields uses?
(If I understand correctly, this can not be set in fvSchemes or mapFieldsDict.)
What would be the best way to keep the divergence free property when mapping a field between two meshes?

[imano]

Hi All!

In order to estimate the solution error on a coarse mesh,
I tried to map a solution on a finer mesh onto the orignal
coarse mesh with mapFileds utility.

But the mapped solution and the original solution are
seriously differ especially in a near-wall region when the normal
distances of the near-wall cell are the same in two meshs.

If we add meshToMesh::MAP option when we use a meshToMesh.interpolate
function in mapFields/MapConsistentVolFields.H or MapVolFields.H (i.e.
we use a direct mapping of nearest-cell values), we won't get severe
difference, but at the same time it won't be smooth.

In addition to that the default interpolation scheme used in the
mapFields (i.e. INTERPOLATION option) is an inverse distance
interpolation, so it seems to me that the mapped results may not have
the second order accuracy (i.e. not linear interpolation). This may
not be a problem when we use it in order to make initial guess on a
finer mesh, but it would not be acceptable in case of measuring a
differences between solutions on different meshes in detail.

So I also tried to use meshToMesh::CELL_POINT_INTERPOLATE which seems
to handle linear interpolation, but the serious inconsitency in the
near-wall region doesn't disappear.

Now I have two questions:

a) Can I consider that the CELL_POINT_INTERPOLATE options actually do
the linear interpolation?

b) Is there any good idea to avoid the inconsistency without using
the the direct mapping.


I attached a sample test case file about the mentioned above, please
try it if you have a spare time!

mapFieldsTest.tar.gz

[imano]

Hello and sorry for my frequent post!

The test case I attached yesterday was extremely not good example.
So I made another test case.

In this case we first calculates a turbulent flow over backward-facing
step (Re=5500) on a fine mesh.

In the next step we maps the results onto a coarse mesh using
mapFields with several interpolation scheme: INTERPOLATION(default),
MAP, CELL_POINT_INTERPOLATION.

In order to avoid violating the limit of y+ condition of the wall
function, the height of the cell near the wall is same between two
meshes.

Finally we sample velocity field on the obtained results at the same
profile lines which pass through center of cells on the coarse mesh
and compare them using plotting program: gnuplot.

You will see the severe inconsistency near the wall between the
velocity profile on the fine mesh and the mapped profile with using
CELL_POINT_INTERPOLATION option.
But at the same time CELL_POINT_INTERPOLATION makes the best accuracy
in the inner region.

Regards,
Masashi

mapFieldsTest2.tar.gz

[hjasak]

I don't want to run the examples myself - how about posting some pictures of your problems instead of posting the code?

Could you give me some more detail on what you are after. The mapping algorithm will basically find a master cell for each cell of the new mesh and grab the data. The easiest way of doing this is just to use the same value; somewhat more sophisticated is a gradient (or inverse distance-based) interpolation, either using cell or point values. If you expect the near-wall interpolation to recognise that you are in the log-law region and do the interpolation based on log distribution, it won't do it. Of course, you can always add the code to handle that case if you want.

Hrv

[imano]

Dear Hrvoje,

Why didn't I think of posting pictures!

Here are pictures.







I don't think of such an interpolation based on a log distribution.
I just want the gradient interpolation even in the near-wall region.

Best regards,
Masashi

[imano]

Sorry, I don't know that "Text description" in the image tag disappers. So I forget to write description of figures in my previous post.

Title of figures are

-Fine mesh
-Coarse mesh
-Velocity vectors on the coarse mesh
-Velocity profile behind the step
-Velocity profile near the floor

from the top respectively.

Regards,
Masashi

[imano]

Dear all,

I found that the above mentioned severe inconsistency near wall
is due to the nature of cell-point interpolation.
This interpolation makes a tet with the center point of a cell which
contains the mapping target point and three vertices of that cell.
As a value on a face center is never used in this interpolation,
weight on the cell center value is regarded as zero if we interpolate
value on the face center.
On the other hand weight on a wall boundary is a half.
So the interpolated value near wall is affected by the boundary value
excessively in spite of the existence of high gradient in the
near-wall region.

We can avoid this problem if we use cell-point-face interpolation
which handle the face center value.


Fig. interpolation schemes

So I added CELL_POINT_FACE_INTERPOLATE option to interpolation
function in meshToMesh class and recompile mapFields to use that. As a
result the recompiled mapFields would be able to map fields linearly
for the most part.

This is the patch for the meshToMesh class.

meshToMesh.patch.gz

Regards,
Masashi

Dear All,

Could somebosy please let me know how to use the command:
mapFields <source> <source> <target> <target> [-consistent] [-parallelSource] [-parallelTarget]
please?

cheers,
fel!c

[maka]

mapFields on inconsistent geometries.

I run mapFields between two inconsistent geometries. The source is double the hight of the target. Both are like channel395 geometry but with 4 blocks. The mapFieldsDict reads:

patchMap
(
bottomWall bottomWall
inout1 inout1
sides1 sides1
);

cuttingPatches
(
topWall
);

the command return successfully without errors but the time folder is not created in the target case directory.

I ran under gdb and it said Program exited normally.

here are some output:

Create databases as time

Source time: 1
Target time: 1
Create meshes

Source mesh size: 52800 Target mesh size: 26400


Mapping fields for time 1


End

can anyone guess the reason? Thanks.

best regards,
Maka

[hjasak]

You did not set the "time-from" and "time-to" correctly. I presume there is no time 1 in your source case, so there's no fields to map.

Hrv

[maka]

Actually, there were no target directory (I'm used to -consistent option). I made one by coping from i.c. and it worked OK. Thanks for your quick help!

Best regards,
Maka.

[asteria]

Hi everybody.
I'm trying to map from coarser mesh to finer mesh , using mapFields utility. But, the problem is that it doesn't give exact interpolated value.
I increased the number of cells twice and the change is like below.

-------------------------------------------------
---------before-------------------------------
------------------------------------------------
boundaryField
{
inlet
{
type fixedValue;
value nonuniform List<vector>
18
(
(0.005401235 0 0)
(0.015277778 0 0)
(0.023919753 0 0)
(0.031327160 0 0)
(0.037500000 0 0)
(0.042438272 0 0)
(0.046141975 0 0)
(0.048611111 0 0)
(0.049845679 0 0)
(0.049845679 0 0)
(0.048611111 0 0)
(0.046141975 0 0)
(0.042438272 0 0)
(0.037500000 0 0)
(0.031327160 0 0)
(0.023919753 0 0)
(0.015277778 0 0)
(0.005401235 0 0)
)
;
}


-------------------------------------------------
---------after-------------------------------
------------------------------------------------

boundaryField
{
inlet
{
type fixedValue;
value nonuniform List<vector>
36
(
(0.00540123 0 0)
(0.00540123 0 0)
(0.0152778 0 0)
(0.0152778 0 0)
(0.0239198 0 0)
(0.0239198 0 0)
(0.0313272 0 0)
(0.0313272 0 0)
(0.0375 0 0)
(0.0375 0 0)
(0.0424383 0 0)
(0.0424383 0 0)
(0.046142 0 0)
(0.046142 0 0)
(0.0486111 0 0)
(0.0486111 0 0)
(0.0498457 0 0)
(0.0498457 0 0)
(0.0498457 0 0)
(0.0498457 0 0)
(0.0486111 0 0)
(0.0486111 0 0)
(0.046142 0 0)
(0.046142 0 0)
(0.0424383 0 0)
(0.0424383 0 0)
(0.0375 0 0)
(0.0375 0 0)
(0.0313272 0 0)
(0.0313272 0 0)
(0.0239198 0 0)
(0.0239198 0 0)
(0.0152778 0 0)
(0.0152778 0 0)
(0.00540123 0 0)
(0.00540123 0 0)
)
;
}

I need more precisely interpolated values. Can you advise me?

Thanks in advance.

in the sea of OpenFOAM.

[gdbaldw]

To All,

I did mapFields to an identical mesh, with the only difference being two wall boundaries of the source were mapped to a single wall (union of two source walls) in the target. Values in the boundary layer are way off, so I'm now running the solver on target mesh. Would be nice to do an exact copy of values, reordered for the target mesh, so that re-solving is unnecessary. Suggestions welcomed. -consistent flag in mapFields fails because number of boundaries differ.

Doug

[lucchini]

Dear All,

I have a question about the accuracy order of the meshToMesh::INTERPOLATE method.

As far as I know, it should be 2nd order accurate for internal cells and 1st order for boundary cells.

Is it that?

Thanks a lot, any suggestion will be really appreciated.

Regards

Tommaso

[ivan_cozza]

Originally Posted by imano

Hi All!

In order to estimate the solution error on a coarse mesh,
I tried to map a solution on a finer mesh onto the orignal
coarse mesh with mapFileds utility.

But the mapped solution and the original solution are
seriously differ especially in a near-wall region when the normal
distances of the near-wall cell are the same in two meshs.

If we add meshToMesh::MAP option when we use a meshToMesh.interpolate
function in mapFields/MapConsistentVolFields.H or MapVolFields.H (i.e.
we use a direct mapping of nearest-cell values), we won't get severe
difference, but at the same time it won't be smooth.

In addition to that the default interpolation scheme used in the
mapFields (i.e. INTERPOLATION option) is an inverse distance
interpolation, so it seems to me that the mapped results may not have
the second order accuracy (i.e. not linear interpolation). This may
not be a problem when we use it in order to make initial guess on a
finer mesh, but it would not be acceptable in case of measuring a
differences between solutions on different meshes in detail.

So I also tried to use meshToMesh::CELL_POINT_INTERPOLATE which seems
to handle linear interpolation, but the serious inconsitency in the
near-wall region doesn't disappear.

Now I have two questions:

a) Can I consider that the CELL_POINT_INTERPOLATE options actually do
the linear interpolation?

b) Is there any good idea to avoid the inconsistency without using
the the direct mapping.


I attached a sample test case file about the mentioned above, please
try it if you have a spare time!

mapFieldsTest.tar.gz

Hi Foamers,
I'm interested in downloading the file mapFieldsTest.tar.gz that Imano posted sometimes ago, but it seems that the link point to nothing. Can someone upload the file?
Thanks, Ivan

[saimat]

Dear Foamers,

I tried to Musashis patch to change my mapFields to allow for the usage of cellPointFace-interpolation because I - like him - need a linear interpolation an the wall. Unfortunately, in the meantime (his post was more than 10 years in the past) the meshToMesh class was changed so that there is no "fromPointMesh_" available anymore. But as far as I understand this is needed to get the cellPointFaceInterpolation working.

Although I know well how to use OpenFOAM, I'm not able to understand the source code in detail (shame on me). Could anyone please give me a hint on how I can provide this "fromPointMesh_" or how I can get this extension/patch running with a recent version of OpenFOAM, respectively? I'm sure that many of you can do this in a jiffy.

You really would help me a lot.

Originally Posted by imano

Dear all,

I found that the above mentioned severe inconsistency near wall
is due to the nature of cell-point interpolation.
This interpolation makes a tet with the center point of a cell which
contains the mapping target point and three vertices of that cell.
As a value on a face center is never used in this interpolation,
weight on the cell center value is regarded as zero if we interpolate
value on the face center.
On the other hand weight on a wall boundary is a half.
So the interpolated value near wall is affected by the boundary value
excessively in spite of the existence of high gradient in the
near-wall region.

We can avoid this problem if we use cell-point-face interpolation
which handle the face center value.


Fig. interpolation schemes

So I added CELL_POINT_FACE_INTERPOLATE option to interpolation
function in meshToMesh class and recompile mapFields to use that. As a
result the recompiled mapFields would be able to map fields linearly
for the most part.

This is the patch for the meshToMesh class.

meshToMesh.patch.gz

Regards,
Masashi