|
[Sponsors] |
uniformDensityHydrostaticPressure: Bug or FeatureRequest |
|
LinkBack | Thread Tools | Search this Thread | Display Modes |
August 13, 2009, 04:32 |
uniformDensityHydrostaticPressure: Bug or FeatureRequest
|
#1 |
Member
Carsten Thorenz
Join Date: Mar 2009
Location: Germany
Posts: 34
Rep Power: 17 |
Hello dear developers!
From the release notes of 1.6 I've concluded that uniformDensityHydrostaticPressure ist supposed to facilitate the transition from pd to p by specifying an equivalent to constant pd. Well, at least for my class of problems (flow of water in a channel with air above it, interFoam-solvers) this not the case. Reason: The old pd to p transition was performed by computing p=pd+rho*g*z. On the boundary, rho was varying with the value of the gamma field. If the watertable was set at z=0, setting a Dirichlet-BC for pd=0 resulted in a constant watertable at the outlet. In the p field, a hydrostatic gradient with rho=rho_water below the watertable and rho=rho_air above the watertable was the result. Mimicking this behaviour with the new formulation doesn't work, because rho is set to a single value. So, my enhancement request is: In uniformDensityHydrostaticPressureFvPatchScalarFiel d change the code, so that two densities can be used. The density of the heavier fluid should be used below pRefPoint, the density of the lighter fluid above pRefPoint. This is slightly different to the old pd formulation, where the current density of the mixture was used. I'm not sure which one is better. Sorry, I'm not fluent in OpenFOAM, but in pseudo-code I'm thinking about changing operator== ( pRefValue_+ rho_*((g.value() & patch().Cf()) - (g.value() & pRefPoint_))) either to if (z>pRefPoint_) operator== ( pRefValue_+ rho_light*((g.value() & patch().Cf()) - (g.value()&pRefPoint_))) else operator== ( pRefValue_+ rho_heavy*((g.value() & patch().Cf()) - (g.value()&pRefPoint_))) or, more equivalent to the old pd-formulation, to: operator== ( pRefValue_+ real_rho*((g.value() & patch().Cf()) - (g.value() & pRefPoint_))) where real_rho is the field value of rho, computed from the gamma/alpha field. Many thanks for your time, Carsten |
|
August 14, 2009, 04:36 |
|
#2 |
Senior Member
Join Date: Mar 2009
Posts: 854
Rep Power: 22 |
> From the release notes of 1.6 I've concluded that uniformDensityHydrostaticPressure ist supposed to facilitate the transition from pd to p by specifying an equivalent to constant pd.
Not quite, only in the case of constant density. For varying density the uniformDensityHydrostaticPressure is inappropriate as is a constant pd. What is needed in this case is a hydrostatic solver for the BC for either p or pd, both of which will vary at the outlet. Alternatively you can try an extrapolated BC for p or pd, i.e. zeroGradient which will work for some/most? cases. H |
|
August 14, 2009, 07:02 |
|
#3 |
Member
Carsten Thorenz
Join Date: Mar 2009
Location: Germany
Posts: 34
Rep Power: 17 |
Hello Henry,
many thanks for clarification. Anyhow, let me explain what I'm talking about: In order to keep the watertable at an outlet constant, our strategy with other codes is to set the following BCs: Pressure : Dirichlet-BC with pressure profile for the _desired_ watertable in both air and water Velocity : Neumann-zero with some stabilization The treatment of the VOF-function depends on the code used, sometimes Dirichlet, sometimes Neumann-zero, sometimes mixed. In the 1.5-release I was able to have a "nice" pressure based inlet-outlet with a fixed (!!!) watertable by shifting the model, so that the watertable is located at z=0. Then, applying a Dirichlet-BC pd=0 resulted in the desired behaviour: If the watertable in the model is too low, water flows into the system, if the watertable is too high it's vice-versa. In 1.6, I can not mimic this. Setting the pressure to zerogradient doesn't fix the watertable. I could separate the inlet-outlet into two patches, one below and one above the watertable and apply the hydrostatic BC to them, but then every time I want to change the watertable I would have to generate a new grid, which is very annoying. With the proposed changes, I think it would be easy to keep the watertable constant in interFoam again, but unfortunately my knowledge of OpenFOAM is unsufficient for implementing this ... Thanks again for your time, Carsten |
|
August 14, 2009, 07:15 |
|
#4 |
Senior Member
Join Date: Mar 2009
Posts: 854
Rep Power: 22 |
What we are planning is an automatic hydrostatic pressure BC which may do what you want if you have a method of fixing the VoF field at the outlet. However what you are proposing is the equivalent of what you were doing with pd and could be implemented quite easily, in fact our training courses cover the knowledge you need to do this.
H |
|
August 14, 2009, 08:09 |
|
#5 |
Member
Carsten Thorenz
Join Date: Mar 2009
Location: Germany
Posts: 34
Rep Power: 17 |
Ah, good to know. Well, after my summer break I intended to dig a little deeper into OpenFOAM (unfortunately I do not have too much time for that , so I'll give it a try then.
Have a nice weekend, Carsten |
|
August 14, 2009, 10:18 |
|
#6 |
Member
Carsten Thorenz
Join Date: Mar 2009
Location: Germany
Posts: 34
Rep Power: 17 |
Addendum:
Maybe not too much hassle: In order to stay consistent with the current behaviour, it might be possible to change the behaviour of the BC in the following way: - Read the entry for "rho" from the " uniformDensityHydrostaticPressure" BC - If the entry for "rho" is a number, behave like before - If the entry for "rho" is a string (e.g. "rho"), read the values from the appropriate field at the boundary and use them Wished I knew how to do it. Have a nice weekend, Carsten |
|
Tags |
interfoam hydrostatic |
|
|
Similar Threads | ||||
Thread | Thread Starter | Forum | Replies | Last Post |
Bug in twoPhaseEulerFoam wallfunctions | alberto | OpenFOAM Bugs | 1 | February 9, 2007 15:15 |
Please report this bug | egp | OpenFOAM Installation | 5 | December 8, 2006 13:56 |
Bug reports | Mattijs Janssens (Mattijs) | OpenFOAM | 0 | January 10, 2005 11:05 |
Win XP hot fix bug!!! | Emilio | Siemens | 1 | March 27, 2003 13:06 |
Forum y2k Bug | Jonas Larsson | Main CFD Forum | 1 | January 5, 2000 11:22 |