CFD Online Logo CFD Online URL
www.cfd-online.com
[Sponsors]
Home > Forums > OpenFOAM Programming & Development

Moving boundary problem based on calculated data

Register Blogs Members List Search Today's Posts Mark Forums Read

Like Tree15Likes

Reply
 
LinkBack Thread Tools Display Modes
Old   October 10, 2013, 06:09
Default
  #21
New Member
 
Aleksander Sandro Grm
Join Date: Feb 2010
Location: Slovenia, Kanal ob Soči
Posts: 9
Rep Power: 8
sandro.grm is on a distinguished road
Send a message via Skype™ to sandro.grm
Yes it works. Results are identical as for single run. I added figures and log files. I run my Gentoo Linux in VM with 4 cores, so the scaling is not linear but is significant.

Cheers, Sandro
Attached Images
File Type: jpg result_parallel.jpg (17.0 KB, 133 views)
File Type: jpg result_single.jpg (16.6 KB, 116 views)
Attached Files
File Type: gz myMoveMesh_results_log.tar.gz (1.0 KB, 42 views)
sandro.grm is offline   Reply With Quote

Old   September 10, 2014, 06:06
Default
  #22
Member
 
Join Date: Jul 2014
Posts: 37
Rep Power: 4
PicklER is on a distinguished road
Thank you Aleksander

Really helped me. I see this thread was last updated 2013, but I will try. 2 questions:

1. Is it possible to move the boundary in the direction of the boundary cells normal vectors? I want to have a cylinder which expands.

2. How can I specify the "expansion"? I want the boundary to expand according to a calculated variable.

So far I figured out that each boundary will move with a fixed constant (specified in pointDisplacement) if the while-loop is placed just after the autoPtr<motionSolver> in the solver and the endTime is increased, only the boundary (specified as patchName) will continue to move. This is fine, since I can allocate the outside of the cylinder as one boundary. Still figuring out how the constants alpha and Tmax work, since their constants from createField.

thank you
Vrede
PicklER is offline   Reply With Quote

Old   September 10, 2014, 06:27
Default
  #23
Senior Member
 
HECKMANN Frédéric
Join Date: Jul 2010
Posts: 237
Rep Power: 9
fredo490 is on a distinguished road
Hi,
1. It is what my code on the first page does. There is one variable called pointnormal. This takes the normal vector at the node.
But in your case I would suggest to use the radial direction instead of the normal. the normal vector theoretically matches the radial direction but from my experience I would not trust it.
Simply give the location of the center of the cylinder (it can be hard coded) and after calculate the vector between the node and the center. This will be your expansion vector.

2)again look at the first page. I do an interpolation from the face center to the node. The face center is the "calculated variable"
Tobi likes this.
fredo490 is offline   Reply With Quote

Old   September 15, 2014, 08:34
Default
  #24
Member
 
Join Date: Jul 2014
Posts: 37
Rep Power: 4
PicklER is on a distinguished road
Hi Frédéric

Your method helped, thank you. So I experimented with moveMesh solver.

Below are 3 screenshots, the first is the original mesh, which consists of a block at the bottom and a block on top with a slight skew top boundary. The next screenshot shows the top and bottom boundaries move according to die pointDisplacement file in the 0 directory. Here is a snippet:

Code:
dimensions      [0 1 -1 0 0 0 0];

internalField   uniform (0 0 0);

boundaryField
{
	top
    {
        type            fixedValue;
        value           uniform (0 0.1 0);
    }
    
    bottom
    {
        type            fixedValue;
        value           uniform (0 -0.1 0);
    }
    outlet
    {
        type            fixedNormalSlip;
        n               (0 0 0);
    }
    
    defaultFaces
    {
        type            empty;
    }
}
As I have said before, the movement defined in the pointDisplacement file will only occur once, therefore all values can be set to zero especially if the speed of the movement will be determined in the solver. The 3rd screenshot show the 4th iteration where only the top boundary move.

As seen, it is only the top "layer" of cells which expand. My question: Is it possible to enlarge all the cells in the top block as the boundary moves?

