Hi all, I've found some diffe
 

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

Hi Francesco! The velocity-
 

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

Hi Bernhard, I'm talking abou
 

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?

Hi Francesco, You can easil
 

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

Hi Francesco! @version: I w
 

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

Thank you both! I should know
 

Thank you both!
I should know where to start from, now.

Francesco

Here I am again. I'm experien
 

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

How are you specifying the b.c
 

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)

Yeah, I've fixed this a while
 

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

Hi Mattijs, hi Hrvoje, Regard
 

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;
http://www.cfd-online.com/OpenFOAM_D...ges/1/5431.jpg
http://www.cfd-online.com/OpenFOAM_D...ges/1/5432.jpg


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

Frank, when you gave me some s
 

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

Yes, I use the patched up 1.4.
 

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

The problem is the proxy serve
 

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

Do you mean a to write a custo
 

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

Hi Juha, Just some hints:
 

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

Hello Juha, I had/having a
 

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

Hello Thomas, There are str
 

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 -