CFD Online Logo CFD Online URL
www.cfd-online.com
[Sponsors]
Home > Forums > OpenFOAM Post-Processing

execFlowFunctionObjects - unknown field problem

Register Blogs Members List Search Today's Posts Mark Forums Read

Like Tree3Likes
  • 1 Post By wyldckat
  • 2 Post By wyldckat

Reply
 
LinkBack Thread Tools Display Modes
Old   September 16, 2011, 06:31
Default execFlowFunctionObjects - unknown field problem
  #1
Member
 
Tibor Nyers
Join Date: Jul 2010
Location: Hungary
Posts: 91
Rep Power: 8
Toorop is on a distinguished road
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!
Toorop is offline   Reply With Quote

Old   September 17, 2011, 04:12
Default
  #2
Super Moderator
 
Bruno Santos
Join Date: Mar 2009
Location: Lisbon, Portugal
Posts: 8,526
Blog Entries: 34
Rep Power: 86
wyldckat is just really nicewyldckat is just really nicewyldckat is just really nicewyldckat is just really nice
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

Last edited by wyldckat; September 17, 2011 at 04:13. Reason: typo
wyldckat is offline   Reply With Quote

Old   September 17, 2011, 05:07
Default
  #3
Super Moderator
 
Bruno Santos
Join Date: Mar 2009
Location: Lisbon, Portugal
Posts: 8,526
Blog Entries: 34
Rep Power: 86
wyldckat is just really nicewyldckat is just really nicewyldckat is just really nicewyldckat is just really nice
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
Pagoda likes this.
wyldckat is offline   Reply With Quote

Old   September 19, 2011, 11:29
Default
  #4
Member
 
Tibor Nyers
Join Date: Jul 2010
Location: Hungary
Posts: 91
Rep Power: 8
Toorop is on a distinguished road
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!
Toorop is offline   Reply With Quote

Old   September 19, 2011, 16:42
Default
  #5
Super Moderator
 
Bruno Santos
Join Date: Mar 2009
Location: Lisbon, Portugal
Posts: 8,526
Blog Entries: 34
Rep Power: 86
wyldckat is just really nicewyldckat is just really nicewyldckat is just really nicewyldckat is just really nice
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 and Pagoda like this.
wyldckat is offline   Reply With Quote

Old   September 20, 2011, 10:52
Default
  #6
Member
 
Tibor Nyers
Join Date: Jul 2010
Location: Hungary
Posts: 91
Rep Power: 8
Toorop is on a distinguished road
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.
Toorop is offline   Reply With Quote

Old   September 20, 2011, 15:56
Default
  #7
Super Moderator
 
Bruno Santos
Join Date: Mar 2009
Location: Lisbon, Portugal
Posts: 8,526
Blog Entries: 34
Rep Power: 86
wyldckat is just really nicewyldckat is just really nicewyldckat is just really nicewyldckat is just really nice
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
wyldckat is offline   Reply With Quote

Old   September 21, 2011, 08:50
Default
  #8
Member
 
Tibor Nyers
Join Date: Jul 2010
Location: Hungary
Posts: 91
Rep Power: 8
Toorop is on a distinguished road
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!
Toorop is offline   Reply With Quote

Old   May 26, 2015, 08:27
Default Unknown field
  #9
New Member
 
Join Date: May 2014
Posts: 25
Rep Power: 3
Phil_ is on a distinguished road
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
Phil_ is offline   Reply With Quote

Old   August 20, 2015, 17:27
Default
  #10
Super Moderator
 
Bruno Santos
Join Date: Mar 2009
Location: Lisbon, Portugal
Posts: 8,526
Blog Entries: 34
Rep Power: 86
wyldckat is just really nicewyldckat is just really nicewyldckat is just really nicewyldckat is just really nice
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:
Code:
    readFields
    {
        functionObjectLibs ( "libfieldFunctionObjects.so" );
        type            readFields;
        fields          (p U phi);
    }
Best regards,
Bruno
wyldckat is offline   Reply With Quote

Old   August 21, 2015, 03:14
Default
  #11
New Member
 
Join Date: May 2014
Posts: 25
Rep Power: 3
Phil_ is on a distinguished road
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:
Code:
    readExistingFields
    {
        functionObjectLibs
        (
            "libsimpleFunctionObjects.so"
        );
        type readAndUpdateFields;
        fields (ptot);
    }
Best regards,
Philip
Phil_ is offline   Reply With Quote

Reply

Tags
execflowfunctionobjects, patchmassflowaverage, unknown field

Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are On


Similar Threads
Thread Thread Starter Forum Replies Last Post
problems after decomposing for running alessio.nz OpenFOAM 5 April 20, 2011 08:44
Xwindows crash with paraview save srinath OpenFOAM Paraview & paraFoam 1 October 15, 2008 09:37
IcoLagrangianFoam problem in contiuation run amp field reading from input stream gschaider OpenFOAM Running, Solving & CFD 2 May 27, 2008 03:45
pressure field problem. michal FLUENT 1 March 18, 2004 15:45
Aeroacustic problem in Automotive field Gabriele Velenich Main CFD Forum 5 December 11, 2001 04:43


All times are GMT -4. The time now is 07:37.