Hi there,
I got stuck with
Hi there,
I got stuck with an intent to do topological changes (layerAdditionRemoval) in version 1.4. I managed to write a class derived from topoChangerFvMesh. I am doing a prescribed movement of one wall, which works fine. I also managed to add a facezone and a layerAdditionRemoval modifier, which is supposed to add/remove layers in front of that moving wall. Using function changeTopology() from that modifier in my class derived from topochangerfvmesh , it also returns me a "true" when I would want the mesh to be modified, so things dont look bad. However, now I have no clue where to get a mapPolyMesh object from, in order to be able to call polyTopoChanger::update(const Foam::mapPolyMesh&). Anyways, I could not find any derivation of topochangerfvmesh in version 1.4 anyways - everything doing topological changes I looked at (in version 1.4), to get some help,e.g. the linearValveLayersFvMesh, is commented out in Make/files. Which makes me wonder if topological changes do work at all in 1.4? Or do I have to resort to Hrvoje's development version? Thank you very much! Thomas |
Time for a classic "works for
Time for a classic "works for me" :-) There has been a number of bug fixes and I'm just about finished with the move to 1.4.1 now. Mesh layering is pretty easy and my topo changes tutorials work without trouble.
Hrv |
Hi Thomas,
it works with 1.4!
Hi Thomas,
it works with 1.4! You don't have to call update explicitly. Just make sure you got the function update() implemented in your derivation of topoChangerFvMesh, it get's called automatically. To execute the actual mesh motion invoke movePoints(yourCalculatedNewPoints) inside the update function. Hope it helps, Björn |
Bjoern, let me give you a hug!
Bjoern, let me give you a hug!
That was exactly the information I needed, works now. Thanks again! Thomas |
LayerAdditionRemoval works fin
LayerAdditionRemoval works fine for me now in serial,however, in parallel (4 processors), I get this:
[2] [2] [2] --> FOAM FATAL ERROR : Face extrusion zone contains no faces. Please check your mesh definition.#0 Foam::error::printStack(Foam:http://www.cfd-online.com/OpenFOAM_D...part/proud.gifstream&) #1 Foam::error::abort() #2 Foam::layerAdditionRemoval::checkDefinition() #3 Foam::layerAdditionRemoval::layerAdditionRemoval(F oam::word const&, int, Foam::polyTopoChanger const&, Foam::word const&, double, double) #4 Foam::layeringFvMesh::addZonesAndModifiers() I can only imagine that there are partitions which are not in contact with the faceZone I specified for the layerAdditionRemoval modifier. But how to tell it? addZonesAndModifiers() seems to be called only on one processor, as far as I can see from my output. I already tried creating and saving the faceZone before and after decomposition, but makes no difference. Any hints? Thanks again! Thomas |
The version you've got does no
The version you've got does not support topological changes in parallel - if you want to run this on more than 1 CPU, it's time to write some code.
Hrv |
"The version you've got" ....
"The version you've got" ....
Sounds like there could be another version? Dont want to say I do not want to write code ... but I am afraid I still have to learn too much to start with that http://www.cfd-online.com/OpenFOAM_D...part/happy.gif Thanks, anyways Thomas |
Well, I wrote the code and whe
Well, I wrote the code and when I wrote it I didn't implement parallel support into any of the topo change stuff. Mattijs (than you) has put some serious effort into handling some parallelism, but as you can see, this is not operational yet.
This is a sufficiently important feature that it must be developed in the near future because so many people need it. I have been playing around with ideas and partial parallelisation of various bits and bobs, but the job is substantial. In short, ongoing (serious and heavy-duty) work: if you just want to run the code, you'll have to wait, otherwise you can consider contributing to the effort. Hrv |
Hi all!
I've managed to use t
Hi all!
I've managed to use topo changes in my case. I've got a problem when there is a layer removal, the pressure always go crasy... and I don't know why! I'm using a modified version of turbForceFoam by Philipose to do the calculations... Here is the output : Time = 0.24 Solving kinematic equations.... Absolute simulation time [sec] = 0.24 Real delta T [sec] = 0.01 Calculating buoyant force . . . . Buoyant force on patch movingCone = 153281 N Calculating Pressure Forces.... Area of patch movingCone = 37.5 Pressure force on patch movingCone = (-0.0568286 -0.0568286 49.6551) N Total Pressure Force along motion vector = 49655.1 N (-0 -0 -1.22762) a la ligne 167 Calculated Re number = 657653 Calculated drag coefficient = 233.677 Calculated acceleration in motion direction [m/s^2] = -4.9996 Calculated velocity of motion [m/s] = (-0,-0,-1.22762) Calculated distance moved [m] = (-0,-0,-0.155522) Updating vertex markup. curDown: 58.8568 curUp: 61.3568 Updating vertex markup2. curLeft: 10.8 curRight: 20.2 Executing mesh motion time step continuity errors : sum local = 5.41714e-12, global = -1.08005e-12, cumulative = -1.30584e-11 DICPCG: Solving for pcorr, Initial residual = 1, Final residual = 7.53489e-07, No Iterations 43 DICPCG: Solving for pcorr, Initial residual = 8.90281e-08, Final residual = 8.90281e-08, No Iterations 0 DICPCG: Solving for pcorr, Initial residual = 8.90281e-08, Final residual = 8.90281e-08, No Iterations 0 Courant Number mean: 1.902e-05 max: 0.0234231 DILUPBiCG: Solving for Ux, Initial residual = 0.0244316, Final residual = 5.01149e-08, No Iterations 1 DILUPBiCG: Solving for Uy, Initial residual = 0.0244316, Final residual = 5.01149e-08, No Iterations 1 DILUPBiCG: Solving for Uz, Initial residual = 0.0166555, Final residual = 8.60463e-08, No Iterations 1 DICPCG: Solving for p, Initial residual = 0.0217529, Final residual = 8.49264e-07, No Iterations 26 DICPCG: Solving for p, Initial residual = 8.32018e-07, Final residual = 8.32018e-07, No Iterations 0 DICPCG: Solving for p, Initial residual = 8.32018e-07, Final residual = 8.32018e-07, No Iterations 0 time step continuity errors : sum local = 4.90486e-12, global = -5.50557e-13, cumulative = -1.36089e-11 DICPCG: Solving for p, Initial residual = 1.61881e-05, Final residual = 9.68505e-07, No Iterations 9 DICPCG: Solving for p, Initial residual = 9.68508e-07, Final residual = 9.68508e-07, No Iterations 0 DICPCG: Solving for p, Initial residual = 9.68508e-07, Final residual = 9.68508e-07, No Iterations 0 time step continuity errors : sum local = 5.70951e-12, global = -1.07183e-12, cumulative = -1.46808e-11 ExecutionTime = 23.06 s ClockTime = 25 s Time = 0.26 Solving kinematic equations.... Absolute simulation time [sec] = 0.26 Real delta T [sec] = 0.01 Calculating buoyant force . . . . Buoyant force on patch movingCone = 153281 N Calculating Pressure Forces.... Area of patch movingCone = 37.5 Pressure force on patch movingCone = (-137.944 -137.944 -112196) N Total Pressure Force along motion vector = -1.12196e+08 N (-0 -0 -1.37557) a la ligne 167 Calculated Re number = 736911 Calculated drag coefficient = -420529 Calculated acceleration in motion direction [m/s^2] = -9.8 Calculated velocity of motion [m/s] = (-0,-0,-1.37557) Calculated distance moved [m] = (-0,-0,-0.182054) Updating vertex markup. curDown: 58.8317 curUp: 61.3317 Updating vertex markup2. curLeft: 10.8 curRight: 20.2 Executing mesh motion time step continuity errors : sum local = 1.44673e-08, global = 2.01092e-09, cumulative = 5.25112e-09 DICPCG: Solving for pcorr, Initial residual = 1, Final residual = 6.52668e-07, No Iterations 45 DICPCG: Solving for pcorr, Initial residual = 1.71903e-07, Final residual = 1.71903e-07, No Iterations 0 DICPCG: Solving for pcorr, Initial residual = 1.71903e-07, Final residual = 1.71903e-07, No Iterations 0 Courant Number mean: 0.000962346 max: 2.61532 DILUPBiCG: Solving for Ux, Initial residual = 0.33902, Final residual = 3.92993e-07, No Iterations 5 DILUPBiCG: Solving for Uy, Initial residual = 0.33902, Final residual = 3.92993e-07, No Iterations 5 DILUPBiCG: Solving for Uz, Initial residual = 0.296688, Final residual = 3.17797e-06, No Iterations 4 DICPCG: Solving for p, Initial residual = 0.803482, Final residual = 7.98478e-07, No Iterations 46 DICPCG: Solving for p, Initial residual = 6.01537e-07, Final residual = 6.01537e-07, No Iterations 0 DICPCG: Solving for p, Initial residual = 6.01537e-07, Final residual = 6.01537e-07, No Iterations 0 time step continuity errors : sum local = 1.78226e-09, global = 2.96637e-11, cumulative = 5.28078e-09 DICPCG: Solving for p, Initial residual = 0.260427, Final residual = 9.7542e-07, No Iterations 44 DICPCG: Solving for p, Initial residual = 1.43951e-06, Final residual = 7.42881e-07, No Iterations 1 DICPCG: Solving for p, Initial residual = 7.42881e-07, Final residual = 7.42881e-07, No Iterations 0 time step continuity errors : sum local = 1.42263e-09, global = 1.32835e-10, cumulative = 5.41362e-09 ExecutionTime = 26.39 s ClockTime = 28 s Courant Number mean: 0.0026763 max: 2.30372 When looking at the solution, we can see that pressure at the insertion point of the layer is way too high (like 1e5 when it is supposed to be aroun 1e2)... Any hints? |
Hello Dominique,
A Good day
Hello Dominique,
A Good day to you :-)! Very interesting to see that you have actually put the solver to use, and even modified it :-)! Didnt expect people to take it up and add on functionality! Really nice :-)! Well... when I implemented the solver, I had not thought of using it in combination with topological changes, though in theory, I dont see why it shouldnt work with it either :-)! So for me it would be very interesting if you could send me the modified version of the solver (only if possible ofcourse!). As for the sudden change in pressure... I am not sure what is taken care of automatically, and what needs to be taken care of in the top level solver... but when you make a topological change (for example layer addition/removal)... you need to map the old solution on to the new mesh. So in your particular case, when you remove a layer, the values of the field variables in the surrounding layers would have to be corrected I think. I am sure Hrvoje can say more about this... he is the main dude behind that code anyway :-)! Have a nice day! Philippose |
I made a mistake earlier... W
I made a mistake earlier... When there is layer removal, everything is working fine. The problem is when adding layers actually...
|
I've just updated everything t
I've just updated everything to 1.4.1-dev svn version from sourceforge.net, and I still have the same problem when adding new layers... Nobody have an Idea???
Thanks! |
You need to be more specific.
You need to be more specific. It all works fine over here and our friends in Milan are using layering all the time. How did you write the solver - will it re-solve the pressure equation after a topo change? Is the flow incompressible in a closed box (no inlet or outlet): if so, the total volume/mass MUST be exactly identical between iterations. Do you get a continuity error after a topo change?
Adding layers should be trivial - all that happens is a cell inflation from zero volume, which is numerically exact. Hrv |
Thanks for your answer
For th
Thanks for your answer
For the solver, I've took icoDyMFoam and added a force solver right before " bool meshChanged = mesh.update() " After mesh motion, I have a volume change of about 1e-10, but there is an inlet and an outlet. After a topological change, the continuity error is of about 1e-15, about the same that in previous iterations... |
I've been thinking about this:
I've been thinking about this: you have to satisfy both the mass continyitu and volume continuity to make for smooth pressure. Looking at your log output, I think I've got more stuff in icoDyMFoam than you - please have a look at this in the dev version.
In any case, you can stick this into your code and see what you get: the volume continuity error must be zer0 to machine tolerance: { volScalarField conserve = -fvc::div(mesh.phi()); // The ddt term constructed by hand because it would be wrong for // Backward Differencing in time. conserve.internalField() += (1.0 - mesh.V0()/mesh.V())/runTime.deltaT().value(); scalar sumLocalContErr = runTime.deltaT().value()* mag(conserve)().weightedAverage(mesh.V()).value(); scalar globalContErr = runTime.deltaT().value()* conserve.weightedAverage(mesh.V()).value(); Info<< "volume continuity errors : sum local = " << sumLocalContErr << ", global = " << globalContErr << endl; } Hrv |
mmm.... Error seems to be th
mmm.... Error seems to be there!
Before the topo. change, I've got a volume continuity error of local : 4e-16 and global : 2e-18 but after topo change, it looks like local :0.189668 and global : -0.189668... I will look again at my modified version of movingConeTopoFvMesh, there should be an error there... Thanks |
Ok so, I juste updated the mov
Ok so, I juste updated the movingConeTopoFvMesh for what I want to do, using the svn movingConeTopoFvMesh. I still have the same problem with volume continuity error... What is the volume continuity error?
Thanks a lot for your answers!! |
Yup: bug. MY bug http://www.c
Yup: bug. MY bug http://www.cfd-online.com/OpenFOAM_D...part/happy.gif Sorry about that. It is fixed now and checked in:
/trunk/Core/OpenFOAM-1.4.1-dev/src/topoChangerFvMesh/movingConeTopoFvMesh/moving ConeTopoFvMesh.C movingConeTopoFvMesh.C Apologies, Hrv |
Ok. I made the corrections, a
Ok. I made the corrections, and no more problem with volume continuity error. Unfortunately, I still have the pressure going crasy problem when adding new layers... very weird!!
|
What is your velocity boundary
What is your velocity boundary condition on the moving wall: are you using movingWallVelocity? Can you reproduce the error on a simple (tutorial) case and with a standard code?
Hrv |
All times are GMT -4. The time now is 14:44. |