Understanding flowRateOutletVelocity implementation

openFo · August 16, 2024, 11:27

Hello,

I am currently looking at the implementation of the flowRateOutletVelocity boundary condition (v2312) and don't understand why the calculation of the velocity based on the mass or volume flow is implemented the way it is. In the updateValues function they calculate the new velocity as follow:

Code:

const scalar flowRate = flowRate_->value(t);
    const scalar estimatedFlowRate = gSum(rho*(this->patch().magSf()*nUp));

    if (estimatedFlowRate > 0.5*flowRate)
    {
        nUp *= (mag(flowRate)/mag(estimatedFlowRate));
    }
    else
    {
        nUp += ((flowRate - estimatedFlowRate)/gSum(rho*patch().magSf()));
    }

    // Add the corrected normal component of velocity to the patch velocity
    Up += nUp*n;

I don't understand why the velocity can't just be calculated from the mass flow and set accordingly. Why is the estimated mass flow compared to 0.5*flowrate?

Does anyone have an idea?

Thanks in advance and kind regards

David

openFo · August 21, 2024, 03:22

So I looked at the code for a little longer and now see that the two expressions for updating the velocity essentially come out to the same expression if you fully resolve them:
$nUp_{new} = nUp_{old}* \frac{\dot{m}_{target}}{\dot{m}_{estimate}}$

Also, I now see that the second equation will result in very large negative velocities in cases where the estimated flow rate is very large, whereas the first equation results in

. Still, I don't understand the reason why
$\dot{m}_{estimate} > 0.5 \dot{m}_{target}$
is the criterion for switching.

August 16, 2024, 11:27	Understanding flowRateOutletVelocity implementation	#1
openFo New Member David von Rüden Join Date: Oct 2019 Location: Germany Posts: 6 Rep Power: 7	Hello, I am currently looking at the implementation of the flowRateOutletVelocity boundary condition (v2312) and don't understand why the calculation of the velocity based on the mass or volume flow is implemented the way it is. In the updateValues function they calculate the new velocity as follow: Code: const scalar flowRate = flowRate_->value(t); const scalar estimatedFlowRate = gSum(rho(this->patch().magSf()nUp)); if (estimatedFlowRate > 0.5flowRate) { nUp = (mag(flowRate)/mag(estimatedFlowRate)); } else { nUp += ((flowRate - estimatedFlowRate)/gSum(rhopatch().magSf())); } // Add the corrected normal component of velocity to the patch velocity Up += nUpn; I don't understand why the velocity can't just be calculated from the mass flow and set accordingly. Why is the estimated mass flow compared to 0.5*flowrate? Does anyone have an idea? Thanks in advance and kind regards David

Similar Threads
Thread	Thread Starter	Forum	Replies	Last Post
Radiation Models in General and the P1 implementation	Tobi	OpenFOAM Running, Solving & CFD	8	September 21, 2021 06:59
Issues in FGM combustion model implementation	Lisandro Maders	OpenFOAM Programming & Development	15	April 22, 2020 20:18
Understanding conjugate solver implementation in openfoam	umeshisode	OpenFOAM Programming & Development	0	February 9, 2015 07:17
Implementation issues of fvSchemes / laplacianScheme, in particular gaussLaplacianSch	thomek	OpenFOAM Programming & Development	0	October 18, 2010 06:10
Please explain the implementation of species transport Eqn in reactingFoam	kallipygian	OpenFOAM Running, Solving & CFD	0	October 13, 2008 08:29

August 21, 2024, 03:22		#2
openFo New Member David von Rüden Join Date: Oct 2019 Location: Germany Posts: 6 Rep Power: 7	So I looked at the code for a little longer and now see that the two expressions for updating the velocity essentially come out to the same expression if you fully resolve them: $nUp_{new} = nUp_{old}* \frac{\dot{m}_{target}}{\dot{m}_{estimate}}$ Also, I now see that the second equation will result in very large negative velocities in cases where the estimated flow rate is very large, whereas the first equation results in . Still, I don't understand the reason why $\dot{m}_{estimate} > 0.5 \dot{m}_{target}$ is the criterion for switching.