CFD Online Logo CFD Online URL
www.cfd-online.com
[Sponsors]
Home > Forums > OpenFOAM Running, Solving & CFD

Dynamic Mesh in OF 141

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

Reply
 
LinkBack Thread Tools Display Modes
Old   September 17, 2007, 10:48
Default Hi all, I've found some diffe
  #1
Senior Member
 
Francesco Del Citto
Join Date: Mar 2009
Location: Zürich Area, Switzerland
Posts: 215
Rep Power: 9
fra76 is on a distinguished road
Hi all,
I've found some differences between OF 1.4 and 1.4.1, regarding dynamic meshes.

In constant/dynamicMeshDict, with version 1.4, I had:

dynamicFvMesh dynamicMotionSolverFvMesh;

motionSolverLibs ("libfvMotionSolvers.so");

solver componentLaplacian x;

but moveMesh ver. 1.4.1 fails, reporting:

Valid solver types are:

5
(
displacementSBRStress
displacementComponentLaplacian
velocityLaplacian
displacementLaplacian
velocityComponentLaplacian
)


So, I replaced componentLaplacian with velocityComponentLaplacian, and it seems that I have the same behaviour as before.

What are the other solvers for?

Is there an easy way to rotate a part around an axis, instead of translating it? I know how to do this with OF 1.3, but the library I used cannot be compiled, because of some deep change in the moving mesh classes.

Regards
Francesco
fra76 is offline   Reply With Quote

Old   September 18, 2007, 07:07
Default Hi Francesco! The velocity-
  #2
Assistant Moderator
 
Bernhard Gschaider
Join Date: Mar 2009
Posts: 3,914
Rep Power: 40
gschaider will become famous soon enoughgschaider will become famous soon enough
Hi Francesco!

The velocity-Solvers are (as you noticed) the old solvers. The displacement solvers let you specify the absolute displacement of the boundary instead of the velocity with which it is moving.

As for rotating: I could think of a way, but I wouldn't call it easy (it involves writing new boundary conditions etc)

Bernhard
__________________
Note: I don't use "Friend"-feature on this forum out of principle. Ah. And by the way: I'm not on Facebook either. So don't be offended if I don't accept your invitation/friend request
gschaider is offline   Reply With Quote

Old   September 18, 2007, 07:22
Default Hi Bernhard, I'm talking abou
  #3
Senior Member
 
Francesco Del Citto
Join Date: Mar 2009
Location: Zürich Area, Switzerland
Posts: 215
Rep Power: 9
fra76 is on a distinguished road
Hi Bernhard,
I'm talking about the OpenCFD 1.4.1 version, not the development one...
BTW, do you know what is the solver called "displacementSBRStress"?

As for rotating: at first, I only need to deform the mesh, without solving flow equations in the meanwhile. So it should be easier than writing a new bc. I did something in version 1.3-develop adding the new routines in src/dynamicFvMesh/ and recompiling libdynamicFvMesh
In 1.4.1, that routine doesn't compile any more, but I guess it can be a basis to write a new one.
Am I too optimistic?
fra76 is offline   Reply With Quote

Old   September 18, 2007, 07:35
Default Hi Francesco, You can easil
  #4
Senior Member
 
Frank Bos
Join Date: Mar 2009
Location: The Netherlands
Posts: 338
Rep Power: 9
lr103476 is on a distinguished road
Hi Francesco,

You can easily change your dynamicFvMesh based library to the new OF-1.4.1 version.

Just change the following in the source file:

laplaceTetDecompositionMotionSolver -> velocityLaplacianFvMotionSolver

fixedValueTetPolyPatchVectorField -> fixedValuePointPatchVectorField

You don't need the following header files:
#include "tetDecompositionMotionSolver.H"
#include "laplaceTetDecompositionMotionSolver.H"
#include "fixedValueTetPolyPatchFields.H"

Instead of these, include the following:
#include "fvMotionSolver.H"
#include "velocityLaplacianFvMotionSolver.H"
#include "fixedValueFvPatchFields.H"

