Development issueshttps://develop.openfoam.com/groups/Development/-/issues2023-12-07T19:01:57Zhttps://develop.openfoam.com/Development/openfoam/-/issues/118BUG: failure in streamLine for motorbike case2023-12-07T19:01:57ZPrashant SonakarBUG: failure in streamLine for motorbike caseAs mentioned in
https://develop.openfoam.com/OpenCFD/OpenFOAM-test/merge_requests/19#note_1157
the case /home/alex2/prashant/QA/UNIT_TESTS/OpenFOAM-test.merge-foundation-test1/MD2014/04star_runTimeImages/simpleFoam/motorBike failed...As mentioned in
https://develop.openfoam.com/OpenCFD/OpenFOAM-test/merge_requests/19#note_1157
the case /home/alex2/prashant/QA/UNIT_TESTS/OpenFOAM-test.merge-foundation-test1/MD2014/04star_runTimeImages/simpleFoam/motorBike failed for parallel execution for streamLines
@andy Mattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comhttps://develop.openfoam.com/Development/openfoam/-/issues/128BUG: runTimePostProcessing static Mode with nFrames >12023-12-07T19:01:57ZPrashant SonakarBUG: runTimePostProcessing static Mode with nFrames >1There should be warning /error if nFrames is >1 for static mode.
Else, the position_ would keep increasing. There should be warning /error if nFrames is >1 for static mode.
Else, the position_ would keep increasing. AdminAdminhttps://develop.openfoam.com/Development/openfoam/-/issues/141BUG: Tutorial case failure2023-12-07T19:01:57ZPrashant SonakarBUG: Tutorial case failureMultiphase:
- reactingTwoPhaseEulerFoam/RAS/wallBoiling
- reactingTwoPhaseEulerFoam/laminar/fluidisedBed
- reactingTwoPhaseEulerFoam/laminar/mixerVessel2D
combustion
- fireFoam/les/oppositeBurningPanels (missing boundaryRadiationP...Multiphase:
- reactingTwoPhaseEulerFoam/RAS/wallBoiling
- reactingTwoPhaseEulerFoam/laminar/fluidisedBed
- reactingTwoPhaseEulerFoam/laminar/mixerVessel2D
combustion
- fireFoam/les/oppositeBurningPanels (missing boundaryRadiationProperties file)
heatTransfer
- chtMultiRegionFoam/windshieldDefrost
incompressible
- simpleFoam/rotorDisk (snappyHexMesh failure)
lagrangian
-MPPICFoam/column (undefined applyLimiting)
- MPPICFoam/cyclone (undefined applyLimiting, Allrun parallel compatible command)
- icoUncoupledKinematicParcelFoam/hopper/hopper* (undefined flux(U) )
mesh
- parallel/cavity/log.redistributePar.reconstruct
- foamyHexMesh/simpleShapes/log.surfaceBooleanFeatures (issue #124)
@Sergio @Mattijs AdminAdminhttps://develop.openfoam.com/Development/openfoam/-/issues/97BUG: runTimePostProcessing doesn't colour iso surfaces2023-12-07T19:01:57ZPrashant SonakarBUG: runTimePostProcessing doesn't colour iso surfacesIf colourBy=field, the output works. However when colourBy=colour it fails to show geometry.
Attached file should work with motorBike case using execFlowFunctionObjects
[postProcessingDict_iso_usingFunctionObject](/uploads/e3952a75...If colourBy=field, the output works. However when colourBy=colour it fails to show geometry.
Attached file should work with motorBike case using execFlowFunctionObjects
[postProcessingDict_iso_usingFunctionObject](/uploads/e3952a759026ca447253ecefb45888a4/postProcessingDict_iso_usingFunctionObject)
@Mattijs AdminAdminhttps://develop.openfoam.com/Development/openfoam/-/issues/122Bug: noise-plus utility2023-12-07T19:01:57ZPrashant SonakarBug: noise-plus utilityThe noise utility exports or reads in data files to ensight format.
The data could be read in paraview but not in EnSight be cause ensight reader can't support special characters
e.g. reader would skip % sign when reading motorBike...The noise utility exports or reads in data files to ensight format.
The data could be read in paraview but not in EnSight be cause ensight reader can't support special characters
e.g. reader would skip % sign when reading motorBike case
patch_motorBike_rider-helmet`%`65.0000.mesh is interpreted as
patch_motorBike_rider-helmet`0`65.0000.mesh
Please update the writer to skip special characters in family name!
Probably this needs to be checked for ensight export in general (?)
@Mattijs Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/140interpolation2DTable<Type>::write does not compile2023-12-07T19:01:56ZMark OLESENinterpolation2DTable<Type>::write does not compilehttps://develop.openfoam.com/Development/openfoam/-/issues/1282dynamicCode does not work with the Intel compiler2023-12-07T19:00:15ZAdmindynamicCode does not work with the Intel compilerIf "blockMesh" is executed in the tutorial $FOAM_TUTORIALS/basic/potentialFoam/cylinder using an OpenFOAM version compiled with the Intel compiler, the following error message will appear:
codeStreamTemplate.C(35): error: invalid line n...If "blockMesh" is executed in the tutorial $FOAM_TUTORIALS/basic/potentialFoam/cylinder using an OpenFOAM version compiled with the Intel compiler, the following error message will appear:
codeStreamTemplate.C(35): error: invalid line number
#line 0 "/path/to/system/blockMeshDict.#codeStream"
I tested this with Intel2018 and 2019 and OpenFOAM v1712 and v1812 on two different systems and the error happens with all instances where dynamicCode is used.
The generated code in cylinder/dynamicCode/_1c19e29ae18c779aa836a14631d6419f303e3d9d/codeStreamTemplate.C in line 35 reads:
#line 0 "/path/to/cylinder/system/blockMeshDict.#codeStream"
The Intel compiler complains about the "0". If instead "blockMesh" is run with an OpenFOAM version compiled with clang or gcc, the same code is generated but the compiler does not complain. A quick fix would be to remove the following line:
https://develop.openfoam.com/Development/OpenFOAM-plus/blob/master/src/OpenFOAM/db/dynamicLibrary/dynamicCode/dynamicCodeContext.C#L129Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/1304template specialization for processorFvPatchScalarField2023-12-07T19:00:15ZMark OLESENtemplate specialization for processorFvPatchScalarField@andy @Mattijs
While doing the mingw port I keep hitting a very strange compilation issue. It complains about duplicate thunks for
`processorFvPatchField<scalar>::initInterfaceMatrixUpdate` etc. Oddly enough, it doesn't have any proble...@andy @Mattijs
While doing the mingw port I keep hitting a very strange compilation issue. It complains about duplicate thunks for
`processorFvPatchField<scalar>::initInterfaceMatrixUpdate` etc. Oddly enough, it doesn't have any problem with `processorFaPatchField<scalar>::initInterfaceMatrixUpdate` which is structured exactly the same way.
I've looked high and low, but can't find anything indicating duplicate inclusion of the file. Also tried with including the declaration of the specialization into `processorFvPatchField.H` itself.
To make a virtue out of a necessity, I simply discarded the specialization and made an 'in-line' specialization within
`processorFvPatchField.C` itself. For example,
```
// Consume straight from scalarReceiveBuf_
if (!std::is_fundamental<Type>::value)
{
// Transform according to the transformation tensor
transformCoupleField(scalarReceiveBuf_, cmpt);
}
```
This will skip the transformCoupleField for label, scalar, solveScalar etc and thus does the same as the template specialization. For C++11, the compiler will presumably be intelligent enough to remove this as unused code (depending on the type). For C++17 the if-constexpr means that it will definitely be removed, as if it were a templated bit of code.
From my perspective, I think that this would be a reasonably good change to make since it does remove some code duplication (and helps with my compilation).
- Anything that I might be missing?
- Any other places with template specialization could also be addressed like this?Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/1303patchAverage2023-12-07T19:00:15ZAdminpatchAverage<!--
*** 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
-->
<!--
All text between these marker...<!--
*** 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
-->
<!--
All text between these markers are comments and will not be present in the
report
-->
### Summary
patchAverage uses the "average" operation (which computes an ensemble average) rather than the "areaAverage". Its results are therefore not equal to patchIntegrate/area. This seems to me an incorrect behavior
### Steps to reproduce
postProcess -func 'patchAverage(name='anyPatch', anyField)'
### Example case
Compare result from postProcess -func 'patchAverage(name='anyPatch', anyField)' with
postProcess -func 'patchIntegrate(name='anyPatch', anyField)'
### What is the current *bug* behaviour?
Integral and average are not exactly related by the area.
### What is the expected *correct* behavior?
Integral and average should be related by the area.
### 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 : v1712
Operating system : Ubuntu 18.04
Compiler : gcc 7.3
### Possible fixes
In /etc/caseDicts/postProcessing/surfaceFieldValue/patchAverage change:
operation average;
to
operation areaAverage;https://develop.openfoam.com/Development/openfoam/-/issues/1218Missing information in the section for RPM installation2023-12-07T19:00:15ZAdminMissing information in the section for RPM installationIn this page: https://www.openfoam.com/download/install-binary-linux.php - in the very first section "RPM Installation", it's missing the instructions on how to activate the OpenFOAM-v1812 shell environment...
I only spotted this becaus...In this page: https://www.openfoam.com/download/install-binary-linux.php - in the very first section "RPM Installation", it's missing the instructions on how to activate the OpenFOAM-v1812 shell environment...
I only spotted this because of this post: https://www.cfd-online.com/Forums/openfoam-installation/215231-rpm-installation-openfoam-v1812-opensuse-15-0-a.html#post726007
\#\# Reattaching the author to the issue ticket: @wyldckat \#\#https://develop.openfoam.com/Development/openfoam/-/issues/1298parProfiling output cleanup2023-12-07T19:00:15ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comparProfiling output cleanupparProfiling output is not very clear.
- negative numbers
- gets output twice
```
parProfiling:
reduce : avg = 77.2517s
min = -97.6182% (processor 0)
max = +21.4343% (processor 4)
all-all : avg = 13.3667s...parProfiling output is not very clear.
- negative numbers
- gets output twice
```
parProfiling:
reduce : avg = 77.2517s
min = -97.6182% (processor 0)
max = +21.4343% (processor 4)
all-all : avg = 13.3667s
min = -18.3042% (processor 5)
max = +11.6958% (processor 4)
parProfiling:
reduce : avg = 77.2517s
min = -97.6182% (processor 0)
max = +21.4343% (processor 4)
all-all : avg = 13.3667s
min = -18.3042% (processor 5)
max = +11.6958% (processor 4)
```https://develop.openfoam.com/Development/openfoam/-/issues/1241BUG: renumberMesh after snappyHexMesh modify behavior of DynamicRefinement2023-12-07T19:00:14ZAdminBUG: renumberMesh after snappyHexMesh modify behavior of DynamicRefinement### Summary
<!-- Summarize the bug encountered concisely -->
renumberMesh does not update properly `cellLevel`, ``Level0Edge`` and ``pointLevel`` files created by ``snappyHexMesh``
but instead delete them.
It will later cause some cells ...### Summary
<!-- Summarize the bug encountered concisely -->
renumberMesh does not update properly `cellLevel`, ``Level0Edge`` and ``pointLevel`` files created by ``snappyHexMesh``
but instead delete them.
It will later cause some cells to be protected and not refined, negating the interest of the dynamic refinement.
### Steps to reproduce
<!-- How one can reproduce the issue - this is very important -->
To reproduce, one can call ``renumberMesh`` in a case with ``snappyHexMes`` and ``dynamicFvMesh``
after ``snappyHexMesh`` has been called.
### 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
-->
I first encountered this bug on a personnal case, but I was able to reproduce it with a tutorial.
* `cp -r $FOAM_TUTORIAL/tutorials/multiphase/interFoam/RAS/motorbike`
* Then add a renumberMesh after snappyHexMesh in Allrun.pre
or replace with [Allrun.pre](/uploads/ca333217cff63f619285d83ce155fee6/Allrun.pre)
and execute Allrun
### What is the current *bug* behaviour?
<!-- What actually happens -->
Actually, at the launch of the solver, some cells are protected from refinement, and therefore will not be
refined by dynamic refinement even if respect the criteria for the refinement.
### What is the expected *correct* behavior?
<!-- What you should see instead -->
No cells should be proctected. So the could be refined if necessary.
### 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.
-->
from log.interFoam :
````
Selecting dynamicFvMesh dynamicRefineFvMesh
Detected 3055 cells that are protected from refinement. Writing these to cellSet protectedCells.
````
here is two pictures showing the expectation and the reality on a case with a cube, since the case with the motorbike diverges and
fails. The first gif was obtained using ``topoMesh`` but I got same results with ``snappyHexMesh`` without ``renumberMesh``.
![output_topomesh](/uploads/5fb559ad59512b44777144f9b259f5c7/output_topomesh.gif)
mesh evolution with ``renumberMesh`` :
![output_maillage](/uploads/4feda3bd1d4df6e73f09bcb3fd3e8e6b/output_maillage.gif)
### 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 : v1806 and v18012
Operating system : debian/buster and Ubuntu bash on Windows
Compiler :
### Possible fixes
<!--
If you can, link to the line of code that might be responsible for the
problem
-->
I have determined that this behavior is caused by the deletion of the
``processor*/constant/polyMesh/{cellLevel,level0Edge,pointLevel}`` files
or the incorrect (I deleted them manually without executing renumberMesh
or created them manually filling them with 0)
Thus, the file responsible is located at ``$WM_PROJECT_DIR/applications/utilities/mesh/manipulation/renumberMesh/renumberMesh.C:1327``
```
// Remove refinement data
hexRef8::removeFiles(mesh);
```
and it should be replaced with function that update the cellLevel, level0Edge and pointLevel files according to the renumbering.
After some tests, I concluded that ``rotateMesh`` and ``transformPoints`` are not affected.
The use of
````
reconstructParMesh -constant -mergeTol 1e-6
deconstructPar -force
````
also results in protectedCells.
Others mesh manipulations utilities may also lead to this behavior.
Thanks a lot, feel free to ask if you need any details.https://develop.openfoam.com/Development/openfoam/-/issues/1036wmkdepend sometimes throws2023-12-07T18:58:57ZMark OLESENwmkdepend sometimes throwsEvidenced by this:
```
terminate called after throwing an instance of 'std::length_error'
what(): basic_string::_M_create
```
The root cause is incorrect token shifting when getting the next file chunk.
@MattijsEvidenced by this:
```
terminate called after throwing an instance of 'std::length_error'
what(): basic_string::_M_create
```
The root cause is incorrect token shifting when getting the next file chunk.
@MattijsMark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/3034snappyHexMesh : have more parallel balancing output2023-12-07T16:49:07ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comsnappyHexMesh : have more parallel balancing output### Functionality to add/problem to solve
Have shm output more information about the (un)balancedness of the mesh. Especially during layer addition the cell count can explode which might lead to out-of-memory problems. This request is t...### Functionality to add/problem to solve
Have shm output more information about the (un)balancedness of the mesh. Especially during layer addition the cell count can explode which might lead to out-of-memory problems. This request is to add a bit more printing of the current / expected state of balancing.
### Target audience
snappyHexMesh in parallelMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comhttps://develop.openfoam.com/Development/openfoam/-/issues/3033Incorrect check for polyMesh::dbDir()2023-12-07T16:48:39ZMark OLESENIncorrect check for polyMesh::dbDir()It checks `objectRegistry::dbDir() == defaultRegion` but this only works on the assumption that the polyMesh is rooted directly on time.
If we relocate to a different database (eg, "finite-volume"), the dbDir() would then be something l...It checks `objectRegistry::dbDir() == defaultRegion` but this only works on the assumption that the polyMesh is rooted directly on time.
If we relocate to a different database (eg, "finite-volume"), the dbDir() would then be something like "finite-volume/region0".
Should be checking on objectRegistry::name() directly, as per polyMesh::regionName().Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/3035inconsistent use of endEntry2023-12-07T16:48:20ZMark OLESENinconsistent use of endEntryAs noted in discussions with @serge , there are still a few places with `os << token::END_STATEMENT << nl` instead of using `endEntry()`
Having `endEntry()` can be useful when trying to trigger on the end event (such as with the cohere...As noted in discussions with @serge , there are still a few places with `os << token::END_STATEMENT << nl` instead of using `endEntry()`
Having `endEntry()` can be useful when trying to trigger on the end event (such as with the coherent format).https://develop.openfoam.com/Development/openfoam/-/issues/3037questionable use of dbDir() in fileOperations::readObjects2023-12-07T16:48:00ZMark OLESENquestionable use of dbDir() in fileOperations::readObjectsEither a bug, or a misunderstanding:
In fileOperations::readObjects we have this code:
```
fileName path(db.path(instance, db.dbDir()/local));
```
If we follow through the hierarchy, this goes back to IOobject::path() with two paramete...Either a bug, or a misunderstanding:
In fileOperations::readObjects we have this code:
```
fileName path(db.path(instance, db.dbDir()/local));
```
If we follow through the hierarchy, this goes back to IOobject::path() with two parameters. There it has this code:
```
return rootPath()/caseName()/instance/db_.dbDir()/local;
```
This appears to be a doubled up use of dbDir.
Leads to this type of debug info:
```
fileOperation::readObjects : db:"<path>/cylinder-new/finite-area/region0" instance:"0"
fileOperation::filePath : fName:"<path>/cylinder-new/0/finite-area/finite-area"
```
when the raw registry has `dbDir() = "finite-area/region0"` and the overloaded version has `dbDir() = "finite-area"`
Not sure why this just appears now...Mattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comhttps://develop.openfoam.com/Development/openfoam/-/issues/3045inconsistent handling of global IOobjects2023-12-07T16:47:33ZMark OLESENinconsistent handling of global IOobjectsSome items such as faSchemes, fvSchemes not properly marked as being global, which now provokes path resolution issues (after changes 4609aa38e1).
Much of the global object handling needs a revamp, but make do with a minor consistency u...Some items such as faSchemes, fvSchemes not properly marked as being global, which now provokes path resolution issues (after changes 4609aa38e1).
Much of the global object handling needs a revamp, but make do with a minor consistency update for now.v2312Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/3042snappyHexMesh (and possibly various other utilities) does not run in parallel2023-12-06T14:55:45ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comsnappyHexMesh (and possibly various other utilities) does not run in parallel<!--
*** 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 -->
snappyHexMesh in parallel fails when reading the constant/extendedFeatureEdgeMesh.
### Steps to reproduce
<!-- How one can reproduce the issue - this is very important -->
`heatTransfer/chtMultiRegionFoam/snappyMultiRegionHeater` tutorial
### 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
-->
See above
### What is the current *bug* behaviour?
<!-- What actually happens -->
- master processor reads ok
- other processors cannot find file
### Environment information
<!--
Providing details of your set-up can help us identify any issues, e.g.
OpenFOAM version : v2306|v2212|v2206|v2112|v2106 etc
Operating system : ubuntu|openSUSE|centos etc
Hardware info : any info that may help?
Compiler : gcc|intel|clang etc
-->
- OpenFOAM version :4609aa38e1
### 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
-->
Introduced with 4609aa38e1. In uncollated file format the communicator is just the local processor so when the testing was done at the 'worldComm' the broadcast only used the local processor.Mattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comhttps://develop.openfoam.com/Development/openfoam/-/issues/3039facGrad not compatible with cache of gradient2023-12-04T15:34:28ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comfacGrad not compatible with cache of gradient### Summary
fac::grad manipulates result from fa::gradScheme<Type>. If this is a cached result it tries to modify the cached value.
### Steps to reproduce
tutorial `finiteArea/liquidFilmFoam/cylinder` with
```
cache
{
grad(h);
...### Summary
fac::grad manipulates result from fa::gradScheme<Type>. If this is a cached result it tries to modify the cached value.
### Steps to reproduce
tutorial `finiteArea/liquidFilmFoam/cylinder` with
```
cache
{
grad(h);
grad(Us);
}
```
### Example case
See above
### What is the current *bug* behaviour?
Attempted non-const access to const-ref:
```
--> FOAM FATAL ERROR: (openfoam-2309)
Attempted non-const reference to const object: tmp<N4Foam14GeometricFieldINS_6VectorIdEENS_12faPatchFieldENS_8areaMeshEEE>
```
### What is the expected *correct* behavior?
<!-- What you should see instead -->
### Relevant logs and/or images
See above
### Environment information
- OpenFOAM version : v2309
### Possible fixes
Move caching up to this level?Kutalmış BerçinKutalmış Berçin