Development issueshttps://develop.openfoam.com/groups/Development/-/issues2017-06-29T20:38:04Zhttps://develop.openfoam.com/Development/openfoam/-/issues/462BUG: Several tutorial failures after commit 2d036ca002017-06-29T20:38:04ZAdminBUG: Several tutorial failures after commit 2d036ca00With the change in behaviour of the inverseDistanceDiffusivity (commit 2d036ca00) to use a run-time selectable wall distance, users are now required to add wall dist construction info into the fvSchemes dictionary. Also, the computed dif...With the change in behaviour of the inverseDistanceDiffusivity (commit 2d036ca00) to use a run-time selectable wall distance, users are now required to add wall dist construction info into the fvSchemes dictionary. Also, the computed diffusivity has dimensions of 1/m as opposed to dimensionless.
Tutorials:
```
heatTransfer/buoyantBoussinesqSimpleFoam/iglooWithFridges:
log.snappyHexMesh: keyword patchDist is undefined in dictionary "system/fvSchemes": fvSchemes
mesh/moveDynamicMesh/SnakeRiverCanyon:
log.moveDynamicMesh: keyword patchDist is undefined in dictionary "system/fvSchemes": fvSchemes
mesh/moveDynamicMesh/relativeMotion/box2D_moveDynamicMesh:
log.moveDynamicMesh: keyword patchDist is undefined in dictionary "system/fvSchemes": fvSchemes
multiphase/potentialFreeSurfaceDyMFoam/oscillatingBox:
log.potentialFreeSurfaceDyMFoam: keyword patchDist is undefined in dictionary "system/fvSchemes": fvSchemes
```Version v1706https://develop.openfoam.com/Development/openfoam/-/issues/504BUG: failure in case multiphase/overInterDyMFoam/floatingBody/background2017-06-19T19:31:53ZPrashant SonakarBUG: failure in case multiphase/overInterDyMFoam/floatingBody/backgroundAttached log from the case file.[log.overInterDyMFoam](/uploads/e418d3a09bf3fe81967f541f09ac64b0/log.overInterDyMFoam)
@Pawan @SergioAttached log from the case file.[log.overInterDyMFoam](/uploads/e418d3a09bf3fe81967f541f09ac64b0/log.overInterDyMFoam)
@Pawan @SergioVersion v1706Mattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comhttps://develop.openfoam.com/Development/openfoam/-/issues/418BUG: dictionary entries not being properly merged/overwritten2018-05-03T18:08:12ZMark OLESENBUG: dictionary entries not being properly merged/overwrittenProblem traced to `substituteScopedKeyword`. Example,
key1 val1;
update
{
key1 val1b;
key2 val2;
}
#inputMode overwrite // or merge
$update
The value for `key1` is not changed.Problem traced to `substituteScopedKeyword`. Example,
key1 val1;
update
{
key1 val1b;
key2 val2;
}
#inputMode overwrite // or merge
$update
The value for `key1` is not changed.Version v1706Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/231foamToEnsight mask is too small/inflexible.2020-03-13T14:19:48ZMark OLESENfoamToEnsight mask is too small/inflexible.Currently have 4-digits, which artificially limits the number of output times to less than 9999.
http://exchange.openfoam.com/node/257Currently have 4-digits, which artificially limits the number of output times to less than 9999.
http://exchange.openfoam.com/node/257Version v1706Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/460odd sizing for hash tables.2017-06-29T20:38:04ZMark OLESENodd sizing for hash tables.Came across a few odd things, especially when copy/copy-constructing from other hash tables.
* HashPtrTable copy from HashPtrTable: uses default size, not related to what it is copying
* HashTable from initializer_list uses list size, n...Came across a few odd things, especially when copy/copy-constructing from other hash tables.
* HashPtrTable copy from HashPtrTable: uses default size, not related to what it is copying
* HashTable from initializer_list uses list size, not 2*list size for its table
* HashSet from HashTable uses number of keys, not the table size.Version v1706Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/495unneeded overhead in mergePoints2017-06-14T13:48:01ZMark OLESENunneeded overhead in mergePointsVersion v1706Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/374Turbulence DFSEM inlet BC fails for some parallel cases2019-12-09T22:04:14ZAdminTurbulence DFSEM inlet BC fails for some parallel casesThe code uses an optimisation for the case that the patch resides on a single processor domain - this information/flag is not reduced across all procs and can lead to hanging cases.The code uses an optimisation for the case that the patch resides on a single processor domain - this information/flag is not reduced across all procs and can lead to hanging cases.Version v1706AdminAdminhttps://develop.openfoam.com/Development/openfoam/-/issues/470surfaceMeshTriangulate does not handle - time selection - moving meshes2017-06-29T20:38:04ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comsurfaceMeshTriangulate does not handle - time selection - moving meshesVersion v1706Mattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comhttps://develop.openfoam.com/Development/openfoam/-/issues/270VTK legacy formats will fail with label-size 642020-03-13T14:22:41ZMark OLESENVTK legacy formats will fail with label-size 64The VTK legacy binary output performs byte-swapping on labels, but since legacy VTK only handles 32-bit ints, the code also only swaps endian content for 32-bits. For 64-bit labels the swapping and output are wrong. The newer VTK formats...The VTK legacy binary output performs byte-swapping on labels, but since legacy VTK only handles 32-bit ints, the code also only swaps endian content for 32-bits. For 64-bit labels the swapping and output are wrong. The newer VTK formats are needed for this.
Code affected:
* setSet/writeFuncs.C
* foamToVTK/writeFuncs.C
* CloudToVTK/vtkTools.CVersion v1706Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/458FixedList '<' operator using a template parameter2017-06-29T20:38:04ZMark OLESENFixedList '<' operator using a template parameterCannot use comparison of list sizes. Okay for UList, but not here.
- noticing the `operator==` method immediately above, should probably also short-circuit the first time `equal` becomes false.
This won't matter much for fixed lists t...Cannot use comparison of list sizes. Okay for UList, but not here.
- noticing the `operator==` method immediately above, should probably also short-circuit the first time `equal` becomes false.
This won't matter much for fixed lists that would generally have small sizes, but same issue in UILList.C and UList.CVersion v1706Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/448added to extendedEdgeMesh fails2019-12-09T21:29:28ZMark OLESENadded to extendedEdgeMesh failsextendedEdgeMesh.C
* lines 1270-1273 -> need sublist to handle zero-sized lists (or segfault)
* line 1274: needs `fem.edgeNormals()` to have the correct size for the looping.
@MattijsextendedEdgeMesh.C
* lines 1270-1273 -> need sublist to handle zero-sized lists (or segfault)
* line 1274: needs `fem.edgeNormals()` to have the correct size for the looping.
@MattijsVersion v1706Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/338BUG: codedFO doesn't warn for backward compatibility/ old version cases2018-05-29T05:39:49ZPrashant SonakarBUG: codedFO doesn't warn for backward compatibility/ old version casesAttached case works ok in v1606+
In develop, solver executes, but doesn't handle codedFO (no output)
The type 'code' is deprecated(!) without warning.
[pitzDaily.tgz](/uploads/17b2db2ccbf340f30477273acc3d94f3/pitzDaily.tgz)
@markAttached case works ok in v1606+
In develop, solver executes, but doesn't handle codedFO (no output)
The type 'code' is deprecated(!) without warning.
[pitzDaily.tgz](/uploads/17b2db2ccbf340f30477273acc3d94f3/pitzDaily.tgz)
@markVersion v1706AdminAdminhttps://develop.openfoam.com/Development/openfoam/-/issues/437BUG: function object time usage does not respect user time2019-12-09T21:29:28ZAdminBUG: function object time usage does not respect user timeIf cases are set up using, e.g. engineTime, the reported times are in 's' and not 'CA'. This relates to file output via the `writeFile` class, and all time-related inputsIf cases are set up using, e.g. engineTime, the reported times are in 's' and not 'CA'. This relates to file output via the `writeFile` class, and all time-related inputsVersion v1706https://develop.openfoam.com/Development/openfoam/-/issues/431Use logical instead of physical path for locating WM_PROJECT_DIR2018-05-03T18:08:12ZMark OLESENUse logical instead of physical path for locating WM_PROJECT_DIRAs experienced by @ivanspisso during installation, the current use of `pwd -P` makes the installation in some cluster environments more difficult since the physical path may correspond to some arbitrary disk and not to the canonical name...As experienced by @ivanspisso during installation, the current use of `pwd -P` makes the installation in some cluster environments more difficult since the physical path may correspond to some arbitrary disk and not to the canonical name.
For example,
OK: /cineca/prod/opt/applications/
NOK: /marconi/prod/opt/applications/
NOK: /galileo/cineca/prod/opt/applications/Version v1706Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/398BUG: surfaceMeshTriangulate doesn't support absolute path2018-05-29T05:39:49ZPrashant SonakarBUG: surfaceMeshTriangulate doesn't support absolute pathRef: EP#331Ref: EP#331Version v1706Mattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comhttps://develop.openfoam.com/Development/openfoam/-/issues/367BUG: fieldAveraging write conflict with timeEnd2019-12-09T21:29:27ZPrashant SonakarBUG: fieldAveraging write conflict with timeEndAttached example illustrating the issue.
- The end time written from solver doesn't contain pMean field
- If we try commenting timeEnd entry from averaging FO, the field is written well.
[pitzDaily_averageFields_pimpleFoam.tgz](/uploa...Attached example illustrating the issue.
- The end time written from solver doesn't contain pMean field
- If we try commenting timeEnd entry from averaging FO, the field is written well.
[pitzDaily_averageFields_pimpleFoam.tgz](/uploads/3448d7e0d4738368f79fac7e05929290/pitzDaily_averageFields_pimpleFoam.tgz)
@mark @MattijsVersion v1706AdminAdminhttps://develop.openfoam.com/Development/openfoam/-/issues/503DOCU: inconsistent documentation for pressure FO2017-06-19T19:42:59ZPrashant SonakarDOCU: inconsistent documentation for pressure FOHeader file mentions keywords pRef optional with default value = 0.
However, this becomes compulsory with dictLookup entry.
Should either be modified to make it consistent (or state conditions when it is required)?
```
Property | ...Header file mentions keywords pRef optional with default value = 0.
However, this becomes compulsory with dictLookup entry.
Should either be modified to make it consistent (or state conditions when it is required)?
```
Property | Description | Required | Default value
pRef | Reference pressure | for total pressure | 0
pInf | Freestream pressure | for coefficient calculation |
```Version v1706AdminAdminhttps://develop.openfoam.com/Development/openfoam/-/issues/294simplify, cleanup surface handling infrastructure2017-12-18T23:17:41ZMark OLESENsimplify, cleanup surface handling infrastructureVersion v1706Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/348Odd logic for treatment of blockMesh zones to sets2018-05-29T05:39:48ZMark OLESENOdd logic for treatment of blockMesh zones to setsIn the blockMesh application (around line 360 or so), the cell zones are written as sets (for ease of processing). Immediately *after* this, a `mesh.removeFiles()` is invoked prior to writing the mesh. Since the polyMesh::removeFiles als...In the blockMesh application (around line 360 or so), the cell zones are written as sets (for ease of processing). Immediately *after* this, a `mesh.removeFiles()` is invoked prior to writing the mesh. Since the polyMesh::removeFiles also removes the `sets` sub-directory, it doesn't look like the sets will survive very long.
Tagged in @Mattijs since he might have an idea.Version v1706https://develop.openfoam.com/Development/openfoam/-/issues/312Separate build directory2018-05-29T05:39:49ZMark OLESENSeparate build directoryDuring recent discussions there was some interest expressed in a binary only distribution. This currently mostly possible by distributing bin/, etc/, platforms/ only. This of course loses that ability to have dynamic code, but can noneth...During recent discussions there was some interest expressed in a binary only distribution. This currently mostly possible by distributing bin/, etc/, platforms/ only. This of course loses that ability to have dynamic code, but can nonetheless be useful.
To make the distributed package smaller, need to manually strip out the dependencies and intermediate build targets.
Propose to split of these intermediates into a separate build/ directory as per third party.Version v1706Mark OLESENMark OLESEN