Hello, I'm working on naval
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.
Yes you can transfer the movin
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.
Thanks Henry for your suggesti
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
transportModel::New(U, phi, "phase1")
transportModel::New(U, phi, "phase2")
model, that was in the rasInterFoam?
2. If so, is it sufficient to substitute in "rasInterFoamMotion.C" the
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();
phi -= mesh.phi();
# include "gammaEqnSubCycle.H"
# include "UEqn.H"
// --- PISO loop
for (int corr=0; corr<nCorr; corr++)
# include "pEqn.H"
# include "movingMeshContinuityErrs.H"
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.
1) Yes. 2) You can remove
2) You can remove the first call to turbulence->correct()
3) Yes try the inkJet test case.
Thanks Henry. Unfortunatly I h
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:
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...
1. You best look at the source
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.
Hi, I'm trying to use the
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?
It's you :-) The parallel m
It's you :-)
The parallel mesh motion test is a part of my standard test loop and it works fine (below).
Certainly is, and as a perso
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.
too bad we didn't meet in Gothenburg. We're just the guys working on the floor you know.
Hi Niklas, Don't get me wro
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.
Hi Niklas, To find out wher
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.
|All times are GMT -4. The time now is 04:30.|