|
[Sponsors] |
Inlet and outlet patches with forced direction (and sign) |
|
LinkBack | Thread Tools | Search this Thread | Display Modes |
August 5, 2023, 06:38 |
Inlet and outlet patches with forced direction (and sign)
|
#1 |
New Member
Carl Kohrs
Join Date: Sep 2019
Posts: 22
Rep Power: 7 |
I have a large domain axi-symmetrical (100 m x 100 m) atmospheric simulation with buoyant flow. I need boundary conditions on the inlet (side) and outlet (top) for which both the direction (normal to the patches, -x and +y respectively) and sign (only inlet -x on inlet, only outlet +y on outlet) are specified.
I have tried combinations of inletOutlet and outletInlet, pressureInletVelocity, pressureNormalInletOutletVelocity and pressureDirectedInletVelocity but I keep getting reverse flow in both cases. Can this be done without programming a custom BC? Because this is atmospheric with a large domain (and based on other people's work in Fluent) reverse flow is not expected. |
|
August 7, 2023, 07:26 |
|
#2 |
Senior Member
Join Date: Dec 2021
Posts: 235
Rep Power: 5 |
Hey
Large domains and proper open boundary conditions for natural convection seems to be one of the recurrent issues with OpenFOAM. I have been looking for a correct setup for quite some time, and I am not the only one take a look at this thread, maybe it will give you some hints and you will figure it out (I have not yet) : Common setup for p_rgh in complete open domains Hopefully we will get a solution soon! |
|
August 12, 2023, 14:35 |
|
#3 |
New Member
Carl Kohrs
Join Date: Sep 2019
Posts: 22
Rep Power: 7 |
Thank you. That thread helped me a while ago to get to my current solution, which has steady and normal-looking behaviour (apart from my mentioned problem). If you are interested I can share my settings, maybe it helps you.
For my current problem: I got half a solution by reducing the domain size (both height and width), which solves the back-flow problem, but I am not fully happy with this work-around and will probably revisit it at some point. |
|
August 16, 2023, 03:56 |
|
#4 | ||
Senior Member
Join Date: Dec 2021
Posts: 235
Rep Power: 5 |
Quote:
If you can share your case it will definitely help. Quote:
Huh this is weird, this is the opposite of the usual recommendations about setting the boundaries far from the region of interest, but hey, if it works |
|||
August 24, 2023, 03:32 |
|
#5 |
New Member
Carl Kohrs
Join Date: Sep 2019
Posts: 22
Rep Power: 7 |
We can discuss what I can share, will DM you.
About the reduced domain size: I'm almost sure there is some issue with the BCs causing this and my "remedy" is just ignoring the issue while causing some unknown inaccuracies. So in the long run I will need a proper solution. |
|
August 24, 2023, 15:12 |
|
#6 |
New Member
Carl Kohrs
Join Date: Sep 2019
Posts: 22
Rep Power: 7 |
Oh never mind. The cause of my issues seem to be that all the fluid in my domain starts dropping as soon as the simulation starts (with thermal and cloud effects removed). Experiments so far show that it is dependent of molar mass (drops less with lower molar mass, but doesn't rise), and is independent of nHydrostaticCorrectors and vapour content (I'm working with humid atmospheric air).
Any suggestions? |
|
August 25, 2023, 11:13 |
|
#7 |
Senior Member
Join Date: Dec 2021
Posts: 235
Rep Power: 5 |
I remember having better stability with incompressiblePerfectGas. The fluid starting to "fall" during the first iterations are probably due to the density and pressure variations right after initialisation. If there are zeroGradient conditions, it might not help much to correct this behavior, not sure about this
Did you try with other equations of state? |
|
August 26, 2023, 10:43 |
|
#8 |
New Member
Carl Kohrs
Join Date: Sep 2019
Posts: 22
Rep Power: 7 |
It appears that this was due to my p_rgh boundary conditions; setting everything solid to fixedFluxPressure solves the falling problem (I was able to see this by writing relatively small timesteps, the pressures near my solid components started dropping as soon as time began and remain there, this was the clue that they were the issue rather than my inlet or outlet or indeed the equation of state). Combined with totalPressure on the outlet (top), I'm getting seemingly good behaviour there (the flow is still in reverse, like my image above, but it flow buoyant flow at least exits the domain instead of simply recirculating (a problem I've had in the past). Nothing I'm doing is, however, giving the expected inlet (side) behaviour.
I saw on one of your other posts that you were struggling to get steady-state solution, taking 5000 iterations to solve. What has worked for me is to solve with Euler until I have nearly steady flow and then changing to localEuler (this has worked better than steadyState). |
|
August 28, 2023, 02:51 |
|
#9 |
New Member
Carl Kohrs
Join Date: Sep 2019
Posts: 22
Rep Power: 7 |
So turns out specifying an hRef is very important, although I don't understand the function of hRef. I did not have one before. Now, when I set it to the elevation of the top of my domain, I get the flow exiting correctly at the top and no falling behaviour. Nearly perfect now with just some small steady movement to figure out (when I neglect the heat transfer effects).
|
|
August 28, 2023, 03:46 |
|
#10 | ||
Senior Member
Join Date: Dec 2021
Posts: 235
Rep Power: 5 |
Hey
It sounds like you are making good progress! Quote:
Yep, I often end up doing that, but it is rather tedious especially in CHT cases with solids taking a long time to reach a steady state (I tried to set their schemes to steadyState while the fluid would remain with Euler but it was really unstable, and decreasing their specific heat so they would heat up faster was also shaky ). Quote:
Aah, I could not figure out how this file would affect the simulation. I will have to try your way. How do you think it would behave with only vertical patches? Should we set hRef to the top of the domain anyway? Could you post some pictures of your flow with a different hRef if you have some time? |
|||
August 28, 2023, 04:42 |
|
#11 | ||
New Member
Carl Kohrs
Join Date: Sep 2019
Posts: 22
Rep Power: 7 |
Quote:
Quote:
|
|||
August 29, 2023, 11:08 |
|
#12 | |
Senior Member
Join Date: Dec 2021
Posts: 235
Rep Power: 5 |
Quote:
My tests were run with a maxCo = 5 in the fvSolution.PIMPLE dictionary so I expect you can ramp it up to 10 or maybe 20 depending on your case. I am not sure how to set up relaxation factors with localEuler though: do we need to relax UFinal, pFinal etc or just U, p etc? |
||
August 29, 2023, 14:45 |
|
#13 | ||
New Member
Carl Kohrs
Join Date: Sep 2019
Posts: 22
Rep Power: 7 |
Quote:
Quote:
You make me doubt where to specify the maxCo. It can be specified in fvSolution or in controlDict... So which one is the governing one. About the pictures: I ran the simulations but cfd-online won't allow me to upload them. Will try again at some point. |
|||
August 30, 2023, 04:50 |
|
#14 | |||
Senior Member
Join Date: Dec 2021
Posts: 235
Rep Power: 5 |
Quote:
I usually have a similar setup. Quote:
What do you mean by "p and p_rgh are not split"? Quote:
That is my understanding as well about localEuler, it speeds up a transient simulation by allowing each cell to use the biggest timestep possible, so you lose the time accurate evolution of your system, but the final state is reached faster. I am pretty sure the maxCo for localEuler is the one defined in fvSolution.PIMPLE. I did several tests where I increased it and the simulation eventually crashed. But it ran fine if I changed the maxCo in controlDict. There are also more settings besides maxCo such as damping and sweep coefficients but they are a bit mysterious Besides this weird inverted pressure field at the initialization, I am still satisfied with the hydrostatic initialization, localEuler and prghTotalHydrostaticPressure. I was previously reluctant to use localEuler solely because I thought natural convection should be achievable by a steady state simulation, but I don't think there are many other options at the moment! |
||||
August 30, 2023, 09:28 |
|
#15 | |||
New Member
Carl Kohrs
Join Date: Sep 2019
Posts: 22
Rep Power: 7 |
Quote:
Quote:
Quote:
Probably a silly question but I only ask due to personal experience Is your g in the right direction. |
||||
September 7, 2023, 08:00 |
|
#16 | ||
Senior Member
Join Date: Dec 2021
Posts: 235
Rep Power: 5 |
Quote:
I agree with the fact that p_rgh should be relatively constant with height. But I rarely work with domains tall enough to affect significatively the hydrostatic field. Not sure how prghTotalHydrostaticPressure would handle multiphase flows, but I think that you would need both p and p_rgh for the example you discuss (water and depth). Quote:
p does vary with height, only in the wrong direction maybe it is due to hRef, I would have to check my latest tests. And yeah, gravity is properly set (not a silly question at all, I stopper counting how many times I made that mistake ) and the flow is eventually moving upwards as expected. Using localEuler is definitely more stable and the end result looks great (using prghTotalHydrosaticPressure, fixedFluxPressure for ph_rgh and hRef set at the top boundary) so I will settle for that for now. The steadyState gives more oscillations and spurious currents with slower convergence. |
|||
Tags |
boundaries condition, reverse flow |
Thread Tools | Search this Thread |
Display Modes | |
|
|
Similar Threads | ||||
Thread | Thread Starter | Forum | Replies | Last Post |
Flipping the direction of FanPressure BC | HouchinM | OpenFOAM Pre-Processing | 1 | December 8, 2017 05:49 |
Sign of massflow across a plane | Chander | CFX | 6 | June 14, 2012 03:36 |
Gravity component and inlet velocity | Vidya | FLUENT | 8 | July 31, 2006 08:28 |