[Toorop]

Hi,

I would like to calculate the patchMassFlowAverage of a scalar at a patch with execFlowFunctionObjects utility.

Everything seems to be fine when I run the solver, it calculates and outputs the values as expected.
system/contolDict

functions 
{
    massFlowAverageT
    {
    type patchMassFlowAverage;
    functionObjectLibs ( "libsimpleFunctionObjects.so" );
    fields ( T );
    patches
    (
        myBoundaryPatchName
    );
    factor 1.0;
    verbose true;
    }
}

If I want to use it for an already completed simulation, OF complains about the missing T field. Actually, the utility doesn't list variable "T" when reading in the fields.

execFlowFunctionObjects -time 0.1

Create time

Create mesh for time = 0.1

Time = 0.1
    Reading phi
    Reading U
    Reading p

On the side note - it skips the turbulence properties as well.

The error message:

--> FOAM Warning : 
    From function probes::read()
    in file patch/patchFieldFunctionObject/patchFieldFunctionObject.C at line 91
    Unknown field T when reading dictionary "/home/user/OpenFOAM/user-2.0.x/run/projects/case/system/controlDict::functions::massFlowAverageT"
    Can only probe registered volScalar, volVector, volSphericalTensor, volSymmTensor and volTensor fields

How can one force the utility to access other fields beyond the default ones.
Thank you!

[wyldckat]

Greetings Tibor,

Mmm, I don't have much experience with this utility, but after looking at the source code (available online here), it looks like the T field might be read if your case has RAS or LES properties.

If that doesn't work, two other possibilities arise:

1. Copy the source code of the utility and modify it in your user folder, so it will read the field.
2. Or try using swak4Foam.

Keep in mind that execFlowFunctionObjects has some limitations; such example: http://www.openfoam.com/mantisbt/view.php?id=215

Best regards,
Bruno

[wyldckat]

Hello once again,

I think this deserved another post... I just saw that there was a major revamp of this utility, as shown here and here.
Try building the latest OpenFOAM 2.0.x and run execFlowFunctionObjects with the new "-noFlow" option!

Best regards,
Bruno

[Toorop]

Hi Bruno,

thank you for your kind reply.

I just got back here and noticed your last message. I have already started to make some modifications to the original utility but failed at some point. Should the new execFlowFunctionObjects fulfill my expectations, this issue can be pointless. However, I would be interested in the correct implement of my idea.

I added the new "fields" option to this utility - I checked the reconstructPar util how to do so - but couldn't get it work.

