Development issueshttps://develop.openfoam.com/groups/Development/-/issues2024-01-18T12:48:14Zhttps://develop.openfoam.com/Development/openfoam/-/issues/3071Minor typo in the documentation link2024-01-18T12:48:14Zs1291Minor typo in the documentation linkThe webpage https://doc.openfoam.com/ lists version 2312 twice instead of 2306 and 2312.
![image](/uploads/1c71968fc14bf589ac5cd76849b7a8a6/image.png)The webpage https://doc.openfoam.com/ lists version 2312 twice instead of 2306 and 2312.
![image](/uploads/1c71968fc14bf589ac5cd76849b7a8a6/image.png)https://develop.openfoam.com/Development/openfoam/-/issues/3070Download Windows Native Broken2024-01-18T12:48:06ZDominic LaVigneDownload Windows Native BrokenHello, the link to download OpenFOAM for windows native gives a 404 error (URL Not found). I would love to download to integrate with MATLAB once this is fixed. Thank you.Hello, the link to download OpenFOAM for windows native gives a 404 error (URL Not found). I would love to download to integrate with MATLAB once this is fixed. Thank you.Andrew HeatherAndrew Heatherhttps://develop.openfoam.com/Development/openfoam/-/issues/3069Feature Request: time-average of sampled surfaces2024-01-18T12:47:52ZDjilou MioubFeature Request: time-average of sampled surfacesGreetings,
As far as I know, it's not possible to perform time-averaging on the sampled surfaces, similar to what the `fieldAverage` function does. In certain situations, a workaround is to use `fieldAverage` to calculate the time-avera...Greetings,
As far as I know, it's not possible to perform time-averaging on the sampled surfaces, similar to what the `fieldAverage` function does. In certain situations, a workaround is to use `fieldAverage` to calculate the time-averaged fields, followed by applying `surfaces` sampling to sample those fields (e.g, `UMean`, `pMean`, etc.).
However, in large 3D cases, it appears inefficient to compute the time-average fields solely to be used later for surface sampling, as it consumes a significant amount of computing resources. It would be more practical to have a direct method for computing the time-average of the sampled surfaces without the need to use fieldAverage as an intermediate step.
Best regardsMark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/3066masterUncollatedFileOperation compilation error on 23122024-01-20T15:12:18ZMatej FormanmasterUncollatedFileOperation compilation error on 2312### compilation problem.
I have: fetched the 2312 source code from master.
I have set my etc-darwin to take most of the libs fro the system (homebrew).
Compilation run with -j -l options.
``
Opt/src/OpenFOAM/primitives/ints/int32/int3...### compilation problem.
I have: fetched the 2312 source code from master.
I have set my etc-darwin to take most of the libs fro the system (homebrew).
Compilation run with -j -l options.
``
Opt/src/OpenFOAM/primitives/ints/int32/int32IO.o
make: *** [/Volumes/ofdisk/OpenFOAM-v2312/build/darwin64ClangDPInt32Opt/src/OpenFOAM/global/fileOperations/masterUncollatedFileOperation/masterUncollatedFileOperation.o] Error 1
make: *** Waiting for unfinished jobs....
Done logging to 'log.darwin64ClangDPInt32Opt'
``
my prefs.sh:
`
export projectDir="/Volumes/OFdisk/OpenFOAM-v2312"
export FOAM_CONFIG_ETC=etc-darwin
export WM_COMPILER_TYPE=system
export WM_COMPILER=Clang
export WM_PRECISION_OPTION=DP
export WM_LABEL_SIZE=32
export WM_COMPILE_OPTION=Opt
export WM_MPLIB=SYSTEMOPENMPI
export SCOTCH_VERSION=scotch-system
export fftw_version=fftw-system
export boost_version=boost-system
export cgal_version=cgal-system
export SCOTCH_ARCH_PATH=/usr/local/Cellar/scotch/7.0.4 ## 6.1.1 # run brew info scotch
export FFTW_ARCH_PATH=/usr/local/Cellar/fftw/3.3.10_1
export MPI_ARCH_PATH=/usr/local/Cellar/open-mpi/4.1.5
export BOOST_ARCH_PATH=/usr/local/Cellar/boost/1.82.0_1
export CGAL_ARCH_PATH=/usr/local/Cellar/cgal/5.6
export LDFLAGS="-L/usr/local/opt/readline/lib"
export CPPFLAGS="-I/usr/local/opt/readline/include"
export CXXFLAGS="-I/usr/local/Cellar/flex/2.6.4_2/include"
export FOAM_EXTRA_CXXFLAGS="-I/usr/local/Cellar/flex/2.6.4_2/include -DBOOST_MATH_DISABLE_FLOAT128"
export VTK_DIR="/usr/local/Cellar/vtk/9.2.5_1" # for runTimePostprocessing FO
export CMAKE_INCLUDE_PATH="/usr/local/Cellar/flex/2.6.4_2/include"
export CMAKE_LIBRARY_PATH="/usr/local/Cellar/flex/2.6.4_2/lib"
`Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/3065argList checking does not release all memory upon failure2024-01-03T10:12:34ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comargList checking does not release all memory upon failure<!--
*** 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 -->
small one: argList checking does not release all memory upon failure.
### Steps to reproduce
<!-- How one can reproduce the issue - this is very important -->
Run any app with incorrect args.
### 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.
-->
```
mattijs$ valgrind --leak-check=full --show-leak-kinds=all subsetMesh
==38812== Memcheck, a memory error detector
==38812== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
==38812== Using Valgrind-3.18.1 and LibVEX; rerun with -h for copyright info
==38812== Command: subsetMesh
==38812==
Using: OpenFOAM-v2312 (2312) - visit www.openfoam.com
Build: _8afb4c8ecf-20231220
Expected 1 arguments but found 0
See 'subsetMesh -help' for usage
or 'subsetMesh -help-full' for extended usage
==38812==
==38812== HEAP SUMMARY:
==38812== in use at exit: 104 bytes in 2 blocks
==38812== total heap usage: 44,804 allocs, 44,802 frees, 4,078,666 bytes allocated
==38812==
==38812== 40 bytes in 1 blocks are still reachable in loss record 1 of 2
==38812== at 0x4A3813F: operator new[](unsigned long) (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==38812== by 0x892FB4C: Foam::argList::argList(int&, char**&, bool, bool, bool) (in OpenFOAM/OpenFOAM-plus/release/OpenFOAM-v2312/platforms/linux64GccDPInt32Opt/lib/libOpenFOAM.so)
==38812== by 0x45A66F: main (in OpenFOAM/OpenFOAM-plus/release/OpenFOAM-v2312/platforms/linux64GccDPInt32Opt/bin/subsetMesh)
```
### Environment information
<!--
Providing details of your set-up can help us identify any issues, e.g.
OpenFOAM version : v2312|v2306|v2212|v2206|v2112 etc
Operating system : ubuntu|openSUSE|centos etc
Hardware info : any info that may help?
Compiler : gcc|intel|clang etc
-->
- OpenFOAM version : v2312Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/3063scotch : different behaviour with/without weights2023-12-20T15:01:04ZMark OLESENscotch : different behaviour with/without weightsAs noted by @Mattijs and @Prashant, it appears that scotch produces a different decomposition if uniform weights are specified versus no weights. Internally they should be the same thing, but needs more investigation.
Modifies changes m...As noted by @Mattijs and @Prashant, it appears that scotch produces a different decomposition if uniform weights are specified versus no weights. Internally they should be the same thing, but needs more investigation.
Modifies changes made in 98246a438eMark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/3061Mistake in documentation? Linear eddy viscosity models2023-12-19T06:18:48ZAli BozorgzadehMistake in documentation? Linear eddy viscosity modelsI think there is a mistake in the documentation in [this link](https://doc.openfoam.com/2306/tools/processing/models/turbulence/ras/linear-evm/).
The mistake can be found right after "leading to:". The second term on the right hand side...I think there is a mistake in the documentation in [this link](https://doc.openfoam.com/2306/tools/processing/models/turbulence/ras/linear-evm/).
The mistake can be found right after "leading to:". The second term on the right hand side should have a negative sign. It should be like the following:
```math
-\rho \textbf{R}_{dev} = \mu_t \left( \nabla \overline{\textbf{u}} + \nabla (\overline{\textbf{u}})^T \right) {\color{red}-} \mu_t \left( \frac{2}{3} \nabla \cdot \textbf{u} \right) \textbf{I}
```https://develop.openfoam.com/Development/openfoam/-/issues/3060[future request] snappyHexMesh: 'std::out_of_range' error2023-12-19T08:39:15ZAkira Azami[future request] snappyHexMesh: 'std::out_of_range' error### Summary
The following error occurred when testing on the supercomputer Fugaku Pre/Post node (large memory(6TB on board)).
\[error messages\] terminate called after throwing an instance of 'std::out_of_range' what(): stoi
It appear...### Summary
The following error occurred when testing on the supercomputer Fugaku Pre/Post node (large memory(6TB on board)).
\[error messages\] terminate called after throwing an instance of 'std::out_of_range' what(): stoi
It appears that the information on the size of the memory could not be expressed integer range.
### Example case
### Steps to reproduce
\[tutorials\] tutorials/incompressible/pisoFoam/LES/motorBike/motorBike (When snappyHexMesh is executed)
$ ./Allrun
### Environment information
- OpenFOAM version : v2306, v2212, etc
- Operating system : RHEL 8.6 (kernel 4.18.0-372)
- Hardware info : Intel Xeon Platinum 8280L (2.70GHz/28core)
- Compiler : icpc (ICC) 2021.10.0 20230609
### Possible fixes
Changing the stoi function in src/OSspecific/POSIX/memInfo/memInfo.C to the stol function will terminate successfully. This correction was found by Fugaku support staff.
```
diff -r 146727f129a6 -r b255d5d23e65 src/OSspecific/POSIX/memInfo/memInfo.C
--- a/OpenFOAM-v2306/src/OSspecific/POSIX/memInfo/memInfo.C Fri Sep 22 16:37:54 2023 +0900
+++ b/OpenFOAM-v2306/src/OSspecific/POSIX/memInfo/memInfo.C Fri Sep 22 16:46:00 2023 +0900
@@ -100,17 +100,17 @@
if (key == "VmPeak")
{
- peak_ = std::stoi(line.substr(delim+1));
+ peak_ = std::stol(line.substr(delim+1));
--nkeys;
}
else if (key == "VmSize")
{
- size_ = std::stoi(line.substr(delim+1));
+ size_ = std::stol(line.substr(delim+1));
--nkeys;
}
else if (key == "VmRSS")
{
- rss_ = std::stoi(line.substr(delim+1));
+ rss_ = std::stol(line.substr(delim+1));
--nkeys;
}
}
@@ -148,7 +148,7 @@
if (key == "MemFree")
{
- free_ = std::stoi(line.substr(delim+1));
+ free_ = std::stol(line.substr(delim+1));
--nkeys;
}
}
```Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/3058solver displacementLaplacian not working in v2212 and v2306 windows distribution2023-12-21T16:24:31ZDuncan van der Heulsolver displacementLaplacian not working in v2212 and v2306 windows distribution<!--
*** 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
snappyHexMesh can not find the displacementLaplacian solver required for the cell displacement in the layer addition step.
### Steps to reproduce
run tutorial \mesh\snappyHexMesh\iglooWi thFridgesDirectionalRefinement
### 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?
snappyHexMesh fails to generate mesh layer addition
### What is the expected *correct* behavior?
snappyHexMesh successfully completes mesh layer addition
### Relevant logs and/or images
Selecting motion solver: displacementLaplacian
--> FOAM FATAL IO ERROR: (openfoam-2212)
Unknown solver type displacementLaplacian
Valid solver types :
2(displacementInterpolation displacementLayeredMotion)
file: system/snappyHexMeshDict.addLayersControls at line 300.
From static Foam::autoPtr<Foam::displacementMotionSolver> Foam::displacementMotionSolver::New(const Foam::word&, const Foam::polyMesh&, const Foam::IOdictionary&, const pointVectorField&, const pointIOField&)
in file motionSolvers/displacement/displacement/displacementMotionSolver.C at line 115.
FOAM exiting
### 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 :V2212/v2306
- Operating system :Windows10
- Hardware info :Intel I9
- 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
-->Pawan GhildiyalPawan Ghildiyalhttps://develop.openfoam.com/Development/openfoam/-/issues/3057bug: Is this file supposed to be nuTilda not muTilda2024-01-03T09:56:28ZHAN BINbug: Is this file supposed to be nuTilda not muTildaIs this file supposed to be nuTilda instead of muTilda? Why are all the other models nuTilda? This one is muTilda. There is only one LES case in the compressible directory.The file address is below
https://develop.openfoam.com/Developme...Is this file supposed to be nuTilda instead of muTilda? Why are all the other models nuTilda? This one is muTilda. There is only one LES case in the compressible directory.The file address is below
https://develop.openfoam.com/Development/openfoam/-/blame/master/tutorials/compressible/rhoPimpleFoam/LES/pitzDaily/0/muTilda#L13https://develop.openfoam.com/Development/openfoam/-/issues/3054updates of solver performance destroy pimple controls2023-12-13T11:42:14ZMark OLESENupdates of solver performance destroy pimple controlsWith commit 0ff86ee2e the management of firstIteration/finalInteration migrated into meshState. However, there is folded into the solverPerformance dictionary which is cleared with `setSolverPerformance` if the time index changes.
Optio...With commit 0ff86ee2e the management of firstIteration/finalInteration migrated into meshState. However, there is folded into the solverPerformance dictionary which is cleared with `setSolverPerformance` if the time index changes.
Options:
- ad hoc preservation of firstIteration/finalInteration when clearing the solverPerformaanceDict
- move firstIteration/finalInteration into a "controls" sub-dictionary and/or place in the main mesh state dictionary.
Reported by @MattijsMark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/3053multiWorld not working with AMI2023-12-18T10:48:03ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.commultiWorld not working with AMI<!--
*** 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 -->
multiWorld not working with AMI. On e.g. `tutorials/basic/laplacianFoam/multiWorld1` you'll get errors:
```
[right/0]
[right/0]
[right/0] --> FOAM FATAL ERROR: (openfoam-2309)
[right/0] attempt to access element 0 from zero sized list
[right/0]
[right/0] From void Foam::UList<Foam::List<int> >::checkIndex(const Foam::label) const [T = Foam::List<int>]
[right/0] in file /home/mattijs/OpenFOAM/OpenFOAM-plus/work/develop/openfoam/src/OpenFOAM/lnInclude/UListI.H at line 207.
[right/0]
```
### Steps to reproduce
See above
### 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 -->
See above
### 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.
-->
See above
### 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
-->
The AMIInterpolation now stores its own communicator (to be able to handle processor-agglomeration). This get set to worldComm at construction time. Instead it needs to be reset to the inter-world communicator.Mattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comhttps://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.