If you'll change this, your dynamicFvMesh based lib should compile and work. Of course you need to make some changes to Make/options, since the tetDecomp stuff is not available in the OF-1.4.1 from openCFD. Furthermore, these changes only work when you specify the velocityLaplacian solver in your constant/dynamicMeshDict.....

Goodluck, Frank
__________________
Frank Bos
lr103476 is offline   Reply With Quote

Old   September 18, 2007, 07:42
Default Hi Francesco! @version: I w
  #5
Assistant Moderator
 
Bernhard Gschaider
Join Date: Mar 2009
Posts: 3,914
Rep Power: 40
gschaider will become famous soon enoughgschaider will become famous soon enough
Hi Francesco!

@version: I was talking about the 1.4.1 not the dev-version

If you need to transform the mesh only once you might prefer the displacement-solvers (but you still might have to write some code because of the non-uniform displacement)

Bernhard
__________________
Note: I don't use "Friend"-feature on this forum out of principle. Ah. And by the way: I'm not on Facebook either. So don't be offended if I don't accept your invitation/friend request
gschaider is offline   Reply With Quote

Old   September 18, 2007, 07:51
Default Thank you both! I should know
  #6
Senior Member
 
Francesco Del Citto
Join Date: Mar 2009
Location: Zürich Area, Switzerland
Posts: 215
Rep Power: 9
fra76 is on a distinguished road
Thank you both!
I should know where to start from, now.

Francesco
fra76 is offline   Reply With Quote

Old   September 18, 2007, 10:27
Default Here I am again. I'm experien
  #7
Senior Member
 
Francesco Del Citto
Join Date: Mar 2009
Location: Zürich Area, Switzerland
Posts: 215
Rep Power: 9
fra76 is on a distinguished road
Here I am again.
I'm experiencing problems while moving the mesh in parallel, with any OF version.
Basically, it can fail in parallel, depending on the partitioning, while in serial it works. The returned error is:

[0]
[0]
[0] --> FOAM FATAL ERROR : face 487 area does not match neighbour by 6.92132% -- possible face ordering problem.
patch:procBoundary0to1 mesh face:58815 face centre: (3.11391 2.49173 0.952634) my area:0.0051016 neighbour area:0.00476031
[0]
[0] From function processorPolyPatch::calcGeometry()
[0] in file meshes/polyMesh/polyPatches/constraint/processor/processorPolyPatch.C at line 208.
[0]
FOAM parallel run exiting
[0]
[1]
[1]
[1] --> FOAM FATAL ERROR : face 487 area does not match neighbour by 6.92132% -- possible face ordering problem.
patch:procBoundary1to0 mesh face:58847 face centre: (3.11008 2.49173 0.952634) my area:0.00476031 neighbour area:0.0051016
[1]
[1] From function processorPolyPatch::calcGeometry()
[1] in file meshes/polyMesh/polyPatches/constraint/processor/processorPolyPatch.C at line 208.
[1]
FOAM parallel run exiting


Does anyone know if there is a fix for this?

Francesco
fra76 is offline   Reply With Quote

Old   September 18, 2007, 17:39
Default How are you specifying the b.c
  #8
Super Moderator
 
Mattijs Janssens
Join Date: Mar 2009
Posts: 1,416
Rep Power: 16
mattijs is on a distinguished road
How are you specifying the b.c. for the mesh motion? You'll have to make sure that your b.c.s specify the same value for coupled points (i.e. points that are on two (or more) processor patches)
mattijs is offline   Reply With Quote

Old   September 18, 2007, 17:39
Default Yeah, I've fixed this a while
  #9
Senior Member
 
Hrvoje Jasak
Join Date: Mar 2009
Location: London, England
Posts: 1,758
Rep Power: 21
hjasak will become famous soon enough
Yeah, I've fixed this a while back - it is to do with the communication sync in parallel for point fields.

Just for reference, all the tet FEM discretisation and motion classes are still alive, well, fully operational, compatible with OpenFOAM-1.4.1 and tested in the dev branck of OpenOFAM-extend.

Enjoy,

Hrv
__________________
Hrvoje Jasak
Providing commercial FOAM/OpenFOAM and CFD Consulting: http://wikki.co.uk
hjasak is offline   Reply With Quote

