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

execFlowFunctionObjects - unknown field problem

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

Like Tree4Likes
  • 1 Post By wyldckat
  • 2 Post By wyldckat
  • 1 Post By hanness

Reply
 
LinkBack Thread Tools Search this Thread 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: 17
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
Retired Super Moderator
 
Bruno Santos
Join Date: Mar 2009
Location: Lisbon, Portugal
Posts: 10,978
Blog Entries: 45
Rep Power: 128
wyldckat is a name known to allwyldckat is a name known to allwyldckat is a name known to allwyldckat is a name known to allwyldckat is a name known to allwyldckat is a name known to all
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
Retired Super Moderator
 
Bruno Santos
Join Date: Mar 2009
Location: Lisbon, Portugal
Posts: 10,978
Blog Entries: 45
Rep Power: 128
wyldckat is a name known to allwyldckat is a name known to allwyldckat is a name known to allwyldckat is a name known to allwyldckat is a name known to allwyldckat is a name known to all
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: 17
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
Retired Super Moderator
 
Bruno Santos
Join Date: Mar 2009
Location: Lisbon, Portugal
Posts: 10,978
Blog Entries: 45
Rep Power: 128
wyldckat is a name known to allwyldckat is a name known to allwyldckat is a name known to allwyldckat is a name known to allwyldckat is a name known to allwyldckat is a name known to all
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: 17
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
Retired Super Moderator
 
Bruno Santos
Join Date: Mar 2009
Location: Lisbon, Portugal
Posts: 10,978
Blog Entries: 45
Rep Power: 128
wyldckat is a name known to allwyldckat is a name known to allwyldckat is a name known to allwyldckat is a name known to allwyldckat is a name known to allwyldckat is a name known to all
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: 17
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
Member
 
Join Date: May 2014
Posts: 40
Rep Power: 12
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
Retired Super Moderator
 
Bruno Santos
Join Date: Mar 2009
Location: Lisbon, Portugal
Posts: 10,978
Blog Entries: 45
Rep Power: 128
wyldckat is a name known to allwyldckat is a name known to allwyldckat is a name known to allwyldckat is a name known to allwyldckat is a name known to allwyldckat is a name known to all
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
Member
 
Join Date: May 2014
Posts: 40
Rep Power: 12
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

Old   October 6, 2015, 12:44
Default
  #12
New Member
 
gned
Join Date: Oct 2012
Posts: 18
Rep Power: 13
gned is on a distinguished road
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
gned is offline   Reply With Quote

Old   October 6, 2015, 16:08
Default
  #13
Member
 
Join Date: May 2014
Posts: 40
Rep Power: 12
Phil_ is on a distinguished road
Hi gned,

I'm using the functionObject only for post processing. This works via a dictionary and does not affect the solver:
Code:
execFlowFunctionObjects -dict system/functionObjectsDict
Hope this info is helpful.

Best regards,
Philip
Phil_ is offline   Reply With Quote

Old   October 8, 2015, 09:41
Default functionObjectsDict
  #14
New Member
 
gned
Join Date: Oct 2012
Posts: 18
Rep Power: 13
gned is on a distinguished road
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 :

Code:
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
gned is offline   Reply With Quote

Old   March 9, 2016, 03:56
Default
  #15
Member
 
hannes
Join Date: Mar 2013
Posts: 47
Rep Power: 13
hanness is on a distinguished road
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
Code:
execFlowFunctionObjects -region water -latestTime -dict system/postProcessingFunctionDict
with the following system/postProcessingDict
Code:
/*--------------------------------*- 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
Code:
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
Code:
// * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * //
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
Code:
//    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
Code:
// * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * //
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!
hanness is offline   Reply With Quote

Old   March 13, 2016, 16:05
Default
  #16
Retired Super Moderator
 
Bruno Santos
Join Date: Mar 2009
Location: Lisbon, Portugal
Posts: 10,978
Blog Entries: 45
Rep Power: 128
wyldckat is a name known to allwyldckat is a name known to allwyldckat is a name known to allwyldckat is a name known to allwyldckat is a name known to allwyldckat is a name known to all
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.
__________________
wyldckat is offline   Reply With Quote

Old   March 14, 2016, 03:25
Default
  #17
Member
 
hannes
Join Date: Mar 2013
Posts: 47
Rep Power: 13
hanness is on a distinguished road
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
wyldckat likes this.
hanness is offline   Reply With Quote

Reply

Tags
execflowfunctionobjects, patchmassflowaverage, unknown field

Thread Tools Search this Thread
Search this Thread:

Advanced Search
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 Off
Pingbacks are On
Refbacks are On


Similar Threads
Thread Thread Starter Forum Replies Last Post
problems after decomposing for running alessio.nz OpenFOAM 7 March 5, 2021 04:49
[OpenFOAM] Xwindows crash with paraview save srinath ParaView 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 14:45
Aeroacustic problem in Automotive field Gabriele Velenich Main CFD Forum 5 December 11, 2001 03:43


All times are GMT -4. The time now is 08:45.