Thank you
Vrede
Attached Images
File Type: png test_org_0.png (14.4 KB, 51 views)
File Type: png test_org_1.png (15.6 KB, 45 views)
File Type: png test_org_4.png (15.8 KB, 48 views)
PicklER is offline   Reply With Quote

Old   September 16, 2014, 14:43
Default
  #25
Member
 
Join Date: Jul 2014
Posts: 37
Rep Power: 4
PicklER is on a distinguished road
My previous problem has become somewhat irrelevant since my mesh movement is very small and my solver takes the change in volume into consideration.

Not sure I need to start a new thread...

My next challenge/question is how to "fix" a mesh when two sides combine (see figures) after movement. Is there a way to remove the cells (or nodes) when they "enter" the mesh?

Kind regards
Vrede
Attached Images
File Type: png test00.png (7.5 KB, 31 views)
File Type: png test01.png (7.7 KB, 35 views)
File Type: png test02.png (8.0 KB, 36 views)
File Type: png test03.png (7.9 KB, 33 views)
PicklER is offline   Reply With Quote

Old   October 10, 2014, 06:31
Default
  #26
New Member
 
Simon Lindberg
Join Date: Oct 2014
Location: Gothenburg
Posts: 2
Rep Power: 0
Simon_2 is on a distinguished road
Hey,

Very nice work of you and Frédéric! Thanks a bunch!

I'm just a bit wondering about a few things that I was wondering about. Why did you not use the
mesh.update() function and instead do a timeloop? Is it better?

And what is the use of the buf variable? The nondimensional alpha value?

I know this is an old thread but I hope I can get a closer understanding for this piece of code !

Thanks
/Simon
Simon_2 is offline   Reply With Quote

Old   October 10, 2014, 13:15
Default
  #27
Senior Member
 
HECKMANN Frédéric
Join Date: Jul 2010
Posts: 237
Rep Power: 9
fredo490 is on a distinguished road
Hi,
I don't really know who you are talking to and what you are referring to.

You need to have one mesh.update at each time step because it is this command that actually move the mesh. Therefore the mesh.update has to be inside a time loop.

I don't understand what is the buf variable you mentioned. Also I don't know where is your alpha. Usually alpha is a non dimensional number that is called the collection efficiency. This number tells you how much matter impact your boundary compared to the mass flux in the free stream.
It is defined as the mass flux in the free stream (kg.m-2.s-1) divided by the mass flux at your boundary.
fredo490 is offline   Reply With Quote

Old   October 10, 2014, 18:26
Default
  #28
New Member
 
Simon Lindberg
Join Date: Oct 2014
Location: Gothenburg
Posts: 2
Rep Power: 0
Simon_2 is on a distinguished road
Thanks for the answer!

Sorry for the confusion, first post here so didn't really understand how a "quick reply" would work. My questions was mainly for Aleksander regarding the changes he did in his version of the code compared to your code. Thnaks for the clarification though!
Simon_2 is offline   Reply With Quote

Old   December 1, 2014, 11:28
Default
  #29
Member
 
Fei Fan
Join Date: Jun 2013
Location: NanJing, China
Posts: 52
Rep Power: 5
Fanfei is on a distinguished road
Quote:
Originally Posted by fredo490 View Post
Here is my dynamicMeshDict file that is in Constant

Code:
dynamicFvMesh      dynamicMotionSolverFvMesh;

motionSolverLibs ("libfvMotionSolvers.so");

solver            displacementLaplacian;

displacementLaplacianCoeffs
{
    diffusivity     quadratic inversePointDistance (wall);
}
and an example of "pointDisplacement" file that is in 0:

Code:
FoamFile
{
    version     2.0;
    format      ascii;
    class       pointVectorField;
    location    "0";
    object      pointDisplacement;
}
// * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * //

dimensions      [0 1 0 0 0 0 0];

internalField   uniform (0 0 0);

boundaryField
{
    inlet
    {
        type            fixedValue;
        value           uniform (0 0 0);
    }
    sides
    {
        type            empty;
    }
    wall
    {
        type            fixedValue;
        value           uniform (0 0 0);
    }
}
Hi HECKMANN Frédéric:
I use your method to move mesh on the boundary of my solver. however, there is a error as i test a case. could you give me a hinte, where should i to modify the code. Thanks.

