[russel60]

Hi all,

I have been working adding the fluid solver cavitatingFoam to the fsiFoam solver from the FluidSolidInteraction toolbox in Foam_extend. I have gotten really close to having the solver compile, but have two persistent issues that I have not been able to resolve. I appreciate any and all help I can get for how to fix these problems.

First: I am getting an 'error: invalid use of void expression' pop up when closing the final parenthesis in the variable declaration section of my code. Error:

fluidSolvers/cavitatingFluid/cavitatingFluid.C: In constructor ‘Foam::fluidSolvers::cavitatingFluid::cavitatingFluid(const Foam::fvMesh&)’:
fluidSolvers/cavitatingFluid/cavitatingFluid.C:216:5: error: invalid use of void expression
     )
     ^

Related Code:

    rho_
    (
        IOobject
        (
            "rho",
            runTime().timeName(),
            mesh,
            IOobject::MUST_READ,
            IOobject::AUTO_WRITE
        ),
        max (psi_*p_ + (1.0 - gamma_)*rhol0
                     + ((gamma_*psiv + (1.0 - gamma_)*psil) - psi_)*pSat,
                     rhoMin)
    ),


    turbulence_
    (
        incompressible::turbulenceModel::New
        (
            U_, phi_, twoPhaseProperties_
        )
    )

{}

[The parenthesis causing the error is in bold. It is the last single parenthesis ')' above '{}']

There are no open parenthesis in the code above the excerpt, and I have taken the turbulence_ line directly from an existing code that compiled successfully. I have read on other posts that this is probably due to asking for an output from a void function, but I do not think I am using any void functions. C++ is still new to me, so I may be very wrong.

Second Issue: I am getting a conversion error when calculating the compressible courant number.

Error:

fluidSolvers/cavitatingFluid/cavitatingFluid.C: In member function ‘virtual void Foam::fluidSolvers::cavitatingFluid::evolve()’:
fluidSolvers/cavitatingFluid/cavitatingFluid.C:412:20: error: cannot convert ‘Foam::tmp<Foam::GeometricField<double, Foam::fvsPatchField, Foam::surfaceMesh> >’ to ‘Foam::scalar {aka double}’ in assignment
             velMag = max(phiOverRho)/mesh.magSf()).value();

Related Code:

 // CourantNo
        {
        scalar CoNum = 0.0;
        scalar meanCoNum = 0.0;
        scalar velMag = 0.0;

        if (mesh.nInternalFaces())
        {
            surfaceScalarField phiOverRho = mag(phi_)/fvc::interpolate(rho_);

            surfaceScalarField SfUfbyDelta =
                 mesh.surfaceInterpolation::deltaCoeffs()*phiOverRho;

            CoNum = max(SfUfbyDelta/mesh.magSf())
                .value()*runTime().deltaT().value();

            meanCoNum = (sum(SfUfbyDelta)/sum(mesh.magSf()))
                .value()*runTime().deltaT().value();

            velMag = max(phiOverRho)/mesh.magSf()).value();
        }

        Info<< "Courant Number mean: " << meanCoNum
            << " max: " << CoNum
            << " velocity magnitude: " << velMag << endl;
        }

I copied and pasted this code from this source, but it still does not work.

https://github.com/Unofficial-Extend...bleCourantNo.H


Thank you in advance for any help!

[wyldckat]

Quick answers:

1. The first problem is likely a misleading error message from the compiler... it's necessary to see the complete block of the constructor, not just the last few lines close to the error. My suspicion is that the constructor has the word "void" right before the definition starts...
2. On the second one, something very wrong is going on here: "magSf())" - there is an extra unmatched closing parenthesis. My guess is that "max(phiOverRho)" was not meant to have the closing parenthesis...

[russel60]

Thank you for your quick reply, Bruno. I was able to fix the second error - it was the location of the closing parenthesis that was causing my error. Silly mistake but sometimes it helps to have a fresh set of eyes look it over :/

I am still struggling with the first error. I went through the whole code and made sure that all of the parenthesis are matched up, but that did not find any errors or fix any problems.

Do you have any other advice for where to look? Could it come from defining a function incorrectly in the .H file?

I have attached the code below, but it is 200 lines long and I understand if you don't want to read through it all.

I doubt my system matters, but I am running Foam_Extend 4.0 in a Bash on Ubuntu on Windows terminal window.

\*---------------------------------------------------------------------------*/

