Development issueshttps://develop.openfoam.com/groups/Development/-/issues2024-01-10T16:47:46Zhttps://develop.openfoam.com/Development/openfoam/-/issues/1542checkMesh aspect ratio2024-01-10T16:47:46ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comcheckMesh aspect ratio### Functionality to add/problem to solve
checkMesh calculates an aspect ratio in the global coordinate system. More relevant would probably using a cell-local coordinate system.
### Proposal
Use the cell-local coordinate system calc...### Functionality to add/problem to solve
checkMesh calculates an aspect ratio in the global coordinate system. More relevant would probably using a cell-local coordinate system.
### Proposal
Use the cell-local coordinate system calculation from e.g. the cellDeterminant check and determine the aspect ratio in that.
### What does success look like, and how can we measure that?
Make e.g. cavity with a lot of grading. See if the reported aspect ratio changes if the case is rotated (e.g. using `transformPoints -rotate`)https://develop.openfoam.com/Development/openfoam/-/issues/2709[Feature request] Macro expansion: Access keywords from separate files2024-01-10T16:36:52Zs1291[Feature request] Macro expansion: Access keywords from separate filesHello,
If I am not mistaken, It appears that OpenFOAM ESI versions do not provide a way to access external keywords from separate files.
OpenFOAM 9 and newer versions allow accessing keywords from separate files with the following synt...Hello,
If I am not mistaken, It appears that OpenFOAM ESI versions do not provide a way to access external keywords from separate files.
OpenFOAM 9 and newer versions allow accessing keywords from separate files with the following syntax:
```
aValue $FOAM_CASE/otherFile!foo;
```
`aValue` will have the value of `$foo` from the file `otherFile` within the case.
My workaround is to use a temporary dictionary with include to access the external keyword, e.g:
```
temp_dict
{
#include "otherFile"
}
aValue $temp_dict/foo;
#remove temp_dict
```
Is this feature already available that I am not aware of?
Thank youhttps://develop.openfoam.com/Development/openfoam/-/issues/692add additional information in header of decomposedBlockData2024-01-10T16:23:36ZMark OLESENadd additional information in header of decomposedBlockDataWe already have a `blocks` entry, but it would be quite convenient for downstream users (eg, paraview) if we also could pass along the underlying data-type in an easy to find place.
Eg,
FoamFile
{
version 2.0;
...We already have a `blocks` entry, but it would be quite convenient for downstream users (eg, paraview) if we also could pass along the underlying data-type in an easy to find place.
Eg,
FoamFile
{
version 2.0;
format binary;
class decomposedBlockData;
blocks 4;
object U;
dataClass volVectorField;
}
At the moment it is a bit of a pain to get at this information.
Would it be useful to have this dataClass information present as `IOobject::headerDataClassName()` with it being identical to `IOobject::headerClassName()` when `dataClass` isn't present?Mattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comhttps://develop.openfoam.com/Development/openfoam/-/issues/602redistributePar -reconstruct produces different phi field w.r.t. reconstructPar2024-01-10T16:22:29ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comredistributePar -reconstruct produces different phi field w.r.t. reconstructPar- take parallel/filter tutorial
- reconstruct time 0.8 (using ascii, 16 digits writeprecision) with both
```
reconstructPar -time 0.8
mpirun -np 3 redistributePar -reconstruct -time 0.8
```
The phi field differs in the last digits on som...- take parallel/filter tutorial
- reconstruct time 0.8 (using ascii, 16 digits writeprecision) with both
```
reconstructPar -time 0.8
mpirun -np 3 redistributePar -reconstruct -time 0.8
```
The phi field differs in the last digits on some faces.https://develop.openfoam.com/Development/openfoam/-/issues/477BUG: polyMesh construction from IOobject does not use instance. (it uses the ...2024-01-10T16:22:02ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comBUG: polyMesh construction from IOobject does not use instance. (it uses the Time::timeName() instead)Finds mesh files using findInstance which starts from timeName()Finds mesh files using findInstance which starts from timeName()Mattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comhttps://develop.openfoam.com/Development/openfoam/-/issues/2224solverInfo - colon in field names2024-01-10T16:13:48ZPacific ESIsolverInfo - colon in field namesUsing a colon in the residual field names of function object solverInfo means that the files created for these fields have names that are indecipherable in Windows. For example, in a recent run, initialResidual:p became ICLAZW~C. Not a p...Using a colon in the residual field names of function object solverInfo means that the files created for these fields have names that are indecipherable in Windows. For example, in a recent run, initialResidual:p became ICLAZW~C. Not a problem in Linux where the computations were done, but it is when I want to examine the results in Windows.
The same comment will apply to field names containing colons that are created anywhere else in OpenFOAM.https://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/2598binModels, force etc have questionable handling of coordinate systems2024-01-10T12:57:09ZMark OLESENbinModels, force etc have questionable handling of coordinate systemsThey expect either a `CofR` entry or a `coordinateSystem` entry. If neither exist, they fallback to using `coordinateSystem(const dictionary&)` construction which then requires the following:
- origin (mandatory)
- rotation (optional)
...They expect either a `CofR` entry or a `coordinateSystem` entry. If neither exist, they fallback to using `coordinateSystem(const dictionary&)` construction which then requires the following:
- origin (mandatory)
- rotation (optional)
If `rotation` is missing, it reverts to using the e3/e1 axis specifications. If these are also missing, will fail to construct.Kutalmış BerçinKutalmış Berçinhttps://develop.openfoam.com/Development/openfoam/-/issues/2521checkMesh -allTopology -allGeometry extensions2024-01-10T11:39:34ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comcheckMesh -allTopology -allGeometry extensions### Functionality to add/problem to solve
checkMesh:
- report duplicate elements in cell/face/point zones
- patch/zone manifold checking across processor boundaries
- avoid table column overflow for high number of digits (no space betwe...### Functionality to add/problem to solve
checkMesh:
- report duplicate elements in cell/face/point zones
- patch/zone manifold checking across processor boundaries
- avoid table column overflow for high number of digits (no space between volume and bounding box)
```
Checking basic cellZone addressing...
CellZone Cells Points VolumeBoundingBox
domain0 843053 972786 0.005553786145390933 (-0.01777677609419323 0.00198479132561023 -0.2625008427378372) (0.252276776117958 0.0770502 0.01250084273903893)
```https://develop.openfoam.com/Development/openfoam/-/issues/1815installation instructions for fedora 322024-01-10T11:32:04ZGhost Userinstallation instructions for fedora 32Hello,
I couldn't find any documentation on how to build openfoam2006 from source on Fedora 32. Could you please point me to the right location?
I have also tried to install it from copr (see below) but it fails:
```
$ sudo dnf copr en...Hello,
I couldn't find any documentation on how to build openfoam2006 from source on Fedora 32. Could you please point me to the right location?
I have also tried to install it from copr (see below) but it fails:
```
$ sudo dnf copr enable openfoam/openfoam
Enabling a Copr repository. Please note that this repository is not part
of the main distribution, and quality may vary.
The Fedora Project does not exercise any power over the contents of
this repository beyond the rules outlined in the Copr FAQ at
<https://docs.pagure.org/copr.copr/user_documentation.html#what-i-can-build-in-copr>,
and packages are not held to any quality or security level.
Please do not file bug reports about these packages in Fedora
Bugzilla. In case of problems, contact the owner of this repository.
Do you really want to enable copr.fedorainfracloud.org/openfoam/openfoam? [y/N]: y
Error: This repository does not have any builds yet so you cannot enable it now.
```
ThanksMark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/1904CentOS precompiled packages don't include scotch2024-01-10T11:27:31ZCristóbal TapiaCentOS precompiled packages don't include scotchHi,
I installed OpenFOAM v2006 with the instructions provided for CentOS in [1]. However, the `decomposePar` command is not working and gives the following error:
```
--> FOAM FATAL ERROR:
Attempted to use <scotch> without the scotchDe...Hi,
I installed OpenFOAM v2006 with the instructions provided for CentOS in [1]. However, the `decomposePar` command is not working and gives the following error:
```
--> FOAM FATAL ERROR:
Attempted to use <scotch> without the scotchDecomp library loaded.
This message is from the dummy scotchDecomp stub library instead.
Please install <scotch> and ensure libscotch.so is in LD_LIBRARY_PATH.
The scotchDecomp library can then be built from src/parallel/decompose/scotchDecomp.
Dynamically loading or linking this library will add <scotch> as a decomposition method.
```
Scotch is installed in the system, but I suppose that there is something else missing. Does this has to do with the "Third-Party" builds (not included in the packages?).
[1] https://develop.openfoam.com/Development/openfoam/-/wikis/precompiled/redhathttps://develop.openfoam.com/Development/openfoam/-/issues/2518Changes or information for FreeBSD port2024-01-10T11:25:00ZYuri ZChanges or information for FreeBSD port```
$ source ./work/OpenFOAM-v2112/etc/bashrc
cc: error: unsupported option '--showme:link'
``````
$ source ./work/OpenFOAM-v2112/etc/bashrc
cc: error: unsupported option '--showme:link'
```https://develop.openfoam.com/Development/openfoam/-/issues/2536Problems with the "useImplicit" feature for coupled patches2024-01-10T11:24:32ZTobias HolzmannProblems with the "useImplicit" feature for coupled patches<!--
*** 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 -->
Hey everybody, since we introduced the `useImplicit` keyword for coupled patches, I had the feeling that we have discrepancies using this feature in the energy equation (e.g., for chtMultiRegionSimpleFoam cases). After having some discussions on the 17th OpenFOAM workshop, people second my statement, that the `implicit` implementation is somehow buggy and lead to different results compared to running the case in the weakly coupling mode (standard one).
Hence, I made further investigations by using the multiRegionHeaterRadiation tutorial:
- Added a FO to record the average temperature inside each region
- Running the case in standard mode
- Running the case by adding the `useImplicit` keyword to the mapped boundary conditions (for all regions)
- Comparing the average temperatures of all regions between both simulations
- Simulation was run for 5000 iterations
- Simulation was performed in serial (no parallel run performed up to now)
The comparison is attached and as we can see, we get different results.
I also attached both cases and the gnuplot script.
If we do have mismatches for the CHT cases, I guess the `cyclic*` patches might have problems as well (e.g., AMI and aero).
### Steps to reproduce
<!-- How one can reproduce the issue - this is very important -->
Unpack the tar ball with the two cases + the gnuplot script.
Run the Allrun script for both cases and execute the gnuplot script.
### Example case
Already mentioned above. No further information required here.
[chtMultiRegionTestCasesImplicitBug.tar.gz](/uploads/9397d6b19087f36fbc0ded7fa7a6c169/chtMultiRegionTestCasesImplicitBug.tar.gz)
<!--
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?
Energy-Mismatch. It seems that the `implicit` somehow adds some sink term which reduces the temperature in the regions.
<!-- What actually happens -->
### What is the expected *correct* behavior?
Having the same results for both, the standard and implicit case.
<!-- What you should see instead -->
### Relevant logs and/or images
![comparison](/uploads/6b6d2d8341c3735ee6e6c460ce058c31/comparison.png)
<!--
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 : v2206|v2112|v2106|v2012|v2006 etc
Operating system : ubuntu|openSUSE|centos etc
Hardware info : any info that may help?
Compiler : gcc|intel|clang etc
-->
- OpenFOAM version : v2206
- Operating system : Ubuntu 20.04
- Hardware info : Not interesting
- Compiler : Gcc v 9.4
### 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
-->https://develop.openfoam.com/Development/openfoam/-/issues/2542Online documentation (user guide) sidebar broken2024-01-10T11:23:42ZChristian RohrOnline documentation (user guide) sidebar broken<!--
*** 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
The sidebar in the user guide is no longer functional. It doesn't show the headings or links to pages making it very difficult to find what you need, as you have to guess search terms. It stays collapsed listing only the main page no matter where you navigate or what you search for.
![image](/uploads/c4694e1879bc8c1e15060b9820c3898f/image.png)
### Steps to reproduce
Just go to the online [user guide](https://www.openfoam.com/documentation/guides/latest/doc/index.html) and try to navigate through.
Have reproduced on Edge, Firefox, Chrome.
### What is the expected *correct* behavior?
The sidebar should populate with the document structure as it does for the API guide. It did so up until about 2 weeks ago. Like this:
![image](/uploads/c180e7a6ffee807794506a23dc46dc20/image.png)https://develop.openfoam.com/Development/openfoam/-/issues/2549Error when cross-compile mingw on OpenSUSE2024-01-10T11:21:47ZQuang NguyenError when cross-compile mingw on OpenSUSEHi all,
When I try to cross compile OF source by using mingw on OpenSuse according to tutorial: https://develop.openfoam.com/Development/openfoam/-/wikis/building/cross-compile-mingw
But I have 2 problems:
- <mpi.h>: no such file or di...Hi all,
When I try to cross compile OF source by using mingw on OpenSuse according to tutorial: https://develop.openfoam.com/Development/openfoam/-/wikis/building/cross-compile-mingw
But I have 2 problems:
- <mpi.h>: no such file or directory
- cannot find -lmsmpi
I don't know how to solve these problem. Could you help me?
Thank you in advance!https://develop.openfoam.com/Development/openfoam/-/issues/2606CylicAMI incompatible with scaling of mesh2024-01-10T11:09:06Zfranco otaolaCylicAMI incompatible with scaling of mesh<!--
*** 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 -->
Hello,
there is a bug regarding the cyclicAMI patches to be more precise regarding the separationVector (at least I think it commes from that).
if we create a mesh that we assign a pair of cyclicAMI patches source and target, and we check the mesh, where we obtain correct AMI weights, if the we scale the mesh with transformPoints(I would guess that this behavior is the same one for the other transformations) the cyclicAMI breakes completly, even in the checkMesh output we can see that the weights are 0.
### Steps to reproduce
<!-- How one can reproduce the issue - this is very important -->
create a mesh with snappyHexMesh
use createPatch to create two cyclicAMI patches that are linked by "transform translational;"
checkMesh to be sure that the AMI weights are correct
scale the mesh using transformPoints -scale 1000
checkMesh again, the AMI weights will explode completly
### 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 -->
the source cyclicAMI patch unlinks from its cyclicAMI target patch after scaling the mesh
### What is the expected *correct* behavior?
<!-- What you should see instead -->
the source and target cyclicAMI patches should stay linked even after doing a transformation of points
### 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 : v2206|v2112|v2106|v2012|v2006 etc
Operating system : ubuntu|openSUSE|centos etc
Hardware info : any info that may help?
Compiler : gcc|intel|clang etc
-->
- OpenFOAM version :2206
- Operating system :ubuntu
- 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
-->https://develop.openfoam.com/Development/openfoam/-/issues/2628Link to source files doesn't work2024-01-10T11:06:28ZTorquil SørensenLink to source files doesn't workWhen using the documentation at https://www.openfoam.com/documentation/guides/latest/api, whenever I click on a link to a source file (*.C), I get a "file not found" web page. E.g, consider the following documentation page:
https://www....When using the documentation at https://www.openfoam.com/documentation/guides/latest/api, whenever I click on a link to a source file (*.C), I get a "file not found" web page. E.g, consider the following documentation page:
https://www.openfoam.com/documentation/guides/latest/api/semiPermeableBaffleMassFractionFvPatchScalarField_8C.html
Under "Detailed Description", there is a link "semiPermeableBaffleMassFractionFvPatchScalarField.C" to https://develop.openfoam.com/Development/OpenFOAM-plus/blob/OpenFOAM-v2112/src/thermoTools/derivedFvPatchFields/semiPermeableBaffle/semiPermeableBaffleMassFraction/semiPermeableBaffleMassFractionFvPatchScalarField.C
But this link doesn't work. I am sent to a "404 page not found" error page.
The same happens when I click on any such link to a *.C-file on any of the documentation pages.
Thankfully, the link further up "Go to the source code of this file" does work.https://develop.openfoam.com/Development/openfoam/-/issues/2510sphereDrop tutorial does not run to the end2024-01-10T11:02:12ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comsphereDrop tutorial does not run to the end<!--
*** 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 -->
sphereDrop tutorial does not run far with layer addition.
Smaller issues:
- runs with PCG on pcorr but GAMG on p_rgh
- runs pcorr to unnecessary tight tolerance?
### Steps to reproduce
<!-- How one can reproduce the issue - this is very important -->
Change end time on sphereDrop tutorial to 0.7 instead of 0.07.
### What is the current *bug* behaviour?
<!-- What actually happens -->
Case diverges at some point - alpha max gets above 1.
### 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.
-->
At around time 0.1992 the deltaT goes from e-5 to e-6 due to the Courant number. After that it starts getting lower and lower (assume velocity goes up - not checked). I've tried with 4 outer correctors but that didn't help.
### Environment information
<!--
Providing details of your set-up can help us identify any issues, e.g.
OpenFOAM version : v2112|v2106|v2012|v2006|v1912|v1906 etc
Operating system : ubuntu|openSUSE|centos etc
Hardware info : any info that may help?
Compiler : gcc|intel|clang etc
-->
- OpenFOAM version : v2206https://develop.openfoam.com/Development/openfoam/-/issues/2515All species from phase are losing mass on interfaceCompositionPhaseChangeMult...2024-01-10T10:59:47ZCássio AzevedoAll species from phase are losing mass on interfaceCompositionPhaseChangeMultiphaseSystemAll species from biomass (particles) are "evaporated" (fibras.particles and H2O.particles into H2O.gas) simultaneusly insted of only H2O.particles.
I'm using the multiphaseEulerFoam solver in Openfoam8.
[phaseProperties](/uploads/89089...All species from biomass (particles) are "evaporated" (fibras.particles and H2O.particles into H2O.gas) simultaneusly insted of only H2O.particles.
I'm using the multiphaseEulerFoam solver in Openfoam8.
[phaseProperties](/uploads/89089d5861aa7a52029f1d704b6551ee/phaseProperties)
[thermophysicalProperties.gas](/uploads/b48930324b73cf847474e519389b6525/thermophysicalProperties.gas)
[thermophysicalProperties.particles](/uploads/cdde465e7fda4d865b522c094d93695c/thermophysicalProperties.particles)https://develop.openfoam.com/Development/openfoam/-/issues/2058Windows OpenFOAM version not writing field files with name including ":"2024-01-10T10:58:10ZSandeepWindows OpenFOAM version not writing field files with name including ":"<!--
*** 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###
Field file names with ":" are not written in result folders
### Steps to reproduce
Run any simulation on windows with proudmanAcousticPower function object.
### Example case
Please check attached zip file as example for same
### What is the current *bug* behaviour?
It writes empty field file with name "proudmanAcousticPower", with 0kb size
### What is the expected *correct* behavior?
It should write two files "proudmanAcousticPower:L_P" and "proudmanAcousticPower:P_A"
### 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.
-->[proudmanAcousticPower.zip](/uploads/33bad9f2537c121066bd2339479115ae/proudmanAcousticPower.zip)
### 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 : OpenFOAM-v2012
- Operating system : Windows
- 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
-->Pawan GhildiyalPawan Ghildiyal