Development issueshttps://develop.openfoam.com/groups/Development/-/issues2016-07-14T02:43:14Zhttps://develop.openfoam.com/Development/openfoam/-/issues/182Opposite displacement in linearMotion class ( solidBodyMotionFunction)2016-07-14T02:43:14ZAdminOpposite displacement in linearMotion class ( solidBodyMotionFunction)Since commit, 6a5d5e903e68f288261ae60a410305f8fbd26f96 , ("septernion: Changed definition of the forward transformation for consistency with spatialTransform") , the transformation() function in linearMotion.C:69 calculates the displac...Since commit, 6a5d5e903e68f288261ae60a410305f8fbd26f96 , ("septernion: Changed definition of the forward transformation for consistency with spatialTransform") , the transformation() function in linearMotion.C:69 calculates the displacement vector of the septernion as: (-velocity_*t) and therefore, the displacement direction is inverted.
Mattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comhttps://develop.openfoam.com/Development/openfoam/-/issues/1Lagrangian standard patch interaction model errors2023-08-19T21:13:18ZAdminLagrangian standard patch interaction model errorsReported statistics are incorrect
* Counters of number and mass of particles continuously reset on output
* Mass escape/stick not calculatedReported statistics are incorrect
* Counters of number and mass of particles continuously reset on output
* Mass escape/stick not calculatedFunctionality migration from internal development lineAdminAdminhttps://develop.openfoam.com/Development/openfoam/-/issues/238strange behaviour of interCondensingEvaporatingFoam for a simple 1D Stefan co...2017-01-27T05:37:29ZAdminstrange behaviour of interCondensingEvaporatingFoam for a simple 1D Stefan condensation test caseI created simple 1D test case for condensation, which is basically the Stefan problem for which analytical
solution exists. The test case is a rod filled with a water vapour (alpha.liquid = 0) at saturation temperature of 380.26 K. In th...I created simple 1D test case for condensation, which is basically the Stefan problem for which analytical
solution exists. The test case is a rod filled with a water vapour (alpha.liquid = 0) at saturation temperature of 380.26 K. In the first case (StefanCond_left) I set:
- on the left wall T = 370.26 K, the right wall is adiabatic and for the rest of the surfaces, empty boundary condition is appllied . In this configuration one can observe rapid condensation and after time 0.1 s all vapour is condensed (alpha.liquid = 1)
In the second case (StefanCond_right) I changed only the side of the cold wall, namely:
- the left wall is adiabatic, the right wall is at T = 370.26 K and for the rest of the surfaces, empty boundary condition is appllied . In this configuration one can observe very slow condensation and after time 0.1 s only 0.0254598 of the vapour condensed (alpha.liquid = 0.0254598).
Is it a bug? The solution should be the mirror image. Can you explain why the condensation rate decreases so much while it shouldn't chaneg? Here are the two mentioned test cases (35MB):
http://fluid.itcmp.pwr.wroc.pl/~pblasiak/download/StefanCond.tar.gzSergio FerrarisSergio Ferrarishttps://develop.openfoam.com/Development/openfoam/-/issues/107BUG: Erroneous output/crash for forceCoeffs and forceCoeffBins using *Mean va...2016-06-10T15:06:02ZPrashant SonakarBUG: Erroneous output/crash for forceCoeffs and forceCoeffBins using *Mean valuesWhen averaging of the field is activated at later time in simulation, using them for forces FO can lead to failure.
- using evaluateControl is one solution
But when no information is provided, it produces
- erroneous output for fo...When averaging of the field is activated at later time in simulation, using them for forces FO can lead to failure.
- using evaluateControl is one solution
But when no information is provided, it produces
- erroneous output for forceCoeffs
- crash when using forceCoeffsBin
[motorBike_forceCoeff-withMeanValues.tgz](/uploads/09f689a12196bf17a9e3bb6ee754ab78/motorBike_forceCoeff-withMeanValues.tgz)
AdminAdminhttps://develop.openfoam.com/Development/openfoam/-/issues/1753TableBase copy constructor does not clear out interpolationWeights / no clone...2021-07-07T08:55:02ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comTableBase copy constructor does not clear out interpolationWeights / no clone() functionality<!--
*** Please read this first! ***
Before opening a new issue, make sure to search for keywords in the issues
filtered by the "bug" label and check to see if it has already been reported
You can see how your report will be ...<!--
*** Please read this first! ***
Before opening a new issue, make sure to search for keywords in the issues
filtered by the "bug" label and check to see if it has already been reported
You can see how your report will be rendered on the platform by using the
"preview" tab above
-->
<!--
All text between these markers are comments and will not be present in the
report
-->
### Summary
<!-- Summarize the bug encountered concisely -->
TableBase might allocate an interpolator (interpolationWeights). interpolationWeights holds a reference to the set of input samples. When copying the TableBase it copies these interpolationWeights which now has a reference to some outside data. If this has gone out of scope the interpolator will access invalid data.
### Steps to reproduce
<!-- How one can reproduce the issue - this is very important -->
Not trivial. Use copy construct on Table (or TableFile). Could not replicate it on e.g. damBreakWithObstacle (topo changes) with U set to uniformFixedValue with a table.
### Example case
<!--
If possible, please create a SMALL example and attach it to your report
If you are using an older version of OpenFOAM this will also determine
whether the bug has been fixed in a more recent version
-->
### What is the current *bug* behaviour?
<!-- What actually happens -->
### What is the expected *correct* behavior?
<!-- What you should see instead -->
### Relevant logs and/or images
<!--
Paste any relevant logs - please use code blocks (```) to format console
output, logs, and code as it's very hard to read otherwise.
-->
### Environment information
<!--
Providing details of your set-up can help us identify any issues, e.g.
OpenFOAM version : v1806|v1812|v1906 etc
Operating system : ubuntu|openSUSE|centos etc
Hardware info : any info that may help?
Compiler : gcc|intel|clang etc
-->
- OpenFOAM version : v2006
- Operating system : any
### Possible fixes
<!--
If you can, link to the line of code that might be responsible for the
problem
The "/label ~bug" text is a gitlab flag that will add the "bug" label to this
issue
-->
Reset autoPtrs in copy constructor. This will trigger rebuilding the interpolator
```
template<class Type>
Foam::Function1Types::TableBase<Type>::TableBase(const TableBase<Type>& tbl)
:
Function1<Type>(tbl),
name_(tbl.name_),
bounding_(tbl.bounding_),
interpolationScheme_(tbl.interpolationScheme_),
table_(tbl.table_),
tableSamplesPtr_(nullptr),
interpolatorPtr_(nullptr)
{}
```Mattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comhttps://develop.openfoam.com/Development/openfoam/-/issues/251foamCalc not reading arguments when executed through runParallel2016-11-11T07:38:37ZRoger AlmenarfoamCalc not reading arguments when executed through runParallelWhen I try to exectute foamCalc through runParallel, I get following errors (command runParallel foamCalc mag U):
[ram@pc-ram xyz]$ more log.foamCalc
...When I try to exectute foamCalc through runParallel, I get following errors (command runParallel foamCalc mag U):
[ram@pc-ram xyz]$ more log.foamCalc
--> FOAM FATAL ERROR:
Unknown calcType type -parallel
Valid calcType selections are:
8
(
addSubtract
components
div
interpolate
mag
magGrad
magSqr
randomise
)
From function static Foam::autoPtr<Foam::calcType> Foam::calcType::New(const Foam::word&)
in file calcType/calcTypeNew.C at line 53.
FOAM aborting
Selecting calcType -parallel
Selecting calcType -parallel
--> FOAM FATAL ERROR:
Unknown calcType type -parallel
Valid calcType selections are:
However, running the full command "mpirun -np 2 foamCalc mag U -parallel" runs without issues.https://develop.openfoam.com/Development/openfoam/-/issues/172probes do not reset search tree2016-12-23T12:44:52ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comprobes do not reset search treepolyMesh::movePoints does not clear out the cellTree
so there might be an inconsistency between tree and mesh.
(the only other data field not clear is the tetPtBaseIs but that probably does not want clearing)
Issue came up in prob...polyMesh::movePoints does not clear out the cellTree
so there might be an inconsistency between tree and mesh.
(the only other data field not clear is the tetPtBaseIs but that probably does not want clearing)
Issue came up in probes with fixedLocations_. Attached workaround for probes.C.
[probes.C](/uploads/3573abdb2621f318f3b5123d77c18632/probes.C)
but probably needs to go into polyMesh::movePointsVersion v1612https://develop.openfoam.com/Development/openfoam/-/issues/169Unsigned versions have the same pTraits limits as their signed counterparts.2016-10-01T08:53:50ZMark OLESENUnsigned versions have the same pTraits limits as their signed counterparts.In uint32.C, uint64.C:
const uint64_t Foam::pTraits<uint64_t>::min = INT64_MIN;
const uint64_t Foam::pTraits<uint64_t>::max = INT64_MAX;
const uint32_t Foam::pTraits<uint32_t>::min = INT32_MIN;
const uint32_t Foam...In uint32.C, uint64.C:
const uint64_t Foam::pTraits<uint64_t>::min = INT64_MIN;
const uint64_t Foam::pTraits<uint64_t>::max = INT64_MAX;
const uint32_t Foam::pTraits<uint32_t>::min = INT32_MIN;
const uint32_t Foam::pTraits<uint32_t>::max = INT32_MAX;
STYLE:
uLabel.H includes the zero-sized file `uLabelSpecific.H`, which should be removed as clutter.
Also reported on mantis as http://bugs.openfoam.org/view.php?id=2137
@Mattijshttps://develop.openfoam.com/Development/openfoam/-/issues/153BUG: fixedMean BC "unallocated"2023-12-07T19:02:00ZPrashant SonakarBUG: fixedMean BC "unallocated"Attached case illustrates the bug in develop branch.
[pitzDaily_fixedMean.tgz](/uploads/500c361b6a284a1297e6c9d2a6a12298/pitzDaily_fixedMean.tgz)
It is when included file defines the value for meanValue entry.
```
Constructin...Attached case illustrates the bug in develop branch.
[pitzDaily_fixedMean.tgz](/uploads/500c361b6a284a1297e6c9d2a6a12298/pitzDaily_fixedMean.tgz)
It is when included file defines the value for meanValue entry.
```
Constructing velocity potential field Phi
No MRF models present
Calculating potential flow
--> FOAM FATAL ERROR:
object of type N4Foam9Function1IdEE is not allocated
From function T* Foam::autoPtr<T>::operator->() [with T = Foam::Function1<double>]
in file /xxx/OpenFOAM-plus.develop/src/OpenFOAM/lnInclude/autoPtrI.H at line 176.
FOAM aborting
#0 Foam::error::printStack(Foam::Ostream&) at ??:?
#1 Foam::error::abort() at ??:?
#2 Foam::fixedMeanFvPatchField<double>::updateCoeffs() at ??:?
#3 Foam::fvMatrix<double>::fvMatrix(Foam::GeometricField<double, Foam::fvPatchField, Foam::volMesh> const&, Foam::dimensionSet const&) at ??:?
#4 Foam::fv::gaussLaplacianScheme<double, double>::fvmLaplacianUncorrected(Foam::GeometricField<double, Foam::fvsPatchField, Foam::surfaceMesh> const&, Foam::GeometricField<double, Foam::fvsPatchField, Foam::surfaceMesh> const&, Foam::GeometricField<double, Foam::fvPatchField, Foam::volMesh> const&) at ??:?
#5 Foam::fv::gaussLaplacianScheme<double, double>::fvmLaplacian(Foam::GeometricField<double, Foam::fvsPatchField, Foam::surfaceMesh> const&, Foam::GeometricField<double, Foam::fvPatchField, Foam::volMesh> const&) at ??:?
#6 Foam::tmp<Foam::fvMatrix<double> > Foam::fvm::laplacian<double, double>(Foam::GeometricField<double, Foam::fvsPatchField, Foam::surfaceMesh> const&, Foam::GeometricField<double, Foam::fvPatchField, Foam::volMesh> const&, Foam::word const&) at ??:?
#7 ? at ??:?
#8 ? at ??:?
#9 __libc_start_main in "/lib64/libc.so.6"
#10 ? at ??:?
```
@Sergio @Mattijs AdminAdminhttps://develop.openfoam.com/Development/openfoam/-/issues/1754LES without any SGS model2020-06-30T05:44:57ZSeo Dong-HoLES without any SGS modelHi
I'd like to do a large eddy simulation **without any SGS model** to compare with the results with it.
How can I set up "turbuleceProperties", etc. on OpenFOAM?
Thank you.Hi
I'd like to do a large eddy simulation **without any SGS model** to compare with the results with it.
How can I set up "turbuleceProperties", etc. on OpenFOAM?
Thank you.https://develop.openfoam.com/Development/openfoam/-/issues/1756Confusing typo in boundary conditions docs2020-07-02T10:14:26ZArashConfusing typo in boundary conditions docsI believe the description of `pressureInletOutletVelocity` is wrong.
>This velocity inlet/outlet boundary condition is applied to **pressure** boundaries where the pressure is specified. A zero-gradient condition is applied for outflow...I believe the description of `pressureInletOutletVelocity` is wrong.
>This velocity inlet/outlet boundary condition is applied to **pressure** boundaries where the pressure is specified. A zero-gradient condition is applied for outflow (as defined by the flux); for inflow, the velocity is obtained from the patch-face normal component of the internal-cell value.
Yet, as the name suggests (or looking at the `Vector` type in the source code implies that it should be applied on **velocity**. It is iterated both in [site](https://www.openfoam.com/documentation/user-guide/standard-boundaryconditions.php) and the [Doxygen](https://www.openfoam.com/documentation/guides/latest/api/classFoam_1_1pressureInletOutletVelocityFvPatchVectorField.html#details) doc. It's not by any means critical, yet it makes it a bit harder to puzzle out for beginners like me.
The very same thing has recurred in `pressureDirectedInletOutletVelocityFvPatchVectorField` too: [Doxygen](https://www.openfoam.com/documentation/guides/latest/api/classFoam_1_1pressureDirectedInletOutletVelocityFvPatchVectorField.html#details)https://develop.openfoam.com/Development/openfoam/-/issues/1757dash bug with string expansion and assignment of default values2020-11-26T13:55:23ZMark OLESENdash bug with string expansion and assignment of default valuesNoticed when compiling OpenFOAM-v2006 modules with ubuntu _bionic_ (18.04) that the module prefix is not being correctly set. Seems to be a weird bug in the `dash` shell expansions.
Starting from any non-root directory
```
echo "$PWD"
-...Noticed when compiling OpenFOAM-v2006 modules with ubuntu _bionic_ (18.04) that the module prefix is not being correctly set. Seems to be a weird bug in the `dash` shell expansions.
Starting from any non-root directory
```
echo "$PWD"
-> /home/user/openfoam/BuildEnv/scratch
```
dash 0.5.8-2.10 (bionic) shows this
```
unset test1
echo "${test1:=${PWD%/*}}"
-> /home/user/openfoam/BuildEnv/scratch <-- WHAT?? Not what we expected
```
The additional quotes cause incorrect expansion. Whereas
```
unset test1
echo ${test1:=${PWD%/*}}
-> /home/user/openfoam/BuildEnv <-- Expected
```
- bash and dash 0.5.10.2-6 (focal) work as expected, with/without quotes
- quoted expansion with `:-` works as expected.
Possible fixes?
- https://git.kernel.org/pub/scm/utils/dash/dash.git/commit/?id=48ca00863af909461d1372998bb90549f27abaaf
- https://git.kernel.org/pub/scm/utils/dash/dash.git/commit/?id=a29e9a1738a4e7040211842f3f3d90e172fa58ce
- https://git.kernel.org/pub/scm/utils/dash/dash.git/commit/?id=878514712c5d21f675c45d99d2f8a04098ea4a19
Possible workarounds
- use unqoted version, but risk fixing it on the next shellcheck
- explicit `if [ -z VAR ]; then ...; fi` construct
- with dirname as `: "${VAR:=$(dirname xxx)}`Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/1759mergeOrSplitBaffles : not identiying -dict arguments2020-07-28T15:15:56ZPawan GhildiyalmergeOrSplitBaffles : not identiying -dict argumentsHello ,
when i am running mergeOrSplitBaffles, with -dict argument , it throw error with latest
v2006.
i.e
> mergeOrSplitBaffles -dict system/mergeOrSplitBafflesDict_boundary
>
> Expected 0 arguments but found 1
Regard...Hello ,
when i am running mergeOrSplitBaffles, with -dict argument , it throw error with latest
v2006.
i.e
> mergeOrSplitBaffles -dict system/mergeOrSplitBafflesDict_boundary
>
> Expected 0 arguments but found 1
Regards
PawanMark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/1760mingw :test case fail2021-07-06T17:36:26ZPawan Ghildiyalmingw :test case fail
@mark
Creating a list of tutorial(except multiphase) which fail in windows version.
I will keep on updating the list.
1. heatTransfer/buoyantBoussinesqSimpleFoam/iglooWithFridges/
The tutorial fail in windows mingw versi...
@mark
Creating a list of tutorial(except multiphase) which fail in windows version.
I will keep on updating the list.
1. heatTransfer/buoyantBoussinesqSimpleFoam/iglooWithFridges/
The tutorial fail in windows mingw version while running snappyHexMesh
It was unable to find "displacementLaplacian" Solver
Adding libs(libfvMotionSolvers) in controlDict, resolve the issue .
2. incompressible/pimpleFoam/LES/surfaceMountedCube/initChannel (Edited)
functionObject surface: to output turbulenceProperties:L,turbulenceProperties:R, turbulenceProperties:R
write variablefile as turbulenceProperties and not turbulenceProperties:Rhttps://develop.openfoam.com/Development/openfoam/-/issues/1761possible bug in `pressureDirectedInletOutletVelocity` BC2020-09-06T10:25:43ZArashpossible bug in `pressureDirectedInletOutletVelocity` BC<!--
*** Please read this first! ***
Before opening a new issue, make sure to search for keywords in the issues
filtered by the "bug" label and check to see if it has already been reported
You can see how your report will be re...<!--
*** Please read this first! ***
Before opening a new issue, make sure to search for keywords in the issues
filtered by the "bug" label and check to see if it has already been reported
You can see how your report will be rendered on the platform by using the
"preview" tab above
-->
<!--
All text between these markers are comments and will not be present in the
report
-->
### Summary
`pressureDirectedInletOutletVelocity` is a mixed BC. Yet, I'm not sure if [this](https://develop.openfoam.com/Development/openfoam/-/blob/OpenFOAM-v1912/src/finiteVolume/fields/fvPatchFields/derived/pressureDirectedInletOutletVelocity/pressureDirectedInletOutletVelocityFvPatchVectorField.C#L205) operator is assigning the correct value. I didn't dig in the code, yet, `pvf` must be either a `refValue` or `refGrad` and in either case, this expression doesn't satisfy the following properties stated [here](https://www.openfoam.com/documentation/guides/latest/doc/guide-bcs-outlet-pressure-inlet-outlet.html):
>- Flow out of the domain: assigns a zero gradient condition
>- Flow into the domain: assigns a velocity based on the flux in the patch-normal direction [or in this case the `inletDir`]
### What is the expected *correct* behavior?
It should be something like [this](https://develop.openfoam.com/Development/openfoam/blob/OpenFOAM-v1912/src/finiteVolume/fields/fvPatchFields/derived/pressureInletOutletVelocity/pressureInletOutletVelocityFvPatchVectorField.C#L212) from the `pressureInletOutletVelocity`v2012Kutalmış BerçinKutalmış Berçinhttps://develop.openfoam.com/Development/openfoam/-/issues/1762libs with word instead of filenames fails re-reading2020-07-06T07:41:13ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comlibs with word instead of filenames fails re-reading<!--
*** Please read this first! ***
Before opening a new issue, make sure to search for keywords in the issues
filtered by the "bug" label and check to see if it has already been reported
You can see how your report will be re...<!--
*** Please read this first! ***
Before opening a new issue, make sure to search for keywords in the issues
filtered by the "bug" label and check to see if it has already been reported
You can see how your report will be rendered on the platform by using the
"preview" tab above
-->
<!--
All text between these markers are comments and will not be present in the
report
-->
### Summary
<!-- Summarize the bug encountered concisely -->
In case (pisoFoam/LES/pitzDaily) the library loading (in e.g. the `functions` functionObjectList) uses the new syntax:
```
libs (sampling)
```
When forcing re-reading by touching system/controlDict it gives an error since it expects a fileName.
### Steps to reproduce
<!-- How one can reproduce the issue - this is very important -->
- take above tutorial
- comment out functions section
- start running
- uncomment functions section & save
### Relevant logs and/or images
<!--
Paste any relevant logs - please use code blocks (```) to format console
output, logs, and code as it's very hard to read otherwise.
-->
```
Re-reading object controlDict from file "ep_1328_fileModification/pitzDaily/system/controlDict"
Overriding OptimisationSwitches according to controlDict
fileModificationSkew 1;
--> FOAM FATAL IO ERROR:
Wrong token type - expected string, found on line 58: word 'sampling'
file: ep_1328_fileModification/pitzDaily/system/controlDict.functions.probes.libs at line 58.
From function Foam::Istream& Foam::operator>>(Foam::Istream&, Foam::fileName&)
in file primitives/strings/fileName/fileNameIO.C at line 58.
FOAM aborting (FOAM_ABORT set)
```
### Environment information
<!--
Providing details of your set-up can help us identify any issues, e.g.
OpenFOAM version : v1806|v1812|v1906 etc
Operating system : ubuntu|openSUSE|centos etc
Hardware info : any info that may help?
Compiler : gcc|intel|clang etc
-->
- OpenFOAM version : v1812Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/242Reconstruct problem for Qro scalarField with libs in controlDict2016-10-03T22:16:38ZAdminReconstruct problem for Qro scalarField with libs in controlDictI'm using version OF-plus from 13 July 2016 (plus-5d9038294daa). I need to add a new radiation library to controlDict file. But even if I add the original libradiationModels.so this problem appears:
When the volScalarField Qr is recon...I'm using version OF-plus from 13 July 2016 (plus-5d9038294daa). I need to add a new radiation library to controlDict file. But even if I add the original libradiationModels.so this problem appears:
When the volScalarField Qr is reconstructed, the scalarField Qro is filled with non-zero values despite its original value is 'uniform 0'.
Till now I have observed that:
* If no library is included in controlDict file, this error does not appear.
* If I add the library but without the NamedEnum definition (and proper .C modifications) in file submodels/boundaryRadiationProperties/boundaryRadiationPropertiesPatch.C, this problem does not appear.
* If I use OF-dev this problem does not appear.
I attach a case to reproduce the error [possibleBugReconstruct.tar.gz](/uploads/3210d3d305fe453710186e944f8d46f1/possibleBugReconstruct.tar.gz). The steps to reproduce it are:
1. extract files from possibleBugReconstruct.tar.gz
2. ./Allrun-parallel
3. reconstructPar -allRegions -time 10
4. vim 10/left/Qr (and check for Qro field)Sergio FerrarisSergio Ferrarishttps://develop.openfoam.com/Development/openfoam/-/issues/130ENH: Extend the foamSystemCheck to include dependencies2017-03-16T08:30:39ZPrashant SonakarENH: Extend the foamSystemCheck to include dependenciesIt might be good to simply execute a script to check any missing dependencies than stating long list in release note.
It would also help non-IT expert to know the missing items.
e.g. flex, bison, cmake, zlib etc could be added to t...It might be good to simply execute a script to check any missing dependencies than stating long list in release note.
It would also help non-IT expert to know the missing items.
e.g. flex, bison, cmake, zlib etc could be added to this system test.
This should assist installation by also listing dependencies required in ThirdParty folder (if any)
@wyldckat @Mattijs @mark @Pawan AdminAdminhttps://develop.openfoam.com/Development/openfoam/-/issues/1763columnAverage2021-07-07T08:56:50ZSeo Dong-HocolumnAverageLooking into a directory "controlDict" in a tutorial "periodicHill', to apply "columnAverage", patches is set "patches (front "proc.*throughfront");". By the way, I do not clearly understand what "proc.*throughfront" means. Actually, thi...Looking into a directory "controlDict" in a tutorial "periodicHill', to apply "columnAverage", patches is set "patches (front "proc.*throughfront");". By the way, I do not clearly understand what "proc.*throughfront" means. Actually, this case has two patches "front" and "back" at the ends of the spanwise direction. Please let me know this.
Moreover, do I have to include two patches "front" and "back" together to do the spanwise average?, otherwise, only one patch "front" or "back" should be included like "patches (front);"?
Thank you.v2112Kutalmış BerçinKutalmış Berçinhttps://develop.openfoam.com/Development/openfoam/-/issues/1765collated fileHandler hangs when using #include clause in decomposeParDict2020-07-09T14:13:58ZMiguel Castellanocollated fileHandler hangs when using #include clause in decomposeParDict<!--
*** Please read this first! ***
Before opening a new issue, make sure to search for keywords in the issues
filtered by the "bug" label and check to see if it has already been reported
You can see how your report will be re...<!--
*** Please read this first! ***
Before opening a new issue, make sure to search for keywords in the issues
filtered by the "bug" label and check to see if it has already been reported
You can see how your report will be rendered on the platform by using the
"preview" tab above
-->
<!--
All text between these markers are comments and will not be present in the
report
-->
### Summary
<!-- Summarize the bug encountered concisely -->
When running the case with collated output, for any given solver, if there is an #include clause into the decomposeParDict, introducing for example an external dictionary with variables but also EVEN if it is a empty dictionary, the run will hang forever. Just the fact that there is an #include clause into the decomposeParDict causes the run to hang indefinitely.
### Steps to reproduce
<!-- How one can reproduce the issue - this is very important -->
For ANY OpenFOAM tutorial (or at least/tested on sineWaveDamping(rhoPimpleFoam) and damBreak(interFoam)):
1. Just add an #include clause into your decomposeParDict (#include myDict)
2. RUN:
blockMesh -fileHandler collated
decomposePar -fileHandler collated
mpirun -np $CORES $SOLVER -parallel -fileHandler collated
HANGS INDEFINITELY ...
3. Remove the #include clause and try again.
4. RUNS SMOOTHLY.
### Example case
ANY OPENFOAM TUTORIAL
<!--
If possible, please create a SMALL example and attach it to your report
If you are using an older version of OpenFOAM this will also determine
whether the bug has been fixed in a more recent version
-->
### Environment information
<!--
Providing details of your set-up can help us identify any issues, e.g.
OpenFOAM version : v1806|v1812|v1906 etc
Operating system : ubuntu|openSUSE|centos etc
Hardware info : any info that may help?
Compiler : gcc|intel|clang etc
-->
- OpenFOAM version : v5. , v6. , v1912
- Operating system : SUSE Linux Enterprise, Arch Linux
- Hardware info :
- Compiler : icc, gcc