View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0001301 | OpenFOAM | Bug | public | 2014-05-21 15:33 | 2016-05-09 12:57 |
| Reporter | feymark | Assigned To | henry | ||
| Priority | normal | Severity | feature | Reproducibility | always |
| Status | resolved | Resolution | fixed | ||
| Platform | Linux | OS | Arch Linux | OS Version | (please specify) |
| Fixed in Version | dev | ||||
| Summary | 0001301: execFlowFunctionObjects doesn't work with multiphase flow | ||||
| Description | Running execFlowFunctionObjects on a multiphase flow case results in the following error, Time = 0 Reading phi Reading U Reading p --> FOAM Warning : --> FOAM FATAL IO ERROR: 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. End Regards, Andreas | ||||
| Tags | No tags attached. | ||||
|
|
Try the -noFlow argument if all you are interested in is generic postprocessing. |
|
|
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. |
|
|
The forces functionObject is special in that it needs a model to determine the wall stress. |
|
|
Reading of two-phase flow model (used in interFOAM) is not implemented in execFlowFunctionObjects. Will this be fixed? |
|
|
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"... |
|
|
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. |
|
|
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. |
|
|
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. |
|
|
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] 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 -noFunctionObjects 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 |
|
|
@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 |
|
|
@henry interFoam is fine. Thank you very much! |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2014-05-21 15:33 | feymark | New Issue | |
| 2014-05-22 16:48 |
|
Note Added: 0003078 | |
| 2014-05-27 10:45 | feymark | Note Added: 0003086 | |
| 2014-05-27 16:13 |
|
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 |
