View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0001431 | OpenFOAM | Bug | public | 2014-10-29 23:05 | 2015-10-22 09:59 |
| Reporter | GRAUPS | Assigned To | henry | ||
| Priority | normal | Severity | major | Reproducibility | always |
| Status | closed | Resolution | suspended | ||
| Platform | Intel | OS | RHEL | OS Version | 5.7 |
| Summary | 0001431: porousBafflePressure boundary isn't respected for incompressible model | ||||
| Description | It appears that the porousBafflePressure boundary condition isn't respected within the attached simple pipe model. The model runs, but I don't see the pressure drop that I'd expect given the velocity of the flow and coefficients for the porous jump. Also, I've tried changing the porous jump boundary conditions to multiple different numbers, it doesn't appear to affect the simulation at all. | ||||
| Steps To Reproduce | See the Allrun script. The porousBafflePressure BC is setup in the createBaffles dictionary. | ||||
| Additional Information | This might stem from another problem that was fixed about 8 months ago with the porousBafflePressure BC. The files... $FOAM_SRC/turbulenceModels/derivedFvPatchFields/porousBafflePressure/porousBafflePressureFvPatchField.H $FOAM_SRC/turbulenceModels/derivedFvPatchFields/porousBafflePressure/porousBafflePressureFvPatchFields.C ...were patched to fix a number of bugs (swapped the definition of the inertial and darcy coefficients and fixed the viscosity to use laminar viscosity instead of turbulent viscosity). However, I recently noticed that there appears to be a second porousBafflePressure BC in the code located here... $FOAM_SRC/TurbulenceModels/turbulenceModels/derivedFvPatchFields/porousBafflePressure/ ...when looking in the files there, I still see the old incorrect equations being used and it is now inconsistent with the other source files that were patched previously. | ||||
| Tags | No tags attached. | ||||
|
|
|
|
|
I ran your case but found there are no faces in the porousBaffle patch, hence no pressure drop. Could you check the mesh construction and get back to us. The problem with $FOAM_SRC/TurbulenceModels/turbulenceModels/derivedFvPatchFields/porousBafflePressure/ is not related as it is not used in simpleFoam. Thanks for alerting me to the inconsistency, I will correct it now. |
|
|
Henry, thanks for taking a look into this. I did some additional testing. 1.) If I change my Allrun script to run in serial only, faces do get assigned to the porousBaffle patch. This works. 2.) In a second test, I created a second decomposeParDict for the solving portion and added the "preserveFaceZones" keyword to the final decomposeParDict and populated it with my faceZone that I will use to create the baffles with after decomposing. This worked, and the porousBafflePressure BCs now have faces associated with them. 3.) In a third test, I moved the createBaffles line of the Allrun script to before the final decomposePar (after meshing and reconstructParMesh) and ran createBaffles in serial. I then added the "preservePatches" keyword to the final decomposeParDict and populated it with my porousBafflePressure patch names. This also worked. So it appears it is a requirement for any Baffle/Cyclic/faceZone used/created by createBaffles to have an associated "preserve" keyword in the decomposeParDict for parallel run. Because of this, it also requires a second decomposeParDict to be slipped in between meshing and running. I imagine if I didn't include this keyword, that this would also mess with faceZones being used as monitoring planes (using function objects) in the controlDict. If this is the case, then why are all faceZones not required to be preserved? |
|
|
About your decomposeParDict options: faceZones can coexist with processor faces. baffles (two back-to-back boundary faces) by their nature cannot. So e.g. monitoring (faceSource functionObject) can use faceZones on which some faces are processor faces. It is only when you create baffles that it requires the faces to be internal. |
|
|
Ok, I still think it should have a better failure mode rather than just ignoring the porousBaffle BC (or any other BC that uses baffles). In a larger model, such things can be hard to find and diagnose. An enhancement would be to have the createBaffles utility (when running in parallel) look for faces on a processor boundary and produce an error if the case wasn't decomposed properly to handle and use the baffles. This way the user will know upfront that he erred, instead of submitting a bug report. :) Another enhancement would be to have decomposePar automatically preserve baffles (assuming they were created previously). I realize now that this turned into an enhancement request rather than a bug report though, so if you want, you may close this ticket. |
|
|
createBaffles will warn (and continue): WarningIn("createFaces(..)") << "Found boundary face (in patch " << pp.name() << ") in faceZone " << fZone.name() << " to convert to baffle patch " << pbm[newPatchI].name() << endl If this does not work please let us know. |
|
|
Mattijs, I do not get that exact warning from the createBaffles utility in the case I uploaded. But I do get this one... --> FOAM Warning : From function createBaffles in file createBaffles.C at line 773 Setting field on boundary faces to zero. You might have to edit these fields. ...I assumed this is one I could ignore though. I did not get the "Found boundary face..." verbiage in any of the warnings during the simulation. So it appears that this may not be working. I am currently running 2.3.x-f84192b5106b in case something was changed since then. Thanks again for your response and discussion. |
|
|
Waiting for responses to questions before continuing. |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2014-10-29 23:05 | GRAUPS | New Issue | |
| 2014-10-29 23:05 | GRAUPS | File Added: tube_test_pj.tar.gz | |
| 2015-02-02 11:43 | henry | Note Added: 0003650 | |
| 2015-02-11 23:36 | GRAUPS | Note Added: 0003749 | |
| 2015-02-12 13:48 |
|
Note Added: 0003751 | |
| 2015-02-12 15:15 | GRAUPS | Note Added: 0003752 | |
| 2015-02-12 15:21 | GRAUPS | Note Edited: 0003752 | |
| 2015-02-13 10:23 |
|
Note Added: 0003755 | |
| 2015-02-13 17:09 | GRAUPS | Note Added: 0003759 | |
| 2015-10-22 09:59 | henry | Note Added: 0005459 | |
| 2015-10-22 09:59 | henry | Status | new => closed |
| 2015-10-22 09:59 | henry | Assigned To | => henry |
| 2015-10-22 09:59 | henry | Resolution | open => suspended |
