You found a bug. There's bits
 

You found a bug. There's bits missing in lnInclude/fvcMeshPhi.C. In the second and third function multiply the return with rho, e.g.


template<class>
tmp<surfacescalarfield> meshPhi
(
const dimensionedScalar& rho,
const GeometricField<type,>& vf
)
{
//HJ, Missing rho. 13/Dec/2006
return rho*fv::ddtScheme<type>::New
(
vf.mesh(),
vf.mesh().ddtScheme("ddt(" + rho.name() + ',' + vf.name() + ')')
)().meshPhi(vf);

}

Alternatively, you can just hack it in the top-level code by multiplying the flux with rho

Apologies,

Hrv

Hi Hrvoje Thanks for the he
 

Hi Hrvoje

Thanks for the help.

I did the change in the top-level code, (with some help from Eric Lillberg)

Regards

Fredrik

Hi Hrv and Fredrik, Let's f
 

Hi Hrv and Fredrik,

Let's fix the other bug in fvcMeshPhi.C, I propose the following change...

template<class>
tmp<surfacescalarfield> meshPhi
(
const volScalarField& rho,
const GeometricField<type,>& vf
)
{
//Eric, Missing interpolated rho 22/Mars/07
return fvc::interpolate(rho)*fv::ddtScheme<type>::New
(
vf.mesh(),
vf.mesh().ddtScheme("ddt(" + rho.name() + ',' + vf.name() + ')')
)().meshPhi(vf);
}

Keep in touch,

//Eric

Nope. I thought about it: me
 

Nope. I thought about it: meshPhi only needs the fields to find the temporal discretisation scheme from the dictionary and return the correct motion fluxes. If you think what is going on here, the scheme will force a certain type of density interpolation onto you, and it is by no means clear I want to multiply the motion flux by rho in any case.

For my taste, I would say that meshPhi returns meshPhi. It is a bit unfortunate and misleading that it takes rho as an argument: it may be better to just take a string.

Therefore, the correct dimension for meshPhi is m^3/s and you can easily manipulate the flux afterwards. Of course, we need agreement on this...

Speak to me,

Hrv

I agree on that the mesh flux
 

I agree on that the mesh flux should be a pure flux and whatever has to be done with it to conform to a specific algorithm should be done in top level code. I suggests that the additional arguments to fvcMeshPhi are dropped.

What do you think?

//Eric

You see, that's the problem: t
 

You see, that's the problem: they cannot be dropped (and I'd really love to). This is to do with second- or higher-order accuracy on the moving mesh. When, for example, you are using second order in time, the mesh flux is not simply the volume swept by the face in motion, but (as Zeljko has explained and tested to death) it needs to be consistent with the discretisation of the ddt term. For example, for a 3-time-level scheme, you will need to use 2 old motion fluxes and manipulate them into meshPhi, just as you use 3 leves of cell volume. If this gets scwered up, you lose second order in time.

In any case, meshPhi is a part of the ddt scheme and I need to know how to construct one - hence all this stuff with a name. The real options I see is either to give meshPhi a string with the name of the ddt scheme, or to look it up from the discretisation dictionary. In any case, a scheme needs to be made - that's why it looked ugly in the first place.

Hmm,

Hrv

Is this bug fixed in ver 1.4?
 

Is this bug fixed in ver 1.4?