[ADGlassby]

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

[wyldckat]

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

[ADGlassby]

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

[ADGlassby]

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

[ADGlassby]

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

[ADGlassby]

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

[ADGlassby]

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

[ADGlassby]

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

[wyldckat]

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:

Originally Posted by ADGlassby

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)!

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.

Originally Posted by ADGlassby

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....

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.

Originally Posted by ADGlassby

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!

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

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

Best regards,
Bruno

[ADGlassby]

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

[ADGlassby]

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

[wyldckat]

Hi Andrew,

Originally Posted by ADGlassby

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.

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

Originally Posted by ADGlassby

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.

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 .

Originally Posted by ADGlassby

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!

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

[ADGlassby]

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

[wyldckat]

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:
   

   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

[ADGlassby]

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

[wyldckat]

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