[knuckles]

Looking at the source code for reactingFoam, YEqn.H defines the variable mvConvection as

tmp<fv::convectionScheme<scalar>> mvConvection
(
    fv::convectionScheme<scalar>::New
    (
        mesh,
        fields,
        phi,
        mesh.divScheme("div(phi,Yi_h)")
    )
);

and this object is used to evaluate the divergence term in YEqn.H and EEqn.H:

// YEqn.H

    + mvConvection->fvmDiv(phi, Yi)

// EEqn.H

    + mvConvection->fvmDiv(phi, he)

By contrast, the other transport equations use

    + fvm::div(phi, field) // "field" is the volScalarField being solved for

I have a guess for why this is, but I'd appreciate some confirmation. My guess is that:

• fvm::div looks up the convection scheme in fvSchemes by searching for the tag "div(phi, [name of field])"
• as coded, mvConvection looks up the convection scheme by searching for the tag "div(phi, Yi_h)"

...and thus that mvConvection:

• saves the user from having to insert a "div(phi, [species name])" for each individual species in the simulation
• ensures that the divergence schemes for the species and for h are the same

Is this interpretation correct? Is there a theoretical reason why it's important that mass and energy/enthalpy use the same divergence scheme?

[Zeppo]

Originally Posted by knuckles

    + fvm::div(phi, field) // "field" is the volScalarField being solved for

Let me cite the source code:

//- src/finiteVolume/finiteVolume/fvm/fvmDiv.C
   ...
   43 template<class Type>
   44 tmp<fvMatrix<Type>>
   45 div
   46 (
   47     const surfaceScalarField& flux,
   48     const GeometricField<Type, fvPatchField, volMesh>& vf,
   49     const word& name
   50 )
   51 {
   52     return fv::convectionScheme<Type>::New
   53     (
   54         vf.mesh(),
   55         flux,
   56         vf.mesh().divScheme(name)
   57     )().fvmDiv(flux, vf);
   58 }
   ...
   75 template<class Type>
   76 tmp<fvMatrix<Type>>
   77 div
   78 (
   79     const surfaceScalarField& flux,
   80     const GeometricField<Type, fvPatchField, volMesh>& vf
   81 )
   82 {
   83     return fvm::div(flux, vf, "div("+flux.name()+','+vf.name()+')');
   84 }

[zhangyan]

Hi everyone!
From above discussion, the conclusion of this thread is that mvConvection is used only for the simplification for the case of multi variables with same scheme.
However:
In my solver, two additional variable is transported.
When I use separate but same scheme for these two variable ( fvm::div(phi, field) ), I found that the results is different with mvConvection ( mvConvection->fvmDiv(phi, field) ).
So, is there any other difference between mvConvection->fvmDiv and fvm::div?

[Rachel0096]

Originally Posted by zhangyan

Hi everyone!
From above discussion, the conclusion of this thread is that mvConvection is used only for the simplification for the case of multi variables with same scheme.
However:
In my solver, two additional variable is transported.
When I use separate but same scheme for these two variable ( fvm::div(phi, field) ), I found that the results is different with mvConvection ( mvConvection->fvmDiv(phi, field) ).
So, is there any other difference between mvConvection->fvmDiv and fvm::div?

Hello，zhangyan！
The convection term of the code I refer to is written like this:

// convection
+ ( UseMvConvection ? mvConvection->fvmDiv(phi + phiVc, Yi) : fvm::div(phi + phiVc, Yi, "div(phi,Yi_h)") )

Have you figured out the difference between mvConvection->fvmDiv and fvm::div?