Old   September 19, 2007, 02:34
Default Hi Mattijs, hi Hrvoje, Regard
  #10
Senior Member
 
Francesco Del Citto
Join Date: Mar 2009
Location: Zürich Area, Switzerland
Posts: 215
Rep Power: 9
fra76 is on a distinguished road
Hi Mattijs, hi Hrvoje,
Regarding the b.c., I think I shouldn't care for the interprocessors b.c., isn't it? If I specify something that work in serial, I'm expecting that the decomposePar utility creates all the needed information for the mesh motion to work in parallel. Am I wrong?

Hrvoje, I have the same problem, with the same partitioning, using version 1.3-dev (may 2007, if I'm not wrong):

Create mesh for time = 0

Selecting motion solver: laplaceTetDecomposition
Selecting motion diffusion: linear
Time = 0.2
ICCG: Solving for motionUx, Initial residual = 0.34477689, Final residual = 9.4942123e-07, No Iterations 135
ICCG: Solving for motionUy, Initial residual = 0, Final residual = 0, No Iterations 0
ICCG: Solving for motionUz, Initial residual = 0, Final residual = 0, No Iterations 0
ICCG: Solving for motionUx, Initial residual = 0.0093146024, Final residual = 9.9272983e-07, No Iterations 92
ICCG: Solving for motionUy, Initial residual = 0.56715025, Final residual = 0.0026012698, No Iterations 5001
ICCG: Solving for motionUz, Initial residual = 0, Final residual = 0, No Iterations 0
ExecutionTime = 99.41 s ClockTime = 100 s

Time = 0.4
Correct mesh motion diffusion field.
ICCG: Solving for motionUx, Initial residual = 0.1432045, Final residual = 1391.8857, No Iterations 5001
ICCG: Solving for motionUy, Initial residual = 0.42487929, Final residual = 3.3289394e+11, No Iterations 5001
ICCG: Solving for motionUz, Initial residual = 0.33279717, Final residual = 1.3932474e-05, No Iterations 5001
ExecutionTime = 385.54 s ClockTime = 387 s

Time = 0.6
Correct mesh motion diffusion field.
ICCG: Solving for motionUx, Initial residual = 0.018106137, Final residual = 0.0051859104, No Iterations 5001
ICCG: Solving for motionUy, Initial residual = 0.02838904, Final residual = 0.0039837638, No Iterations 5001
ICCG: Solving for motionUz, Initial residual = 0.24074598, Final residual = 0.016838073, No Iterations 5001
[0]
[0]
[0] --> FOAM FATAL ERROR : face 0 area does not match neighbour by 0.00287477 with tolerance 0.0001. Possible face ordering problem.
patch: procBoundary0to1 mesh face: 58328
[0]
[0] From function
[0] processorPolyPatch::calcGeometry()
[0] in file meshes/polyMesh/polyPatches/derivedPolyPatches/processorPolyPatch/processorPolyPatch.C at line 217.
[0]
FOAM parallel run exiting
[0]
[1]
[1]
[1] --> FOAM FATAL ERROR : face 0 area does not match neighbour by 0.00287477 with tolerance 0.0001. Possible face ordering problem.
patch: procBoundary1to0 mesh face: 58360
[1]
[1] From function
[1] processorPolyPatch::calcGeometry()
[1] in file meshes/polyMesh/polyPatches/derivedPolyPatches/processorPolyPatch/processorPolyPatch.C at line 217.
[1]
FOAM parallel run exiting


If you look at the output, you can notice that the solver reaches the maximum number of iterations, without converging. This doesn't happen at all in serial.
Look at the following pictures;




Do you think that a newer dev. version could solve this problem? I have some problem accessing the subversion repository, due to very strict proxy settings...

Francesco
fra76 is offline   Reply With Quote

Old   September 24, 2007, 07:57
Default Frank, when you gave me some s
  #11
Senior Member
 
Francesco Del Citto
Join Date: Mar 2009
Location: Zürich Area, Switzerland
Posts: 215
Rep Power: 9
fra76 is on a distinguished road
Frank, when you gave me some suggestions on how to recompile my dynamicFvMesh based library to the new OF-1.4.1 version, was you referring to the sourceforge one?

Francesco
fra76 is offline   Reply With Quote

Old   September 24, 2007, 09:29
Default Yes, I use the patched up 1.4.
  #12
Senior Member
 
Frank Bos
Join Date: Mar 2009
Location: The Netherlands
Posts: 338
Rep Power: 9
lr103476 is on a distinguished road
Yes, I use the patched up 1.4.1 from openCFD and the development version. Try to use the svn to download the latest release, search the message board on how to use this.

Frank
__________________
Frank Bos
lr103476 is offline   Reply With Quote

Old   September 24, 2007, 09:39
Default The problem is the proxy serve
  #13
Senior Member
 
Francesco Del Citto
Join Date: Mar 2009
Location: Zürich Area, Switzerland
Posts: 215
Rep Power: 9
fra76 is on a distinguished road
The problem is the proxy server, even if it shouldn't...
However, I'd like to write a sort of "rotateDisplacementLaplacian" for version 1.4.1 (not dev).
I mean, something like displacementLaplacian, where you can specify the absolute movement of each part, but assigning a rotation.

Thanks
Francesco
fra76 is offline   Reply With Quote

Old   September 24, 2007, 10:47
Default Do you mean a to write a custo
  #14
Senior Member
 
Frank Bos
Join Date: Mar 2009
Location: The Netherlands
Posts: 338
Rep Power: 9
lr103476 is on a distinguished road
Do you mean a to write a custom boundary condition based on angularOscillatingVelocity?
In my view it is easier to write a variant on the dynamicBodyFvMesh library, such that you define a couple of rotation matrices. The next thing is to update the velocity of the points on the moving patch accordingly.

Regards, Frank
__________________
Frank Bos
lr103476 is offline   Reply With Quote

Old   September 24, 2007, 16:26
Default Hi Juha, Just some hints:
  #15
Senior Member
 
Frank Bos
Join Date: Mar 2009
Location: The Netherlands
Posts: 338
Rep Power: 9
lr103476 is on a distinguished road
Hi Juha,

Just some hints:

* The laplaceTetDecomposition motion solver is not present in the standard release of OF-1.4.1. Just type it wrong and it should give you the available options, i.e. velocityLaplacian or so....
* For some dictionary settings take a look at the movingCone tutorial.
* For the latest patched-up OF-1.4.1 you only need to define the motion in the pointMotionU in the 0 dir.
* To define the motion on a boundary, just start by using the pointField BC: oscillatingVelocity or angularOscillatingVelocity.....

Regards, Frank
__________________
Frank Bos
lr103476 is offline   Reply With Quote

Old   September 27, 2007, 02:32
Default Hello Juha, I had/having a
  #16
New Member
 
Thomas Gallinger
Join Date: Mar 2009
Posts: 28
Rep Power: 8
thomas is on a distinguished road
Hello Juha,

I had/having a similar problem with OF and dynamic meshes.

Where did you get the patches from? Having a look at the extension site, I cannot find any.

Thanks very much
Thomas
thomas is offline   Reply With Quote

Old   September 29, 2007, 09:08
Default Hello Thomas, There are str
  #17
New Member
 
Juha Kortelainen
Join Date: Mar 2009
Posts: 6
Rep Power: 8
kortelainen is on a distinguished road
Hello Thomas,

There are straight forward instructions in the General Guidelines section:

http://openfoam-extend.wiki.sourceforge.net/Subversion_Guidelines#GuidelinesForU sers

Look for the use case "User only wants to patch his OpenCFD distribution of OpenFOAM with bug-fixes". Maybe there should be some note about this site at the OpenCFD pages. I had to do some detective work for this, too.

- Juha -
kortelainen 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
Dynamic mesh Virag Mishra FLUENT 0 October 1, 2007 07:02
Dynamic Mesh Lety FLUENT 1 January 17, 2006 02:58
dynamic mesh - structured or cooper mesh Manoj Kumar FLUENT 2 November 11, 2005 02:18
dynamic mesh and sliding mesh nasser FLUENT 0 November 1, 2005 03:37
Dynamic mesh Hongyan_Huang FLUENT 2 December 15, 2002 09:17


All times are GMT -4. The time now is 13:09.