SonicDyMFoam: DynamicMeshDict Solver?
 

Hello all,

I am trying to implement the tutorial mixerVesselAMI2D in sonicDyMFoam (it is normally in pimpleDyMFoam). When I try to run the case, I get the following error:

I do not understand why a solver is required in dynamicMeshDict for this case. mixerVesselAMI2D uses unlike other pimpleDyMFoam cases that use other dynamicFvMeshes; therefore I do not understand why a solver needs to be specified in the compressible but not incompressible moving mesh solver.

Could anyone suggest how I could fix this?

Thanks,

Dan

Greetings Daniel,

I'm feeling poetic... so I'll paraphrase a well known expression:
:D

OK, so the core reason why the "dynamicMeshDict" has to be configured differently is because the solvers themselves are different when handling dynamic meshes:

• pimpleDyMFoam relies on "createDynamicFvMesh.H" for creating a dynamic mesh:
  • https://github.com/OpenFOAM/OpenFOAM...eDyMFoam.C#L49
  • https://github.com/OpenFOAM/OpenFOAM...ynamicFvMesh.H
• sonicDyMFoam relies on a motion solver, coded directly into the main solver: https://github.com/OpenFOAM/OpenFOAM...cDyMFoam.C#L52

The solution... well, the quick fix is to add the missing "solver" entry. A quick search lead me to moveMesh which also relies on the "motionSolver" class: https://github.com/OpenFOAM/OpenFOAM...moveMesh.C#L46
Looking at the tutorials for mesh motion only: https://github.com/OpenFOAM/OpenFOAM...oveDynamicMesh - you'll find these two examples:

• https://github.com/OpenFOAM/OpenFOAM...ynamicMeshDict
• https://github.com/OpenFOAM/OpenFOAM...ynamicMeshDict

