|
[Sponsors] |
setReference pressure problem when having source term in pdEqn |
|
LinkBack | Thread Tools | Search this Thread | Display Modes |
May 7, 2019, 20:25 |
setReference pressure problem when having source term in pdEqn
|
#1 |
Senior Member
Daniel
Join Date: Mar 2013
Location: Noshahr, Iran
Posts: 348
Rep Power: 21 |
Dear foamers,
I'm working on a problem dealing with evaporation and condensation of water inside a closed domain. The fixedFluxPressure boundary condition is applied on all the boundaries which necessitate the need for setting a reference pressure before solving the pdEqn. The evaporation-condensation model adds a mass transfer source in pdEqn as follow: Code:
fvScalarMatrix pdEqn ( fvc::div(phiHbyA) - fvm::laplacian(rAUf, pd_) - (vDotc - vDotv) ); If it helps further investigating the issue, here is the full pEqn function: Code:
void interPhaseChangeFluid::pEqn ( const fvMesh& mesh, const fvVectorMatrix& UEqn ) { rAU_ = 1.0/UEqn.A(); surfaceScalarField rAUf("rAUf", fvc::interpolate(rAU_)); volVectorField HbyA("HbyA", U_); HbyA = rAU_*UEqn.H(); surfaceScalarField phiHbyA ( "phiHbyA", (fvc::interpolate(HbyA) & mesh.Sf()) + fvc::ddtPhiCorr(rAU_, rho_, U_, phi_) ); #include "updateRobinFsiInterface.H" adjustPhi(phiHbyA, U_, pd_); //- calculating surface tension flux //- + gravitational flux surfaceScalarField phig ( interface_.capillaryFlux(rAUf) - ghf_*fvc::snGrad(rho_)*rAUf*mesh.magSf() ); //- adding the resulting flux to the main flux phiHbyA += phig; Pair<tmp<volScalarField> > vDot = phaseChangeModel_->vDot(); const volScalarField& vDotc = vDot[0](); const volScalarField& vDotv = vDot[1](); while (pimple_.correctNonOrthogonal()) { fvScalarMatrix pdEqn ( fvc::div(phiHbyA) - fvm::laplacian(rAUf, pd_) - (vDotc - vDotv) ); pdEqn.setReference(pRefCell_, getRefCellValue(pd_, pRefCell_)); pdEqn.solve ( mesh.solutionDict().solver(pd_.select(pimple_.finalInnerIter())) ); if (pimple_.finalNonOrthogonalIter()) { phi_ = phiHbyA + pdEqn.flux(); U_ = HbyA + rAU_*fvc::reconstruct((phig + pdEqn.flux())/rAUf); U_.correctBoundaryConditions(); gradU_ = fvc::grad(U_); } } //- re-evaluate pressure using additional terms p_ = pd_ + rho_*gh_; p_.correctBoundaryConditions(); gradp_ = fvc::grad(p_); if (pd_.needReference()) { p_ += dimensionedScalar ( "p", p_.dimensions(), pRefValue_ - getRefCellValue(p_, pRefCell_) ); pd_ = p_ - rho_*gh_; } //- Make the fluxes relative to the mesh motion fvc::makeRelative(phi_, U_); } D.Khazaei |
|
May 8, 2019, 01:37 |
|
#2 |
Senior Member
Tom-Robin Teschner
Join Date: Dec 2011
Location: Cranfield, UK
Posts: 204
Rep Power: 16 |
So just to clarify, the source term that you added is
Code:
(vDotc - vDotv) Anyways, so what I know so far is that solving the equation explicitly or implicitly does not seem to make a change (no influence of the matrix coefficients due to the implicit solver), I also thought that the source term may be multiplied by the volume but that doesn't change anything (also it seems strange, other threads on adding source terms to openfoam do not do this, but I tried anyway, I guess to calm my paranoia ...). Are you sure that the issue is due to the reference pressure? There is also a method called constrainPressure(), maybe that would help in your case? |
|
May 8, 2019, 12:09 |
|
#3 | ||||||
Senior Member
Daniel
Join Date: Mar 2013
Location: Noshahr, Iran
Posts: 348
Rep Power: 21 |
Quote:
Quote:
I think it has something to do with velocity prediction after solving for pd where the velocity is corrected using pdEqn.flux(). Quote:
explicit implementation: if you look into interPhaseChangeFoam and interCondensingEvaporatingFoam solvers it can be seen that this is a common approach. Code:
fvScalarMatrix pdEqn ( fvc::div(phiHbyA) - fvm::laplacian(rAUf, pd_) - (vDotc - vDotv) ); Code:
fvScalarMatrix pdEqn ( fvc::div(phiHbyA) - fvm::laplacian(rAUf, pd_) - fvm::Sp((vDotc - vDotv) / (pd_ + pd0), pd_) ); Code:
fvScalarMatrix pdEqn ( fvc::div(phiHbyA) - fvm::laplacian(rAUf, pd_) - fvm::SuSp((vDotc - vDotv) / (pd_ + pd0), pd_) ); Code:
pd_.needReference() Code:
pdEqn.setReference(pRefCell, pdRefValue) Quote:
Quote:
However, I don't have any problem with the source term if I don't try to model a closed-domain. So my problem seems to be related to setting a reference pressure when having a source term in pEqn. Quote:
I don't think foam-extend has such a library called constrainPressure(), I will look into it. However, both adjustPhi and constrainPressure modify boundaries of the domain. My problem is not limited to boundaries, if I put the reference location inside the domain, then I will see unrealistic velocity and Temperature there. Regards Last edited by Daniel_Khazaei; May 8, 2019 at 15:11. |
|||||||
May 8, 2019, 17:11 |
|
#4 |
Senior Member
Tom-Robin Teschner
Join Date: Dec 2011
Location: Cranfield, UK
Posts: 204
Rep Power: 16 |
my bad, could you then indicate what the correct velocity and temperature field should look like? (I presume it is just a homogeneous field of velocity and temperature, i.e. no spikes as seen in your contour plots then?)
It seems you have already put more effort into understanding the issue than I could, so I have some new ideas to try for my issue (thanks for that), but now that I understand your problem a bit better, I agree that our problems are probably fundamentally different. But if I understand that correctly, you do not have the issue when you use at least on one boundary a dirichlet condition for the pressure? I.e. the problem only arises when you have fully Neumann boundary conditions? I remember a similar problem when I was writing a simplified code for the lid driven cavity problem, there the pressure also has fully Neumann BCs and when prescribing a reference cell and value that approach was always giving wrong results for the cell where I put the reference pressure (similar to what you are showing). In the end I removed the reference pressure approach and just calculated the average pressure and removed that from the simulation (did the job, I guess you could say it is more of a global approach, whereas prescribing the reference cell could be seen as a local approach). Anyways, in openfoam that may not work as easily (and may also not be generalised for different cases), so I am not sure what to do about that. One thing I am a bit more surprised about is that the pressure field seems to be OK while the velocity field is not. They should be coupled and even if the issue is only within the velocity field, at the next update it should then also affect the pressure. Thats a bit odd. And the last thing, you said that you expect the problem to be with "pdEqn.flux()", but in-fact that method is always called (?!), while you say the issue only arises when if (pd_.needReference()) evaluates to true? Then I would expect the issue to be there, what makes you think it is the flux method then? (just trying to understand your thinking, maybe I missunderstood something along the way) |
|
May 8, 2019, 21:19 |
|
#5 | ||||||
Senior Member
Daniel
Join Date: Mar 2013
Location: Noshahr, Iran
Posts: 348
Rep Power: 21 |
Quote:
Yes, exactly. I have also installed ANSYS Fluent student version and performed the simulation there. There should never be such a spike in velocity and temperature fields and those fields should start changing smoothly as the simulation goes on. Quote:
Quote:
Quote:
When I was analyzing the same case with ANSYS Fluent, it says that to see the actual reference location you need to run the following TUI command which is only available when the simulation doesn't have any pressure related boundary conditions: Code:
define -> operating-conditions -> used-ref-pressure-location I have tried to remove pdEqn.setReference and that just cause immediate divergence. Quote:
Quote:
Maybe the solution doesn't converge properly when I insert the source and the pdEqn.setReference() is active simultaneously. Although that doesn't answer why pd_ field doesn't show any anomaly if there is a convergence problem. Code:
if (pimple_.finalNonOrthogonalIter()) { phi_ = phiHbyA + pdEqn.flux(); U_ = HbyA + rAU_*fvc::reconstruct((phig + pdEqn.flux())/rAUf); U_.correctBoundaryConditions(); gradU_ = fvc::grad(U_); } |
|||||||
May 9, 2019, 05:41 |
|
#6 |
Senior Member
Tom-Robin Teschner
Join Date: Dec 2011
Location: Cranfield, UK
Posts: 204
Rep Power: 16 |
I see, thanks for the additional explanation. This might not work (or be pointless), but what happens if you call pd_.correctBoundaryConditions(); ? And could you also explain what the pd equation actually solves?
Regarding the pressure boundary implementation, I lterally just looped over all cells, added the pressure to a counter and then diveded the counter by the number of elements. That was then my average pressure and I removed that from my pressure field. Or in pseudo code Code:
averagePressure = 0 for element in totalElements { averagePressure += pressure[element] } averagePressure /= totalElements for element in totalElements { pressure -= averagePressure } I am actually not sure how fluent handles the reference pressure. You can specify your operational pressure which, for incompressible flows, should be anyways irrelevant. During post processing that value is used, however, to calculate your total pressure but I am not sure if the value is used in the simulation itself. |
|
May 9, 2019, 18:45 |
|
#7 | |||
Senior Member
Daniel
Join Date: Mar 2013
Location: Noshahr, Iran
Posts: 348
Rep Power: 21 |
Quote:
Well it's just the same as p_rgh in OpenFOAM, with different naming in foam-extend. It solves for the pressure subtracted by rho*gh. Quote:
Quote:
Regards |
||||
May 10, 2019, 01:44 |
|
#8 |
Senior Member
Daniel
Join Date: Mar 2013
Location: Noshahr, Iran
Posts: 348
Rep Power: 21 |
today I have noticed something that I can't understand. I have modified the code to output pd_ values at each step:
Code:
fvScalarMatrix pdEqn ( fvc::div(phiHbyA) - fvm::laplacian(rAUf, pd_) - (vDotc - vDotv) ); Info << "1- pd before setting a reference = " << pd_[pRefCell_] << endl; pdEqn.setReference(pRefCell_, getRefCellValue(pd_, pRefCell_)); Info << "2- pd after setting a reference = " << pd_[pRefCell_] << endl; pdEqn.solve ( mesh.solutionDict().solver(pd_.select(pimple_.finalInnerIter())) ); Info << "3- pd after solve = " << pd_[pRefCell_] << endl; I though that pdEqn.setReference is supposed to actually keep pd_ value at pRefCell constant. Am I wrong here? I think that may reveal why prediction of velocity using pdEqn.flux() causes non-physical values. If I remove the source term from pdEqn, then pd_ value remains constant at all the steps and I don't get non-physical velocity or temperature field anymore. |
|
May 10, 2019, 09:20 |
|
#9 |
Senior Member
Tom-Robin Teschner
Join Date: Dec 2011
Location: Cranfield, UK
Posts: 204
Rep Power: 16 |
ahhh, I see, in-fact, the following line doesn't make any sense (at least to me)
Code:
pdEqn.setReference(pRefCell_, getRefCellValue(pd_, pRefCell_)); Code:
pdEqn.setReference(pRefCell_, pRefValue); |
|
May 10, 2019, 11:34 |
|
#10 | |
Senior Member
Daniel
Join Date: Mar 2013
Location: Noshahr, Iran
Posts: 348
Rep Power: 21 |
Quote:
Code:
//- re-evaluate pressure using additional terms p_ = pd_ + rho_*gh_; p_.correctBoundaryConditions(); if (pd_.needReference()) { p_ += dimensionedScalar ( "p", p_.dimensions(), pRefValue_ - getRefCellValue(p_, pRefCell_) ); pd_ = p_ - rho_*gh_; } Code:
p_ = pd_ + rho_*gh_; p_.correctBoundaryConditions(); Code:
if (pd_.needReference()) { p_ += dimensionedScalar ( "p", p_.dimensions(), pRefValue_ - getRefCellValue(p_, pRefCell_) ); pd_ = p_ - rho_*gh_; } Code:
pdEqn.setReference(pRefCell_, getRefCellValue(pd_, pRefCell_)); Code:
pdEqn.setReference(pRefCell_, pRefValue); The interesting think is that I tried using TEqn.setReference to enforce constant temperature at ref. cell but the exact same problem is there. If TEqn contains any source term then setReference can't keep T constant at the specified value. |
||
May 12, 2019, 00:51 |
|
#11 |
Senior Member
Daniel
Join Date: Mar 2013
Location: Noshahr, Iran
Posts: 348
Rep Power: 21 |
just looking for any reason behind this issue, I have just noticed that there is a bug report about it:
https://develop.openfoam.com/Develop...lus/issues/465 As I'm using the exact same mass transfer model in my solver, I think the same limitation is inherited: "The mass can not be conserved when any mass transfer model is involved." So, no closed-doamin for now until I have enough time to come up with a solution. Probably ANSYS found a solution for this, because it handles these kind of simulation without any problem. |
|
May 13, 2019, 01:07 |
|
#12 |
Senior Member
Tom-Robin Teschner
Join Date: Dec 2011
Location: Cranfield, UK
Posts: 204
Rep Power: 16 |
I see, well, half satisfying but at least we know its not your code then
|
|
February 27, 2020, 10:27 |
|
#13 |
Member
X Meng
Join Date: Jun 2012
Location: Scotland
Posts: 89
Rep Power: 13 |
Unfortunately, I got the same issue. Having no idea why and how to fix.
As you can see from my screenshot, the pressure spike is at the reference cell (pRefCell=0). This leads to a crash later. My solver for this case is buoyantSimpleFoam. Mesh quality is quite good, since the geometry is simple. Help needed and really appreciate in advance!!! |
|
|
|
Similar Threads | ||||
Thread | Thread Starter | Forum | Replies | Last Post |
[Other] Tabulated thermophysicalProperties library | chriss85 | OpenFOAM Community Contributions | 62 | October 2, 2022 03:50 |
[swak4Foam] Installation Problem with OF 6 version | Aurel | OpenFOAM Community Contributions | 14 | November 18, 2020 16:18 |
[foam-extend.org] Problems installing foam-extend-4.0 on openSUSE 42.2 and Ubuntu 16.04 | ordinary | OpenFOAM Installation | 19 | September 3, 2019 18:13 |
pisoFOAM (LES) - internal pipe flow - convergence | gu1 | OpenFOAM Running, Solving & CFD | 0 | January 11, 2018 16:39 |
"parabolicVelocity" in OpenFoam 2.1.0 ? | sawyer86 | OpenFOAM Running, Solving & CFD | 21 | February 7, 2012 11:44 |