Development issueshttps://develop.openfoam.com/groups/Development/-/issues2021-07-08T07:05:07Zhttps://develop.openfoam.com/Development/openfoam/-/issues/2094read updated VTK legacy format2021-07-08T07:05:07ZMark OLESENread updated VTK legacy formattopic flagged on [paraview discourse](https://discourse.paraview.org/t/paraview-segmentation-fault-core-dumped/6694) with a wandering title, but the essentials:
With new VTK versions, the internal vtkCellArray changed (see 9338f0b8600d1...topic flagged on [paraview discourse](https://discourse.paraview.org/t/paraview-segmentation-fault-core-dumped/6694) with a wandering title, but the essentials:
With new VTK versions, the internal vtkCellArray changed (see 9338f0b8600d1ba5f0b24f79a83c63111e90675b for previous changes). As a result of this, the VTK legacy format has also changed.
### Previously
```
POLYGONS (npoly) (nPolys + nConnectivity)
n1 verts1...
n2 verts2...
...
```
### Updated
```
POLYGONS (npoly) (nConnectivity)
OFFSETS int
0 n1 n1+n2 n1+n2+n3 ...
CONNECTIVITY int
verts1 verts2 ...
```
Same thing for unstructured etc. We probably don't yet want to update our output routines to generate the new contents (and potentially ruin things for any downstream consumers of the files), but should adjust the readers to accommodate.
Note: cannot tell from any particular VTK spec if the ordering OFFSETS/CONNECTIVITY vs CONNECTIVITY/OFFSETS is prescribed, but the internal vtkCellArray writer routine does output then in OFFSETS/CONNECTIVITY order. So reasonable to start there.Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/2093BUG: forces: UName entry is not used2021-08-05T12:56:59ZKutalmış BerçinBUG: forces: UName entry is not used### Summary
<!-- Summarize the bug encountered concisely -->
For basic incompressible and compressible simulations, the `force` function object has not been using a given `UName` for the `devRhoReff` computation (affecting the tangenti...### Summary
<!-- Summarize the bug encountered concisely -->
For basic incompressible and compressible simulations, the `force` function object has not been using a given `UName` for the `devRhoReff` computation (affecting the tangential component), but using the `U` of the latest available step.
In contrast, the `pName` has always been being used correctly.
### Steps to reproduce
<!-- How one can reproduce the issue - this is very important -->
Consider any tutorial using the `force` function object.
Compute the following, and compare the output of integrated forces or force fields:
- `fieldAverage` of `force` function object using instantaneous `U` field.
- `force` function object using a given `UMean` at the end of the simulation; obtain `UMean` by using `fieldAverage`.
The results consistently differ within a certain range of decimal points irrespective of initialisation/sampling duration.
### 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
-->
api = 2102
patch = 210414
HEAD = 5eb48c443a
version = com
compiler = Clang (system)
= clang version 9.0.1
mpi = SYSTEMOPENMPI
= mpirun (Open MPI) 1.10.7.0.5e373bf1fd
OS = Description: openSUSE Leap 15.1
opts = linux64ClangDPInt32Opt
### 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
-->
(EP#1224)Kutalmış BerçinKutalmış Berçinhttps://develop.openfoam.com/Development/openfoam/-/issues/2092redistributePar does not always detect whether reconstruction is needed2024-01-05T16:55:06ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comredistributePar does not always detect whether reconstruction is needed### Functionality to add/problem to solve
redistributePar does not always decide to reconstruct mesh correctly
- run `redistributePar` with -decompose (or decomposePar)
- remove constant/polyMesh (but not processorXXX/constant/polyMesh...### Functionality to add/problem to solve
redistributePar does not always decide to reconstruct mesh correctly
- run `redistributePar` with -decompose (or decomposePar)
- remove constant/polyMesh (but not processorXXX/constant/polyMesh/*addressing)
- now redistributePar still thinks it has an undecomposed mesh (since above *addressing still exists)
### Target audience
Cleanup scripts that don't delete addressing
### Proposal
Add some more checks
(EP 1573) @Prashant @markMark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/2091Style: PDRFOAM2021-05-19T13:49:16ZHenning ScheuflerStyle: PDRFOAMPDR and PDRAutorefine end with:
Info<< "\n end\n";
instead of
Info<< "End\n";PDR and PDRAutorefine end with:
Info<< "\n end\n";
instead of
Info<< "End\n";Henning ScheuflerHenning Scheuflerhttps://develop.openfoam.com/Development/openfoam/-/issues/2089BUG: turbulentDFSEMInlet: wrong operator in checkStresses function2021-06-09T13:47:40ZKutalmış BerçinBUG: turbulentDFSEMInlet: wrong operator in checkStresses function### Summary
<!-- Summarize the bug encountered concisely -->
In [L1003](https://develop.openfoam.com/Development/openfoam/-/blob/master/src/finiteVolume/fields/fvPatchFields/derived/turbulentDFSEMInlet/turbulentDFSEMInletFvPatchVectorF...### Summary
<!-- Summarize the bug encountered concisely -->
In [L1003](https://develop.openfoam.com/Development/openfoam/-/blob/master/src/finiteVolume/fields/fvPatchFields/derived/turbulentDFSEMInlet/turbulentDFSEMInletFvPatchVectorField.C#L1003), the relevant term `*a_yy` should be `/a_yy`.
The bug was found by Ole Meyer, @h2o_meyer.v2106Kutalmış BerçinKutalmış Berçinhttps://develop.openfoam.com/Development/openfoam/-/issues/2088blockMesh fails when mergePatchPairs is used and regions are declared2021-05-21T07:57:54ZMark YobbblockMesh fails when mergePatchPairs is used and regions are declared<!--
*** 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 using mergePatchPairs in blockMeshDict, blockMesh fails only when regions are declared as part of a block declaration with hex.
### Steps to reproduce
<!-- How one can reproduce the issue - this is very important -->
Author a blockMeshDict file with 3 blocks that share common planes. Declare patches for two of the adjacent blocks. Use mergePatchPairs to merge the patches together. In the hex declaration assign a region name to any one of the blocks. blockMesh fails even if the region defined is not associated with a merged block. (That is why I indicated 3 blocks 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
-->
I am attaching a sample case that I made to trouble shoot the problem I was having.
### What is the current *bug* behaviour?
The bug behavior is that blockMesh fails to complete and outputs the following messasge:
```
--> FOAM FATAL ERROR: (openfoam-2012)
point, face or cell zone already exists
From void Foam::polyMesh::addZones(const Foam::List<Foam::pointZone*>&, const Foam::List<Foam::faceZone*>&, const Foam::List<Foam::cellZone*>&)
in file meshes/polyMesh/polyMesh.C at line 1007.
FOAM aborting
#0 Foam::error::printStack(Foam::Ostream&) at ??:?
#1 Foam::error::exitOrAbort(int, bool) at ??:?
#2 Foam::polyMesh::addZones(Foam::List<Foam::pointZone*> const&, Foam::List<Foam::faceZone*> const&, Foam::List<Foam::cellZone*> const&) at ??:?
#3 ? in ~/OpenFOAM/OpenFOAM-v2012/platforms/linux64GccDPInt32Opt/bin/blockMesh
#4 __libc_start_main in /lib/x86_64-linux-gnu/libc.so.6
#5 ? in ~/OpenFOAM/OpenFOAM-v2012/platforms/linux64GccDPInt32Opt/bin/blockMesh
Aborted
```
### What is the expected *correct* behavior?
The correct behavior is to successfully generate the mesh with the regions defined as long as blocks from different regions were not joined with mergePatchPairs.
### Relevant logs and/or images
<!--
Paste any relevant logs - please use code blocks (```) to format console
output, logs, and code as it's very hard to read otherwise.
-->
### Environment information
<!--
Providing details of your set-up can help us identify any issues, e.g.
OpenFOAM version : v1806|v1812|v1906 etc
Operating system : ubuntu|openSUSE|centos etc
Hardware info : any info that may help?
Compiler : gcc|intel|clang etc
-->
- OpenFOAM version :2012
- Operating system :Debian 10 (Buster)
- Hardware info :AMD Ryzen 9 3900X 12-Core Processor, 64 GB ddr4
- Compiler :g++ 4:8.3.0-1,g++-8 8.3.0-6[blockMeshDict](/uploads/67dfd557d69b8288c115d8cd9b3d16ab/blockMeshDict)
### 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/2084missing decomposition constraint for finite-area2021-11-05T18:07:40ZMark OLESENmissing decomposition constraint for finite-arearaised during discussion with @Mattijs - the outside perimeter of a finiteArea **can** be split on a processor boundary. This means loss of the BC and replacement with a bad processor definition.
@Sergioraised during discussion with @Mattijs - the outside perimeter of a finiteArea **can** be split on a processor boundary. This means loss of the BC and replacement with a bad processor definition.
@SergioMark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/2083remove/deprecate construct list from two iterators2021-07-15T16:54:40ZMark OLESENremove/deprecate construct list from two iteratorsThere are different two-parameter forms when constructing a `List`, notably these:
```
List(const label len, const T& val);
List(const UList<T>& list, const labelUList& indices);
template<class InputIterator>
List(InputIterator begIter...There are different two-parameter forms when constructing a `List`, notably these:
```
List(const label len, const T& val);
List(const UList<T>& list, const labelUList& indices);
template<class InputIterator>
List(InputIterator begIter, InputIterator endIter)
```
This typically causes compilation issues with 64-bit labels, eg,
```
bad: labelList test(5, 0);
good: labelList test(label(5), 0);
good: labelList test(5, Zero);
```
otherwise the two-iterator constructor masks everything.
In the past, this has prompted both the removal (c43b78e8de830a327409a0449400e6decc9488f4) and the reinstatement (d01eb45cfc5936d337bafd93d7ed1370d26586b9) of this constructor, even if the problem was never resolved.
Although we generally deal with the problem by properly casting the arguments, still cannot unmask the mapping constructor.
For example,
```
labelList allValues = ...;
labelList indices = ...;
labelList myValues(allValues, indices); -> Error bad iterator pair!!
```
Although this mapping lookup works with Field and most other types of List, it will not work for a `labelList`.
This leads to this type of code:
```
callFunction(labelList(UIndirectList<label>(allValues, indices)));
```
vs
```
callFunction(labelList(allValues, indices));
```
Propose once again removing the construct from iterator pair and/or replace with a tagged version. For example,
```
template<class InputIterator>
List(std::piecewise_construct, InputIterator begIter, InputIterator endIter)
```
Open to suggestions for better dispatch tags.Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/2082DEShybrid leads to crash for single and mixed precision versions of OpenFOAM2021-06-10T09:01:50ZHendrik HetmannDEShybrid leads to crash for single and mixed precision versions of OpenFOAM<!--
*** 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 -->
OpenFOAM crashes if using the DEShybrid blending scheme with single (SP) or mixed precision (SPDP) compilation.
### Steps to reproduce
<!-- How one can reproduce the issue - this is very important -->
Compile OpenFOAM in single or mixed precision mode. Run any case with DEShybrid blending scheme for div(phi,U).
### 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
-->
pitzDaily with SA-DDES and DEShybrid blending scheme
[DEShybrid_pitzDaily.tar.gz](/uploads/784a1c6c92f877792108b1d972745bf2/DEShybrid_pitzDaily.tar.gz)
### What is the current *bug* behaviour?
<!-- What actually happens -->
OpenFOAM crashes.
### What is the expected *correct* behavior?
<!-- What you should see instead -->
No crash :-)
### 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.
-->
```
Starting time loop
fieldAverage fieldAverage1:
Restarting averaging for fields:
U: starting averaging at time 0
p: starting averaging at time 0
Sampled surface:
nearWall -> vtk
Time = 1e-05
Courant Number mean: 8.74894e-05 max: 0.0315889
#0 Foam::error::printStack(Foam::Ostream&) at ??:?
#1 Foam::sigFpe::sigHandler(int) at ??:?
#2 ? in /lib64/libc.so.6
#3 Foam::pow(Foam::Field<float>&, Foam::UList<float> const&, float const&) at ??:?
#4 Foam::tmp<Foam::GeometricField<float, Foam::fvPatchField, Foam::volMesh> > Foam::pow<Foam::fvPatchField, Foam::volMesh>(Foam::GeometricField<float, Foam::fvPatchField, Foam::volMesh> const&, Foam::dimensioned<float> const&) at ??:?
#5 Foam::tmp<Foam::GeometricField<float, Foam::fvPatchField, Foam::volMesh> > Foam::pow<Foam::fvPatchField, Foam::volMesh>(Foam::GeometricField<float, Foam::fvPatchField, Foam::volMesh> const&, float const&) at ??:?
#6 Foam::DEShybrid<Foam::Vector<float> >::calcBlendingFactor(Foam::GeometricField<Foam::Vector<float>, Foam::fvPatchField, Foam::volMesh> const&, Foam::GeometricField<float, Foam::fvPatchField, Foam::volMesh> const&, Foam::GeometricField<Foam::Vector<float>, Foam::fvPatchField, Foam::volMesh> const&, Foam::GeometricField<float, Foam::fvPatchField, Foam::volMesh> const&) const at ??:?
#7 Foam::DEShybrid<Foam::Vector<float> >::blendingFactor(Foam::GeometricField<Foam::Vector<float>, Foam::fvPatchField, Foam::volMesh> const&) const at ??:?
#8 Foam::DEShybrid<Foam::Vector<float> >::weights(Foam::GeometricField<Foam::Vector<float>, Foam::fvPatchField, Foam::volMesh> const&) const at ??:?
#9 Foam::fv::gaussConvectionScheme<Foam::Vector<float> >::fvmDiv(Foam::GeometricField<float, Foam::fvsPatchField, Foam::surfaceMesh> const&, Foam::GeometricField<Foam::Vector<float>, Foam::fvPatchField, Foam::volMesh> const&) const at ??:?
#10 Foam::fv::boundedConvectionScheme<Foam::Vector<float> >::fvmDiv(Foam::GeometricField<float, Foam::fvsPatchField, Foam::surfaceMesh> const&, Foam::GeometricField<Foam::Vector<float>, Foam::fvPatchField, Foam::volMesh> const&) const at ??:?
#11 ? at ??:?
#12 ? at ??:?
#13 __libc_start_main in /lib64/libc.so.6
#14 ? at /home/abuild/rpmbuild/BUILD/glibc-2.26/csu/../sysdeps/x86_64/start.S:122
Gleitkomma-Ausnahme (Speicherabzug geschrieben)
```
### 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 : v1912
- Operating system : openSUSE 15.1
- Hardware info :
- Compiler : gcc7
### 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
-->Kutalmış BerçinKutalmış Berçinhttps://develop.openfoam.com/Development/openfoam/-/issues/2080add multi-region support for foamToEnsight2021-07-08T07:05:25ZMark OLESENadd multi-region support for foamToEnsightMark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/2079change location of "static" ensight geometry2021-05-28T12:16:15ZMark OLESENchange location of "static" ensight geometryLooking at adding in multi-region support for foamToEnsight (#2080) and we have a slight chance of name collisions if someone happens to have a region called "data" or "geometry", since these are reserved names in our EnSight output.
Wa...Looking at adding in multi-region support for foamToEnsight (#2080) and we have a slight chance of name collisions if someone happens to have a region called "data" or "geometry", since these are reserved names in our EnSight output.
Was thinking that `geometry` should become `data/constant/geometry`, by inserting a _constant_ data sub-directory.
Any concerns about this affecting workflows etc, or any other thoughts?
@andy @Mattijs @Sergio @kuti @Prashant @Pawan @chiaraMark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/2078Crash with dynamicMotionSolverFvMeshAMI2024-01-10T10:57:24ZDavid HoraCrash with dynamicMotionSolverFvMeshAMIHi all
I wanted to test the dynamicMotionSolverFvMeshAMI but my simulation of a centrifugal fan crashes immediately because of an unallocated autoPtr. The case has 9.3 million cells and consists of an impeller and a volute. The simulati...Hi all
I wanted to test the dynamicMotionSolverFvMeshAMI but my simulation of a centrifugal fan crashes immediately because of an unallocated autoPtr. The case has 9.3 million cells and consists of an impeller and a volute. The simulation is a restart from a dynamicMotionSolverFvMesh simulation where two revolutions were calculated without problems. Unfortunately I can't reproduce it with a smaller case. I hope the log file helps. Otherwise let me know if you need more information.
Kind regards
David
[pimpleFoam_rerun.log](/uploads/0a899b9c446f6fd1bade038e6d63546f/pimpleFoam_rerun.log)Kutalmış BerçinKutalmış Berçinhttps://develop.openfoam.com/Development/openfoam/-/issues/2077Missing "make" causes misleading error about missing C++ compiler rule2021-06-18T16:58:25ZMichael BazarewskyMissing "make" causes misleading error about missing C++ compiler rule### Summary
In the event that wmake is installed but make is not (eg in the case of a binary installation on a very clean cloud server environment), RunFunctions incorrectly reports that there is no rule for C++ compilation. This is du...### Summary
In the event that wmake is installed but make is not (eg in the case of a binary installation on a very clean cloud server environment), RunFunctions incorrectly reports that there is no rule for C++ compilation. This is due to the code not validating the existence of "make".
### Steps to reproduce
On an Ubuntu system that does not have make installed but does have the 2012 binaries installed and the proper PATH configuration, attempt to Allrun one of the tutorials.
The real cause can be seen if you `sh -x ./Allrun` and note the "swallowed" error from wmake that is exposed.
### Example case
### What is the current *bug* behaviour?
"missing C++ rule, cannot compile" error
### What is the expected *correct* behavior?
"No make command found ... cannot compile"
### Relevant logs and/or images
### 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 : v2012
- Operating system : ubuntu
- Hardware info : n/a
- Compiler : gcc
### Possible fixes
This can be fixed by adding the following at or about [line 67](https://develop.openfoam.com/Development/openfoam/-/blob/master/bin/tools/RunFunctions#L67) (that's the correct place as of when I'm submitting this) of RunFunctions:
```
if ! command -v make > /dev/null
then
echo "No make command found ... cannot compile" 1>&2
return 1
fi
```https://develop.openfoam.com/Development/openfoam/-/issues/2076planned changes to geometricVoF2021-06-08T20:33:33ZHenning Scheuflerplanned changes to geometricVoFAs hinted in issue #1955, we (@johan_roenby and me) are planning to update the geometricVoF code and unify it with our open-source release:
https://arxiv.org/abs/2103.00870
https://github.com/DLR-RY/twophaseflow
This step will signific...As hinted in issue #1955, we (@johan_roenby and me) are planning to update the geometricVoF code and unify it with our open-source release:
https://arxiv.org/abs/2103.00870
https://github.com/DLR-RY/twophaseflow
This step will significantly reduce our time spent maintaining both codes and should raise the code quality of both releases. This would also signficantly simplify testing the library for us.
Currently, the libraries are almost identical and the only feature added is the capability to run interIsoFoam with AMR. In this process, smaller changes to the comments are also planned.
Would you support this approach?
if so, I would create a new branch so we can merge into develop later
@kuti @andy @markv2106Henning ScheuflerHenning Scheuflerhttps://develop.openfoam.com/Development/openfoam/-/issues/2075OpenFOAM v2012 writes following links2021-05-28T12:17:00ZMortesinsOpenFOAM v2012 writes following links<!--
*** 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
When OpenFOAM v2012 writes to a file that is a link to another file (without appending), OpenFOAM does not delete the link and create a new file but instead it writes following the link. This was not the case in OpenFOAM v2006.
### Steps to reproduce
- Create a new case that has the mesh files as links to another mesh
- Create a new cellzone with topoSet, the cellZones file will be written following the link.
### What is the current *bug* behaviour?
OpenFOAM writes following the link
### What is the expected *correct* behavior?
OpenFOAM should delete the link and create a new file instead
### 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 : v2012
- Operating system : centos
- Hardware info :
- Compiler : gcc 8.4.0
### Possible fixes
Line 63 of fstreamPointers.C should be:
```
if (!append && Foam::type(targetName, false) == fileName::LINK)
```
instead of:
```
if (!append && Foam::type(targetName) == fileName::LINK)
```
https://develop.openfoam.com/Development/openfoam/-/blob/master/src/OpenFOAM/db/IOstreams/Fstreams/fstreamPointers.C#L63
It used to be like this in v2006:
https://develop.openfoam.com/Development/openfoam/-/commit/6e2b7be983627377b710b99d85c817a4a6d2fd02#aa6eaec82d81fc041c39215bd8a02d1566444620_97_75Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/2074Dead link on homepage2021-04-27T17:10:20ZJohan RoenbyDead link on homepageThe link to https://www.develop.openfoam.com in the 2nd bullet point here is wrong:
[https://www.openfoam.com/governance/how-to-get-involved](https://www.openfoam.com/governance/how-to-get-involved)
It should be https://develop.openfoa...The link to https://www.develop.openfoam.com in the 2nd bullet point here is wrong:
[https://www.openfoam.com/governance/how-to-get-involved](https://www.openfoam.com/governance/how-to-get-involved)
It should be https://develop.openfoam.comhttps://develop.openfoam.com/Development/openfoam/-/issues/2072checkMesh does not handle -allRegions2024-01-05T16:57:07ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comcheckMesh does not handle -allRegions### Functionality to add/problem to solve
decomposePar has a `-allRegions` argument. Nice to have on e.g. `checkMesh`.### Functionality to add/problem to solve
decomposePar has a `-allRegions` argument. Nice to have on e.g. `checkMesh`.https://develop.openfoam.com/Development/openfoam/-/issues/2071Geometry names in snappyHexMesh and surfaceFeatureExtract2021-04-29T13:58:00ZChiara PesciGeometry names in snappyHexMesh and surfaceFeatureExtract### Functionality to add/problem to solve
In general, a geometry file name starting with a digit is not accepted by the parser. Thus, snappyHexMesh or surfaceFeatureExtract will throw an error if a geometry file name is like _12_motorBi...### Functionality to add/problem to solve
In general, a geometry file name starting with a digit is not accepted by the parser. Thus, snappyHexMesh or surfaceFeatureExtract will throw an error if a geometry file name is like _12_motorBike.stl_.
A workaround, without changing the file name, could be to pass the name of the file as a string, i.e. using quotations marks "12_motorBike.stl". This workaround works for snappyHexMesh, but not for surfaceFeatureExtract, because the latter has a stricter policy to explicitly ignore regular expressions.
Would it be possible to have the same behaviour in both utilities? Possibly relaxing the policy for surfaceFeatureExtract.
Thank you and best regards,
ChiaraMark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/2069Possible bug in Fuchs-Knudsen evaporation model2021-12-09T20:12:57ZCarlos Peña-MonferrerPossible bug in Fuchs-Knudsen evaporation model<!--
*** 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 -->
Fuchs-Knudsen evaporation model instantly evaporates the active liquid phase. There is apparently a missing variable, particle surface area, in the calculation of the mass transfer according to the reference paper (Eq. 20 in https://doi.org/10.1016/j.jaerosci.2016.12.001). I made some calculation tests adding the particle surface area and then the model gives reasonable results.
### 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 : v2012
- Operating system : N/A
- Hardware info : N/A
- Compiler : N/A
### 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
-->
Adding particle surface area to the calculation on line 257 on
$FOAM_SRC/lagrangian/intermediate/submodels/Reacting/PhaseChangeModel/LiquidEvapFuchsKnudsen/LiquidEvapFuchsKnudsen.C
```
- // mass flux [kg/s]
- const scalar Ni = (rhog*Sherwood*Dab*Cm/d)*log((1 - YeInf)/(1 - YeSurf));
- // mass transfer [kg]
- dMassPC[lid] += Ni*dt;
+ // mass flux [kg/m2/s]
+ const scalar Ni = (rhog*Sherwood*Dab*Cm/d)*log((1 - YeInf)/(1 - YeSurf));
+ // mass transfer [kg]
+ dMassPC[lid] += Ni*areaS*dt;
```
I passed `areaS` to the `calculate` function as `this->areaS(d)`.Kutalmış BerçinKutalmış Berçinhttps://develop.openfoam.com/Development/openfoam/-/issues/2068update dependencies OpenSUSE Leap 15.22021-12-22T14:47:51ZRamkumarupdate dependencies OpenSUSE Leap 15.2Hi.. i am using OpenSUSE Leap 15.2 and would like to compile OpenFOAM on that.. but when i see the dependencies list, they are all provided for Leap 15.1 only and are being incompatible/not found during installation..
and my build fails...Hi.. i am using OpenSUSE Leap 15.2 and would like to compile OpenFOAM on that.. but when i see the dependencies list, they are all provided for Leap 15.1 only and are being incompatible/not found during installation..
and my build fails due to this in the middle.
could u plz update the dependencies and instructions for OpenSUSE Leap 15.2? as this release was made in July of 2020?Mark OLESENMark OLESEN