best Regards
Fan fei
Attached Images
File Type: jpg movemesh_errot.jpg (64.5 KB, 41 views)
Fanfei is offline   Reply With Quote

Old   December 1, 2014, 20:03
Default
  #30
Senior Member
 
HECKMANN Frédéric
Join Date: Jul 2010
Posts: 237
Rep Power: 9
fredo490 is on a distinguished road
Hi, it seems that you used the extended version of openfoam. Unfortunately I am not familiar with this version...

In your solver, did you include all the library that I used?

Edit, see the post #10 of page 1
fredo490 is offline   Reply With Quote

Old   December 1, 2014, 21:19
Default
  #31
Member
 
Fei Fan
Join Date: Jun 2013
Location: NanJing, China
Posts: 52
Rep Power: 5
Fanfei is on a distinguished road
Quote:
Originally Posted by fredo490 View Post
Hi, it seems that you used the extended version of openfoam. Unfortunately I am not familiar with this version...

In your solver, did you include all the library that I used?

Edit, see the post #10 of page 1
Hi, I copy all the library you used. And I found some library are different in extend version. so I'm trying to find where is wrong.

Best regards
Fan Fei
Fanfei is offline   Reply With Quote

Old   December 1, 2014, 23:21
Default pointMotionU
  #32
Member
 
Tony Ladd
Join Date: Aug 2013
Posts: 35
Rep Power: 5
tladd is on a distinguished road
My postdoc and I have been working on a moving mesh code for a while now, starting with Frederic Heckmann's post as a template. Let me just make a few general points:

1) pointMotionU is better than pointDisplacement. In long runs with large mesh motion a discrepancy builds up between the positions of the cell centers calculated by averaging the vertexes (how OF determines them) and the original position + pointDisplacement. In the end the code breaks in situations where it runs fine with pointMotionU. I think pointDisplacement is intended for solid motion (small displacements). pMU works in differential mode and there is no inconsistency.

2) faceToPointInterpolate is a method of the primitivePatch class. Thus it does not work properly across coupled patches such as cyclic or processor. Connected with this is that pointNormal is a vector field (with no information about boundaries, just a list of data). Thus you cannot get OF to apply coupled patch type boundary conditions and pointNormal is always wrong across cyclic or processor patches.

3) Combining these ideas, a better strategy is to calculate the MotionU field at the face centers using the faceNormals. Then interpolate to the points to get the pointMotionU field. Since pMU is a pointVectorField (with boundaries) we think you can use OF's methods for coupled patches. Right now we are doing this by hand but I think we will have a proper solution soon.

4) One last point. OF always seems to apply the correct boundary conditions to the points field. So if pointMotionU has a component across a cyclic patch (for example), the points are still OK (ie on the cyclic boundary). But since pMU is wrong the Laplace solver gets the wrong solution and the internal points go haywire.

Hope this helps a few people

Tony
tladd is offline   Reply With Quote

Old   December 2, 2014, 21:34
Default
  #33
Member
 
Fei Fan
Join Date: Jun 2013
Location: NanJing, China
Posts: 52
Rep Power: 5
Fanfei is on a distinguished road
Quote:
Originally Posted by fredo490 View Post
Hi, it seems that you used the extended version of openfoam. Unfortunately I am not familiar with this version...

In your solver, did you include all the library that I used?

Edit, see the post #10 of page 1
Hi HECKMANN Frédéric:
I try all the ways i know. But the problem didn't solve. the header field as below:
Quote:
#include "fvCFD.H"
#include "meshTools.H"
#include "dynamicFvMesh.H"
#include "singlePhaseTransportModel.H"
#include "turbulenceModel.H"
#include "faCFD.H"
#include "incompressible/singlePhaseTransportModel/singlePhaseTransportModel.H"
#include "RASModel.H"
#include "primitivePatchInterpolation.H"
#include "pointFields.H"

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

