CFD Online Discussion Forums

CFD Online Discussion Forums (http://www.cfd-online.com/Forums/)
-   OpenFOAM Running, Solving & CFD (http://www.cfd-online.com/Forums/openfoam-solving/)
-   -   Why to say OF uses %e2%80%98Pseudostaggered%e2%80%99 finite volume numerics (http://www.cfd-online.com/Forums/openfoam-solving/59636-why-say-uses-e2-80-98pseudostaggered-e2-80-99-finite-volume-numerics.html)

leosding August 30, 2005 20:30

Hi all FOAMers, On OpenCFD we
 
Hi all FOAMers,
On OpenCFD web:
To maintain generality and solve complex on real 3D cases, OpenFOAM uses

'Pseudo-staggered' finite volume numerics

but I can not find out from source.
Would somebody give me some help for understanding it?

Thanks in advance!
Leo

hjasak August 30, 2005 21:09

It means that the velocity fie
 
It means that the velocity field in the algorithm is treated as passive and instead of solving transport equations for it you recover it from the flux field (which caries the same information). That would be the:

U += rUA*fvc::reconstruct((phi - phiU)/rUAf);

bit in the pressure equation of interFoam;

Hrv

leosding August 30, 2005 21:44

But in application simpleFoam
 
But in application simpleFoam you solve the UEqn with
"solve(UEqu()++-fvc::grad(p));"
but I find the solution of UEqn --velocity field-- isn't used in following steps(if my understanding is right.), only use the UEqu.A() and UEqn.H() from UEqn assembling fvVectormatrix, then why solve the UEqu?

Leo

leosding August 30, 2005 21:46

sorry, type erro. Should be "
 
sorry, type erro. Should be
"solve(UEqu()==-fvc::grad(p));"


Leo

hjasak August 30, 2005 22:11

Hehe, how about: U = rUA*U
 
Hehe, how about:

U = rUA*UEqn.H();

We said before in this forum that the H() operator uses the current solution to do a Jacobi sweep:

In Hoperations.C

// H operator
template<class>
tmp<field<type> > lduMatrix::H(const Field<type>& sf) const
{
tmp<field<type> > tHphi
(
new Field<type>(lduAddr_.size(), pTraits<type>::zero)
);

if (lowerPtr_ || upperPtr_)
{
Field<type> & Hphi = tHphi();

const scalarField& Lower = lower();
const scalarField& Upper = upper();

// Take refereces to addressing
const unallocLabelList& l = lduAddr_.lowerAddr();
const unallocLabelList& u = lduAddr_.upperAddr();

for (register label face=0; face<l.size(); face++)
\ {
Hphi[u[face]] -= Lower[face]*sf[l[face]]; <--- right there!
Hphi[l[face]] -= Upper[face]*sf[u[face]];
\ }
}

return tHphi;
}

and then called in fvMatrix.C

tHphi().internalField() += lduMatrix::H(psi_.internalField()) + source_;


Hrv

leosding August 30, 2005 22:18

I get it. Thanks a lot!
 
I get it.

Thanks a lot!

henry August 31, 2005 03:13

In addition to the reconstruct
 
In addition to the reconstruct method to convert the staggered pressure gradient and "drag" terms into cell centered versions for the momentum corrector I have also introduced the ddtPhiCorr method to replace the cell-centered rate-of-change with the face-based flux version in the flux predictor making the solution for the fluxes not only staggered with respect to the pressure gradient and "drag" terms but also staggered with respect to the rate-of-change. Test solutions of the simplified shallow-water equations have shown that this formulation is equivalent to the Arakawa and Lamb C-grid staggering.

sampaio June 14, 2007 13:51

Sorry if I came late to this d
 
Sorry if I came late to this discussion, but I still dont get it...

If I set
U = rUA*UEqn.H();

isnt the U previously calculated in
if (momentumPredictor)
{
solve(UEqn == -fvc::grad(p));
}
lost anyway?

What is the point of checking "momentumPredictor" if the value of U will be lost anyway inside PISO loop (U = rUA*UEqn.H())?

I feel my understanding of OF is still very poor, so I am sorry for this stupid question...

Best regards,
luiz

sampaio June 14, 2007 16:15

Sorry, of course U = rUA*UEqn.
 
Sorry, of course U = rUA*UEqn.H() scope was limited to PISO loop by the brackets and would not affect the solved momentum equation.
Sorry for that...


All times are GMT -4. The time now is 19:10.