|
[Sponsors] |
Simulating standing wave in rhopSonicFoam solver |
|
LinkBack | Thread Tools | Search this Thread | Display Modes |
May 7, 2008, 10:02 |
Hi all
I am trying to simu
|
#1 |
Senior Member
Nishant
Join Date: Mar 2009
Location: Glasgow, UK
Posts: 166
Rep Power: 17 |
Hi all
I am trying to simulate the standing wave formation in rhopsonicfoam solver. I am applying a timevaryingFixedVaalue patch at inlet for pressure and fixed value patch for velocity (with value v=0.001m/s). My simulation is going smooth if velocity is zero. but when velocity is some value like 0.001m/s the simulation crashes with high courant number at around 0.06 sec. i m using vanLeer div scheme. and deltaT = 1e-5. can anybody suggest something? Nishant
__________________
Thanks and regards, Nishant |
|
May 7, 2008, 10:19 |
Hi Nishant
rhopsonicFoam i
|
#2 |
Senior Member
Niels Gjoel Jacobsen
Join Date: Mar 2009
Location: Copenhagen, Denmark
Posts: 1,900
Rep Power: 37 |
Hi Nishant
rhopsonicFoam is not using adaptive time stepping, thus try to follow the guidelines in the following thread to make the solver time adaptive (do not panic, it is rather straight forward): http://www.cfd-online.com/cgi-bin/Op...how.cgi?1/7583 Best regards, Niels
__________________
Please note that I do not use the Friend-feature, so do not be offended, if I do not accept a request. |
|
May 7, 2008, 12:20 |
Niels, Thanks for the prompt r
|
#3 |
Senior Member
Nishant
Join Date: Mar 2009
Location: Glasgow, UK
Posts: 166
Rep Power: 17 |
Niels, Thanks for the prompt reply.
I am rather not using the turbfoam solver. so the headers are not similar. I can not see courant.H header in my rhopSonic.C file. However my case is still runing well with only changing the controldict file, WITHOUT recompiling the source. The results are also not very encouraging and it also failed in a similar fashiion! Nishant
__________________
Thanks and regards, Nishant |
|
May 7, 2008, 16:09 |
Hi Nishant
I meant that you
|
#4 |
Senior Member
Niels Gjoel Jacobsen
Join Date: Mar 2009
Location: Copenhagen, Denmark
Posts: 1,900
Rep Power: 37 |
Hi Nishant
I meant that you should add the header files inside the time loop as suggested in the thread. That would give you the possibility of basing the time step on the Courant number. I do not believe that simply changing the controlDict will yield any differences at all. Best regards, Niels
__________________
Please note that I do not use the Friend-feature, so do not be offended, if I do not accept a request. |
|
May 7, 2008, 16:21 |
Nishant Singh,
look in to yo
|
#5 |
Senior Member
Matvey Kraposhin
Join Date: Mar 2009
Location: Moscow, Russian Federation
Posts: 355
Rep Power: 21 |
Nishant Singh,
look in to your solver source, it should be like this: int main(int argc, char *argv[]) { # include "setRootCase.H" # include "createTime.H" # include "createMesh.H" # include "readThermodynamicProperties.H" # include "createFields.H" // * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * // Info<< "\nStarting time loop\n" << endl; for (runTime++; !runTime.end(); runTime++) { Info<< "Time = " << runTime.value() << nl << endl; # include "readPISOControls.H" scalar HbyAblend = readScalar(piso.lookup("HbyAblend")); # include "readTimeControls.H" scalar CoNum = max ( mesh.surfaceInterpolation::deltaCoeffs() *mag(phiv)/mesh.magSf() ).value()*runTime.deltaT().value(); Info<< "Max Courant Number = " << CoNum << endl; # include "setDeltaT.H" if you can't find line #include "setDeltaT.H", than you must add it, otherwise, your task is given wrong
__________________
MDPI Fluids (Q2) special issue for OSS software: https://www.mdpi.com/journal/fluids/..._modelling_OSS GitHub: https://github.com/unicfdlab Linkedin: https://linkedin.com/in/matvey-kraposhin-413869163 RG: https://www.researchgate.net/profile/Matvey_Kraposhin |
|
May 7, 2008, 17:55 |
My rhopsonicFoam.c file is sam
|
#6 |
Senior Member
Nishant
Join Date: Mar 2009
Location: Glasgow, UK
Posts: 166
Rep Power: 17 |
My rhopsonicFoam.c file is same as shown above. (and i think this comes with OpenFoam-1.4.1 )But the result obtained is not encouraging. So I suspect there is some other problem.
I kept the initial internal field for U as (0 0 0). Do I need to keep some other initial value for U as this is a transient problem. Can anybody comment? Nishant
__________________
Thanks and regards, Nishant |
|
May 8, 2008, 02:12 |
Is your case internal/external
|
#7 |
Senior Member
Matvey Kraposhin
Join Date: Mar 2009
Location: Moscow, Russian Federation
Posts: 355
Rep Power: 21 |
Is your case internal/external?
What BC's are using for U/p? What is min/max cell volume?
__________________
MDPI Fluids (Q2) special issue for OSS software: https://www.mdpi.com/journal/fluids/..._modelling_OSS GitHub: https://github.com/unicfdlab Linkedin: https://linkedin.com/in/matvey-kraposhin-413869163 RG: https://www.researchgate.net/profile/Matvey_Kraposhin |
|
May 8, 2008, 07:33 |
Its a internal case. flow is i
|
#8 |
Senior Member
Nishant
Join Date: Mar 2009
Location: Glasgow, UK
Posts: 166
Rep Power: 17 |
Its a internal case. flow is inside the rectangular duct.
BCs are p: internal field uniform 1; Inlet- timevaryingfixedvalue outlet - fixedValue 1 U: internalfield (0 0 0) inlet - fixedvalue (0 0 0.001) outlet - zerogradient CheckMesh Reports: Mesh stats points: 169781 edges: 499380 faces: 489600 internal faces: 470400 cells: 160000 boundary patches: 6 point zones: 0 face zones: 0 cell zones: 0 Number of cells of each type: hexahedra: 160000 prisms: 0 wedges: 0 pyramids: 0 tet wedges: 0 tetrahedra: 0 polyhedra: 0 Checking topology... Boundary definition OK. Point usage OK. Upper triangular ordering OK. Topological cell zip-up check OK. Face vertices OK. Face-face connectivity OK. Number of regions: 1 (OK). Checking patch topology for multiply connected surfaces ... Patch Faces Points Surface inlet 1600 1681 ok (not multiply connected) outlet 1600 1681 ok (not multiply connected) side1 4000 4141 ok (not multiply connected) side2 4000 4141 ok (not multiply connected) topWall 4000 4141 ok (not multiply connected) bottomWall 4000 4141 ok (not multiply connected) Checking geometry... Domain bounding box: (0 0 0) (4 4 10) Boundary openness (7.43763e-17 -3.33392e-18 1.76418e-16) OK. Max cell openness = 8.67362e-17 OK. Max aspect ratio = 1 OK. Minumum face area = 0.01. Maximum face area = 0.01. Face area magnitudes OK. Min volume = 0.001. Max volume = 0.001. Total volume = 160. Cell volumes OK. Mesh non-orthogonality Max: 8.53774e-07 average: 0 Non-orthogonality check OK. Face pyramids OK. Max skewness = 8.82696e-14 OK. Min/max edge length = 0.1 0.1 OK. All angles in faces OK. Face flatness (1 = flat, 0 = butterfly) : average = 1 min = 1 All face flatness OK. Mesh OK. End
__________________
Thanks and regards, Nishant |
|
May 8, 2008, 07:59 |
This is a laminar case and no
|
#9 |
Senior Member
Nishant
Join Date: Mar 2009
Location: Glasgow, UK
Posts: 166
Rep Power: 17 |
This is a laminar case and no turbulence model has been used.
Nishant
__________________
Thanks and regards, Nishant |
|
May 8, 2008, 08:17 |
Hi Nishant
Have you tried t
|
#10 |
Senior Member
Niels Gjoel Jacobsen
Join Date: Mar 2009
Location: Copenhagen, Denmark
Posts: 1,900
Rep Power: 37 |
Hi Nishant
Have you tried to see what happens, if you as a first approach skip the timeVarying BC on p and put dp/pn=0. That would give you a nice channel flow, and if that succeeds, then you know your attention should be on your boudnary conditions. I have a hunch which tells me that specifying Dirichlet on pressure in both ends and Dirichlet on the U at the inlet some what over-determines the system. The short story is that you have a pressure gradient which will be able to drive some net flux, but on the other hand you specify the flux by U: uniform (0 0 0.001), which makes it inconsistent. Good luck and best regards - Niels
__________________
Please note that I do not use the Friend-feature, so do not be offended, if I do not accept a request. |
|
May 8, 2008, 10:48 |
try using pressureInletVelocit
|
#11 |
Senior Member
Matvey Kraposhin
Join Date: Mar 2009
Location: Moscow, Russian Federation
Posts: 355
Rep Power: 21 |
try using pressureInletVelocity for U at inlet
or outletInlet for pressure at inlet
__________________
MDPI Fluids (Q2) special issue for OSS software: https://www.mdpi.com/journal/fluids/..._modelling_OSS GitHub: https://github.com/unicfdlab Linkedin: https://linkedin.com/in/matvey-kraposhin-413869163 RG: https://www.researchgate.net/profile/Matvey_Kraposhin |
|
|
|
Similar Threads | ||||
Thread | Thread Starter | Forum | Replies | Last Post |
SonicTurbFoam Vs rhopSonicFoam | vishal | OpenFOAM Running, Solving & CFD | 0 | January 29, 2009 00:58 |
RhopSonicFoam reference | abhishek | OpenFOAM Running, Solving & CFD | 0 | November 5, 2006 22:43 |
Viscous rhopSonicFoam | didomenico | OpenFOAM Running, Solving & CFD | 0 | February 9, 2006 02:29 |
RhopSonicFoam | didomenico | OpenFOAM Running, Solving & CFD | 0 | October 3, 2005 10:53 |
Standing Cylinder | Garvin Forrester | Main CFD Forum | 1 | June 15, 2001 14:28 |