[mm66]

Hi Foamers,

I am facing a problem with icoReactingMultiphaseInterFoam solver. In U boundary condition, I have specified the inlet mass flow rate as:

Inlet
    {
        type        	flowRateInletVelocity;
        massFlowRate    constant 0.00785;
        value           $internalField;
    }

But the solver returns:

Expression patchMassFlow on Inlet:  sum=-6.15397e-06

I have the following in controlDict:

	patchMassFlow
	{
		type			patchExpression;
		accumulations (
			sum
		);
		patches (
			Inlet
			Outlet
		);
		expression		"phi";
		verbose			true;
		outputControlMode	timeStep;
		outputInterval		1;
		writeStartTime		2;
		allowCoupled		true;
	}

Any ideas? Thanks

Regards,
MJ

[mm66]

Seems that it is being divided by the density (according to the inlet VOF). But why is the mass flow being divided by density?!!

[mm66]

Originally Posted by mm66

Seems that it is being divided by the density (according to the inlet VOF). But why is the mass flow being divided by density?!!

Anyone please? So confused here

More info for Gas:

thermoType
{
    type            heRhoThermo;
    mixture         pureMixture;
    transport       const;
    thermo          hConst;
    equationOfState incompressiblePerfectGas;
    specie          specie;
    energy          sensibleEnthalpy;
}

And for Liquid:

thermoType
{
    type            heRhoThermo;
    mixture         pureMixture;
    transport       const;
    thermo          hConst;
    equationOfState rhoConst;
    specie          specie;
    energy          sensibleEnthalpy;
}

[tas38]

I believe you need to add the following to the 'flowRateInletVelocity' bc in order for it to be interpreted as mass flow rather than volumetric flow...

rho  rho;

[mm66]

Originally Posted by tas38

I believe you need to add the following to the 'flowRateInletVelocity' bc in order for it to be interpreted as mass flow rather than volumetric flow...

rho  rho;

Dear Troy,

Thanks a lot for your reply. I tried and specified rho as you mentioned but the solver still returns the same value (ignoring rho?). Don't know what is causing this

Regards,
MJ

[tas38]

I assume that the 'patchMassFlow' value you have quoted corresponds to the converged solution and not some intermediate step?

What results do you get for the inlet mass flowrate using the postprocessing utility? E.g.

postProcess -func 'flowRatePatch(name=Inlet)'

[mm66]

Originally Posted by tas38

I assume that the 'patchMassFlow' value you have quoted corresponds to the converged solution and not some intermediate step?

What results do you get for the inlet mass flowrate using the postprocessing utility? E.g.

postProcess -func 'flowRatePatch(name=Inlet)'

Thanks Troy. Yes, it is for the converged solution. Here is an example:

ExecutionTime = 5.3 s  ClockTime = 5 s

Expression patchMassFlow on Inlet:  sum=-5.53761e-05
Expression patchMassFlow on Outlet:  sum=5.53761e-05
fieldAverage fieldAverage1 write:
    Calculating averages

Courant Number mean: 0.00156158 max: 1.5566
Interface Courant Number mean: 1.55945e-05 max: 0.991976
Maximum ddtAlpha : 8.60109e-16
Maximum DiffNum : 0
deltaT = 1.63891e-06
Time = 0.00101337

I also tried postProcess as you mentioned, it returns the same value, for example:

Time = 0.005

Reading fields:
    surfaceScalarField: phi

Executing functionObjects
surfaceFieldValue flowRatePatch(name=Inlet) write:
    sum(Inlet) of phi = -5.53761e-05

[peterhess]

See 1.43:

https://k.kakaocdn.net/dn/cjKN6m/btq...&knm=tfile.pdf

Regards

Peter

[mm66]

Originally Posted by peterhess

See 1.43:

https://k.kakaocdn.net/dn/cjKN6m/btq...&knm=tfile.pdf

Regards

Peter

Hi Peter,

Thanks for your reply. I updated the U boundary condition accordingly:

Inlet
    {
        type			flowRateInletVelocity;
        massFlowRate		0.00785;
	extrapolateProfile	yes;
	rho			rho;
        rhoInlet		140.14;
        value			uniform (0 0 0); 
    }

Still getting the same value

[tas38]

What is being set for the phase fraction (alpha) fields at the inlet? Is it single phase or some mixture of liquid and gas?

[mm66]

Originally Posted by tas38

What is being set for the phase fraction (alpha) fields at the inlet? Is it single phase or some mixture of liquid and gas?

It is 90% gas:

    Inlet
    {
        type            fixedValue;
        value           uniform 0.9;
    }

or 10% liquid:

    Inlet
    {
        type            fixedValue;
        value           uniform 0.1;
    }

[tas38]