//Included in cavitatingFluid.H
  //#include "twoPhaseMixture.H"
  //#include "turbulenceModel.H"
  //#include "fvCFD.H"
#include "cavitatingFluid.H"
#include "barotropicCompressibilityModel.H"
#include "pimpleControl.H"
#include "volFields.H"
#include "findRefCell.H"
#include "adjustPhi.H"
#include "fluidSolidInterface.H"
#include "addToRunTimeSelectionTable.H"
#include "fixedGradientFvPatchFields.H"

#include "EulerDdtScheme.H"
#include "CrankNicolsonDdtScheme.H"
#include "backwardDdtScheme.H"

#include "elasticSlipWallVelocityFvPatchVectorField.H"
#include "elasticWallVelocityFvPatchVectorField.H"
#include "elasticWallPressureFvPatchScalarField.H"

// * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *//

namespace Foam
{
namespace fluidSolvers
{

// * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * //

defineTypeNameAndDebug(cavitatingFluid, 0);
addToRunTimeSelectionTable(fluidSolver, cavitatingFluid, dictionary);

// * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * //

cavitatingFluid::cavitatingFluid(const fvMesh& mesh)
:
    fluidSolver(this->typeName, mesh),
    U_
    (
        IOobject
        (
            "U",
            runTime().timeName(),
            mesh,
            IOobject::MUST_READ,
            IOobject::AUTO_WRITE
        ),
        mesh
    ),
    p_      
    (
        IOobject
        (
            "p",
            runTime().timeName(),
            mesh,
            IOobject::MUST_READ,
            IOobject::AUTO_WRITE
        ),
        mesh
    ),
    gradp_(fvc::grad(p_)),
    gradU_(fvc::grad(U_)),
    phi_
    (
        IOobject
        (
            "phi",
            runTime().timeName(),
            mesh,
            IOobject::READ_IF_PRESENT,
            IOobject::AUTO_WRITE
        ),
        fvc::interpolate(U_) & mesh.Sf()
    ),


    //Adding thermodynamicProperties stuff from cavitatingFoam
    thermoProperties_
    (
        IOobject
        (
            "thermodynamicProperties",
            runTime().constant(),
            mesh,
            IOobject::MUST_READ,
            IOobject::NO_WRITE
        )
    ),

    psil(thermoProperties_.lookup("psil")),
    rholSat(thermoProperties_.lookup("rholSat")),
    psiv(thermoProperties_.lookup("psiv")),
    pSat(thermoProperties_.lookup("pSat")),
    rhovSat("rhovSat", psiv*pSat),
    rhol0("rhol0", rholSat - pSat*psil),
    rhoMin(thermoProperties_.lookup("rhoMin")),

    gamma_
    (
        IOobject
        (
            runTime().timeName(),
            mesh,
            IOobject::NO_READ,
            IOobject::AUTO_WRITE
        ),
        gamma_ = max(min((rho_ - rholSat)/(rhovSat - rholSat), scalar(1)), scalar(0))
    ),

//This might come into play later.  May need the previous value of gamma_
//    gamma_.oldTime()

    phiv_
    (
        IOobject
        (
            "phiv",
            runTime().timeName(),
            mesh,
            IOobject::READ_IF_PRESENT,
            IOobject::AUTO_WRITE
        ),
        //Changed from flux(U_) to this:
        fvc::interpolate(U_) & mesh.Sf()
    ),

//Can't use any info statements in this file...
//    Info<< "Reading transportProperties\n" << endl;
    twoPhaseProperties_(U_,phiv_, "gamma"),

//Can't use any info statements in this file...
//    Info<< "Creating compressibilityModel\n" << endl;
    psiModel_
    (
        barotropicCompressibilityModel::New
        (
            thermoProperties_, gamma_
        )
    ),

    psi_("psi",psiModel_->psi()),


    //Adding lines from cavitatingFoam createFields.H
    rho_
    (
        IOobject
        (
            "rho",
            runTime().timeName(),
            mesh,
            IOobject::MUST_READ,
            IOobject::AUTO_WRITE
        ),
        max (psi_*p_ + (1.0 - gamma_)*rhol0
                     + ((gamma_*psiv + (1.0 - gamma_)*psil) - psi_)*pSat,
                     rhoMin)
    ),


