[decah]

Dear Foamers

I am a beginner OF programmer trying to compile a simple modification to the driftFluxFoam velocity correction function Udm that looks like:



where f(x) is a combination of variables and g is gravitational acceleration.

My issue is getting the function to read g, which is a file in the transportProperties dictionary. When compiling I get an error messages like ‘g was not declared in this scope’.
I have tried many things like:
1. including the “readGravitationalAcceleration.H” file within some of the related files
2. adding a dimensionedVector term called ‘grav’ to the transportProperties dictionary itself then calling it along with the other velocity function variables
3. trying to define const uniformDimensionedVectorField in the modified file
4. looking at other default solvers and their functions for similar calculations

I feel like this is something straightforward and it's just lack of experience getting in the way but I've been at it for days now and any help would be much appreciated!!

Many Thanks!

Declan

[GerhardHolzinger]

Since, you are about to create your own relativeVelocityModel, which is a separate compilation unit than the solver itself, you need to include the header file for the appropriate data type. Secondly, you can look-up the gravity field from the object data base of OpenFOAM.

In the code below, the necessary include statement as well as the construction by look-up is listed. You might want to put the include statement into the header of your relativeVelocityModel class, and the look-up statement into the function-body of your Udm() method, or whereever you need to access gravity.

// include data type, if necessary
#include "uniformDimensionedFields.H"

uniformDimensionedVectorField g
(
    mesh.lookupObject<uniformDimensionedVectorField>("g")
);

[decah]

Hi Gerhard, thank you for your post.

I have not yet been able to solve the problem! I am creating an alternative relative velocity model (simple and general are the default models) called general2 and I would like to define Udm within the general2.C file.

If I declare

uniformDimensionedVectorField g
(mesh.lookupObject<uniformDimensionedVectorField>("g"));

in this file I get errors complaining that the mesh has not been defined here.

I feel there must be a way to simply read the g file located in the constant folder without having to read it from the mesh itself? Could I somehow get transportProperties to read it for me and then just take it from transportProperties with all the other parameters?

[GerhardHolzinger]

Originally Posted by decah

Hi Gerhard, thank you for your post.

I have not yet been able to solve the problem! I am creating an alternative relative velocity model (simple and general are the default models) called general2 and I would like to define Udm within the general2.C file.

I feel there must be a way to simply read the g file located in the constant folder without having to read it from the mesh itself? Could I somehow get transportProperties to read it for me and then just take it from transportProperties with all the other parameters?

Of course mesh has not been defined in your class general2. However, you can get a reference to the mesh.

If you take a look at the constructor of the base class for the relative velocity models, especially, the second and third argument of the IOobject constructor, shows you how to get a reference to the mesh and the run-time objects.

Foam::relativeVelocityModel::relativeVelocityModel
(
    const dictionary& dict,
    const incompressibleTwoPhaseInteractingMixture& mixture
)
:
    mixture_(mixture),
    alphac_(mixture.alpha2()),
    alphad_(mixture.alpha1()),
    rhoc_(mixture.rhoc()),
    rhod_(mixture.rhod()),

    Udm_
    (
        IOobject
        (
            "Udm",
            alphac_.time().timeName(),
            alphac_.mesh(),
            IOobject::READ_IF_PRESENT,
            IOobject::AUTO_WRITE
        ),
        alphac_.mesh(),
        dimensionedVector("Udm", dimVelocity, Zero),
        UdmPatchFieldTypes()
    )
{}

There is no need to read gravity from the constant directory again, as it has been already read. And it has been registered with the mesh, hence you can use object lookup.
Which is done e.g. in twoPhaseEulerFoam/twoPhaseSystem/diameterModels/IATE/IATEsources/IATEsource/IATEsource.C

The whole purpose of OpenFOAM's object registry is to avoid every class reading fields on their own. If the solver and the drag model would read the velocity field independently, you end up with two independent copies of U. If the solver updates U, then the drag models needs to be told, that its copy of U is now outdated. This is a can of worms nobody really wants opened. Thus, you get yourself a reference to the one and only velocity field, which is by virtue of being the only one, always up to date.

[decah]

Hi Gerhard,

Thanks again for your help and explaining about the OF objectRegistry.

I was eventually able to implement g in the following way:

 g_
    (
        IOobject
        (
            "g",
            alphac_.time().timeName(),
            alphac_.mesh(),
            IOobject::MUST_READ,
            IOobject::NO_WRITE
        ),
    )

A note for anyone else doing this, I had to save the g file from transportProperties in the starting time folder.