CFD Online Discussion Forums

CFD Online Discussion Forums (http://www.cfd-online.com/Forums/)
-   OpenFOAM Post-Processing (http://www.cfd-online.com/Forums/openfoam-post-processing/)
-   -   execFlowFunctionObjects - unknown field problem (http://www.cfd-online.com/Forums/openfoam-post-processing/92515-execflowfunctionobjects-unknown-field-problem.html)

Toorop September 16, 2011 06:31

execFlowFunctionObjects - unknown field problem
 
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
Code:

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.
Code:

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:
Code:

--> 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 September 17, 2011 04:12

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 September 17, 2011 05:07

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 September 19, 2011 11:29

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.
Code:

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:
Code:

--> 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 September 19, 2011 16:42

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:
    Code:

    execFlowFunctionObjects.C

    EXE = $(FOAM_APPBIN)/execFlowFunctionObjects

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

    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 September 20, 2011 10:52

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.
Code:

execFlowFunctionObjectsAddFields -fields '(T)' -time 0.1
The modified execFlowFunctionObjects.C file, the code is injected just after the phi, U, p reading procedure:
Code:

// 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 September 20, 2011 15:56

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 September 21, 2011 08:50

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

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_ May 26, 2015 08:27

Unknown field
 
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:
Code:

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:
Code:

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


All times are GMT -4. The time now is 04:11.