|
[Sponsors] |
July 21, 2008, 03:53 |
Having a look into the new sol
|
#1 |
Member
Patricio Bohorquez
Join Date: Mar 2009
Location: Jaén, Spain
Posts: 95
Rep Power: 17 |
Having a look into the new solver interDyMFoam of OF-1.5, I have just realised that the effective viscosity muEff in the UEqn.H file has not been defined according to twoPhaseProperties.muf() + fvc::interpolate(rho*turbulence->nut()).
Should we replace the UEqn.H file in interDyMFoam with the one in rasInterFoam and recompile the solver? Cheers, Patricio |
|
July 21, 2008, 04:05 |
interDyMFoam is setup for lami
|
#2 |
Senior Member
Join Date: Mar 2009
Posts: 854
Rep Power: 22 |
interDyMFoam is setup for laminar flow. If you want to use it for turbulent flow simply transfer the turbulence model parts from either rasInterFoam for RAS or lesInterFoam for LES.
H |
|
July 21, 2008, 05:20 |
Thanks for the explanation Hen
|
#3 |
Member
Patricio Bohorquez
Join Date: Mar 2009
Location: Jaén, Spain
Posts: 95
Rep Power: 17 |
Thanks for the explanation Henry, and for the new release OF-1.5.
(The following lines in interDyMFoam.C were confusing me #include "incompressible/RASModel/RASModel.H" turbulence->correct();) |
|
July 21, 2008, 05:44 |
Good point, thanks for bringin
|
#4 |
Senior Member
Join Date: Mar 2009
Posts: 854
Rep Power: 22 |
Good point, thanks for bringing it to my attention. This application was in a state of flux before release and we have been developing a better version which will be included in the next OpenFOAM release. For now I agree with your proposal of adding the turbulent part of the viscosity in UEqn.H and then switch to the "laminar" turbulence model to run laminar. I will make this change here also.
Thanks again H |
|
July 23, 2008, 03:50 |
hello, everyone.
i have a q
|
#5 |
Guest
Posts: n/a
|
hello, everyone.
i have a question that how the variables are updated when the dynamic mesh is changed. in the dynamic mesh solver "icoDyFoam.C", after the mesh is changed, the code calls the following commands: bool meshChanged = mesh.update(); if (meshChanged) { ........ # include "correctPhi.H" ........ } in the "correctPhi.H", a Poission equation of pcorr is defined as the following: fvScalarMatrix pcorrEqn ( fvm::laplacian(rUA, pcorr) == fvc::div(phi) ); I know that the phi has been made the flux absolute before the mesh is updated, and made the flux relative after the mesh is updated. My question is about the rUA in the left hand of this equation. I think that the rUA was calculated from the "UEqn.H" at the last time step. if so, where has the rUA been updated after the mesh is changed. If the new cells happened due to the mesh motion, what is the rUA at the new cells? I hope someone can help me even if this is a stupid question. by the way, I am also troubling with the mechnism for the phi update. someone can suggest me the references about the dynamics mesh? Thanks! ZHAO |
|
July 23, 2008, 04:55 |
rUA only needs to be approxima
|
#6 |
Senior Member
Join Date: Mar 2009
Posts: 854
Rep Power: 22 |
rUA only needs to be approximate for pcorr, in fact choosing 1 will also work fine. If the mesh moves without topology change rUA is unchanged but with topology change it is mapped automatically to the new mesh.
H |
|
July 24, 2008, 02:08 |
Thanks you very much,Henry.
|
#7 |
Guest
Posts: n/a
|
Thanks you very much,Henry.
Another question for icoDyMFoam.C in OF-1.5. in gammaEqn.H, there are the following commands: ............ surfaceScalarField phiGamma = fvc::flux ( phi, gamma, gammaScheme ) + fvc::flux ( -fvc::flux(-phir, scalar(1) - gamma, gammarScheme), gamma, gammarScheme ............. I think that the fvc::flux(phi, gamma, gammaScheme) is obtained from the old ( the last time step) gamma field at the center of the changed mesh. Is it right? I am wondering whether this old gamma at the center of the changed mesh is unchanged when the mesh moves without topology change, and it is mapped automatically to the new mesh with topology change. If a scalar or vector field is defined similarly to the gamma or velocity field in the createFields.H, this user-defined field is also mapped automatically to the new mesh with topology change? Thanks! ZHAO |
|
July 24, 2008, 02:28 |
All fields registered with the
|
#8 |
Senior Member
Join Date: Mar 2009
Posts: 854
Rep Power: 22 |
All fields registered with the database are automatically mapped to the new mesh following mesh topology change and are unchanged without topology change as required by the Lagrangian-Eulerian time-space discretization used for moving meshes.
H |
|
September 8, 2008, 22:19 |
Hello All:
I am trying to r
|
#9 |
Senior Member
musaddeque hossein
Join Date: Mar 2009
Posts: 309
Rep Power: 18 |
Hello All:
I am trying to run the tank sloshing 2D case under interDymFoam. Is any documentation available like the other tutorials. There isnt one with the documentation for OpenFOAM 1.5. Thanks |
|
September 9, 2008, 08:23 |
Musaddeque: (and OpenCFD folks
|
#10 |
Member
Ola Widlund
Join Date: Mar 2009
Location: Sweden
Posts: 87
Rep Power: 17 |
Musaddeque: (and OpenCFD folks!)
The Allrun script in the sloshingTank2D tutorial contains the commands needed to make the case run. Problem is that the m4 template blockMeshDict.m4 is broken: "format" is probably a reserved word (?) in m4, and needs to be quoted in line 11! Note the shape of the quotes: `format' (see m4 manual for details...) With this fixed, I could run the tutorial using the Allrun script. /Ola PS: corrected blockMeshDict.m4 is attached... blockMeshDict.m4 |
|
September 9, 2008, 08:43 |
Ola:
What does the ".m4" ex
|
#11 |
Senior Member
musaddeque hossein
Join Date: Mar 2009
Posts: 309
Rep Power: 18 |
Ola:
What does the ".m4" extension at the end of the blockMeshDict.m4 imply? Is this specific to OpenFOAM? or do I need something else. Sorry for being so ignorant. Musa |
|
September 9, 2008, 09:53 |
Hi Musa!
The .m4 means that
|
#12 |
Assistant Moderator
Bernhard Gschaider
Join Date: Mar 2009
Posts: 4,225
Rep Power: 51 |
Hi Musa!
The .m4 means that you should replace it with the corresponding .m4 in that tutorial case. If you have a look at the Allrun-file in that case and then type "man m4" on your command line the purpose of this file should become obvious. And "No": m4 is not OpenFOAM-specific. Unless the classic sendmail is also part of OpenFOAM
__________________
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 11, 2008, 03:52 |
Ola,
Over the many years I
|
#13 |
Senior Member
Join Date: Mar 2009
Posts: 854
Rep Power: 22 |
Ola,
Over the many years I have been using m4 with blockMesh I have never come across the problem you are seeing with the "format" keyword. I need to investigate this further before making the change you suggest in all the .m4 files in the tutorials. Which OS are you running on? Which version of m4? Thanks H |
|
September 11, 2008, 05:09 |
Hi Henry,
The server runs S
|
#14 |
Member
Ola Widlund
Join Date: Mar 2009
Location: Sweden
Posts: 87
Rep Power: 17 |
Hi Henry,
The server runs SUSE Linux Enterprise Server 10, SP2. GNU m4 version is 1.4.4. I enclose the blockMeshDict of the slochingTank2D tutorial, produced before my extra quotes. I also enclose the output from the dumpdef command in m4. "format" is defined there, from where I don't know. Please keep me posted on your conclusions. Best regards, Ola blockMeshDict.org dumpdef.txt |
|
September 11, 2008, 05:18 |
Hi again,
The m4 'format' b
|
#15 |
Member
Ola Widlund
Join Date: Mar 2009
Location: Sweden
Posts: 87
Rep Power: 17 |
Hi again,
The m4 'format' built-in is described in the manual for GNU m4 1.4.6. It is described in Section 15.1 as a GNU extension to m4. It also says that all GNU extensions can be suppressed with the '-G' option to m4. I wouldn't be surprised if the GNU extensions can be suppressed already at compilation of m4, which would explain why it's distro specific. /Ola |
|
September 11, 2008, 06:27 |
I am running GNU m4 1.4.6 on S
|
#16 |
Senior Member
Join Date: Mar 2009
Posts: 854
Rep Power: 22 |
I am running GNU m4 1.4.6 on SuSE 10.2 and at appears that the -G option is set by default, well at least the blockMeshDict of the slochingTank2D tutorial runs through correctly.
However if using `format' will allow the .m4 files in OpenFOAM to operate correctly with the GNU extensions I am happy to make the change and will push the updated files into our git repository. H |
|
September 11, 2008, 09:07 |
Ola:
Many thanks for your r
|
#17 |
Senior Member
musaddeque hossein
Join Date: Mar 2009
Posts: 309
Rep Power: 18 |
Ola:
Many thanks for your response. I ran the Allrun for tank sloshing problem for 2D and 3d and things worked ok - even paraview didnt crash!. I did not have to replace the blockMeshDict file with the one you sent. I am running OpenFoam 1.5 on Suse 11. Musa |
|
November 5, 2008, 22:33 |
I would appreciate it if someo
|
#18 |
Senior Member
musaddeque hossein
Join Date: Mar 2009
Posts: 309
Rep Power: 18 |
I would appreciate it if someone could tell me how to provide a sinusiodal swaying to the 2d tank sloshing problem. I am trying to model a case where a tank of fluid is subject to some oscillation Asin(2*pi8t/T). Does OpenFoam have a facility where the since wave source can be plugged in and processed for the solvers to pick up.
Musa |
|
November 6, 2008, 02:59 |
Have you looked at the
slos
|
#19 |
Senior Member
Join Date: Mar 2009
Posts: 854
Rep Power: 22 |
Have you looked at the
sloshingTank2D sloshingTank2D3DoF sloshingTank3D sloshingTank3D3DoF tutorial cases? H |
|
November 7, 2008, 23:05 |
Henry:
I looked at the slos
|
#20 |
Senior Member
musaddeque hossein
Join Date: Mar 2009
Posts: 309
Rep Power: 18 |
Henry:
I looked at the sloshingTank2D case and tried to modify the control dictionary such that there is only swaying and no roll or heave, thus: // Centre of gravity CofG (0 0 0); // Model scale ratio // lamda 50; lamda 50; // Max roll amplitude [rad] //rollAmax 0.22654; rollAmax 0.0; // Min roll amplitude [rad] //rollAmin 0.10472; rollAmin 0.0; // Heave amplitude [m] //heaveA 3.79; heaveA 0.0; // Sway amplitude [m] //swayA 2.34; swayA 2.5; // Damping Coefficient [-] Q 0.010; // Time Period for liquid [sec] Tp 1.27; // Natural Period of Ship [sec] Tpn 11.93; // Reference time step [sec] dTi 0.059; // Incr. in Tp/unit 'dTi'[-] dTp -0.001; I left the other parameters intact. The solution ran for 3 hours before I terminated the process. Any suggestions as to how I can do that? I look forward to your response. |
|
|
|
Similar Threads | ||||
Thread | Thread Starter | Forum | Replies | Last Post |
turbulent viscosity limited to viscosity ratio of | Hua | FLUENT | 7 | September 27, 2019 06:42 |
turbulent viscosity limited to viscosity ratio... | frank | FLUENT | 19 | December 15, 2015 22:54 |
Turbulent viscosity Limited to viscosity ratio | Adrian | FLUENT | 12 | September 21, 2011 04:22 |
Turbulent viscosity limited to viscosity ratio... | Cyril | FLUENT | 8 | February 7, 2006 20:34 |
turbulent viscosity limited to viscosity ratio | mukkarum | FLUENT | 3 | May 11, 2004 04:05 |