int main(int argc, char *argv[])
{
# include "setRootCase.H"
# include "createTime.H"
# include "createDynamicFvMesh.H"
# include "readGravitationalAcceleration.H"
# include "createFaMesh.H"
# include "createFields.H"
# include "initContinuityErrs.H"
and options are
Quote:
EXE_INC = \
-I$(LIB_SRC)/turbulenceModels/incompressible/turbulenceModel \
-I$(LIB_SRC)/transportModels \
-I$(LIB_SRC)/turbulenceModels \
-I$(LIB_SRC)/turbulenceModels/incompressible/RAS/RASModel \
-I$(LIB_SRC)/transportModels/incompressible/singlePhaseTransportModel \
-I$(LIB_SRC)/finiteVolume/lnInclude\
-I$(LIB_SRC)/finiteArea/lnInclude\
-I$(LIB_SRC)/sampling/lnInclude\
-I$(LIB_SRC)/dynamicMesh/dynamicFvMesh/lnInclude \
-I$(LIB_SRC)/dynamicMesh/dynamicMesh/lnInclude \
-I$(LIB_SRC)/dynamicMesh/meshMotion/lnInclude \
-I$(LIB_SRC)/meshTools/lnInclude

EXE_LIBS = \
-lincompressibleTransportModels \
-lincompressibleTurbulenceModel \
-lincompressibleRASModels \
-lincompressibleLESModels \
-lfiniteVolume \
-lfiniteArea \
-ldynamicMesh \
-lmeshTools \
-ldynamicFvMesh \
-lfvMotionSolver\
-ltopoChangerFvMesh \
-llduSolvers \
-L$(MESQUITE_LIB_DIR) -lmesquite
I don't kown where is wrong. Could you help me.

Best regards
Fan Fei
Fanfei is offline   Reply With Quote

Old   December 3, 2014, 10:51
Default
  #34
Member
 
Fei Fan
Join Date: Jun 2013
Location: NanJing, China
Posts: 52
Rep Power: 5
Fanfei is on a distinguished road
Quote:
Originally Posted by Fanfei View Post
Hi, I copy all the library you used. And I found some library are different in extend version. so I'm trying to find where is wrong.

Best regards
Fan Fei
Hi HECKMANN Frédéric:
I find the reason of this error, which is caused by the incompatiable of creatDynamicFvMesh.H and creatFamesh.H. The creatFamesh is used to create a areField to use FAM. As deleted #include "creatFamesh.H", it will be work. But the warnning is still there. As dynamicMesh I has a question. in our program pointdisplacement is used, that means the point of bounday patch will move, however, in fvSolition the cellDisplacement is used, is that mean the value will interpolated from point to cell(Vol), is that right? I so sorry to trouble you again, but i hope i can get some help. Thanks.

Best regards
Fan Fei
Fanfei is offline   Reply With Quote

Old   December 3, 2014, 20:08
Default
  #35
Senior Member
 
HECKMANN Frédéric
Join Date: Jul 2010
Posts: 237
Rep Power: 9
fredo490 is on a distinguished road
In openfoam and most CFD software, you can only move the nodes. Indeed, the cell is built from the nodes coordinate.

Usually we only move the nodes of a boundary and after we ask a "solver" to find the position of the nodes of the domain. The solver will move the nodes of the domain (not those of the boundaries) according to a law that you specify. The Laplace law is often used because it is robust (it consider the rotation) but you can also use a proportional displacement that will act as a spring that push the nodes with a force that decrease as you go away from the boundary. There are tens of morphing solver and each one has its advantages and drawbacks. You have to choose it depending of the motion you are expecting.
fredo490 is offline   Reply With Quote

Old   February 7, 2015, 18:12
Default
  #36
New Member
 
Join Date: Apr 2009
Posts: 11
Rep Power: 9
deepinheart is on a distinguished road
Hi Frédéric,

Thanks for your nice job. I could adapt your code to my application. The only problem is that the mesh is moving as what is defined but only at the first time step.


while (runTime.loop())
{
PointDisplacement.boundaryField()[patchID] == dispVals;
Info<< "Time = " << runTime.timeName() << endl;
//mesh.movePoints(motionPtr->newPoints());
mesh.moving();
mesh.update();


runTime.write();

Info<< "ExecutionTime = " << runTime.elapsedCpuTime() << " s"
<< " ClockTime = " << runTime.elapsedClockTime() << " s"
<< nl << endl;
}
deepinheart is offline   Reply With Quote

Old   February 7, 2015, 22:45
Default
  #37
Senior Member
 
HECKMANN Frédéric
Join Date: Jul 2010
Posts: 237
Rep Power: 9
fredo490 is on a distinguished road
Hi,
I think that your solver is ok. The problem might be located in your "0" folder and in the "pointdisplacement" file. From my guess the "pointdisplacement" file is not updated/forwarded to next time step.
fredo490 is offline   Reply With Quote

Old   February 23, 2015, 10:54
Default
  #38
Member
 
Join Date: Mar 2013
Posts: 92
Rep Power: 5
giack is on a distinguished road
Hi to all,
I'm doing simulations moving a wall boundary where the dispacement of the movement is chosen by a variable evaluated during the simulation. The first movement steps work very well but at certain iteration I encounter the same problem shown by Vrede in the post #25. I was thinking to use add/remove layers to solve it.

Does anyone have some ideas to solve it? Vrede, did you solve the problem?

Thanks to all
Regards

Giacomo
giack is offline   Reply With Quote

Old   February 23, 2015, 11:11
Default
  #39
Member
 
Join Date: Jul 2014
Posts: 37
Rep Power: 4
PicklER is on a distinguished road
Hi Giacomo

No, sorry, I have not solved this problem yet. I do not know if there is any existing utility to remove points when faces overlap. You could try to identify and remove these points and then define the corresponding faces with the new point, but this will be brute force.

Sorry, I could not help more
PicklER is offline   Reply With Quote

Old   March 2, 2015, 09:32
Default
  #40
ngj
Senior Member
 
Niels Gjoel Jacobsen
Join Date: Mar 2009
Location: Deltares, Delft, The Netherlands
Posts: 1,698
Rep Power: 27
ngj will become famous soon enoughngj will become famous soon enough
Dear all,

I find it interesting to have a thread, where these things are being discussed. I have noticed above that it was suggested to use the faceToPointInterpolation method, which is available in the PrimitivePatchInterpolation class.

I have just finalised a paper where the mass conserving properties of this exact interpolation scheme was analysed (http://onlinelibrary.wiley.com/doi/1....4015/abstract). The conclusion was that the scheme does not conserve the volume of sand in the bed, when the bed level change is interpolated from the faces to the points. This lack of mass conservation is not uniquely related to sediment transport and morphodynamics.

There are several issues related to error, but to mention a few:

  • There is not made a projection of the distance weights onto the horizontal plane. This means that the interpolation weights change over time, as the boundary deforms. This even though the displacements are perpendicular to the horizontal plane.
  • In 2D simulations, the width of the computational domain in the empty direction has an effect on the mass conservation error. This is solely related to the fact that the weights are from the faces to the points. For instance, on non-equidistant grids and very wide meshes in the empty direction, the interpolation becomes a simple average (identical weights for all points). This is obviously not correct, since the mesh is defined as non-equidistant.
An alternative interpolation method is proposed in the same paper.

I hope that these finding are valuable for some of you.


Kind regards,


Niels
__________________
Please note that I do not use the Friend-feature, so do not be offended, if I do not accept a request.
ngj is offline   Reply With Quote

Reply

Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are On


Similar Threads
Thread Thread Starter Forum Replies Last Post
An error has occurred in cfx5solve: volo87 CFX 5 June 14, 2013 17:44
domain imbalance for enrgy equation happy CFX 14 September 6, 2012 01:54
Framework for moving mesh based on 2D-computation as a boundary condition Arnoldinho OpenFOAM Running, Solving & CFD 0 May 17, 2011 12:48
RPM in Wind Turbine Pankaj CFX 9 November 23, 2009 05:05
How to update polyPatchbs localPoints liu OpenFOAM Running, Solving & CFD 6 December 30, 2005 18:27


All times are GMT -4. The time now is 01:05.