View Issue Details

IDProjectCategoryView StatusLast Update
0001301OpenFOAM[All Projects] Bugpublic2016-05-09 12:57
ReporterfeymarkAssigned Tohenry 
Status resolvedResolutionfixed 
PlatformLinuxOSArch LinuxOS Version(please specify)
Product Version 
Fixed in Versiondev 
Summary0001301: execFlowFunctionObjects doesn't work with multiphase flow
DescriptionRunning execFlowFunctionObjects on a multiphase flow case results in the following error,

Time = 0
    Reading phi
    Reading U
    Reading p
--> FOAM Warning :
cannot find file

file: /home/feymark/OpenFOAM/feymark-2.3.x/run/NACA0009/v20/0/p at line 0.

    From function regIOobject::readStream()
    in file db/regIOobject/regIOobjectRead.C at line 73.


TagsNo tags attached.



2014-05-22 16:48


Try the -noFlow argument if all you are interested in is generic postprocessing.


2014-05-27 10:45

reporter   ~0003086

Okay, so I have a simulation that has been running for some time so I have the p field. If I use the -noFlow argument I'm not able to get any output from the forces. However, if I just run execFlowFunctionObjects the following error occurs,

Time = 0.38739
    Reading phi
    Reading U
    Reading p
No finite volume options present

--> FOAM Warning :
    From function void Foam::forces::initialise()
    in file forces/forces.C at line 190
    Could not find U, p or rho in database.
    De-activating forces.

Problem is that execFlowFunctionObjects doesn't read the rho field.


2014-05-27 16:13


The forces functionObject is special in that it needs a model to determine the wall stress.


2014-07-08 23:31

reporter   ~0003156

Reading of two-phase flow model (used in interFOAM) is not implemented in execFlowFunctionObjects. Will this be fixed?


2016-04-30 22:57

updater   ~0006214

I've been interested in this topic, mostly due to curiosity.
And after some researching into OpenFOAM's source code, the conclusion I've gotten so far is that it would make more sense to have a systematic way for the solvers themselves to handle execution of the function objects, without going into the outer solving loop.

Because the main problem is that there isn't exactly an easy to consolidate all transport models under a single structure. Specially multiphase solvers, given that each solver in this category can use one of several possible structures, may it be a mixture based structured or its own explicit separate phase management system.

This means that we either have:

 - to overload execFlowFunctionObjects with maybe a dozen transport models/systems and have some way to tell which one should be loaded ("type" definition inside "transportProperties" or "thermophysicalProperties");

 - or we delegate this feature to the solvers themselves, something like and option for "-onlyRunFunctionObjects", as a counter-option to "-noFunctionObjects". Because this way all of the necessary fields are loaded-in, along with any bits and pieces needed for running the case.

The second solution seems the more practical, at least for the near future, given that consolidating all transport models under a single management system would be a rather massive overhaul of OpenFOAM's infrastructure... at least based on what I've seen so far in the source code.

The problem with the second solution is that this would load some extra options to the solver that might lead to some confusion, for example the "-time" option would be a bit strange as an option when using "-help"...


2016-04-30 23:08

manager   ~0006215

I have also thought about this issue a lot and also came to the conclusion that it would be better if the solvers had an option to run the functionObjects but the problem is how to handle multiple time-steps, each of which must be read and processed which is very different to the handling of the time-loop in the solvers. The other option would be to separate the part of the solver code which constructs the fields and models in such a manner that it can be executed in the solver or in execFlowFunctionObjects.

Any of the options is a significant amount of work.


2016-05-01 09:27

manager   ~0006218

The simplest option for handling multiple time-steps would be to use a script (or program with a "system" call) to execute the solver to process the functionObjects separately for each time-step. The only major disadvantage is that the mesh will be read and constructed for each time-step which is an unnecessary overhead except for moving-mesh cases for which the mesh needs to be reconstructed anyway.


2016-05-01 19:52

updater   ~0006220

I was thinking about borrowing some of the ideas from execFlowFunctionObjects and using #include's to include the snippets of code needed for handling the 2 main phases of "-onlyRunFunctionObjects":

  1- First include would be for adding up the necessary command line options.

  2- Second include would be before the "while(runtime...)" loop, which would have a big if "-onlyRunFunctionObjects" block that would end with a "return 0" at the end and wrap up the solver before entering the loop.

This way it would be minimally invasive to most solvers and it would only grow the binaries a little bit.

The only issue I've seen so far is whether we will need a third header file for defining the dictionary re-loading function that execFlowFunctionObjects has internally, at least for "*DyMFoam" solvers.

Things didn't go as I wanted today, so I don't have a proof-of-concept of this.


2016-05-08 09:41

manager   ~0006245

commit 30e2f912e54a54a370509685197509e846ef3a9a

    simpleFoam: Added experimental "-postProcess" option
        Executes application functionObjects to post-process existing results.
        If the "dict" argument is specified the functionObjectList is constructed
        from that dictionary otherwise the functionObjectList is constructed from
        the "functions" sub-dictionary of "system/controlDict"
        Multiple time-steps may be processed and the standard utility time
        controls are provided.
    This functionality is equivalent to execFlowFunctionObjects but in a
    more efficient and general manner and will be included in all the
    OpenFOAM solvers if it proves effective and maintainable.
    The command-line options available with the "-postProcess" option may be
    obtained by
    simpleFoam -help -postProcess
    Usage: simpleFoam [OPTIONS]
      -case <dir> specify alternate case directory, default is the cwd
      -constant include the 'constant/' dir in the times list
      -dict <file> read control dictionary from specified location
      -latestTime select the latest time
      -newTimes select the new times
                        do not execute functionObjects
      -noZero exclude the '0/' dir from the times list, has precedence
                        over the -withZero option
      -parallel run in parallel
      -postProcess Execute functionObjects only
      -region <name> specify alternative mesh region
      -roots <(dir1 .. dirN)>
                        slave root directories for distributed running
      -time <ranges> comma-separated time ranges - eg, ':10,20,40:70,1000:'
      -srcDoc display source code in browser
      -doc display application documentation in browser
      -help print the usage


2016-05-08 14:36

manager   ~0006246

@feymark: It is not clear from your report which multiphase solver you are using but assuming it is interFoam this is fixed in OpenFOAM-dev by

commit 51281bdf8e85959398d0b1e648f6e762e17a2790
interFoam: Added -postProcess option


2016-05-09 08:12

reporter   ~0006249

@henry interFoam is fine. Thank you very much!

Issue History

Date Modified Username Field Change
2014-05-21 15:33 feymark New Issue
2014-05-22 16:48 user4 Note Added: 0003078
2014-05-27 10:45 feymark Note Added: 0003086
2014-05-27 16:13 user4 Note Added: 0003088
2014-07-08 23:31 gucong Note Added: 0003156
2015-08-17 01:13 wyldckat Severity minor => feature
2016-04-30 22:57 wyldckat Note Added: 0006214
2016-04-30 23:08 henry Note Added: 0006215
2016-05-01 09:27 henry Note Added: 0006218
2016-05-01 19:52 wyldckat Note Added: 0006220
2016-05-08 09:41 henry Note Added: 0006245
2016-05-08 14:36 henry Note Added: 0006246
2016-05-09 08:12 feymark Note Added: 0006249
2016-05-09 12:57 henry Status new => resolved
2016-05-09 12:57 henry Fixed in Version => dev
2016-05-09 12:57 henry Resolution open => fixed
2016-05-09 12:57 henry Assigned To => henry