void Foam::calc(const argList& args, const Time& runTime, const fvMesh& mesh)
{
    Info<< "calc Entry Point" << endl;
    argList::addOption
    (
    "fields",
    "list",
    "specify a list of fields to be reconstructed. Eg, '(T0 T1 T2)' - "
    "regular expressions not currently supported"
    );

    Info<< "    Reading phi" << endl;
    ...

But OF says:

--> FOAM FATAL ERROR: 
Wrong number of arguments, expected 0 found 1
Invalid option: -fields

How this additional argument implementation should be done? Unlike the reconstructPar.C file, the execFlowFunctionObjects.C file doesn't have a main function, what's the trick?

I will have a look at the new features of execFlowFunctionObjects as well.
Thank you!

[wyldckat]

Hi Tibor,

Ah, in these cases where things seem to come from thin air, look at the following files on the solver/utility folder in question:

• Make/files:

  execFlowFunctionObjects.C
  
  EXE = $(FOAM_APPBIN)/execFlowFunctionObjects

  OK, nothing suspicious here...
• Make/options:

  EXE_INC = \
      -I$(LIB_SRC)/postProcessing/postCalc \
      -I$(LIB_SRC)/transportModels \
      -I$(LIB_SRC)/turbulenceModels \
      -I$(LIB_SRC)/turbulenceModels/LES/LESdeltas/lnInclude \
      -I$(LIB_SRC)/thermophysicalModels/basic/lnInclude \
      -I$(LIB_SRC)/finiteVolume/lnInclude
  
  EXE_LIBS = \
      $(FOAM_LIBBIN)/postCalc.o \
      -lincompressibleTransportModels \
      -lincompressibleRASModels \
      -lincompressibleLESModels \
      -lbasicThermophysicalModels \
      -lspecie \
      -lcompressibleRASModels \
      -lcompressibleLESModels \
      -lfiniteVolume \
      -lgenericPatchFields

  Ah HA! Notice the two lines I've put in bold? It's the file postCalc.o that has the missing code, which is already pre-built and ready to be used by any utility that uses the same Foam::calc() function, which comes pre-defined in calc.H!

If we visit the folder "$(LIB_SRC)/postProcessing/postCalc" - which in the shell environment translates to "$FOAM_SRC/postProcessing/postCalc" - there you will find the file postCalc.C that has the common pre-built code.

So, if you want to continue developing your own utility:

• Copy postCalc.C and calc.H to your utility's source code folder;
• Modify Make/options and remove the above two lines in bold.
• Add postCalc.C to Make/files.
• And finally modify the copied postCalc.C file to have the new command line options!

Let us know how things turn out

Best regards,
Bruno

[Toorop]

Bruno, I really appreciate your comprehensive guide, thanks a lot!

With your help I have managed to assemble the new utility, everything is fine at compilation - so far so good

But my field read falters, something is read in, but cannot be extracted out. For the sake of clarity, I limited the range of variables just to volScalarFields - so I set the fieldClassName to volScalarField :: DimensionedInternalField, and maybe this is the point where I miss something. I have the variable T as volScalarField and this is the variable I'm interested in.

execFlowFunctionObjectsAddFields -fields '(T)' -time 0.1

The modified execFlowFunctionObjects.C file, the code is injected just after the phi, U, p reading procedure:

// New Code Start
    HashSet<word> selectedFields;
    if (args.optionFound("fields"))
    {
    args.optionLookup("fields")() >> selectedFields;
    Info<< "fields option found" << endl;
    }

    const word& fieldClassName = DimensionedField<scalar, volMesh>::typeName;
    Info<< fieldClassName << endl;
    IOobjectList objects(mesh, runTime.timeName());
    IOobjectList fields = objects.lookupClass(fieldClassName);

    if (fields.size())
    {
    Info<< "    Reading additional " << fieldClassName << "s\n" << endl;
    }
    else
    {
    Info<< "fields.size() = 0" << endl;
    }

    forAllConstIter(IOobjectList, fields, fieldIter)
    {
    if
    (
        selectedFields.found(fieldIter()->name())
    )
    {
        Info<< "        " << fieldIter()->name() << endl;
    }
    }
// New Code End

The code steps into the first if statement, so I guess that part is OK. But then it skips all the relevant stages. It prints out that the fields size is zero and the whole iteration is omitted as well.

About the new execFlowFunctionObjects - it works like a charm with the -noFlow option.

A quick question: how to update OF correctly?
I made a git pull @ $WM_PROJECT_DIR folder, and if I remember correctly the bin and tutorial folder was gone amongst others and the Allwmake script was missing as well. So I deleted the whole stuff and made a fresh git clone and compiled it from the ground up.

[wyldckat]

Hi Tibor,

Sadly, I don't know enough yet about OpenFOAM's code to help you any further on the new utility My best suggestion would be to examine the new version of the utility and compare it with the old one, in order to figure out how things are really done or should be done. Here's the online commit difference log that shows what was changed: https://github.com/OpenFOAM/OpenFOAM...dc66aa85930451

As for updating from the git repository, "git pull" should do the trick, but you stumbled upon something that was done back in the 15-17th of August when the OpenFOAM Foundation was initiated. In a nutshell: all files were removed in the last commits (only in the last commits), remaining only modified versions of README.{html,org} for people to read and figure out what to do...
For more, you can read it here: https://github.com/OpenCFD/OpenFOAM-2.0.x/

As someone said: when in doubt, check the source

Best regards,
Bruno

[Toorop]

Bruno, thank you for all your help, hats off!

The -noFlow option works just great + I have a better understanding of the underlying structure of the code and the compilation procedure. Thx again!

[Phil_]

Hi,

I'm experiencing the same problem as Toorop when postprocessing a case using function objects, except the -noFlow flag does not help. This occurs with OF2.3.1.

The function object definition in system/controlDict looks like:

libs (
      "libOpenFOAM.so"
      "libsimpleSwakFunctionObjects.so"
      "libswakFunctionObjects.so"
      "libgroovyBC.so"
     );

functions
(
    massFlowAveragePtot
    {
        type                         patchMassFlowAverage;
        functionObjectLibs
        (
            "libsimpleFunctionObjects.so"
        );
        outputControlMode    timeStep;
        outputInterval            1;
        fields
        (
            ptot
        );
        patches
        (
            inlet
            outlet
        );
        factor               1.0;
        verbose            true;
   }
);

When executing execFlowFunctionObjects -noFlow -latestTime:

Create time

Create mesh for time = 1000

--> FOAM Warning : 
    From function SolverInfo::SolverInfo(const dictionary& dict,const objectRegistry &obr)
    in file SolverInfo/SolverInfo.C at line 70
    Can't find phi-field with name phi
Assumin incompressible solver
phi: phi
Compressible: 0
Turbulent: 0
LES: 0
--> FOAM Warning : 
    From function probes::read()
    in file patch/patchFieldFunctionObject/patchFieldFunctionObject.C at line 100
    Unknown field ptot when reading dictionary ".massFlowAveragePtot"
    Can only probe registered volScalar, volVector, volSphericalTensor, volSymmTensor and volTensor fields

Time = 1000
    Operating in no-flow mode; no models will be loaded. All vol, surface and point fields will be loaded.
Reading volScalarField ptot
Reading volScalarField p
Reading volVectorField U
Reading surfaceScalarField phi

End

The postProcessing directory is created but it's empty.

Best regards,
Philip

[wyldckat]

Greetings Philip,

I finally managed to take a look into this and I've now realized that I only mentioned the solution for that problem in the example case I have at https://github.com/wyldckat/execFunctionObjects/ - the solution for loading fields that aren't loaded automatically with the "-noFlow" option, can be loaded with another function object, for example:

    readFields
    {
        functionObjectLibs ( "libfieldFunctionObjects.so" );
        type            readFields;
        fields          (p U phi);
    }

Best regards,
Bruno

[Phil_]

Hi Bruno,

thank you for your help.

I already found out by myself but forgot to post the answer, sorry about that

Instead of libfieldFunctionObjects.so I'm using the libsimpleFunctionObjects.so:

    readExistingFields
    {
        functionObjectLibs
        (
            "libsimpleFunctionObjects.so"
        );
        type readAndUpdateFields;
        fields (ptot);
    }

Best regards,
Philip

[gned]

Hi Phil_ and wyldckat !
followed your precious posts and now, testing them on pitzdaily for instance, I can arrive to have
> execFlowFunctionObjects

to work , once added
readExistingFields { functionObjectLibs ( "libsimpleFunctionObjects.so" ); type readAndUpdateFields; fields (p); }in the controlDict file .
BUT if I leave this, the execution of the solver
> simpleFoam
on the contrary complains :
--> FOAM FATAL ERROR:
Field p does not exist

SO how to save both the options to have the function objects to work ?
Thanks

[Phil_]

Hi gned,

I'm using the functionObject only for post processing. This works via a dictionary and does not affect the solver:

execFlowFunctionObjects -dict system/functionObjectsDict

Hope this info is helpful.

Best regards,
Philip

[gned]

Yes ! the problem can be circumvented leaving the default dictionary of the functionObjects (controDict) clean and putting aside another user-created dictionary
functionObjectsDict like this one :

functions
{
 
  readExistingFields  
    {
        functionObjectLibs
        (
            "libsimpleFunctionObjects.so"

        );
        type readAndUpdateFields;
        fields ( p );
    }

staticPressureNew
{
    type staticPressureNew;
    functionObjectLibs//start a new line here :
(
"libmyWork.so"// my own created lib
);
    pName        p;
    rho 1.205;
    outputControl    outputTime;
}
}

and then execute the command
>>execFlowFunctionObjects -dict system/functionObjectsDict


Thank you !

i

[hanness]

Hi,

unfortunately I ran into a similar Problem and so far have not been able to solve it with the Information posted here. I'm using chtMultiRegionFoam from OF3.0.1 to simulate a simple pipe flow (regions fluid="water" and solid="pipe"). When running

execFlowFunctionObjects -region water -latestTime -dict system/postProcessingFunctionDict

with the following system/postProcessingDict

/*--------------------------------*- C++ -*----------------------------------*\
| =========                 |                                                 |
| \\      /  F ield         | OpenFOAM: The Open Source CFD Toolbox           |
|  \\    /   O peration     | Version:  3.0.1                                 |
|   \\  /    A nd           | Web:      www.OpenFOAM.org                      |
|    \\/     M anipulation  |                                                 |
\*---------------------------------------------------------------------------*/
FoamFile
{
    version     2.0;
    format      ascii;
    class       dictionary;
    location    "system";
    object      postProcessingFunctionDict;
}
// * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * //

functions
{
    PatchMassFlowAverage
    {
        type    patchMassFlowAverage;
        region  water;
//        functionObjectLibs ( "libsimpleSwakFunctionObjects.so" );
        patches (
                INLET
                OUTLET
                );
        fields  (
                T
                );
        outputControlMode       timeStep;
        outputInterval          1;
        verbose                 true;
    }

}
// ************************************************************************* //

it will abort with the following message

Create time
Create mesh water for time = 50000
    Reading T
--> FOAM Warning :
    From function SolverInfo::SolverInfo(const dictionary& dict,const objectRegistry &obr)
    in file SolverInfo/SolverInfo.C at line 70
    Can't find phi-field with name phi
Assumin incompressible solver
phi: phi
Compressible: 0
Turbulent: 0
LES: 0
Time = 50000
    Reading phi
    Reading U
    Reading p
No finite volume options present
Selecting thermodynamics package
{
    type            heRhoThermo;
    mixture         pureMixture;
    transport       polynomial;
    thermo          hPolynomial;
    equationOfState icoPolynomial;
    specie          specie;
    energy          sensibleEnthalpy;
}
Selecting turbulence model type RAS
Selecting RAS turbulence model kOmegaSST
Selecting patchDistMethod meshWave
kOmegaSSTCoeffs
{
...}
 
--> FOAM FATAL ERROR:
    request for polyMesh pipe from objectRegistry pipe failed
    available objects of type polyMesh are
1(salt)
    From function objectRegistry::lookupObject<Type>(const word&) const
    in file /home/openfoam/OpenFOAM/OpenFOAM-3.0.1/src/OpenFOAM/lnInclude/objectRegistryTemplates.C at line 198.
FOAM aborting
#0  Foam::error::printStack(Foam::Ostream&) at ??:?
#1  Foam::error::abort() at ??:?
#2  Foam::polyMesh const& Foam::objectRegistry::lookupObject<Foam::polyMesh>(Foam::word const&) const at ??:?
#3  Foam::compressible::turbulentTemperatureCoupledBaffleMixedFvPatchScalarField::updateCoeffs() at ??:?
#4  Foam::mixedFvPatchField<double>::evaluate(Foam::UPstream::commsTypes) at ??:?
#5  Foam::GeometricField<double, Foam::fvPatchField, Foam::volMesh>::GeometricBoundaryField::evaluate() at ??:?
#6  Foam::readAndUpdateFields::execute() at ??:?
#7  Foam::OutputFilterFunctionObject<Foam::readAndUpdateFields>::execute(bool) at ??:?
#8  Foam::functionObjectList::execute(bool) at ??:?
#9  ? at ??:?
#10  ? at ??:?
#11  __libc_start_main in "/lib/x86_64-linux-gnu/libc.so.6"
#12  ? at ??:?
Aborted (core dumped)

There are a few things that I don't understand.

1. First of all, it says that it can't read the phi-field, yet a few lines later it does read it.
2. Aparrently it's reading T but not executing the function?
3. Last, but not least it tries to read the pipe-mesh and fails to do so which spoils the rest. However, I ran the program on the fluid mesh and not the solid part, so why does it try to read it?

When I run the command with the -noFlow flag as suggested above things Change, but don't improve. The output is as follows

// * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * //
Create time
Create mesh water for time = 50000
--> FOAM Warning :
    From function SolverInfo::SolverInfo(const dictionary& dict,const objectRegistry &obr)
    in file SolverInfo/SolverInfo.C at line 70
    Can't find phi-field with name phi
Assumin incompressible solver
phi: phi
Compressible: 0
Turbulent: 0
LES: 0
--> FOAM Warning :
    From function probes::read()
    in file patch/patchFieldFunctionObject/patchFieldFunctionObject.C at line 100
    Unknown field T when reading dictionary "/home/hs/OpenFOAM/hs-3.0.0/run/Dynasalt/pipe/system/postProcessingFunctionDict.functions.PatchMassFlowAverage"
    Can only probe registered volScalar, volVector, volSphericalTensor, volSymmTensor and volTensor fields
Time = 50000
    Operating in no-flow mode; no models will be loaded. All vol, surface and point fields will be loaded.
Reading volScalarField kappa
Reading volScalarField rho
Reading volScalarField k
Reading volScalarField omega
Reading volScalarField alphat
Reading volScalarField nut
Reading volScalarField Cp
Reading volScalarField mu
Reading volScalarField p_rgh
Reading volScalarField alpha
Reading volScalarField p
Reading volScalarField T
Reading volScalarField h
Reading volVectorField U
Reading surfaceScalarField phi
Reading uniformDimensionedVectorField g
End

Now, it does not complain about the pipe-mesh anymore - so far so good.

1. It still complains about missing phi-field and thereafter reads it
2. It tries to execute the function before actually reading in the fields - why does it do so?

My last try has been to additionally load the fields by adding one of the functions mentioned above

//    readExistingFields
//    {
//      region  water;
//        type readAndUpdateFields;
//        fields (T);
//    }

    readFields
    {
        functionObjectLibs ( "libfieldFunctionObjects.so" );
        region  water;
        type            readFields;
        fields          (T );
    }

but both will result again in the region error

// * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * //
Create time
Create mesh water for time = 50000
    Reading T
--> FOAM Warning :
    From function SolverInfo::SolverInfo(const dictionary& dict,const objectRegistry &obr)
    in file SolverInfo/SolverInfo.C at line 70
    Can't find phi-field with name phi
Assumin incompressible solver
phi: phi
Compressible: 0
Turbulent: 0
LES: 0
Time = 50000
    Operating in no-flow mode; no models will be loaded. All vol, surface and point fields will be loaded.
Reading volScalarField kappa
Reading volScalarField rho
Reading volScalarField k
Reading volScalarField omega
Reading volScalarField alphat
Reading volScalarField nut
Reading volScalarField Cp
Reading volScalarField mu
Reading volScalarField p_rgh
Reading volScalarField alpha
Reading volScalarField p
Reading volScalarField T
Reading volScalarField h
Reading volVectorField U
Reading surfaceScalarField phi
Reading uniformDimensionedVectorField g

--> FOAM FATAL ERROR:
    request for polyMesh pipe from objectRegistry pipe failed
    available objects of type polyMesh are
1(salt)
    From function objectRegistry::lookupObject<Type>(const word&) const
    in file /home/openfoam/OpenFOAM/OpenFOAM-3.0.1/src/OpenFOAM/lnInclude/objectRegistryTemplates.C at line 198.
FOAM aborting
#0  Foam::error::printStack(Foam::Ostream&) at ??:?
#1  Foam::error::abort() at ??:?
#2  Foam::polyMesh const& Foam::objectRegistry::lookupObject<Foam::polyMesh>(Foam::word const&) const at ??:?
#3  Foam::compressible::turbulentTemperatureCoupledBaffleMixedFvPatchScalarField::updateCoeffs() at ??:?
#4  Foam::mixedFvPatchField<double>::evaluate(Foam::UPstream::commsTypes) at ??:?
#5  Foam::GeometricField<double, Foam::fvPatchField, Foam::volMesh>::GeometricBoundaryField::evaluate() at ??:?
#6  Foam::readAndUpdateFields::execute() at ??:?
#7  Foam::OutputFilterFunctionObject<Foam::readAndUpdateFields>::execute(bool) at ??:?
#8  Foam::functionObjectList::execute(bool) at ??:?
#9  ? at ??:?
#10  ? at ??:?
#11  __libc_start_main in "/lib/x86_64-linux-gnu/libc.so.6"
#12  ? at ??:?

Apparently the reading of the field works ("Reading T"), however, the intended function "patchMassFlowAverage" is not executed at all...

Sorry for the lengthy post, anybody any idea?

Tanks a lot!

[wyldckat]

Quick answer @hanness: I've spent over an hour trying to figure this out, without adding new code and I'm already too tired today to solve this one

As far as I can figure out, the correct way to do this is with funkyDoCalc. But I only figured this out after about an hour and I'm in no the mood to continue hunting for the solution Please search for examples on how to use funkyDoCalc.

[hanness]

Thank you Bruno for your neverending efforts to help!
Eventually, I ended up doing the entire postprocessing with pvpython since there is a little more to do than only calculate the mass flow weighted average of the temperature. It took me some time to get the syntax right, but once you got it it's a really powerful tool.
Nevertheless, there should be a simpler way to "just" get a mass flow averaged value. Next time I'll try with funkyDoCalc.

Best regards,
Hannes