Now the real problem is... will sonicDyMFoam perform the way you want it to, since it uses dynamic meshes differently? Unfortunately, that I do not know the answer :(

Best regards,
Bruno

Hello Bruno,

Thanks for the quick and thorough response! I will dig into the code to identify the differences, though at first glance I think my best bet would be to make sonicDyMFoam handle dynamic meshes like pimpleDyMFoam. Any idea why there would be two ways to handle dynamic meshes? I cannot conceive of a link between dynamic mesh handling and compressibility.

Thanks,

Dan

Hi Daniel,

There are various ways of handling dynamic meshes. AFAIK, it can go from a dynamic refinement depending on the evolution of a field, to the full-on AMI.

But when it comes to sonicDyMFoam, I wouldn't be surprised that the real issue is that the code was not upgraded...
... OK, so I went back in time and stopped at OpenFOAM 1.5.x. Back then, it was actually named sonicFoamAutoMotion :D: http://repo.or.cz/w/OpenFOAM-1.5.x.g...amAutoMotion.C
If I understand things correctly, this solver only takes into account motions in the mesh. It does not handle flux corrections, refinements or AMI. Just plain old-simple mesh motions are supported. And as the header on the solver states:
Compressible, but only laminar flow! This seems to be the key reason why it only uses mesh motion...

If you have a look into the tutorial "incompressible/pimpleDyMFoam/movingCone", this one seems to be easily adapted for working with sonicDyMFoam... although it'll require some adjustments in order to throw the fluid into a supersonic laminar flow... although with a symmetry place in the correct place, you can easily do it!

Best regards,
Bruno

Thanks again, Bruno! I will try the other method of displacement - it is not as directly applicable as that used by mixerVessel, but it may still do the job.

Regards,

Dan

Bruno,

Sorry to hijack this thread.... I've managed to get my AMI mesh moving but I'm finding that the model crashes when the valve begins to close. I have been trying to figure out why and have been experimenting. The model, you might remember, is DP driven and I have been trying to use rhoPimpleFoam since the DP drive is quite large, over 1e7 Pascals. I have concluded that I should be using sonicDymFoam, this is why I'm on this thread!

If I am moving the valve walls would this be movingTopology rather than movingMesh? If sonicDyMFoam can only handle movingMesh does this mean I can't implement the valve closure using this numerical Solver?

If this is the case how am I going to get rhoPimpleDyMFoam to solve as the valve nears closure (or begins to crack open which is ACTUALLY what I'm trying to model).

Your opinion would be gratefully received as always.

Best Regards
Andrew

Greetings Andrew,

A few more details about how the mesh is behaving where the valve is opening/closing would be helpful to further understand what's in play here.
In addition, knowing what kind of mesh you are using could be helpful as well, namely if it is purely tetrahedral mesh or polyhedral or mixed cell types.

I vaguely remember reading on this topic here on the forum, where this kind of simulation is rather complicated to perform, specially when the closure means that the mesh will have to be cut or stitched together. Ah, here we go: http://www.cfd-online.com/Forums/ope...tml#post406801 post #9
Well, that post was written before OpenFOAM 2.2 was released, but I think AMI hasn't improved so much yet. The information related to AMI was: http://www.openfoam.org/version2.2.0...conditions.php - I honestly haven't figured out what they mean by "fixedJump" :(

Some time ago there were some tutorials for engineFoam, which one would think that should have valves in it, but I've never looked into it properly.


Now, without a solution in sight, my best bet would be to:

1. Simulate up to the point where the valves have barely not yet closed/opened, which might imply that you need to make the time step as smallest/necessary and as possible near the point of closing/opening.
2. Then use a new case with the mesh in place without/with the aforementioned crack, respectively.
3. Use mapFields to interpolate the results from the last simulation time snapshot to the new mesh.
4. Then happily continue simulating the rest of the moving process, until you hit the same issue of open/close :)

But I've never done this myself, so I have no clue if it will work or not :(


Oh, as for your question about sonicDyMFoam and topology: dynamic mesh solvers are allegedly meant to be able to handle dynamic motion of meshes, including topology changes, as long as the "constant/dynamicMeshDict" provides the correct libraries and settings. Of course the problem is to know which library can handle this kind of thing :(

Best regards,
Bruno

Bruno,

Thanks for the your response! In answer to your questions, my mesh is purely tetrahedral, I used Salome to develop the mesh and it seems pretty good, I found that trying to make a structured hexahedral mesh was REALLY difficult since I was getting oddball cell shapes that neither Salome liked or checkMesh for that matter.

I think that my problem is that rather large pressure differential across the model, 1.6e7 down to 1e5 Pascals. I initially thought that this was producing large velocities that the solver, rhoPimpleDyMFoam, was unable to cope with but looking closer these velocities are around 300 - 750 m/s which I'm pretty sure can be dealt with by rhoPimplDyMFoam.

I have tried different ways of initialising the model and I have found that the model really blows up when I set my initial conditions for inlet and outlet pressure as 1e7 and 1e5 Pascals, which to me being an Engineer, seems pretty obvious. If I set the outlet initial condition to be lets say 10000 Pascals less than the inlet then the model seems to pick up and run but the almost closed condition still blows up.

I have hit upon trying to use rhoSimpleFoam to get a steady state condition that I can then start the moving model off with but I find that the big pressure differential causes problems again. At the moment I have initialised the steady state with NO pressure differential, I have set BOTH inlet and outlet to 1e7 Pascals. Obviously rhoSimpleFoam is ecstatic about this and the model reaches steady state! Unfortunately I'm not sure how to take the steady state model and make it transient. I'm not sure how I would reset the outlet boundary condition pressure to 1e5 Pascals to get the drive working again.

I'm going to try running the model from valve fully open to valve fully closed and see exactly where the failure occurs. I will then repost to the forum.

I'll go and have a look at the links you posted about the sliding interfaces. I might be able to avoid this true sliding interface by accepting a small amount of leakage past the valve, ie having some mesh between the valve body and the walls which I suppose would get around the sliding interface problem. I just wonder how small a gap I can have between the valve and AMI interface before things get out of shape.

Regards

Andrew

Hi Andrew,

A few notes:

• The only tutorial I can remember that works by pressure difference is this "incompressible/pimpleFoam/TJunction".
• Mesh resolution in the right places is highly important. A few examples:
  • http://www.cfd-online.com/Forums/ope...tml#post451688 - post #6
  • Strange Results at Tank Outlet with InterFoam post #17
• One suggestion is that you do a local study of the zone where the flow is becoming constrained, by modelling with a 2D model of one side of a cross-section of the valve. This way you can study the level of mesh refinement you need and see what forces and speeds are in play here.

Best regards,
Bruno

Hi Bruno,

Thanks for your pointers I am just browsing through them at the moment.

While I was browsing I thought I would try a slightly different approach. This approach was taken by one of the OpenCFD trainers at the start of the year when I attended the OpenFoam course in London. This was a basic model with no moving mesh or topology and the inlet pressure was "bled in" from atmospheric up to 1.6e7 Pascals. The model used sonicFoam but I played with it and managed to get it working with pimpleFoam and rhoPimpleFoam so I know these solvers CAN model the final flow regime.

What I have done is moved the mesh using moveDynamicMesh until the valve is fully open then copied the points file from my final time step back into the constant/polyMesh directory then started the simulation with the internal pressure set to 1e5 Pascals and the inlet pressure increasing over time using a table function in the BC file, I have set the rotating Motion to 0 deg/sec to fix the valve in position. I have found that the model crashes when the inlet pressure reaches about 2e5 Pascals which is odd because the geometry is essentially the same as the test case from the start of the year. But I can see that the MESH has changed!!

I have noted that the time steps, which I have allowed to be adjusted, are about 1e-7 seconds and the model crashes quickly, after only a couple of iterations, if I try to set the initial timestep to anything greater than 1e-5 seconds. Could this be a geometry/mesh issue? The original test model was made with a structured Hex mesh whereas this model is a tetrahedral unstructured mesh which I have tried to refine around the AMI interface and around the valve / downstream restriction orifice.

I have used Salome to generate the mesh since I found that sHM couldn't formulate a mesh that I considered usable and the geometry is a little too complex for me to generate a blockMesh input file.

The link below is to a zip of the model, the final step before running the case. I wonder if you could run this and let me know your thoughts?

https://www.dropbox.com/s/bmbx13k4lsg2rng/model.zip

Since I am accepting some leakage past the valve I believe that this ISNT, now, a sliding face problem since I have a continous mesh around both sides of the AMI interface. Would you consider this to be correct thinking?

Hope you can point me in the right direction!

Thanks
Andrew

Hi Bruno,

I thought I would just give a brief update on where I have got to.

I'm still running the model with the FIXED mesh at the moment, ie no moving valve body.

The model still crashes :-( I had noticed that with a 1e5 Pascal outlet pressure boundary condition the solver was beginning to calculate negative pressures which I guess I should have seen, considering the venturi effect across an orifice results in a dip in pressure BELOW the downstream pressure prior to recovering to the downstream pressure!

My current position is that I have refined the mesh quite substantially since I had thought the the flow pattern at the walls looked a little rough and I thought this might be causing localised upsets. I have also increased the outlet pressure BC to 2e5 pascals which seems to remove the dip into the negative pressure.

This final (current) crash seems to show that the rhoMax/rhoMix reporting is little odd. rhoMin seems to have flat lined at the minimum allowed value (0.5) supplied in the fvSolution file. This seems to happen a couple of reporting steps before the crash. up until this point the rhoMin is being calculated at about 0.7-0.8 which is about right for the fluid I am modelling with.

To investigate this I have reduced the allowable Courant number from 0.9 to 0.4 and reduced the time reporting steps to get a closer step resolution in paraFoam.

If I am having physical property problems would I be better using something other than this:

thermoType
{
type hePsiThermo;
mixture pureMixture;
transport sutherland;
thermo hConst;
equationOfState perfectGas;
specie specie;
// energy sensibleInternalEnergy;
energy sensibleEnthalpy;
}

Would I get better control if I were to use perhaps a polynomial correlation, like JANAF or something?, and change from perfect gas?

Not sure how I would implement this though ?

Would appreciate your direction here?

Andrew

Hi Andrew,

I'm glad you've been moving forward with this!
I haven't managed to look into this myself, which is why I didn't give you any feedback :(.

I haven't managed yet to read your posts carefully, but I'll try to look into them and to do some experiments with the case this coming weekend, specially because I'm interested in these kinds of simulation cases.

Best regards,
Bruno

Bruno,

Thanks for your comments..... one thing has occurred to me tonight. I have approached this problem from a couple of different directions, the starting point at 2e5 Pascals and 1e6 Pascals, with the outlet BC pressure set at 2e5 Pascals. The pressure, I see, is falling to around 2e4 Pascals. When I declare rhoMin as 0.5 in fvSolutions what pressure will this refer to? if it is one of the BC pressures then the solver must be trying to EXTRAPOLATE the rho value and getting silly numbers and then fixing at 0.5 which I am suspecting will cause instabilities in the solution.

Do you have any thoughts about this? how can I prevent the solve extrapolating, or coming up with a unmoving value? If I can provide a tabular input for pressure Vs density I think this might solve my problem ??

Regards

Andrew

Hi Bruno,

I wonder if you can answer this one from your experience??

Does OpenFoam consider choked velocity? I'm seeing velocities well in excess of sonic in the downstream (or the orifice) pipework. In my experience choked velocity in pipework is a natural limit at Mach 1. I'm using rhoPimpleDymFoam (also rhoPimpleFoam this morning!) but I'm sure that I have seen the same with sonicFoam.

The model is still crashing with a rhoMin going to the minimum allowed by fvSolution immediately after the last stable time reporting step. :-(

Regards

Andrew

Bruno,

I'm beginning to think I am having mesh problems. I might go back to a basic geometry with no movement and try to get it working. Like I said the OpenCFD tutor produced a model that worked happily with little refinement with sonicFoam, pimpleFoam and rhoPimpleFoam. The mesh was no where near as fine as the mesh I have produced and there were no crashes, even when I ran the model with full inlet pressure (1.6e7) and minimum outlet pressure (1e5).

It's frustrating but I think this is best since I am using Salome for mesh production and the tutor used blockMesh so I need to establish that Salome can create a mesh that will work for this geometry.

I'll keep updating this thread with my progress.

I would still appreciate your guidance on the different thermoPhysicalProperties methods, ie replacement for perfectGas and JANAF or other polynomial/tabular property methods, as I would like to run my final model as close to the "real" thing as I possibly can, I have compositional data from a process simulator that can provide physical properties that differ from those I am using at present.

Regards

Andrew

Hi Andrew,

I'll try to answer now a few of the quickest answers, the others I'll try to do in a few hours from now:
I think that OpenFOAM can only do "consider choked velocity" if:

1. You use a solver that has abilities to simulate near sonic speeds.
2. You use a turbulence model that can encompass similar situations.

That's one of the reasons why I wrote this on post #9:
It's a lot easier to generate a 2D mesh near the valve using blockMesh or snappyHexMesh. And you can even have the dynamic mesh part working!
If you prefer using GUIs, try:

• SwiftBlock - http://openfoamwiki.net/index.php/Contrib/SwiftBlock
• SwiftSnap - http://openfoamwiki.net/index.php/Contrib/SwiftSnap

For more information on snappyHexMesh: http://openfoamwiki.net/index.php/SnappyHexMesh

Tetrahedral meshes are useful for this kind of mesh motion, depending on the dynamic mesh library being used, but should used with a lot of care. Basically because tetrahedral meshes are bad for CFD :(

You can try using polyDualMesh, but it's not a silver bullet: http://openfoamwiki.net/index.php/PolyDualMesh
It essentially is able to create the dual of the tetrahedral mesh, which is a polyhedral mesh. Problem is that polyhedral meshes can be very tricky to use on dynamic meshes...


My experience on this is extremely limited, but my educated guess is that you should primarily use experimental data and/or data you trust. One simple example would be to use the polynomial equations that you can find on thermodynamic-related books.

In the lack of such, use JANAF, since is scientific/engineering data (I think), ready to be used. But you have to be careful with the temperature limitations that these tables.

As for during development, perfect gas should be ... perfect for development of the base case :D

Best regards,
Bruno

Bruno,

Thanks for the FURTHER responses :-) I'll have a look at the SwiftBlock, that looks interesting and might give me a fighting chance of getting a mesh to work properly! As far at 2D is concerned, I am working in 2D because I didn't see the value in doing 3D for this problem, since the model would potentially have >>1e6 cells and I don't want to tie my laptop up for too long in one go!

I'm going to, also, try structured Hex mesh again since unstructured, as you say could also be adding to my problems.

I have avoided using blockmesh for my geometry stating that it is too complex. What is your opinion here am I being to hard on blockMesh? Is it possible to do this geometry using blockMesh given the annulus around the valve etc??

I'll update after my next step!

Regards

Andrew

Hi Andrew,

Well, the idea I was trying to convey is that you can more easily create a similar 2D model using blockMesh, but probably not an accurate one. The objective is to have a proof of concept.
I haven't used SwiftBlock yet, so I don't know what are the limitations, but in theory you should be able to draw each mesh block.

I didn't manage to look into this yesterday, but I'll try to at least look today at the case you shared.

Best regards,
Bruno

Hi Andrew,

I finally managed to look at the model. This reminds me of this post of mine: http://www.cfd-online.com/Forums/ope...tml#post451688 post #6 - if you look at the images on that post, you'll see how bad tetrahedral cells can be for CFD! And mesh-wise, it's very similar to your case!

Attached is an image that clearly indicates that using the tetrahedral cells are very bad news near the walls.

Unfortunately, using polyDualMesh only made things a lot worse.


I've got a question: what on Earth is that ring?
Is the valve actually a sphere inside a flexible-wall tube? But still... it's very confusing, specially since there is mesh inside the "sphere"...

As for the case itself, it does need to have a proper mesh. Tetrahedral mesh is simply not going to cut it, as you can see from the attached image. You could try adding a prismatic boundary layer to the walls and inlet/outlet, but it won't fix everything.

You could try using enGrid, which is able to generate prismatic boundary cells, along with using a tetrahedral mesh inside the domain, but enGrid is a bit tricky to use...


As for mesh motion, this clearly looks like a mesh that needs to collapse cells... otherwise the cells will become very small when the valve continues to advance to the constriction.

Either way, the conclusion is simple:

1. First you need a good mesh for CFD. You might want to start with a simpler valve geometry first, to make it easier to implement with blockMesh.
2. Then you can start worrying about the solver.
3. And only then you can finally worry about mesh motion...

By the way: have a look into the tutorial case "incompressible/pimpleDyMFoam/movingCone". It uses the "wedge" feature of OpenFOAM, which can help you simplify even further your experimental case set-up.

Best regards,
Bruno

Hi Bruno,

Sorry , didn't see your post come in, must look at my settings!

https://dl.dropboxusercontent.com/u/...%20Diagram.jpg

The link above might explain what my geometry is actually trying to achieve, rather than me writing a load of words just now. But the basics are that the valve is a moving ball with a single straight through port. The ball rotates on a shaft from closed to open (and the other way :-) ) All this model is steel. I have simplified the geometry to just show the ball and the "envelope" of the valve body (this is all rigid)

I think that should explain the mesh within the valve.

I'm looking at structured Hex meshing with blockMesh since I am a little suspicious of conversion from an external mesh type to internal OpenFoam type. I just want to rule this out.

I'll keep posting my progress!

Regards

Andrew

Bruno,

I've re-run the model based on blockMesh formulation, rather than Salome, and it crashed again on run away rhoMin, unlike the OpenCFD tutor model. I did notice some dimensional differences with my model and the tutor model so I modified the tutor model to reflect my actual dimensions and the model crashed on run away rhoMin.

Basically in the original tutor model rhoMin dips to about 0.8 and then recovers and then rises over time. The dip and recovery takes about 0.01s when I have my inlet pressure rising from 1e5 to 1.6e7 Pascals in 0.5s. When I ran the modified model the rhoMin value reached 0.7 (limit stipulated in fvSolution) and then stayed there until it crashed.

After thinking this through I modified my limitinf rhoMin from 0.7 to 0.2 to allow some room for manoeuvre. This has allowed the modified model to run to the end of the run without crashing. the dip and recovery reached about 0.42 and took roughly the same length of time.

This poses the question, does rhoPimpleFoam require a recovery period immediately after startup of a model run?

One thing that concerns me is the fact that the crash seems to be connected to the orifice diameter change (the tutor model had a larger orifice diameter) so when I come to modelling the valve moving from closed to open I'm going to have a MUCH smaller orifice to model. IS this going to cause a run away rhoMin crash??

I plan to look into this by chaining the orifice dimension to a MUCH smaller value and running the model again an seeing if the rhoMin dip/recovery is an issue or not.

As always your thoughts would be most welcome!

Best Regards

Andrew

Hi Andrew,

OK, the image does help understand things a lot better.

But this raises a very important detail: that mesh ring should not exist, the one shown in the first attachment. There are two reasons for its non-existence:

1. That mesh outside of the tube is introducing a considerable error to your solution, because it's allowing fluid flow through them, which implies rather high flow rates and there isn't enough mesh resolution for it.
2. The steep mesh resolution changes made by that ring will distort even more the flow of the fluid.

Technically, what you should have is something like this:

1. 3 mesh sections, separated by moving baffles.
2. The middle section is able to rotate and along with it will appear a baffle on each side, which will constrain the flow of the fluid. In other words, that ring becomes a simple surface without thickness.

The simplest valve example is shown in the second attachment. You should use this kind of model first, so that you can more easily assess what is happening here. And it's a lot easier to do with just blockMesh.

In either models, there is a very important limitation: As soon as the valve is fully closed, your case becomes a multi-region case. In other words, the solver won't be able to properly handle the 2 or 3 mesh regions, unless it's coded to do so.

So, if I'm right, there are a few options I can see, when the valve is closed:

1. Either you simulate each section individually, after mapping the data from the last time snapshot of when it was just one region and vice-versa.
2. Or you'll need to implement a solver that can handle multiple regions, as demonstrated by the "chtMultiRegion*Foam" solvers.

In conclusion, my suggestion to approach this is as follows:

1. Remove the valve completely and first concern yourself with having a working flow in the pipe, using a good uniform mesh!
2. Play with the mesh refinement (globally and locally), to see what issues to expect as the mesh gradually becomes more refined.
3. Once you've figured this out, add in the simple valve example, where one of the walls simply starts to invade the pipe, until it nearly closes the pipe. This is where knowing the influence of the mesh resolution comes in handy.
4. After this, there is the concept of having 2 baffles invading the domain, instead of a big wall. This helps investigate the effect of the baffles on the flow. The tutorial "heatTransfer/buoyantSimpleFoam/circuitBoardCooling" gives a good example on this topic.
5. Finally, with all of the information you've learned, you can now merge the topics of moving/rotating mesh and the introduction of baffles... although perhaps the baffles aren't necessary....

Best regards,
Bruno

Bruno,

Thanks for taking a look at the diagram and giving me your time again! I understand, I think, where the limitation comes in with my rotating model. I hadn't really understood the mesh issue. I think that the encroaching wall option would do the job admirably. I just have to understand how to do this!

I'm still running into the run-away rhoMin crash issue. From what you have just written I'm beginning to think that the mesh resolution is the issue. Should I refine the WHOLE mesh or is it ok to refine the mesh in a discrete region around the orifice? (I'm just fiddling with the orifice diameter at the moment to see when the crash stops (I managed to get it to work with 2mm but, like I said earlier the rhoMin drops to an incredibly low value)

I have implemented janaf thermodynamics which seems to bring the temperatures (early on) in line with what I would expect from such a large pressure drop. Obviously, though, this isn't saving the model from the rhoMin crash. :-(

I shall re-run the model with an increased mesh resolution all over to see if this helps the model stability.... I'll then play with discrete regions around the orifice later.

Thanks again!

Andrew

Bruno,

In your experience can you have to fine a mesh? I've been running this model with a couple of different mesh resolutions and I seem to be seeing that the model becomes less stable (and crashes really quickly) when I reduce the cell size.

Is this something to be expected?

If I'm going to model right down to valve just cracked should I be setting the cell size to have the same linear dimension as the initial opening? This sounds like I would have trouble running a single model from shut to fully open is the cell dimension can be too small for a particular model!

Regards

Andrew

Bruno,

I'm having real problems with the physical properties calculations and I'm beginning to think that it is perhaps down to the turbulence modelling. I'm using RAS (k-e) at the moment but the model I am running at the moment has a 2mm diameter orifice with a large pressure drop across it. When I watch the animation of the run (up to the point it crashes) I see that the flows are really unstable and highly turbulent with lots of back flow regions.

Would LES or perhaps changing the RAS subset from k-e help this issue. I think with such large turbulence and instability the physical properties are suffering which is causing a downward spiral leading to a crash. I don't think refining the mesh any more than I have is going to help. I have got to the point where the y-direction cell dimension is 1/3 the orifice diameter which I presume should be plenty fine enough (that's about .6mm)!

I'm going to have a look at the effect of this, I'll perhaps look at the backwardStep tutorials first and try to drive them to destruction to see how they break :-)

Regards

Andrew

Bruno,

Just out of interest when I am talking about temperature and pressure with OpenFOAM am I supposed to be talking Absolute, Gauge, Static, Dynamic or Stagnation? Obviously this will have a significant bearing on all my problems!

Regards

Andrew

Bruno,

I think I might have found my problem. My outlet Pressure BC might have been incorrect. I am running the model (I haven't changed the turbulence modelling) just now and it "seems" stable.

My outlet pressure BC is a waveTransmissive and I had set my infinite pressure to 1e5 Pascals but the infinite distance was 1 metre. With the large flow rates involved in my model the pressure losses between the orifice outlet and the infinite location were big enough to cause local static pressures to fall to perhaps a few thousand pascals. applying this pressure in my property package application resulted in densities > 0.1 kg/m3.

I think I should have deduced this long before now :-( Anyway I have set my infinite pressure to 3e5 and the location to .1m which should give the model half a chance of solving correctly.... It seems to be doing well just now as the density is fluctuating around a value that actually makes sense, as a result of this the temperature is holding up too! although I am seeing quite a bit of compressive heating resulting in the temperature rising upstream of the orifice! However if the model runs to completion then I will look at how to deal with this little nugget later!

I'll put an update in once I know which way this model is going to turn!

Regards

Andrew

Hmm, still got a crash but I think I'm on the right path with the infinite pressure and location I'm going to make a few changes over the weekend to see if I can get it to converge.

I do also think there may be some mileage in looking at LES as the density fluctuates quite sharply throughout the computation, indicated by rhoMin, which would suggest a lot of turbulence and disturbance which may be handled better by LES rather than RAS.

Your comments would obviously be most welcome!

Regards

Andrew

Hi Andrew,

For better or for worse, these weeks are going to be terribly busy for me. If that wasn't enough, my experience in most of the questions you've asked in these past posts are beyond me and others would require me to run some tests to try and diagnose myself.

Therefore, I'll at least try to answer what I can see that I might be able to suggest:

If I understand you correctly, you only have 3 cells along Y for representing the orifice?
That seems to me to be extremely too few cells, since this way you're implying that whatever goes through those cells is merely cosmetic. I say this in the sense that it seems to imply that it's not the flow that passes through the orifice that is important, it's only the pressure difference imposed by it that matters.
Having said this, I have no idea of how many cells should be used for representing that orifice.


Mmm... why do I have the feeling that you're getting closer, but that you haven't managed to figure out what the real values should actually be or at least what are the physical characteristics in play here.
What I mean by this is that even though you've changed from 1.0m to 0.1m, it seems that you're only trying to solve the problem with a hammer, instead of finding out what the correct values should be.

I'm not able to suggest much here, but "compressible nozzle flow" comes to mind... and it's one of those topics that are explained in books about Fluid Mechanics, such as "Fluid Mechanics" by Frank White.


Good question! Honestly it all depends on the solver being used and how it solves the pressure equations. There is a great function object named "pressureTools" in OpenFOAM 2.2 that can help figure out which pressure values are actually in play. For more information:

• http://foam.sourceforge.net/docs/cpp/a01705.html
• http://www.cfd-online.com/Forums/ope...s-2-2-0-a.html

A few more loose ideas:

1. By the way, for more information about the wave transmissive boundary condition: http://foam.sourceforge.net/docs/cpp...6.html#details - although it looks pretty cryptic to me :(
2. As for LES vs RAS: it depends on the kind of vortices that are likely to appear. Some times the tell-tale sign is when the RAS modelling is giving results that are too smooth, in the sense that it almost feels that the fluid is behaving too perfectly.
   But still, more important than the turbulence model, you should consider in which sonic zone is your flow, because you can easily have a lousy simulation simply because you wanted to do a subsonic simulation when the flow is supersonic... (why do I have the feeling I already wrote about this on this thread...)
3. Honestly, nothing beats having experimental data for comparison. If possible, you should have experimental results to compare your simulation with, even if it's only a convergent-divergent nozzle simulation. Because without it, the closest is likely to be DNS (http://www.openfoam.com/features/turbulence.php), which is a considerably heavy simulation model, but at least it should be the most accurate simulation you can get... at least in theory :rolleyes:

OK, I think I'm all out of ideas+suggestions for this week :(. Good luck!

Best regards,
Bruno

Bruno,

Ha ha.... I feel like you're egging me on :-)

Anyway the important result from this whole modelling experience is to show that when the valve opens with this huge pressure behind it the restriction orifice doesn't produce a normal shock but "bleeds in" and produces oblique shocks which won't destroy the pipework downstream!

By inspection this is pretty obvious, since the valve takes 2 seconds to reach fully open, but I have committed to show this using CFD.

It does feel like I'm using a hammer to solve my predicament but what I want to achieve is a solution I can then understand and understand why and how I got there. In reality the infinite pressure location may actually be much further than 1 metre away from my domain !!

I'll take a look at the links you sent me, thanks. Hopefully the model will solve and I'll have a way forward by the end of the weekend ;-)

Best Regards and many thanks for your response!

Andrew

Bruno,

I have made a bit of progress since last week, but I have hit a new snag too.

I have managed to get the model to run from 0 pressure drop right up to full pressure drop. I have taken the original OpenCFD tutor model, which was a sonicFoam based model, and I have re-run the model with modifications since the model was made with an old openFoam version, I think it was 2.1 and there were a couple of changes between that version and 2.2.x that caused the model to stall.... I managed to get this working.

After the initial run I changed ONLY the orifice dimension and the mesh resolution. I have run a case at 20mm diameter and 2 mm diameter, both of which run right up to 1.6e7 Pascals inlet pressure. I am running another model just now at 1mm but this one needs a little attention, probably a tighter mesh dimension.

Anyway I have notice between the to larger orifice diameters that the downstream velocity INCREASES with decreasing orifice diameter. This isn't my experience of restriction orifices. A reduction in orifice diameter results in a reduced throughput. Thus the downstream velocity should fall!

I am wondering if my original model hypothesis is correct?

Happy but in a worried sort of way :-/

Andrew

Hi Andrew,

Nice! That's a great step in the right direction!

Mmm... perhaps you jumped too much when going from 20 to 2mm? Because 10x smaller orifice might either equate to 10x more speed or 100x more speed... and not having the correct mesh resolution can lead to... a very colourful flow :), but completely surrealistic :(.

Well, from what you wrote some time ago, the speed does increase but only up to a certain limit value.

This is also why I mentioned the convergent-divergent nozzle, because the flow should be similar and for which you will have a theoretical approximation of what the actual solution should be! Here's an example: http://en.wikipedia.org/wiki/De_Laval_nozzle


My guess is that if you continue to advance without first looking at the documented convergent-divergent nozzle and simulate such a case, then you should do something like this:

1. 20mm orifice:
   1. Normal mesh.
   2. 2x more resolution.
   3. 4x more resolution.
   4. Compare results. When the changes are too small to distinguish, pick the coarser mesh (since it's faster).
2. 15mm orifice:
   1. Normal mesh (based on the previous case).
   2. 2x more resolution.
   3. 4x more resolution.
   4. Compare results...
3. 10mm orifice...
4. 5mm orifice...
5. 4mm orifice...
6. 3mm orifice...
7. 2mm orifice...
8. 1mm orifice...

Best regards,
Bruno

Hi Bruno,

Sorry for the delay in responding, I've been away on holiday. I will follow up on the steps you suggested to define the optimum mesh refinement.... I did get an openfoam crash on the 1mm orifice run and I haven't been able to get it to run yet but I suspect I will find my answer by following your recommended steps.

I think I might not have been very clear when I was describing the flow regime going back a couple of weeks/months (?). What I see happening with my valve/orifice model is that as the valve cracks open the throughput (mass flow) will increase with valve travel until the opening created by the valve is equal (in cross section) to the opening created by the orifice. At this point the throughput will have reached it's maximum. [When the orifice diameter is reduced the throughput SHOULD reduce since the orifice throughput is generally proportional to orifice diameter and pressure differential (up to the critical pressure ratio, ie choked]

The velocity in this model should be limited by sonic velocity at the orifice throat, however when I read the article you linked in your message about the convergent/divergent nozzle I see that the velocity downstream of the throat will pass sonic. Looking at the model geometry it's possible that for the very small orifice diameters the flow lines would form a "soft" con/div nozzle shape facilitating the higher than sonic velocities. The larger orifice diameters cause the expanding flowlines to impact the pipe wall which I suppose upsets this downstream sonic velocity growth (??). Could this be the reason why the model crashes at the small diameters? ie the jet is free rather than confined by the pipe? It may be that the massflow is decreasing but the downstream density is falling which would allow the velocity to increase. Doesn't really work in my mind though since with falling downstream pressure should come falling downstream temperature which will cause the density to stabilise or rise slightly.

Too many things going on in my head :-)

I'll let you know how your steps work though..... might have to look at a dedicated CFD box though, using half my laptop cores is becoming a bit hard to take as the mesh resolution increases!

Best Regards

Andrew

Hi Andrew,

After re-reading your post, only 2 things come to mind:

1. There is at least one boundary condition in OpenFOAM for "freestream". You can find tutorials that use this by running:
   
   Code:

   ---

   grep -R -i -e "freestream" $FOAM_TUTORIALS/*

   ---

2. I think the problem with the smaller orifice was the insufficient mesh resolution inside the orifice itself.

Best regards,
Bruno

Hi Bruno,

Thanks for continuing to think about me :-)

I have been trying to understand why the model continues to crash and I have been doing some "studying" and I'm beginning to think that the temperature change across the downstream oblique shocks is something to do with it. When the model crashes and I run paraFoam the temperatures I see downstream of the orifice are extreme to say the least. This is not my experience of restriction orifices. Treating the orifice as an isenthalpic pressure loss gives a temperature drop from 333K to about 260K. The model which is using the compressible shock temperature calculation (I presume) returns a temperature loss of 333K to 46K!!

I have looked at this shock calculation and the temperature ratio is proportional to the pressure ratio and a factor which is calculated by gamma (Cp/Cv). In my models I have used 1.3 for gamma which, when you do the calculation, returns a downstream temperature of about 60K. I'm currently running the model with a fictitious gamma of 1.02 which should return a downstream temperature of about 265K. I'm wondering is this will give me some stability??

With the pressure drop, gas compressibility change, and the associated downstream mach number I can't see that my model can be anything but compressible. This returns me to the question I posed a couple of weeks ago about choked velocity in ducts. I don't know enough about fluid dynamics to know WHY the choking occurs and how when you have a mass flow through this device the downstream velocity should remain at or below Mach 1. This is stretching my understanding of fluid mechanics and dynamics a little :-/

If the flow in a duct CANNOT under any circumstances be greater than Mach 1 does this not mean that the upstream conditions would propagate into the downstream piping in a jet long enough to enable the dissipation of the momentum into the downstream conditions at less than Mach 1 ?

Trawling the net isn't really giving me enough detailed information of choked flow in ducts.

I read the article you linked about flow in con/div nozzles and I can see the arguments but wouldn't this mean that having a nozzle installed in a pipe you could accelerate the velocity in the nozzle to supersonic conditions which would propagate into the downstream pipe (or duct) this would then mean that choke velocity in a duct would be defeated?

I'm beginning to think I am out thinking myself here!

I will look to increase the resolution a bit more, but my laptop is working hard all the time so completion of a run is taking more and more time!! Can I use refineMesh and JUST refine the mesh from the inlet of the orifice to the outlet of the model? how would an interface between the refined and unrefined mesh work?

Would appreciate your thoughts here.

Andrew

Hi Andrew,

I was looking at a tutorial just now, for another forum thread, regarding refineMesh. And I was using the tutorial "multiphase/cavitatingFoam/ras/throttle" as an example to try out some stuff with said refineMesh.

And what I saw was basically what you're looking for, at least from the point of view of the orifice in a pipe.
The base mesh on the orifice was of 3 cells wide and after refinement it is 24 cells!

This is also a very good example of the kind of refinements you should be looking for.

As for boundary conditions, this tutorial uses a decompression of 300 bar to 100 bar, instead of setting the inlet or outlet speed. The tutorial itself is for the mixture of two fluids, but still, the mesh and overall boundary conditions might come in handy for you.

Also on the topic of boundary conditions, the "waveTransmissive" boundary condition for the outlet might be the best option, as demonstrated in the tutorial "compressible/sonicFoam/ras/prism". But then again, perhaps it's overkill?

As for the choking effect, here's what Wikipedia has on this:

• http://en.wikipedia.org/wiki/Choked_flow
• http://en.wikipedia.org/wiki/Compressible_flow

In a sense, the detail isn't as much of the flow being inside a pipe, it's the amount of turbulence being generated after the orifice that actually constrains the maximum flow speed.


Last but not least, if you feel insecure with these CFD and fluid flow concepts, perhaps it would be a good choice to either:

• Pick a good book on fluid flow and/or CFD and study it.
• And/or resort to request a small support contract from any company that uses OpenFOAM (http://openfoamwiki.net - look for "8.3 Commercial Companies") and/or to use the http://www.cfd-online.com/Forums/cfd-freelancers/ forum, in order to give you a push in the right direction.

Best regards,
Bruno