|
[Sponsors] |
August 9, 2005, 09:42 |
Hello,
I'm working on naval
|
#1 |
Member
|
Hello,
I'm working on naval simulations. The first tests I've made with the free-surface solver rasInterFoam are very encouraging. Now I would like to incorporate in the solver I'm using (rasInterFoam) the "Automatic mesh motion" technique. In this way it will be easy (I hope) to produce simulations with boat prescribed motions or n-DOF boat dynamic simulations. I read that the interFoam has moving mesh capabilities. Are its moving mesh features similar to the icoFoamAutoMotion solver? Is it possible to clone the interFoam moving mesh structures directly to the rasInterFoam? I'm just starting to looking at these OpenFOAM features and I will be very grateful for every suggestion, paper reference, tutorial, experience you will give to me. Best regards, Michele. |
|
August 9, 2005, 09:54 |
Yes you can transfer the movin
|
#2 |
Senior Member
Join Date: Mar 2009
Posts: 854
Rep Power: 22 |
Yes you can transfer the moving-mesh capability from interFoam into rasInterFoam but you may find it easier to transfer the RAS modelling from rasInterFoam into interFoam as this may entail fewer changes.
|
|
August 10, 2005, 08:26 |
Thanks Henry for your suggesti
|
#3 |
Member
|
Thanks Henry for your suggestion.
I modified the files, obtaining a "rasInterFoamMotion" solver starting from the interFoam and adding RAS. I need some clarifications: 1. in "createFields.H" is it correct to replace the autoPtr<transportmodel> phase1 ( transportModel::New(U, phi, "phase1") ); autoPtr<transportmodel> phase2 ( transportModel::New(U, phi, "phase2") ); with the autoPtr<transportmodel> twoPhaseLaminar ( transportModel::New(U, phi,"twoPhase") ); model, that was in the rasInterFoam? 2. If so, is it sufficient to substitute in "rasInterFoamMotion.C" the phase1->correct(); phase2->correct(); with turbulence->correct(); after the mesh move procedure? It has the drawback that the turbulent equations will be calculated twice for each timestep: the first one just after the mesh motion and the second one after the PISO. Any workaround? May I suppress one of the turbulence->correct() istances? I obtain something like the following: ... phi += mesh.phi(); mesh.move(); phi -= mesh.phi(); turbulence->correct(); // phase1->correct(); // phase2->correct(); # include "gammaEqnSubCycle.H" # include "UEqn.H" // --- PISO loop for (int corr=0; corr<nCorr; corr++) { # include "pEqn.H" # include "movingMeshContinuityErrs.H" turbulence->correct(); runTime.write(); ... } 3. Is it possible to obtain a test case of interFoam with the moving mesh? I found the inkJet code, and I think I will need to start from it in order to specify boundary conditions for my ship. Thanks Michele. |
|
August 10, 2005, 08:36 |
1) Yes.
2) You can remove
|
#4 |
Senior Member
Join Date: Mar 2009
Posts: 854
Rep Power: 22 |
1) Yes.
2) You can remove the first call to turbulence->correct() 3) Yes try the inkJet test case. |
|
August 10, 2005, 13:06 |
Thanks Henry. Unfortunatly I h
|
#5 |
Member
|
Thanks Henry. Unfortunatly I haven't found the inkJet complete case, in the distribution I have only the source files inside the interFoam directory. So I'm unable to run the case. Am I missing anything?
1) I tried to apply this solver to the damBreak case (with the interFoam solver), just to see what happens, so I changed the motionProperties file as following: movingFvMesh movingInkJetFvMesh; movingInkJetFvMeshCoeffs { amplitude 1.0; frequency 0.5; refPlaneX 0.0; }; The interFoam runs but I obtain strange results: the polyMesh/points file seems to change only a little between time-write 0 and 0.05, and then it remains constant... Moreover the boundaries are not moved (should I specify somewhere motion boundary conditions?), the Courant number is not respected during the simulation (about 0.5 instead of the 0.2, but this may be due to excessive fast motions, but once again, I don't see motions apart the first step), the dam doesn't break, in 1 second it just reaches the obstacle... Excuse for my stupid questions. I need some tips to understand how to manage simulations with the interFoam moving mesh capabilities. 2) Anyway, it seems that the inkJet has only analitically-specified mesh motion (that sometimes can be useful) but I was thinking adding the motion solver for computing the mesh updates. Is it possible to use the same strategy of the icoFoamAutoMotion? Excuse for bothering you with these elementary questions... Michele. |
|
August 10, 2005, 19:19 |
1. You best look at the source
|
#6 |
Senior Member
Mattijs Janssens
Join Date: Mar 2009
Posts: 1,419
Rep Power: 26 |
1. You best look at the source for movingInkjetFvMesh in the interFoam solver. Just create your own movingFvMesh class which implements the behaviour you want.
2. Yes, but you have wrap it in your own class (see 1) and just make sure that the 'move()' member function does all the mesh motion solving. |
|
September 26, 2005, 07:13 |
Hi,
I'm trying to use the
|
#7 |
Member
Niklas Wikstrom
Join Date: Mar 2009
Posts: 86
Rep Power: 17 |
Hi,
I'm trying to use the motionSolver for a turning rudder application, and it works fine in serial computations. However, running in parallel does not work with more than 2 processes involved. For a small test case I end up with the following fatal: --> FOAM FATAL IO ERROR : wrong token type - expected int found on line 0 the scalar 40 file: IOstream at line 0. From function operator>>(Istream&, int&) in file primitives/int/intIO.C at line 74. FOAM parallel run exiting On a larger case, most of the processes "go to sleep", while the master load remains on 100%. Last output from OpenFOAM is Selection motion diffusion: quadratic Might there be a bug in the motion solver, or is it only me? thank you Niklas |
|
September 26, 2005, 07:29 |
It's you :-)
The parallel m
|
#8 | |
Senior Member
Hrvoje Jasak
Join Date: Mar 2009
Location: London, England
Posts: 1,907
Rep Power: 33 |
It's you :-)
The parallel mesh motion test is a part of my standard test loop and it works fine (below). Hrv Quote:
__________________
Hrvoje Jasak Providing commercial FOAM/OpenFOAM and CFD Consulting: http://wikki.co.uk |
||
September 26, 2005, 07:57 |
Certainly is,
and as a perso
|
#9 |
Member
Niklas Wikstrom
Join Date: Mar 2009
Posts: 86
Rep Power: 17 |
Certainly is,
and as a person I'm not evil :-) Thank you for answering. Have to go through the case again, then. Happens on really simple cases, though. Eg on the offsetCylinder in the tut's. Noticed now that (at least for that case) it depends on the decomposition (method simple): (4 1 1) NOT OK. (2 2 1) OK. (1 4 1) NOT OK. Wierd. too bad we didn't meet in Gothenburg. We're just the guys working on the floor you know. /Niklas |
|
September 26, 2005, 08:23 |
Hi Niklas,
Don't get me wro
|
#10 |
Senior Member
Hrvoje Jasak
Join Date: Mar 2009
Location: London, England
Posts: 1,907
Rep Power: 33 |
Hi Niklas,
Don't get me wrong, I've nothing against you personally and I am sorry we hadn't met in Gotherburg in person - unfortunately, I have to earn a living from time to time as well. I am pretty certain my version is OK because I use it a lot. If things depend on the decomposition, this may be an indication of errors when the globally shared points and edges are determined - you will need to check this manually. I know Mattijs has been working on this and the test cases are OK, but I am not sure how much testing it has received. Hrv
__________________
Hrvoje Jasak Providing commercial FOAM/OpenFOAM and CFD Consulting: http://wikki.co.uk |
|
September 26, 2005, 09:21 |
Hi Niklas,
To find out wher
|
#11 |
Senior Member
Mattijs Janssens
Join Date: Mar 2009
Posts: 1,419
Rep Power: 26 |
Hi Niklas,
To find out where it goes wrong: lamwipe, switch on FOAM_ABORT, lamboot and use lamrun script (see board) to run the processes in separate windows. |
|
|
|
Similar Threads | ||||
Thread | Thread Starter | Forum | Replies | Last Post |
Released RBF motion solver | lr103476 | OpenFOAM Running, Solving & CFD | 6 | December 11, 2020 09:02 |
[Technical] Automatic Mesh Refinement and Tetrahedral Meshes | philippose | OpenFOAM Meshing & Mesh Conversion | 8 | May 21, 2016 16:44 |
Motion diffusivity solver has problems with patches moving toward each other | bfa | OpenFOAM Running, Solving & CFD | 2 | July 8, 2009 22:35 |
Oscillatory mesh motion setup mesh flux ERROR | jaswi | OpenFOAM Running, Solving & CFD | 5 | August 23, 2007 05:41 |