Pressurized tank - simple case (interMixingFoam)
 

Hello all,


I am at my wit's end - trying to simulate a simple pressurized tank simulation but it's not working. I think there's some very simple mistake involved.

1) Simple vertical tank with open top (a 10 m deep hole for example)
2) tank top opens to atmospheric pressure
3) There are air, LNG and LOX regions in the tank:
3)a - high pressure air pocket (~60 psi) on the bottom (between 0 to 3 m)
3)b - LNG region above it (between 3 to 6 m)
3)c - LOX region above the LNG (between 6 to 9m)
3)d - atmospheric pressure air above the LOX region (9 to 10m i.e top of the tank)
4) gravity is taken into account
5) interMixingFoam solver is used

Naturally I would expect that the high pressure air would drive the LOX and LNG upward but the simulation shows that the initial setup stays in place i.e. absolutely no movement and/or pressure change is happening.

The case is based on the damBreak tutorial - although that one did not take pressure into account.

Can someone explain me (like I'm 5) how to set up a case like this?

Thanks - I have spent so much time trying to model this, it's getting ridiculous. It feels like I tried every combination of p, p_rgh, etc.

I will attached the case once I figure out how to do it...

Andy


Edit: I added the ZIP file for the case. It also contains the Python script to generate the entire case from scratch.


Any help is appreciated !!!

Hi

I looked at your files and couldnt understand the issue.

Then I went back and modified the dambreak tutorial interMixingFoam to have the liquids at the same height.

Interestingly at t 0.5 nothing happens!, it is until t 0.6 that some collapse starts.



Perhaps this gives you a clue?

A couple of quick observations. First your LNG density (70.8kg/m3) seems rather low ... I would expect something around 500. That's clearly not your main problem though.

The other observation is that you are not setting up a realistic initial pressure field. If the fluid layers were in equilibrium (and I know that you want to model a rollover type event from a hi p gas burp, but bear with me), then you'd see a hydrostatic pressure decrease in p with height, and step changes in prgh at each fluid layer.

You have initialised p with 1e7 in the air layer and 1010 in the LOX, LNG and upper air layers, with a boundary condition of 101325 at the top. prgh is initialised with a constant value of 101325. Now, the internal value of p is calculated from prgh in createFields (https://cpp.openfoam.org/v8/solvers_..._source.html):
so your initial p-variation is ignored. My advice is to calculate the prgh values in the different layers, using prgh = p + rho*9.81*h (you have implicitly set href =0; might be easier setting it to 9, but up to you) and set these in setFields. Your initial pressure field will then be more physical, and might give the solver an easier time.

Tobermory - thank you for the insights;


The LNG density is not realistic, I think I was using a different material.

So if I understand your approach, no need to define "p" anywhere at all -not in setFieldsDict or in the 0/ folder but define p_rgh instead?

Make p_rgh realistic (around 60psi) on the bottom air volume and atmospheric on the top "atmosphere" region?


Define p_rgh BOTH in 0/ folder and in setFieldsDict?


I hope I got this right - if not please spell it out.


Thanks
Andy

You need to define boundary conditions for p (and therefore include a 0/p file), but this solver is not reading the internal field settings for p from 0/p; instead, it uses the p_rgh and alpha fields to calculate p.

Turning to p_rgh - yes, set up the 0/p_rgh file first with sensible boundary conditions. fixedFlux pressure works well on the walls; fixedValue of 101325 makes sense for the top (atmospheric) boundary.

Now you need to define the variation in p_rgh through the internal field. With layers of constant density fluid like yours, it jumps in value at each interface, but is constant in each layer. So from y=10 (top BC) down to just above y=9 (top of LNG layer), p_rgh is fixed at 101325. At the interface, whilst the pressure is continuous across the interface, there is a jump in p_rgh of (rho_y- - rho_y+)*9.81*h, where h is the height of the interface (strictly the height above the reference, href, but you have assumed href=0), and rho_y- and rho_y+ are the densities on the lower and upper side of the interface. So calculate the p_rgh values in each layer and use setFields to set these values correctly. That accounts for the hydrostatic variation in pressure. Now add an offset to p_rgh in the bottom air level to generate the driving over-pressure.

Note: your initial p field, in 0/p, will not be correct if you view it in paraview ... but to set that, you need to either use codeStream to set a linear variation with height in each layer, or use something like swak4Foam. Never mind - it won't affect you solution ... just your initial t=0 picture.

Does that make sense? Good luck, and let us know how you get on.

Tobermory, your comments have been really helpful, thank you.

The plot thickens.... - the initial case I started this thread with has changed a bit (I was trying to use a simpler case but it turns out it is better to address it as is).

So the case I am tasked with is a pressurized tank which is set up as such: pressurized air on the top, liquid under it and a vent/valve on the bottom of the tank which opens at t=0.

See attached diagram. The case is a 90-degree "slice" of a round tank setup. I used symmetryPlanes for simplification.

I *think* I set up the p_rgh values right but when checking the simulation at 0.01s (10 msec after valve opens) the pressures do not look right - see attached screenshot. I would expect to see a high-pressure (~200 psi) air pocket on the top still - but it shows much lower values.
The top of the top tank (TOP_tank_dry) whould be 200 psi, then the pressuirzed water under it in TOP_tank_wet some more with rgh added.

Between the two tanks is an atmospheric gap where spillage can occur. Then on the bottom is an open tank with p_rgh set accordingly due to the water column in it.


The case should simulate how the two liquids mix over time according to different ullage pressures - so this is just a template.



The screenshot from ParaView shows the pressure at the top air pocket (dark blue) as 86581 Pa which is way lower than atmospheric or even the prescribed 200 psi would be. I don't understand what went wrong. I think I have a mistake at the pressure setups but I can't see where.


I did not make a 0/p file as it seems to be calculated anyhow - would that be the issue?



The setFieldsDict:
and the 0/p_rgh:
I even split the tank volumes to different regions ( *_wet vs. *_dry) so that I can better define the high vs. low pressure areas - not sure if that helps.

Can you please look into this case? I have attached the Python script to generate it as well as the whole case folder as a ZIP file.



Thank you much
Andy

Hey,

probably the problem is the fact that you use interMixingFoam. This solver is based on incompressible assumptions and hence, will not take compression effects into account. The pressure should be redistributed completely (and non expected/non-physical) though the whole domain. Furthermore, the user guide states:


So probably, you are looking for compressibleMultiphaseInterFoam.
https://www.openfoam.com/documentati...andard-solvers

I think introducing compressibility at an early stage of the case setup will complicate unnecessarily the understanding.
There are a few important things to build before modelling how density will change with pressure, (which by the way is only worth doing if Mach number is > 0.3)

Your statement reminds me to my old boss. Sorry, I cannot agree here as the equations and the phenomena one can capture will be different. The case setup has higher pressurized air at the bottom which can only be modeled if a relation between pressure and density exists.

But of course you can still try to simulate and try to solve thi case by using interMixingFoam. It will simply not work.

By thw way, if you try to model a tank expansion of 200 Pa difference to the atmosphere can also not be modeled using pimple Foam. It's simply the equation.

Hi Tobi


is not about deciding which model will work or not.


It is simply about adding complexity one step at a time. Im sure more complex models will represent more accurately the reality, but the price of handling more variables at once with little experience is high.

Thank you!



https://c.tenor.com/0RremLvtrSIAAAAC...impson-doh.gif
No wonder that blasted thing didn't work! :eek:

I spent a lot of time on the complex case and I could never figure out why pressure did not make a difference.....of course!!!!


So now I'm building a much simpler model with a high pressure "burp" under a water column using compressibleMultiPhaseInterFoam - so far it appears that the water column is moving up, so it's a good start. Just started the run so we'll see.



Thanks again


Andy

Okay, accepted but you cannot simulate buoyancy without a compressible solver or at least the Boussinesq Approximation. Here, you cannot use interMixingFoam for different pressure loaded fluids. It's simply not possible :).

And as far as I got it, this wants to be considered and does not work until now. Hence, you need to change the solver.

Your welcome Andi. Good luck.

One note: This is exactly what is wrong here. Its not deciding if you choose different turbulence models to capture vortex separation more or less accurately, its really the base phenomenon one is interested in which - in fact - is related to the equations we are using. Again, as I already mentioned, the bottom has a higher pressure (or at least is initialized with a higher pressure). Using an incompressible assumption will not give you a pressure wave (to lower pressurized areas) as the main terms are missing in the equations.

And this statement is already proven by Andy :)
I just want to clarify your doubts and I agree that one should start with less complex solvers/physics. However, one cannot (even for simple problems) start to investigate into some topic while neglecting necessary phenomenon. One cannot calculate a solidification while not taken into account the temperature or density change (well okay - there are ways to overcome this but its not physical correct).

Im glad it worked out. I just had a different (maybe more conservative approach), where from my experience, initial conditions are key. But is great to have so many solvers in OF to try out.



Im in the process of writing a setFields function to initialize the pressure field, in case you guys are interested.



Cheers!

Nice catch Tobi - I hadn't thought to question the solver. The underlying lesson from the above, and mirroring your last comment frantov, is that it always pays to think very carefully about the physics of the problem before starting to try amd model it. The "simplest" seeming cases can sometimes prove the most difficult!

Agreed totally, frantov, that cases in my experience generally run more smoothly if the inital conditions are set up correctly/physically. It has always bugged me that the initial conditions in the dam break tutorial are non-physical (the pressure field is incorrect) - this gets fixed, of course, in the first time step, but it bugs me that the starting conditions are non-physical. That probably tricks others in thinking that they can ignore the initial pressure field specification in their simulations.