OpenFOAM adapter for InterFoam: Density in Incompressible flow

Official adapters and tutorials
, ,
1

Hello,
Can anyone explain how to set the rho in preciceDict for OpenFoam adapter? Must it be the same as that in transportProperties? Then why do you need to set rho twice and not just get from transportProperties?

FSI
{
  solverType incompressible;
  rho rho [1 -3 0 0 0 0 0] 1;
}

Here, whether I set rho 1 or 1000, the force does not change at all when using interFoam. From the source code [ForceBase.C]( openfoam-adapter/ForceBase.C at develop · precice/openfoam-adapter (github.com)), it seems rho is only used to calculate viscous force, how does it affect the pressure?

2

In FSI, the rho from the preciceDict is kind of a backup if the adapter fails to fetch the rho value from OpenFOAM (see https://github.com/precice/openfoam-adapter/blob/49b62673e87fb0ca42267b4ac679e306ef1672b8/FSI/ForceBase.C#L61-L80) which is relevant for, e.g., incompressible solver (where there is no density field). In your case, interFoam should generate a rho field which is picked up by the adapter.

In which place? The specified density in the adapter doesn’t affect the pressure. If at all, it is used for the computation of coupling quantities.

Does it answer your question?

3

Hi David,
Thank you for your reply! This answered my question why a rho is needed in the FSI subdict. It also confirms my founding that rho here does not affect the force calculation when interFoam is used. If fact, this subdict is not necessary for interFoam.

However, it is worth to note that the force will be scaled by the rho set in transportProperties if I set the solverType explicitly as incompressible. I guess there are some conflicts in the if else statement in ‘ForceBase.C’ handling the solverType and rho. Can you check on this?

FSI
{
  solverType incompressible;
  // rho rho [1 -3 0 0 0 0 0] 1000;  // not used for interFoam 
}
transportProperties ```

phases (water air);

water
{
transportModel Newtonian;
nu [0 2 -1 0 0 0 0] 1.09e-06;
rho [1 -3 0 0 0 0 0] 1000;
}

air
{
transportModel Newtonian;
nu [0 2 -1 0 0 0 0] 1.48e-05;
rho [1 -3 0 0 0 0 0] 1e-5;
}

sigma [1 0 -2 0 0 0 0] 0;

</details>
4

Yes, the pressure is supposed to be scaled, because the pressure is scaled by the density in incompressible flows in OpenFOAM.

Which conflict are you referring to? Which behavior should be different in your opinion? Could you be more specific on this?

5

Do I need to set solverType in FSI subdict for interFoam?

I am referring the following code:

//lookup correct rho
Foam::tmp<Foam::volScalarField> preciceAdapter::FSI::ForceBase::rho() const
{
    // If volScalarField exists, read it from registry (for compressible cases)
    // interFoam is incompressible but has volScalarField rho

    if (mesh_.foundObject<volScalarField>("rho"))
    {
        return mesh_.lookupObject<volScalarField>("rho");
    }
    else if (solverType_.compare("incompressible") == 0)
    {
        const dictionary& FSIDict =
            mesh_.lookupObject<IOdictionary>("preciceDict").subOrEmptyDict("FSI");

        return tmp<volScalarField>(
            new volScalarField(
                IOobject(
                    "rho",
                    mesh_.time().timeName(),
                    mesh_,
                    IOobject::NO_READ,
                    IOobject::NO_WRITE),
                mesh_,
                dimensionedScalar(FSIDict.get<dimensionedScalar>("rho"))));
    }
    else
    {
        FatalErrorInFunction
            << "Did not find the correct rho."
            << exit(FatalError);

        return volScalarField::null();
    }
}

For interFoam, mesh_.foundObject<volScalarField>("rho") is true or false?

In the comments, it states that interFoam is incompressible but has volScalarField rho. But, if don’t I set solverType as incompressible, the force is 1000 times smaller than if set.

6

I just tried interFoam on my system and OpenFOAM (the adapter) categorizes it as compressible solver. In this case, the upper branch of the code is used. If you specify the solverType as incompressible, the upper branch of the if branch is still used (rho field is still there). However, the calculations of the force is different between compressible and incompressible solvers (scaling by the density) and that’s why you observe the differences.

What is the right thing for you? Considering that we select the automatically determined solverType according to the pressure dimension I would guess that compressible is the way to go here (otherwise it doesn’t make a lot of sense for me dimension-wise). However, please don’t take this comment for granted. Deciding here for either of these types should be doable in your case, though, if you roughly know which force (magnitude) you would expect at the interface (which of both results seem more reasonable for you?).

1 Like
7

Exactly, I have the same observation. It seems compressible gives the right force and incompressible gives a wrong scaled force. Actually, leaving FSI subdict blank gives the same correct force.

But I don’t really understand how setting ‘incompressible’ solverType influences the force in the code. I really wonder where the pressure force is scaled except when computing the viscous force in ForceBase.C.

By the way, the OpenFOAM built-in function object forces already takes the density considered so it gives the correct force.

1 Like
8

That’s done here (note the rho)

9

Thanks David. Now I see the pressure force is calculated first then added by the viscous force.

10

This topic was automatically closed 3 days after the last reply. New replies are no longer allowed.