    turbulence_
    (
        incompressible::turbulenceModel::New
        (
            U_, phi_, twoPhaseProperties_
        )
    )

{}

Thank you again for any help!

[wyldckat]

Quick answer: Well, I've spotted suspect number one:

gamma_ = max(min((rho_ - rholSat)/(rhovSat - rholSat), scalar(1)), scalar(0))

within:

    gamma_
    (
        IOobject
        (
            runTime().timeName(),
            mesh,
            IOobject::NO_READ,
            IOobject::AUTO_WRITE
        ),
        gamma_ = max(min((rho_ - rholSat)/(rhovSat - rholSat), scalar(1)), scalar(0))
    ),

This isn't Python, therefore that "gamma_" within "gamma_" is a fairly illegal operation here on the constructor...

Changing to this might work:

    gamma_
    (
        IOobject
        (
            runTime().timeName(),
            mesh,
            IOobject::NO_READ,
            IOobject::AUTO_WRITE
        ),
        max(min((rho_ - rholSat)/(rhovSat - rholSat), scalar(1)), scalar(0))
    ),

that said, it should be this:

    gamma_
    (
        IOobject
        (
            runTime().timeName(),
            mesh,
            IOobject::NO_READ,
            IOobject::AUTO_WRITE
        ),
        mesh,
        max(min((rho_ - rholSat)/(rhovSat - rholSat), scalar(1)), scalar(0))
    ),

to give a mesh structure then assign the same scalar value to all cells in the mesh.

[russel60]

Good catch - I think it may have helped because it changed the error message from an invalid void expression to the following:

fluidSolvers/cavitatingFluid/cavitatingFluid.C: In constructor ‘Foam::fluidSolvers::cavitatingFluid::cavitatingFluid(const Foam::fvMesh&)’:
fluidSolvers/cavitatingFluid/cavitatingFluid.C:209:5: error: no matching function for call to ‘Foam::GeometricField<double, Foam::fvPatchField, Foam::volMesh>::GeometricField(Foam::IOobject, const Foam::fvMesh&, Foam::tmp<Foam::GeometricField<double, Foam::fvPatchField, Foam::volMesh> >)’
     )
     ^

This corresponds to the same end parenthesis as before. I'm afraid I don't know enough to understand why making the above correction (adding 'mesh,' and removing 'gamma_ = ') changed the error message. Do you have any other suggestions?

[Daniel_Khazaei]

Originally Posted by russel60

This corresponds to the same end parenthesis as before. I'm afraid I don't know enough to understand why making the above correction (adding 'mesh,' and removing 'gamma_ = ') changed the error message. Do you have any other suggestions?

I have seen this kind of errors multiple times and it is actually a misleading error as already suggested by Bruno

When the compiler complains and it points you to last line of the constructor block of your code, then you have probably done something wrong in the initialization step way before that line...

check this line:

psi_("psi", psiModel_->psi())

I'm not quite sure, but if you have defined "const volScalarField& psi_" in your header file, the correct way to initialize psi_ would be:

psi_(psiModel_->psi())

[russel60]

Thank you Daniel for your reply. I tried replacing the psi_(psiModel_->psi()) line, but it still gave me an error. I assumed that the same convention applied for the following two lines:

    rhovSat("rhovSat", psiv*pSat),
    rhol0("rhol0", rholSat - pSat*psil),

so I corrected them to:

    rhovSat(psiv*pSat),
    rhol0(rholSat - pSat*psil),

I am still getting an error, but I assume that this was an improvement to my code.

Do you have any other ideas for corrections? Anything helps!

[Daniel_Khazaei]

Originally Posted by russel60

Thank you Daniel for your reply. I tried replacing the psi_(psiModel_->psi()) line, but it still gave me an error. I assumed that the same convention applied for the following two lines:

    rhovSat("rhovSat", psiv*pSat),
    rhol0("rhol0", rholSat - pSat*psil),

so I corrected them to:

    rhovSat(psiv*pSat),
    rhol0(rholSat - pSat*psil),

I am still getting an error, but I assume that this was an improvement to my code.

Do you have any other ideas for corrections? Anything helps!

Actually no, that was why I said if you have defined psi_ as follow in your header file, because I guessed you have probably defined psi_ as a reference to the psi variable defined in psiModel_:

"const volScalarField& psi_;"

If "rhovSat" and "rhol0" are dimensionedScalar, then your previous initialization was OK, no need to change them...

If you can share your .h and .C file, I maybe able to test and fix the error!
trying to debug on the fly is a bit harder without knowing how the variables are defined

[Daniel_Khazaei]

well, I was free last night and since you haven't provided the source code yet, I had to start from scratch! The solver does compile without any problem, but I didn't have time to check whether it actually runs or not...

also add these four lines in:

src/fluidSolidInteraction/Make/options

-I$(LIB_SRC)/thermophysicalModels/barotropicCompressibilityModel/lnInclude \

-lbarotropicCompressibilityModel \

src/fluidSolidInteraction/Make/files

fluidSolvers/cavitatingFluid/cavitatingFluid.C

also make sure the solvers are aware of the new library by adding the following line in their Make/files:

-lbarotropicCompressibilityModel \

[russel60]

Thank you for looking into this, Daniel! I looked through the code you posted, and I really appreciate how well commented and structured it is. Hopefully I can learn a lot from reading through and running this code!

I tried downloading and running the attached files, but I unfortunately was not able to get it to run right away. I will spend today debugging and will hopefully get it working, but I wanted to post the issues I saw in case I make it worse rather than better in my attempt to fix it

I suspect that you are running a different version of Openfoam. In my source code

~/foam/foam-extend-4.0/src/finiteVolume/fvMatrices/solvers/MULES$

I did not have any IMULES or CMULES files that were included. In an attempt to fix this, I found the required files on Github and downloaded them into the appropriate directory, then ran wmake to compile. Unfortunately, this did not fix the issue, and I got the following error:

fluidSolvers/cavitatingFluid/cavitatingFluid.C:34:20: fatal error: IMULES.H: No such file or directory
compilation terminated.

The only way I found to correct this error was to move all the required files (IMULES.H, CMULES.H, etc...) into the /cavitatingFluid directory. This was my naive way to getting the error messages to disappear, but doesn't seem like the correct way to do it...


Once I did that to all the files, however, I still have error messages. They mention 'redundant declarations' of some of the functions. Here is the first error message that appears:

In file included from fluidSolvers/cavitatingFluid/cavitatingFluid.C:37:0:
fluidSolvers/cavitatingFluid/IMULES.H:68:1: error: redundant redeclaration of ‘void Foam::MULES::implicitSolve(Foam::volScalarField&, const surfaceScalarField&, Foam::surfaceScalarField&, Foam::scalar, Foam::scalar)’ in same scope [-Werror=redundant-decls]
 );
 ^
In file included from fluidSolvers/cavitatingFluid/cavitatingFluid.C:36:0:
fluidSolvers/cavitatingFluid/MULES.H:96:6: note: previous declaration of ‘void Foam::MULES::implicitSolve(Foam::volScalarField&, const surfaceScalarField&, Foam::surfaceScalarField&, Foam::scalar, Foam::scalar)’
 void implicitSolve
      ^

Like I said above, I will try to step through and figure out these issues today. Did you run into any of these when compiling it on your end?

Thank you again for your help!

[Daniel_Khazaei]

Ooops... well I'm running my custom build of foam-extend-4.0...That MULES stuff are ported back from OpenFOAM-4.x! Although they are not needed as cavitatingFoam does not use any function from MULES, I have just forgotten to remove unnecessary headers...here you go:

[russel60]

So close! I think there is one thing leftover from your modified version of Foam_extend. Here is the error I got:

fluidSolvers/cavitatingFluid/cavitatingFluid.C: In constructor ‘Foam::fluidSolvers::cavitatingFluid::cavitatingFluid(const Foam::fvMesh&)’:
fluidSolvers/cavitatingFluid/cavitatingFluid.C:474:13: error: ‘MUST_READ_IF_MODIFIED’ is not a member of ‘Foam::IOobject’
             IOobject::MUST_READ_IF_MODIFIED,
             ^

I am tempted to replace this with with 'MUST_READ', but I saw on the documentation that 'MUST_READ' will not re-read, and 'MUST_READ_IF_MODIFIED' can re-read. Do you think this will be an issue?

EDIT: Since the 'MUST_READ' parameter only controls the reading of the thermodynamic properties, I determined it would be alright to 'MUST_READ'. With that addition, the solver compiles!!! Now I will begin trying to run it. More questions may follow...

[Daniel_Khazaei]

Originally Posted by russel60

So close! I think there is one thing leftover from your modified version of Foam_extend. Here is the error I got:

fluidSolvers/cavitatingFluid/cavitatingFluid.C: In constructor ‘Foam::fluidSolvers::cavitatingFluid::cavitatingFluid(const Foam::fvMesh&)’:
fluidSolvers/cavitatingFluid/cavitatingFluid.C:474:13: error: ‘MUST_READ_IF_MODIFIED’ is not a member of ‘Foam::IOobject’
             IOobject::MUST_READ_IF_MODIFIED,
             ^

I am tempted to replace this with with 'MUST_READ', but I saw on the documentation that 'MUST_READ' will not re-read, and 'MUST_READ_IF_MODIFIED' can re-read. Do you think this will be an issue?

Well, you are right! if you want to re-read the variables when dictionary is modified you should use MUST_READ_IF_MODIFIED (I have ported this functionality from foam-extend-4.1)!

However I can think of a trick to re-read the variables from thermodynamicProperties every time-step, which is not as efficient as MUST_READ_IF_MODIFIED:

1- define a new function in cavitatingFluid.H called readThermodynamicProperties:

void readThermodynamicProperties);

2-then in cavitatingFluid.C define it as follow:

void cavitatingFluid::readThermodynamicProperties()
{
    psil_ = thermodynamicProperties_.lookup("psil");

    rholSat_ = thermodynamicProperties_.lookup("rholSat");

    psiv_ = thermodynamicProperties_.lookup("psiv");

    pSat_ = thermodynamicProperties_.lookup("pSat");

    rhovSat_ = psiv_*pSat_;

    rhol0_ = rholSat_ - pSat_*psil_;

    rhoMin_ = thermodynamicProperties_.lookup("rhoMin");
}

3-Finally place the following anywhere before pimple loop:

readThermodynamicProperties();

[russel60]

Thanks Daniel!

I am trying to get this thing to run, and have run into an issue that I don't understand. I am getting this error:

--> FOAM FATAL IO ERROR:
keyword PIMPLE is undefined in dictionary "/home/russel60/foam/russel60-4.0/FluidSolidInteraction/run/fsiFoam/Test_BeamInCrossFlow/fluid/system/fvSolution"

file: /home/russel60/foam/russel60-4.0/FluidSolidInteraction/run/fsiFoam/Test_BeamInCrossFlow/fluid/system/fvSolution at line 21.

The line to which this error is referring is bold in the code below:

solvers
{
    p
    {
        solver          GAMG;

I am not seeing how I can change the solver for the pressure to fix this error. Does anyone have an idea of how to eliminate this error?

Thanks for any help!!

[Daniel_Khazaei]

Originally Posted by russel60

Thanks Daniel!

I am trying to get this thing to run, and have run into an issue that I don't understand. I am getting this error:

--> FOAM FATAL IO ERROR:
keyword PIMPLE is undefined in dictionary "/home/russel60/foam/russel60-4.0/FluidSolidInteraction/run/fsiFoam/Test_BeamInCrossFlow/fluid/system/fvSolution"

file: /home/russel60/foam/russel60-4.0/FluidSolidInteraction/run/fsiFoam/Test_BeamInCrossFlow/fluid/system/fvSolution at line 21.

this basically is a cavitatingFoam solver, so you can learn how to setup a case by checking its tutorial, the error is simply saying it can not find PIMPLE keyword! looking at one of the tutorials' fvSolution file:

PIMPLE
{
    nCorrectors                2;
    nNonOrthogonalCorrectors   1;

//    removeSwirl                2;
}

[russel60]

Thanks Daniel. Sorry about being lazy - I probably could have figured that last error out had I sat and thought about it more.

I am getting the solver to run now, but I am getting strange errors that should be more substantial to resolve. The first error I am getting is a convergence error, and I am not sure which methods of reducing convergence (reducing time interval, adding solver iterations, adding relaxation factors) will be effective. This is my first time facing compressible flow convergence problems, so I don't have much of a background to build on. I have tried adding solver iterations to the PIMPLE loop and reducing the time step down to 1e-8, but it still has issues. My gut tells me that there should be a way to get this to function without using a timestep that small.

Here is the relevant output from the solver for this test case:

Time = 0.001679, iteration: 2
Current fsi under-relaxation factor: 0.3
Maximal accumulated displacement of interface points: 3.29648
GAMG:  Solving for cellMotionUx, Initial residual = 0.98352, Final residual = 0.000333322, No Iterations 4
GAMG:  Solving for cellMotionUy, Initial residual = 0.988273, Final residual = 0.000347393, No Iterations 4
Evolving fluid solver: cavitatingFluid
phiv Courant Number mean: 0.0487225 max: 36.7028 acoustic max: 1.14288 velocity magnitude: 54182.9
PIMPLE: iteration 1
BiCGStab:  Solving for rho, Initial residual = 0.00670156, Final residual = 4.56921e-09, No Iterations 4
max-min rho: 831.466 123.913
max-min gamma: 0.850719 0
DILUPBiCG:  Solving for Ux, Initial residual = 0.972146, Final residual = 4.40214e-09, No Iterations 14
DILUPBiCG:  Solving for Uy, Initial residual = 0.992549, Final residual = 4.5559e-09, No Iterations 14
max(U) 74025.9
DILUPCG:  Solving for p, Initial residual = 0.759809, Final residual = 3.25184e-07, No Iterations 2
time step continuity errors : sum local = 0.000300917, global = 6.31167e-05, cumulative = 6.31167e-05
Predicted p max-min : 8.38927e+09 -1.71444e+09
max-min gamma: 1 0
Phase-change corrected p max-min : 8.76167e+09 0
max(U) 74025.9
DILUPCG:  Solving for p, Initial residual = 0.0781179, Final residual = 3.86097e-10, No Iterations 3
time step continuity errors : sum local = 0.000179644, global = -0.000129819, cumulative = -6.67027e-05
Predicted p max-min : 3.25006e+10 -1.34899e+07
max-min gamma: 0.850743 0
Phase-change corrected p max-min : 3.25006e+10 0
max(U) 74025.9
DILUPCG:  Solving for p, Initial residual = 0.0344993, Final residual = 1.59429e-08, No Iterations 3
time step continuity errors : sum local = 0.000430743, global = -0.000261194, cumulative = -0.000327897
Predicted p max-min : 4.92461e+10 -1.70199e+09
max-min gamma: 1 0
Phase-change corrected p max-min : 4.92461e+10 0
max(U) 74025.9
DILUPCG:  Solving for p, Initial residual = 0.049723, Final residual = 4.8541e-08, No Iterations 3
time step continuity errors : sum local = 0.000316062, global = -0.000333262, cumulative = -0.000661159
Predicted p max-min : 5.21414e+10 -2.71796e+09
max-min gamma: 1 0
Phase-change corrected p max-min : 5.21414e+10 0
max(U) 74025.9
GAMG:  Solving for p, Initial residual = 0.377605, Final residual = 4.66198e-09, No Iterations 19
time step continuity errors : sum local = 0.000914845, global = 0.000486651, cumulative = -0.000174508
Predicted p max-min : 5.82384e+09 -6.13846e+11
max-min gamma: 1 0
Phase-change corrected p max-min : 8.88034e+09 0
max(U) 370734

Any tips or tricks for how to help this test case converge would be greatly appreciated!!


I am getting a second error from another test case I am running with this solver. This case has no pressure differential across the boundary, and no velocity field boundary condition. The flow is driven by the shear force caused from a translating wall boundary condition on the top wall. I have imposed these boundary conditions with the following code from U/ :

boundaryField
{
    interface
    {
        type            movingWallVelocity;
        value           uniform (0 0 0);
    }
    outlet
    {
        type            zeroGradient;
    }
    inlet
    {
        type            fixedValue;
        value           uniform (0 0 0);
    }
    bottom
    {
        type            fixedValue;
        value           uniform (0 0 0);
    }
    top
    {
        type            translatingWallVelocity;
        U               (0.1 0 0);
        value           uniform (0 0 0);
    }

When I run this case, it appears as if the inner surface (labeled 'Interface') is creating a velocity field in the fluid. I think this is indicative of the solver getting confused as to which wall is actually moving. Where do you think this error could come from? I have attached an image showing the test case before and after I run it (showing velocity field contours).

As always, any and all help is greatly appreciated!!

[Daniel_Khazaei]

Something is clearly wrong...without knowing what density ratio and solid elastic modulus is used in your simulation I cant be much of a help

For the initial step, run the cavitatingFoam tutorials with fluidFoam solver and setting the solver as cavitatingFluid in fluidProperties!
This is to make sure that the cavitatingFluid produces the same result as cavitatingFoam and nothing is wrong with our modifications...

However, the interface relaxation factor and accumulated displacement are way too high for the solver to remain stable!
There should not be a need to use such a small time step, and if you are using strongly coupled approach the internal fsi loop over fluid and solid regions is usually enough to get convergence without applying relaxations or pimple corrector...what I usually do and suggest when dealing with fsi problems:

1- use "fluidFoam" to simulate only the fluid region without any mesh motion. Thus you make sure that the fluid part is OK before starting the more complex fsi simulation...

2- use "solidFoam" to do the same thing as step 1.

3- Finally start the fsi simulation: if there is any problem you can make sure that is related to mesh motion or fsi coupling!

For the second part, the "interface" boundary is defined as coupled in fsiProperties? if yes and you are setting it as "movingWallVelocity", then the solver is acting as expected since the viscous and pressure forces cause the solid part to deform...

[russel60]

Hi Daniel, thanks again for your comments.

I think that it is a really good idea to try to run the cavitatingFoam tutorials with my cavitatingFluid solver! Some initial difficulties I faced trying to do this: I do not have the functions 'fluidFoam' or 'solidFoam' that would allow me to run just the fluid or solid solvers. I did some quick Googling, and it appears that those functions are part of the FOAM_FSI extension from David Bloom. I read through that code, and it looks reasonably different from the FSI setup I have installed on my machine. Do you have this code in your FoamExtend build? Would it be worth it for me to use it?

As for the other case - you are right in that it is probably acting as expected. I displayed the velocity fields around the center bar, and the flow goes towards straight toward the shrinking bar.

I will try to reduce the interface relaxation factor and get the cavitatingFoam tutorials running.

If you are still curious, here are the contents of my 'rheologyProperties' file that controls the density and the modulus for the solid model:

// * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * //

planeStress no;

rheology
{
    type linearElastic;
    rho rho [1 -3 0 0 0 0 0] 2000;
    E E [1 -1 -2 0 0 0 0] 1e5; //Actual original: 1e4 //Original: 1.4e6;
    nu nu [0 0 0 0 0 0 0] 0.4;
}

// ************************************************************************* //

Thanks!

[Daniel_Khazaei]

Originally Posted by russel60

Hi Daniel, thanks again for your comments.

I think that it is a really good idea to try to run the cavitatingFoam tutorials with my cavitatingFluid solver! Some initial difficulties I faced trying to do this: I do not have the functions 'fluidFoam' or 'solidFoam' that would allow me to run just the fluid or solid solvers. I did some quick Googling, and it appears that those functions are part of the FOAM_FSI extension from David Bloom. I read through that code, and it looks reasonably different from the FSI setup I have installed on my machine. Do you have this code in your FoamExtend build? Would it be worth it for me to use it?

I have used the original package from OpenFOAM wiki, you should have both of them in the following directory:

/extend-bazaar/FluidSolidInteraction/src/solvers/

The fluid and solid solvers are defined as a module here:

/extend-bazaar/FluidSolidInteraction/src/fluidSolidInteraction/fluidSolvers/

/extend-bazaar/FluidSolidInteraction/src/fluidSolidInteraction/solidSolvers/

but the top level solvers that actually use those modules are defined here:

/extend-bazaar/FluidSolidInteraction/src/solvers/

It totally worth the time, they will save you much more time and headaches when you reach the part that the actual fsi simulation is going to start.

Originally Posted by russel60

If you are still curious, here are the contents of my 'rheologyProperties' file that controls the density and the modulus for the solid model:

planeStress no;

rheology
{
    type linearElastic;
    rho rho [1 -3 0 0 0 0 0] 2000;
    E E [1 -1 -2 0 0 0 0] 1e5; //Actual original: 1e4 //Original: 1.4e6;
    nu nu [0 0 0 0 0 0 0] 0.4;
}

Thanks!

With the above setting if the working fluid is water, then the density ratio is close to one and combined with the low modulus of elasticity...you need a very careful setup to make the simulation stable when dealing with the strongly coupled situation!

[russel60]

Originally Posted by Daniel_Khazaei

With the above setting if the working fluid is water, then the density ratio is close to one and combined with the low module of elasticity...you need a very careful setup to make the simulation stable when dealing with the strongly coupled situation!

You are very right about this line! I realized that I do not need such a low modulus. When I enter a more realistic value, my code works a lot better! I haven't done a full round of testing, but it is looking a lot better.

I see where you are directing me for the /fluidSolvers and /solidSolvers, and I do not have those. It will be my project for the weekend to install those on my machine and get everything up to date.

I am very grateful for your help, Daniel! It was very helpful to me, and hopefully will be very helpful to other visitors to this thread!

Tom