It appears that the behavior of the bc does not change from volume flow to mass flow despite the specification of rho and/or rhoInlet. The simplest solution would then be to specify the desired volumetric flow at the inlet. This is easy enough given that you have prescribed alpha.

It remains unclear, however, why the solver does not interaction with the bc in the manner typical of single phase flows. I have used the 'flowRateInletVelocity' bc previously for single phase simulations (simpleFoam and pimpleFoam) and the behavior most certainly changes following specification of rho.

[mm66]

Originally Posted by tas38

It appears that the behavior of the bc does not change from volume flow to mass flow despite the specification of rho and/or rhoInlet. The simplest solution would then be to specify the desired volumetric flow at the inlet. This is easy enough given that you have prescribed alpha.

It remains unclear, however, why the solver does not interaction with the bc in the manner typical of single phase flows. I have used the 'flowRateInletVelocity' bc previously for single phase simulations (simpleFoam and pimpleFoam) and the behavior most certainly changes following specification of rho.

Yes, exactly. I have also worked with flowRateInletVelocity several times with no problem but this one looks different.

I have just specified the equivalent volumetricFlowRate the result is almost the same

I have also tried the equivalent velocity (fixedValue) for the boundary. Still getting values at the same order of magnitude (i.e. e-5)!!!

[Bloerb]

icoReactingMultiphaseInterFoam is an incompressible solver. Incompressible solvers are internally using a pressure divided by density for numerical efficiency. Hence phi might be u*A not rho*u*A. Please check the unit inside the phi file in one of your results directories. If that is the case "sum phi" will return the volumetric flow rate not the mass flowrate.

[tas38]

Originally Posted by Bloerb

icoReactingMultiphaseInterFoam is an incompressible solver. Incompressible solvers are internally using a pressure divided by density for numerical efficiency. Hence phi might be u*A not rho*u*A. Please check the unit inside the phi file in one of your results directories. If that is the case "sum phi" will return the volumetric flow rate not the mass flowrate.

While this is true, I think a bigger issue that the thread originator is having relates to the inlet boundary conditions. Changing the nature of the boundary condition to/from volumetric flowrate, mass flowrate, or prescribed velocity does not seem to illicit the desired response in the simulation. This issue seems to be related to the multiphase solver employed as both myself and the thread originator have successfully applied such inlet bcs for single phase simulations (simpleFoam, pimpleFoam, etc.).

[Bloerb]

i have looked it up. The solver uses two fields, phi, volumetric flux, and rhoPhi mass flux. Hence my assumption is correct that you calculated it wrong with your function object.



the inflow boundary condition does the following to calculate the patch value:

const scalar avgU = -flowRate_->value(t)/gSum(rho*patch().magSf());
operator==(avgU*n);

• minus for inlow (negativ n direction is inside)
• flowRate_->value(t) is the function1 value (value at the current time) of the volumetric flowrate or massflowrate (you can prescribe it as a function or table etc, in your case constant)
• gSum(rho*patch().magSf()) means sum up all faces density*area values

if a volumetric flow rate is prescribed rho=1 else

                patch().lookupPatchField<volScalarField, scalar>(rhoName_);            const fvPatchField<scalar>& rhop =

the density name of the solver is rho and rhoName defaults to that, hence i do not see an issue with the boundary condition. You might have to check the rho file. Since it is created by default, it might not list the correct density corresponding to the alpha field at the boundary.


You should however note that is prescribes exactly one value for the entire patch, not a profile and it does not adress the phase distribution.

[mm66]

Originally Posted by Bloerb

i have looked it up. The solver uses two fields, phi, volumetric flux, and rhoPhi mass flux. Hence my assumption is correct that you calculated it wrong with your function object.



the inflow boundary condition does the following to calculate the patch value:

const scalar avgU = -flowRate_->value(t)/gSum(rho*patch().magSf());
operator==(avgU*n);

• minus for inlow (negativ n direction is inside)
• flowRate_->value(t) is the function1 value (value at the current time) of the volumetric flowrate or massflowrate (you can prescribe it as a function or table etc, in your case constant)
• gSum(rho*patch().magSf()) means sum up all faces density*area values

if a volumetric flow rate is prescribed rho=1 else

                patch().lookupPatchField<volScalarField, scalar>(rhoName_);            const fvPatchField<scalar>& rhop =

the density name of the solver is rho and rhoName defaults to that, hence i do not see an issue with the boundary condition. You might have to check the rho file. Since it is created by default, it might not list the correct density corresponding to the alpha field at the boundary.


You should however note that is prescribes exactly one value for the entire patch, not a profile and it does not adress the phase distribution.

Dear Bloerb and Troy,

Thanks a lot for your time and help.
The strange thing is that regardless of the assigned value for the mass flow rate the solver returns the same patch mass flow rate value...

Bloerb, what "rho file" are you referring to?