Development issueshttps://develop.openfoam.com/groups/Development/-/issues2023-12-18T15:49:40Zhttps://develop.openfoam.com/Development/openfoam/-/issues/3052GAMG: support for polling2023-12-18T15:49:40ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comGAMG: support for polling<!--
*** 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 -->
processorGAMGInterfaceField does not implement ready() even though it maintains its own requests. Hence any polling will call matrixInterfaceUpdate in original order, negating any benefit of polling. Note that it only affects operations inside the GAMG solver.
### Steps to reproduce
<!-- How one can reproduce the issue - this is very important -->
Hard. Default lduInterfaceField::ready() returns true so it will do the waiting instead in the matrixInterfaceUpdate routine.
### What is the current *bug* behaviour?
<!-- What actually happens -->
Order of GAMG interface updates is always the same.
### What is the expected *correct* behavior?
<!-- What you should see instead -->
Re-runs might give slightly different truncation error.
### 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 : 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 : v2309https://develop.openfoam.com/Development/openfoam/-/issues/3051foamFormatConvert messing up files2023-12-19T08:19:28ZFranz DfoamFormatConvert messing up files### Summary
When converting a Lagrangian case from binary to ascii with foamFormatConvert, it's messing up some values, notably the origID of the particles in the particleTracks. While they are fine in binary, or when running the case i...### Summary
When converting a Lagrangian case from binary to ascii with foamFormatConvert, it's messing up some values, notably the origID of the particles in the particleTracks. While they are fine in binary, or when running the case in ASCII from the beginning, they are set to -1 when converting the case.
### Steps to reproduce / Example
This can be reproduced using the tutorial case /tutorials/lagrangian/simpleReactingParcelFoam/verticalChannel
1. Edit the controlDict to have `writeFormat binary;` (instead of the default `ascii`)
2. Run the case (at least until it writes one step, that's a matter of a few seconds)
3. Do a quick `touch a.foam` and check the particleTracks in Paraview. The tracks have a value in the origId. This is how it should be.
4. Change the controlDict back to `writeFormat ascii;`
5. run `foamFormatConvert`
6. Go to verticalChannel/20/lagrangian/reactingCloud1Tracks, and have a look at the file origId (no need for Paraview, as it's ascii now), it now says `6202{-1}`, i.e. all origId entries in the track are `-1` (which is not very useful).
### What is the current *bug* behaviour?
origID becomes -1
### What is the expected *correct* behavior?
No change in the file contents.
### 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
- OpenFOAM version : v2306
- Operating system : Ubuntu 22.04.3 LTS
- Hardware info :
- Compiler :
### 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
-->Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/3050Wrong keyword in template file for particleTrackProperties2023-12-18T15:49:05ZFranz DWrong keyword in template file for particleTrackPropertiesIn /applications/utilities/postProcessing/lagrangian/particleTracks/particleTrackProperties
Keyword in file (line 17): `cloudName`
Keyword expected by utility particleTracks: `cloud`In /applications/utilities/postProcessing/lagrangian/particleTracks/particleTrackProperties
Keyword in file (line 17): `cloudName`
Keyword expected by utility particleTracks: `cloud`Kutalmış BerçinKutalmış Berçinhttps://develop.openfoam.com/Development/openfoam/-/issues/3049snappyHexMesh bit more printing2023-12-21T11:54:41ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comsnappyHexMesh bit more printing### Functionality to add/problem to solve
Have more information about the layer generation outer iterations
### What does success look like, and how can we measure that?
Include the wanted number of layers to the printed information:...### Functionality to add/problem to solve
Have more information about the layer generation outer iterations
### What does success look like, and how can we measure that?
Include the wanted number of layers to the printed information:
```
patch faces layers overall thickness
target mesh [m] [%]
----- ----- ----- ---- --- ---
maxY 20 3 3 0.00061 87.1
minY 20 3 3 0.00061 87.1
A 12 3 3 0.000479 68.5
A_slave 12 3 3 0.000479 68.5
```Mattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comhttps://develop.openfoam.com/Development/openfoam/-/issues/3048Wiki update suggestion: how to enable CRB/PowerTools on Rocky-8/Rocky-9 in th...2023-12-20T15:01:27ZYoshiaki SendaWiki update suggestion: how to enable CRB/PowerTools on Rocky-8/Rocky-9 in the same wayhttps://develop.openfoam.com/Development/openfoam/-/wikis/precompiled/redhat
```
yum -y install epel-release
crb enable
```
This `crb enable` command enables PowerTools on Rocky-8 and enables CRB on Rocky-9.https://develop.openfoam.com/Development/openfoam/-/wikis/precompiled/redhat
```
yum -y install epel-release
crb enable
```
This `crb enable` command enables PowerTools on Rocky-8 and enables CRB on Rocky-9.Kutalmış BerçinKutalmış Berçinhttps://develop.openfoam.com/Development/openfoam/-/issues/3046faceZone handling for vtkWrite function object2023-12-21T15:51:17ZAaronfaceZone handling for vtkWrite function objectThe vtkWrite function object has much of the functionality of foamToVTK, but could benefit from support for faceZones. Via topoSet selection, there is support for exporting cellZones, but not faceZones. Thus, foamToVTK must be used, whic...The vtkWrite function object has much of the functionality of foamToVTK, but could benefit from support for faceZones. Via topoSet selection, there is support for exporting cellZones, but not faceZones. Thus, foamToVTK must be used, which cannot be executed at runtime.https://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/3044add flag to not keep comments in foamDictionary and set default behavior to k...2023-12-21T15:52:40Zfranco otaolaadd flag to not keep comments in foamDictionary and set default behavior to keep them### Functionality to add/problem to solve
foamDictionary when using -set or other flags removes all the comments. this makes almost unsable the tool as a lot of us have pieces of code commented that came from other cases and we want to k...### Functionality to add/problem to solve
foamDictionary when using -set or other flags removes all the comments. this makes almost unsable the tool as a lot of us have pieces of code commented that came from other cases and we want to keep. I would propose that the default behavior would be to keep the comments (as people could loose information) and add a flag to not keep them like -removeComments or something in that logic
### Target audience
users in general
### Proposal
detect the comments and place them in between the entries where it was before.
### What does success look like, and how can we measure that?
if we use it for transportProperties for a dictionary that looks like this:
```
transportModel Newtonian;
//[g m s K kgmol A cd]
nu 1e-05; //[0 2 -1 0 0 0 0]
//comment
//comment2
/* block
of
comment
*/
Sct 0.7; //[0 0 0 0 0 0 0]
//comment3
```
that the resulting dictionary at least look like this (with each time that there is a // a new line is created and the /* */ block comments are kept as they were):
```
transportModel Newtonian;
//[g m s K kgmol A cd]
nu 1;//[0 2 -1 0 0 0 0]
//coment
//comment2
/* block
of
comment
*/
Sct 0.7;//[0 0 0 0 0 0 0]
//comment3
```
even if the final structure is not ideal this would be a great addition to using it.https://develop.openfoam.com/Development/openfoam/-/issues/3043Add support for extrae profiling.2023-12-20T16:59:20ZMark OLESENAdd support for extrae profiling.Patch provided by @josep.pocurull
[OpenFOAM-v2206.extrae-profiling.patch](/uploads/9a9bfbc7b7af9f9e35eef00bc343580c/OpenFOAM-v2206.extrae-profiling.patch)Patch provided by @josep.pocurull
[OpenFOAM-v2206.extrae-profiling.patch](/uploads/9a9bfbc7b7af9f9e35eef00bc343580c/OpenFOAM-v2206.extrae-profiling.patch)Mark 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çinhttps://develop.openfoam.com/Development/openfoam/-/issues/3038SRFModel tmp early release2023-11-30T17:56:13ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comSRFModel tmp early release<!--
*** 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 -->
SRFModel illegal tmp use
### Steps to reproduce
<!-- How one can reproduce the issue - this is very important -->
Run SRFPimpleFoam tutorial:
```
--> FOAM FATAL ERROR: (openfoam-2309)
tmp<N4Foam14GeometricFieldINS_6VectorIdEENS_12fvPatchFieldENS_7volMeshEEE> deallocated
```
### 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 : v2308
### 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 in !628Mattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comhttps://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/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/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/3030Dead links on documentation page2024-01-10T16:12:56ZJohan RoenbyDead links on documentation pageAll pdf links are dead on https://www.openfoam.com/documentation/overviewAll pdf links are dead on https://www.openfoam.com/documentation/overviewhttps://develop.openfoam.com/Development/openfoam/-/issues/3028non-orthogonal faces to set nonOrthoFaces2023-11-16T15:22:11ZFarshad Ansarinon-orthogonal faces to set nonOrthoFacesHello,
When I import my data.unv with the ideasUnvToFoam command, everything is ok. But after meshCheck I get this error:
*Number of severely non-orthogonal (> 70 degrees) faces: 612.
Non-orthogonality check OK.
<<Writing 612 no...Hello,
When I import my data.unv with the ideasUnvToFoam command, everything is ok. But after meshCheck I get this error:
*Number of severely non-orthogonal (> 70 degrees) faces: 612.
Non-orthogonality check OK.
<<Writing 612 non-orthogonal faces to set nonOrthoFaces
Face pyramids OK.
Max skewness = 1.23757 OK.
Coupled point location match (average 0) OK.
Failed 1 mesh checks.
what should I do?
thankshttps://develop.openfoam.com/Development/openfoam/-/issues/3025stringOps::split with keep empty accidentally ignores non-empty trailing element2023-11-09T10:57:48ZMark OLESENstringOps::split with keep empty accidentally ignores non-empty trailing elementMark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/3023object registry filtered objects uses derived name2023-11-07T21:01:55ZMark OLESENobject registry filtered objects uses derived nameAffects the implementation of csorted etc.
It checks the name from the cast pointer
```
matchName(ptr->name())
```
instead of from the object pointer
```
matchName(obj->name())
```
This only seems to affect finite-area directly, since t...Affects the implementation of csorted etc.
It checks the name from the cast pointer
```
matchName(ptr->name())
```
instead of from the object pointer
```
matchName(obj->name())
```
This only seems to affect finite-area directly, since the cast pointer will have "region0" as its name, whereas the object is actually registered as "faMesh". Cross-ref EP2297
Regression introduced with 95e2a2e887d but was not exposed until 129b738136f (develop branch)Mark OLESENMark OLESEN