Development issueshttps://develop.openfoam.com/groups/Development/-/issues2023-12-18T08:37:25Zhttps://develop.openfoam.com/Development/openfoam/-/issues/2409atmBuoyancyTurbSource not working for RNGkEpsilon2023-12-18T08:37:25ZPetros AmpatzidisatmBuoyancyTurbSource not working for RNGkEpsilonTried to run the **atmForestStability** verification case with the RNGkEpsilon model. I got the following error:
`--> FOAM FATAL ERROR: (openfoam-2112) failed lookup of RNGkEpsilon:GbyNu (objectRegistry region0) available objects of typ...Tried to run the **atmForestStability** verification case with the RNGkEpsilon model. I got the following error:
`--> FOAM FATAL ERROR: (openfoam-2112) failed lookup of RNGkEpsilon:GbyNu (objectRegistry region0) available objects of type volScalarField::Internal: 20 (rhok ...)`
I think this is because **atmBuoyancyTurbSource** needs access to **GbyNu**.
In _kEpsilon.C_ line 248 `this->type() + ":GbyNu",` is missing from the respective _RNGkEpsilon.C_ file.
When this line is inserted in _RNGkEpsilon.C_ it seems to work.
I guess the same applies to the realizableKE.
Many thanksKutalmış BerçinKutalmış Berçinhttps://develop.openfoam.com/Development/openfoam/-/issues/3059Free Stream BC not working with ABL2023-12-19T10:11:10ZRaphael AranhaFree Stream BC not working with ABL<!--
*** 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 freeStream BC is not working properly with atmBoundaryLayerInletVelocity. It is not loading the information of the ABL and only using the value .
### Steps to reproduce
<!-- How one can reproduce the issue - this is very important -->
### Example case
if you try to run the example in the link https://www.openfoam.com/documentation/guides/latest/api/classFoam_1_1freestreamFvPatchField.html
it will not work, it will request a value and the value will overwrite the ABL profile
<!--
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 -->
### 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.
-->
### 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 :v2306
- 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/3064streamFunction FO message about not finding seed2023-12-20T13:10:09ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comstreamFunction FO message about not finding seed<!--
*** 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 -->
streamFunction FO reports message about not finding starting seed. Investigate. Also indentation of various FOs (see case below) is not consistent.
### Steps to reproduce
<!-- How one can reproduce the issue - this is very important -->
Run `incompressible/pisoFoam/RAS/cavity`
### What is the current *bug* behaviour?
Message about streamFunction not finding seed.
### 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 : v2310https://develop.openfoam.com/Development/openfoam/-/issues/3010snappyHexMesh: multi-region closed volume stl region assignment broken2024-01-02T12:59:33ZmonkeyseesnappyHexMesh: multi-region closed volume stl region assignment broken
### Summary
snappyHexMesh seems to delete all cells despite having 2 closed name surfaces that are marked as inside. One is nested inside the other but that's about the only tricky thing here.
In intermediate output it does seem sna...
### Summary
snappyHexMesh seems to delete all cells despite having 2 closed name surfaces that are marked as inside. One is nested inside the other but that's about the only tricky thing here.
In intermediate output it does seem snappy refines out the mesh with the right regions set from regionSplit, but removes them before finishing Foam::meshRefinement::baffleAndSplitMesh ending in crashes.
Basically from refined cells, snappyHexMesh should just be seeing if each one of the cell centers is unset and if it is, it should check if the cell center is inside any one of the closed volume surfaces (in the order of the list), and if it is, we should assign the cell a cell zone id (the refinement surface region name or cell zone if explicitly named) that corresponds to the closed volume surfaces from the geometry list (declaration list order to resolve ambiguity); it should be considered inside by default or from the zoneInside flag. It should not be deleted.
### Steps to reproduce
<!-- How one can reproduce the issue - this is very important -->
### Example case
[snappycase.zip](/uploads/3d7f1ef2cbab7232a7018eb840958880/snappycase.zip)
### What is the current *bug* behaviour?
Currently it crashes without locations and pointinside <coordinate> all being set - which still seems easy to get incorrect output - none of these should be necessary to generate a mesh - and indeed writing debug meshes can show good intermediate results. Frequently the background mesh ends up in the final output.
### What is the expected *correct* behavior?
Snappy should succeed and have the outer.stl surface with the inner.stl surface inside that, marked as separate regions. User should not have to use locationsInMesh and at most a locationOutsideMesh. Background mesh shouldn't be output.
### Relevant logs and/or images
```
Found 2 closed, named surfaces. Assigning cells in/outside these surfaces to the corresponding cellZone.
Walking from known cellZones; crossing a faceZone face changes cellZone
Created baffles in = 0 s
After introducing baffles : cells:0 faces:0 points:0
--> FOAM FATAL ERROR: (openfoam-2306)
No points or no cells in mesh
bad size -2147483647
From Foam::List<T>::List(Foam::label, Foam::zero) [with T = int; Foam::label = int]
in file /home/abuild/rpmbuild/BUILD/OpenFOAM-v2306/src/OpenFOAM/lnInclude/List.C at line 157.
FOAM aborting
[stack trace]
=============
#1 Foam::error::simpleExit(int, bool) in /usr/lib/openfoam/openfoam2306/platforms/linux64GccDPInt32Opt/lib/libOpenFOAM.so
#2 Foam::error::exiting(int, bool) in /usr/lib/openfoam/openfoam2306/platforms/linux64GccDPInt32Opt/lib/libOpenFOAM.so
#3 Foam::List<int>::List(int, Foam::zero) in /usr/lib/openfoam/openfoam2306/platforms/linux64GccDPInt32Opt/bin/snappyHexMesh
#4 Foam::meshRefinement::printMeshInfo(bool, Foam::string const&) const in /usr/lib/openfoam/openfoam2306/platforms/linux64GccDPInt32Opt/lib/libsnappyHexMesh.so
#5 Foam::meshRefinement::baffleAndSplitMesh(bool, Foam::snapParameters const&, bool, bool, Foam::Field<double> const&, int, Foam::dictionary const&, Foam::Time&, Foam::List<int> const&, Foam::List<int> const&, Foam::Field<Foam::Vector<double> > const&, Foam::List<Foam::word> const&, Foam::Field<Foam::Vector<double> > const&, bool, Foam::refPtr<Foam::coordSetWriter> const&) in /usr/lib/openfoam/openfoam2306/platforms/linux64GccDPInt32Opt/lib/libsnappyHexMesh.so
#6 Foam::snappyRefineDriver::baffleAndSplitMesh(Foam::refinementParameters const&, Foam::snapParameters const&, bool, Foam::dictionary const&) in /usr/lib/openfoam/openfoam2306/platforms/linux64GccDPInt32Opt/lib/libsnappyHexMesh.so
#7 Foam::snappyRefineDriver::doRefine(Foam::dictionary const&, Foam::refinementParameters const&, Foam::snapParameters const&, bool, Foam::meshRefinement::FaceMergeType, Foam::dictionary const&) in /usr/lib/openfoam/openfoam2306/platforms/linux64GccDPInt32Opt/lib/libsnappyHexMesh.so
#8 ? in /usr/lib/openfoam/openfoam2306/platforms/linux64GccDPInt32Opt/bin/snappyHexMesh
```
### Environment information
<!--
OpenFOAM version : v2306
Operating system : openSUSE
-->
- OpenFOAM version :v2306 (using science repos packages)
- Operating system : openSUSE 5.5
- Hardware info : amd
- Compiler :gcc
### Possible fixes
Seems like the issue occures either on this line or potentially just a little later
https://develop.openfoam.com/Development/openfoam/-/blob/master/src/mesh/snappyHexMesh/meshRefinement/meshRefinementBaffles.C?ref_type=heads#L3362https://develop.openfoam.com/Development/openfoam/-/issues/1528snappyHexMesh castellation step creates gaps between curved triangulated surf...2024-01-02T13:17:31ZDries AllaertssnappyHexMesh castellation step creates gaps between curved triangulated surfaces### Summary
In multiRegion cases, the castellation step of snappyHexMesh creates small gaps between curved triangulated surfaces (specified by stl files exported from CAD software AutoDesk Invecntor) when they are not exactly equal, eve...### Summary
In multiRegion cases, the castellation step of snappyHexMesh creates small gaps between curved triangulated surfaces (specified by stl files exported from CAD software AutoDesk Invecntor) when they are not exactly equal, even when stl files are exported at very high resolution (highest resolution available in the CAD software).
### Steps to reproduce
The issue can be reproduced by applying snappyHexMesh on a multiregion case with a curved interface between two regions, and with the different regions specified by different stl files exported from CAD software.
### Example case
Attached is a minimal working example consisting of two concentric cylinders corresponding to a fluid and a solid region. Only the castellation step of snappyHexMesh is run. [MWE.tar.gz](/uploads/21ca31e1c36f1f0e4a2673ec786c5fd9/MWE.tar.gz)
### What is the current *bug* behaviour?
The castellation step of snappyHexMesh creates small gaps between two triangulated surfaces, i.e., on the interface between two regions. As a result, some faces on the interface are identified as walls instead of mappedWalls between the two surfaces. In the snapping step, the gaps are closed but the patch type of some faces remains wall instead of mappedWall.
### What is the expected *correct* behavior?
snappyHexMesh should not remove cells located between two triangulated surface when the two triangulated surfaces coincide within a certain tolerance. The tolerance should be such that coinciding surfaces exported by CAD software can be meshed without creating small gaps. Possibly, this tolerance could be a user input.
### Relevant logs and/or images
Attached is a log file ([log.txt](/uploads/d20cb17863dbfce7ae643e6f8d23c929/log.txt)) of the provided minimal working example (logs of surfaceFeatureExtract - blockMesh - snappyHexMesh - splitMeshRegions) as well as some figures showing the case setup and the gaps on the interface.
Overview of the multiRegion geometry.
![MWE_fig1](/uploads/46a8588961f77c7616bdefac7eede9f1/MWE_fig1.png)
Detailed view of the interface.
![MWE_fig2](/uploads/a691486b653b0a97414885d0052784e1/MWE_fig2.png)
View of the interface, showing some faces that are identified as type wall (white) instead of mappedWall (red)
![MWE_fig3](/uploads/d6a1e6157024dad044c6cc8306f2dd6c/MWE_fig3.png)
### 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 : v1906
- Operating system : CentOS Linux release 7.6.1810
- Hardware info :
- Compiler : intel
### Possible fixeshttps://develop.openfoam.com/Development/openfoam/-/issues/3006Cannot run analysis parallel by using MinGW with OpenFOAM v23062024-01-03T14:52:43ZQuang NguyenCannot run analysis parallel by using MinGW with OpenFOAM v2306When I try to run analysis by using MinGW OpenFOAM v2306 with parallel option, I got this error. I don't know if anyone has the same error and if there is any way to solve it?
I run with command: mpirun -np 2 rhoSimpleFoam -parallel.
T...When I try to run analysis by using MinGW OpenFOAM v2306 with parallel option, I got this error. I don't know if anyone has the same error and if there is any way to solve it?
I run with command: mpirun -np 2 rhoSimpleFoam -parallel.
Thank you very much for any support.
![analysis_parallel_error](/uploads/38496cabb95551473c1178279aa59dd2/analysis_parallel_error.png)Pawan GhildiyalPawan Ghildiyalhttps://develop.openfoam.com/Development/openfoam/-/issues/2700coincidentBaffleInteraction missing from the source code (but present in the ...2024-01-04T09:46:28ZFranz DcoincidentBaffleInteraction missing from the source code (but present in the documentation?)In the files multiInteraction.C and multiInteraction.H, there is some reference to a feature / keyword "coincidentBaffleInteraction". While it is documented, it seems that the feature has not been implemented and the keyword is not worki...In the files multiInteraction.C and multiInteraction.H, there is some reference to a feature / keyword "coincidentBaffleInteraction". While it is documented, it seems that the feature has not been implemented and the keyword is not working.
Seems to be a long-standing issue:
https://bugs.openfoam.org/view.php?id=2939
https://www.cfd-online.com/Forums/openfoam-solving/141571-cyclic-boundary-conditions-particles.htmlAndrew HeatherAndrew Heatherhttps://develop.openfoam.com/Development/openfoam/-/issues/2736dynamicMesh failure restarting using CrankNicholson2024-01-04T10:56:23ZJamie MacLeoddynamicMesh failure restarting using CrankNicholson<!--
*** 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 -->
When restarting a case using dynamic meshing the first step fails with an error:
```
--> FOAM FATAL IO ERROR: (openfoam-2212 patch=230110)
size 77961 is not equal to the expected length 78325
file: 0.002/ddt0(rho,U).internalField at line 21.
From void Foam::Field<Type>::assign(const Foam::entry&, Foam::label) [with Type = Foam::Vector<double>; Foam::label = int]
in file ./src/OpenFOAM/lnInclude/Field.C at line 241.
FOAM exiting
```
This occurs regardless of whether dynamicMeshDict is altered or not (it may work sometimes if it is set to not refine every step, and happens to not align with the restart step, as previous tests have found that it works this way).
Almost certainly this associated with the 2nd order time scheme (which I would certainly strongly prefer to use), as Euler has no issues with the restart vs CN.
### Steps to reproduce
<!-- How one can reproduce the issue - this is very important -->
Run attached case until a new time, in this instance 0.002, and then try to restart.
### 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
-->
[dynMfail.zip](/uploads/384f0ef04572001fa268baf4d8ffcea3/dynMfail.zip)
### What is the current *bug* behaviour?
<!-- What actually happens -->
Restarting when using dynamic meshing fails with size error when using Crank Nicholson timeScheme.
### What is the expected *correct* behavior?
<!-- What you should see instead -->
The simulation restarts as a normal timestep would.
### 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 : v2212|v2206|v2112|v2106|v2012 etc
Operating system : ubuntu|openSUSE|centos etc
Hardware info : any info that may help?
Compiler : gcc|intel|clang etc
-->
```
Build : _c9081d5d-20230220 OPENFOAM=2212 patch=230110 version=2212
Arch : "LSB;label=32;scalar=64"
Exec : interFoam1
```
- Operating system : WSL Ubuntu 22.04
- Hardware info : Tested on Ryzen 5 2600 and Intel X chip
- Compiler : gcc?https://develop.openfoam.com/Development/openfoam/-/issues/2732An error occurred with the reconstructPar command2024-01-04T10:57:34Zliu haoAn error occurred with the reconstructPar command<!--
*** 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
An error occurred when executing the reconstructPar command with parallel computation
### Steps to reproduce
Run the example case
### 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
-->
Use Case From [https://turbmodels.larc.nasa.gov/naca0012_val.html](url) and https://github.com/tomrobin-teschner/OpenFOAMCaseGenerator [](url)
[Naca0012_number_of_processors_2_number_of_corrector_steps_3.zip](/uploads/174a417be398fc0c7f7af5d1ac8084fb/Naca0012_number_of_processors_2_number_of_corrector_steps_3.zip)
### 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.
-->
```
Reconstructing fields
region=region0
Time = 0.01
Reconstructing FV fields
Reconstructing volScalarFields
cp
--> FOAM FATAL IO ERROR: (openfoam-2206)
size 110 is not equal to the expected length 64
file: processor0/0.01/cp.boundaryField.farfield at line 7214 to 7215.
From Foam::Field<Type>::Field(const Foam::word&, const Foam::dictionary&, Foam::label) [with Type = double; Foam::label = int]
in file ./src/OpenFOAM/lnInclude/Field.C at line 218.
FOAM exiting
```
### Environment information
<!--
Providing details of your set-up can help us identify any issues, e.g.
OpenFOAM version : v2212|v2206|v2112|v2106|v2012 etc
Operating system : ubuntu|openSUSE|centos etc
Hardware info : any info that may help?
Compiler : gcc|intel|clang etc
-->
- OpenFOAM version :v2206
- Operating system :windows
- Hardware info :N/A
- Compiler :gcc(Ubuntu on WSL)https://develop.openfoam.com/Development/openfoam/-/issues/2032faMesh does not have own registry2024-01-05T16:57:44ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comfaMesh does not have own registry### Functionality to add/problem to solve
faMesh does not have its own objectRegistry but uses the polyMesh one. This means e.g. that its data() conflicts with that of a fvMesh.
### What does success look like, and how can we measure t...### Functionality to add/problem to solve
faMesh does not have its own objectRegistry but uses the polyMesh one. This means e.g. that its data() conflicts with that of a fvMesh.
### What does success look like, and how can we measure that?
Successfully run any finiteArea case with
```
DebugSwitches
{
regIOobject 2;
}
```
(this debugswitch will trigger aborting upon double registration)https://develop.openfoam.com/Development/openfoam/-/issues/1937redistributePar produces illogical warning message2024-01-05T16:59:11ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comredistributePar produces illogical warning message<!--
*** 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 -->
redistributePar uses internally fvMeshSubset to subset mesh+fields to send to other processors. Exposed internal faces will produce a warning for any boundary condition holding per-face information (e.g. fixedValue v.s. uniformFixedValue).
Since the bits will get stitched later on there is actually no use for the warning message - it is just due to the current implementation.
### Steps to reproduce
<!-- How one can reproduce the issue - this is very important -->
Eg in `tutorials/incompressible/simpleFoam/pitzDaily` :
```
mpirun -np 2 redistributePar -decompose -parallel
```
This will give a warning:
```
--> FOAM Warning :
From Foam::fixedValueFvPatchField<Type>::fixedValueFvPatchField(const Foam::fixedValueFvPatchField<Type>&, const Foam::fvPatch&, const Foam::DimensionedField<Type, Foam::volMesh>&, const Foam::fvPatchFieldMapper&) [with Type = double]
in file src/finiteVolume/lnInclude/fixedValueFvPatchField.C at line 81
On field subsetepsilon patch lowerWall patchField fixedValue : mapper does not map all values.
To avoid this warning fully specify the mapping in derived patch fields.
```
### 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 : <= v2006Mattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comhttps://develop.openfoam.com/Development/openfoam/-/issues/2038Wall parameter oscillation of flow field behind shock wave2024-01-08T04:06:00Zdu lWall parameter oscillation of flow field behind shock wave### Summary
Wall parameter oscillation of flow field behind shock wave in hypersonic flow
### Example case
[wedge.tar.xz](/uploads/af59c839c67444ce2bb35b645f273bb5/wedge.tar.xz)
### Environment information
** OpenFOAM version :*...### Summary
Wall parameter oscillation of flow field behind shock wave in hypersonic flow
### Example case
[wedge.tar.xz](/uploads/af59c839c67444ce2bb35b645f273bb5/wedge.tar.xz)
### Environment information
** OpenFOAM version :** v2012|v1706
**Operating system :** ubuntu 1804
** Solver:** rhoCentralFoam
I have calculated the laminar flow , transition flow and turbulent flow cases. The model is *k−ωSSTLM* and *k−ωSST*, respectively. The *yplus* no more than 1 near the wall. And the wall parameter oscillation phenomenon appears in all cases.
About the choice of limiter, I also tried many options. The **divSchemes** has no obvious influence on this phenomenon.
But when I use commercial software to calculate under the same boundary conditions and mesh, there is no such phenomenon. This makes me very confused.Kutalmış BerçinKutalmış Berçinhttps://develop.openfoam.com/Development/openfoam/-/issues/1785wallDist method meshWave does clipping twice2024-01-08T11:01:20ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comwallDist method meshWave does clipping twiceIn the code `src/finiteVolume/fvMesh/wallDist/patchDistMethods/Poisson/PoissonPatchDistMethod.C` it twice does clipping:
```
// For overset: enforce smooth y field (yPsi is smooth, magGradyPsi is
// not)
mesh_.interpolate(y);...In the code `src/finiteVolume/fvMesh/wallDist/patchDistMethods/Poisson/PoissonPatchDistMethod.C` it twice does clipping:
```
// For overset: enforce smooth y field (yPsi is smooth, magGradyPsi is
// not)
mesh_.interpolate(y);
// Need to stabilise the y for overset meshes since the holed cells
// keep the initial value (0.0) so the gradient of that will be
// zero as well. Turbulence models do not like zero wall distance.
y.max(SMALL);
// For overset: enforce smooth y field (yPsi is smooth, magGradyPsi is
// not)
mesh_.interpolate(y);
```
Not sure but only second one probably needs to be done. Check.https://develop.openfoam.com/Development/openfoam/-/issues/2488redistributePar -decompose with inconsistent nProcs2024-01-08T13:36:51ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comredistributePar -decompose with inconsistent nProcs### Functionality to add/problem to solve
redistributePar -decompose gives illogical error message if the number of procs does not equal the number in the decomposeParDict. E.g. in decomposeParDict:
```
numberOfSubdomains 2;
```
Run wi...### Functionality to add/problem to solve
redistributePar -decompose gives illogical error message if the number of procs does not equal the number in the decomposeParDict. E.g. in decomposeParDict:
```
numberOfSubdomains 2;
```
Run with
```
mpirun -np 4 redistributePar -decompose -parallel
```
Produces output
```
[0] --> FOAM FATAL ERROR: (openfoam-2202 patch=220310)
[0] number of processor directories = 1 is not equal to the number of processors = 4
```
which is not very helpful.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/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/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/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/2635#eval and #calc rounding issues2024-01-11T12:19:46Zfranco otaola#eval and #calc rounding issues<!--
*** 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 #eval function gives wrong results for small calculations. this can be highly troublesome as it is not something that one can 'see' easily.
### Steps to reproduce
<!-- How one can reproduce the issue - this is very important -->
create a file with different eval commands and use foamDictionary to add an entry so it computes all the results.
### Example case
create a file with following variables
```
dp #eval{ sqrt(3./2.) *1e-3};
a #eval{ 2/sqrt(2.)*$dp };
A_square #eval{ $a*$a };
A_inlet #eval{ $A_square-2*degToRad(180)*$dp*$dp*0.25 };
Q $A_inlet;
Qerror #eval{$A_inlet};
e #eval{0.2526944494428081};
Uin #eval{ $Q/($A_square*$e) };
```
run `foamDictionary -entry edges -value file_test -set "( )"`
the evaluated file gives
```
dp 0.00122474;
a 0.00173241;
A_square 2.99982e-06;
A_inlet 6.42824e-07;
Q 6.42824e-07;
Qerror 1e-06;
e 0.252694;
Uin 1.31912;
edges ( );
```
which are not all correct (it looks like rounding issue)
### 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 :centos
- Hardware info :
- Compiler :Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/3079cyclicAMI transformation calculation uses a single face2024-01-11T13:28:32ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comcyclicAMI transformation calculation uses a single face<!--
*** 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 -->
cyclicAMI transformation calculation uses a single face so can give large errors
### Steps to reproduce
<!-- How one can reproduce the issue - this is very important -->
### Example case
`incompressible/simpleFoam/pipeCyclic/`
In system/controlDict add:
```
DebugSwitches
{
cyclicAMI 1;
}
writePrecision 16;
```
and run e.g. checkMesh:
```
cyclicAMIPolyPatch::calcTransforms: patch:side2 Specified rotation: n0:(0 0.7071068286895752 -0.7071068286895752) n1:(0 -0.7071068286895752 -0.7071068286895752) swept angle: 90 [deg] reverse transform: (1 0 0 0 0 -1.00000011920929 0 1.00000011920929 0)
patch: side2
forwardT = 1((1 0 0 0 0 1.00000011920929 0 -1.00000011920929 0))
reverseT = 1((1 0 0 0 0 -1.00000011920929 0 1.00000011920929 0))
separation = 0()
collocated = 1(0)
```
The transformation should be close(r) to 1. Also checkMesh gives an open cells warning.
This is independent of #2635 since I replaced the #eval with calculated values in the blockMeshDict.
<!--
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 -->
### What is the expected *correct* behavior?
<!-- What you should see instead -->
no warning about open cells
### 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 : v2312
### 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
-->
It currently uses the largest face.
- does it use the opposite face?
- or can it use some average?