|
[Sponsors] |
September 17, 2007, 11:48 |
Hi all,
I've found some diffe
|
#1 |
Senior Member
Francesco Del Citto
Join Date: Mar 2009
Location: Zürich Area, Switzerland
Posts: 237
Rep Power: 18 |
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 |
|
September 18, 2007, 08:07 |
Hi Francesco!
The velocity-
|
#2 |
Assistant Moderator
Bernhard Gschaider
Join Date: Mar 2009
Posts: 4,225
Rep Power: 51 |
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 |
|
September 18, 2007, 08:22 |
Hi Bernhard,
I'm talking abou
|
#3 |
Senior Member
Francesco Del Citto
Join Date: Mar 2009
Location: Zürich Area, Switzerland
Posts: 237
Rep Power: 18 |
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? |
|
September 18, 2007, 08:35 |
Hi Francesco,
You can easil
|
#4 |
Senior Member
Frank Bos
Join Date: Mar 2009
Location: The Netherlands
Posts: 340
Rep Power: 18 |
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 |
|
September 18, 2007, 08:42 |
Hi Francesco!
@version: I w
|
#5 |
Assistant Moderator
Bernhard Gschaider
Join Date: Mar 2009
Posts: 4,225
Rep Power: 51 |
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 |
|
September 18, 2007, 08:51 |
Thank you both!
I should know
|
#6 |
Senior Member
Francesco Del Citto
Join Date: Mar 2009
Location: Zürich Area, Switzerland
Posts: 237
Rep Power: 18 |
Thank you both!
I should know where to start from, now. Francesco |
|
September 18, 2007, 11:27 |
Here I am again.
I'm experien
|
#7 |
Senior Member
Francesco Del Citto
Join Date: Mar 2009
Location: Zürich Area, Switzerland
Posts: 237
Rep Power: 18 |
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 |
|
September 18, 2007, 18:39 |
How are you specifying the b.c
|
#8 |
Senior Member
Mattijs Janssens
Join Date: Mar 2009
Posts: 1,419
Rep Power: 26 |
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)
|
|
September 18, 2007, 18:39 |
Yeah, I've fixed this a while
|
#9 |
Senior Member
Hrvoje Jasak
Join Date: Mar 2009
Location: London, England
Posts: 1,904
Rep Power: 33 |
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 |
|
September 19, 2007, 03:34 |
Hi Mattijs, hi Hrvoje,
Regard
|
#10 |
Senior Member
Francesco Del Citto
Join Date: Mar 2009
Location: Zürich Area, Switzerland
Posts: 237
Rep Power: 18 |
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 |
|
September 24, 2007, 08:57 |
Frank, when you gave me some s
|
#11 |
Senior Member
Francesco Del Citto
Join Date: Mar 2009
Location: Zürich Area, Switzerland
Posts: 237
Rep Power: 18 |
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 |
|
September 24, 2007, 10:29 |
Yes, I use the patched up 1.4.
|
#12 |
Senior Member
Frank Bos
Join Date: Mar 2009
Location: The Netherlands
Posts: 340
Rep Power: 18 |
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 |
|
September 24, 2007, 10:39 |
The problem is the proxy serve
|
#13 |
Senior Member
Francesco Del Citto
Join Date: Mar 2009
Location: Zürich Area, Switzerland
Posts: 237
Rep Power: 18 |
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 |
|
September 24, 2007, 11:47 |
Do you mean a to write a custo
|
#14 |
Senior Member
Frank Bos
Join Date: Mar 2009
Location: The Netherlands
Posts: 340
Rep Power: 18 |
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 |
|
September 24, 2007, 17:26 |
Hi Juha,
Just some hints:
|
#15 |
Senior Member
Frank Bos
Join Date: Mar 2009
Location: The Netherlands
Posts: 340
Rep Power: 18 |
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 |
|
September 27, 2007, 03:32 |
Hello Juha,
I had/having a
|
#16 |
New Member
Thomas Gallinger
Join Date: Mar 2009
Posts: 28
Rep Power: 17 |
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 |
|
September 29, 2007, 10:08 |
Hello Thomas,
There are str
|
#17 |
New Member
Juha Kortelainen
Join Date: Mar 2009
Posts: 6
Rep Power: 17 |
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 - |
|
Thread Tools | Search this Thread |
Display Modes | |
|
|
Similar Threads | ||||
Thread | Thread Starter | Forum | Replies | Last Post |
Dynamic mesh | Virag Mishra | FLUENT | 0 | October 1, 2007 08: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 |