Development issueshttps://develop.openfoam.com/groups/Development/-/issues2022-08-22T09:58:39Zhttps://develop.openfoam.com/Development/openfoam/-/issues/2570foamDictionary does not allow wildcards as key2022-08-22T09:58:39ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comfoamDictionary does not allow wildcards as key### Functionality to add/problem to solve
E.g. we want to change the 'type' for multiple patches :
```
foamDictionary 0/U -entry boundaryField/BFAN.*/type -set foo
```
### Target audience
Complex use of foamDictionary.
### Proposal
...### Functionality to add/problem to solve
E.g. we want to change the 'type' for multiple patches :
```
foamDictionary 0/U -entry boundaryField/BFAN.*/type -set foo
```
### Target audience
Complex use of foamDictionary.
### Proposal
Have each entry expanded into multiple keys by default. Optionally disable with `-literalRE` similar to `changeDictionary` so you could add a wildcard entry to a dictionary.
You could have inbetween where we expand some wildcards but not others but that might be overkill.
### What does success look like, and how can we measure that?
See if we can do above replacement.
### Links / references
### Fundinghttps://develop.openfoam.com/Development/openfoam/-/issues/2569native MPI reduce not triggered2022-10-26T07:19:41ZMark OLESENnative MPI reduce not triggeredReported by @Mattijs
in symmetryPlanePolyPatch.C there is a
```
if (returnReduce(size(), sumOp<label>()))
{
```
This does not seem to trigger the native Foam::reduce with `sumOp<label>` in mpi/UPstreamReduce.C ? I was checking all inv...Reported by @Mattijs
in symmetryPlanePolyPatch.C there is a
```
if (returnReduce(size(), sumOp<label>()))
{
```
This does not seem to trigger the native Foam::reduce with `sumOp<label>` in mpi/UPstreamReduce.C ? I was checking all invocations of MPI_Send/MPI_Recv.Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/2568wrong type in valueAverageBaseTemplates2022-09-07T14:33:08ZMarkus Towarawrong type in valueAverageBaseTemplatesI think [this](https://develop.openfoam.com/Development/openfoam/-/blob/master/src/OpenFOAM/db/functionObjects/valueAverageBase/valueAverageBaseTemplates.C#L121) should be declared as Type2:
```Type valueOld(pTraits<Type2>::zero);```
...I think [this](https://develop.openfoam.com/Development/openfoam/-/blob/master/src/OpenFOAM/db/functionObjects/valueAverageBase/valueAverageBaseTemplates.C#L121) should be declared as Type2:
```Type valueOld(pTraits<Type2>::zero);```
As Type can be instantiated as label, there might be unintended truncation going on.Andrew HeatherAndrew Heatherhttps://develop.openfoam.com/Development/openfoam/-/issues/2567Wrong Viscous force when using "density variable" in turbulenceProperties2022-08-19T12:43:12ZMyo Zin AungWrong Viscous force when using "density variable" in turbulencePropertiesA new "density variable" feature in turbulenceProperties was introduced in v2012. ([Release Notes](https://www.openfoam.com/news/main-news/openfoam-v20-12/solver-and-physics))
When I was testing the DTCHullMoving tutorial with "kEpsilon"...A new "density variable" feature in turbulenceProperties was introduced in v2012. ([Release Notes](https://www.openfoam.com/news/main-news/openfoam-v20-12/solver-and-physics))
When I was testing the DTCHullMoving tutorial with "kEpsilon" and "realizableKEpsilon" models and "density variable" in the constant/turbulenceProperites, the viscous component of the forces are too much underpredicted (over 7 times samller compared to the original settings). But the pressure component is almost the same as original result. The results are comparable with the original tutorial when running without "density variable" option. I believe there is a problem with that new feature.https://develop.openfoam.com/Development/openfoam/-/issues/2566BUG: incorrect order for output scaling (transformPoints, ...)2022-08-18T11:57:47ZMark OLESENBUG: incorrect order for output scaling (transformPoints, ...)Noticed while working on #2565, the output write scaling should be applied *after* undoing the effects of the specified rotation centre. Currently the scaling applied before undoing the rotation centre, which means the resulting output w...Noticed while working on #2565, the output write scaling should be applied *after* undoing the effects of the specified rotation centre. Currently the scaling applied before undoing the rotation centre, which means the resulting output would be entirely wrong if rotation centre *and* output scaling are combined!Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/2565extend surface writer transforms to include centre of rotation specification2022-10-04T14:34:21ZMark OLESENextend surface writer transforms to include centre of rotation specificationTopic raised in EP1961 - it can be useful to specify the centre of rotation instead of a local coordinate system origin/rotation for handling similar to transformPoints/surfaceTransformPoints.
As part of the change, it would be reasonab...Topic raised in EP1961 - it can be useful to specify the centre of rotation instead of a local coordinate system origin/rotation for handling similar to transformPoints/surfaceTransformPoints.
As part of the change, it would be reasonable to accept _-centre_ or `-rotation-centre` etc for the command-line options, since the use of `-origin` can be ambiguous. In these cases, would still accept `-origin` as aliased option.Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/2564Proposal to change optimization option of the default Fujitsu ARM64 compiler2022-11-17T07:27:58ZAkira AzamiProposal to change optimization option of the default Fujitsu ARM64 compiler### Functionality to add/problem to solve
I'm trying to install by spack and run OpenFOAM on Supercomputer Fugaku by Fujitsu compiler.
I would like to request a change in the default level of optimization, as I have experienced
problems...### Functionality to add/problem to solve
I'm trying to install by spack and run OpenFOAM on Supercomputer Fugaku by Fujitsu compiler.
I would like to request a change in the default level of optimization, as I have experienced
problems with side effects of optimization in Fugaku when running snappyHexMesh.
(User reported snappyHexMesh going to endless loop.)
Especially "-ffp-contract=fast" was particularly impactful.
I would like to see the level lowered to the safer side.
wmake/rules/linuxARM64Fujitsu/c++Opt
c++OPT = -ffp-contract=fast -ffast-math -O3 -funsafe-math-optimizations
-->
c++OPT = -O3
This may be related to this issue.
https://develop.openfoam.com/Development/openfoam/-/issues/2537
### Target audience
Fugaku Users
### Proposal
I suggest lowering the optimization level.
I have confirmed that it can be done with the -O3 option as following version.
OpenFOAM version: v2012, v2106, v2206
Fujitsu compiler version: 1.2.35Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/2563rotatingCylinders tutorial is missing2023-01-13T00:16:16ZHasan CelikrotatingCylinders tutorial is missingHello,
The link of rotatingCylinders tutorial is broken, or the tutorial is missing, somehow. The link for `$FOAM_TUTORIALS/incompressible/simpleFoam/rotatingCylinders` on OpenFOAM User Guide rotatingCylinders tutorial [page](https://ww...Hello,
The link of rotatingCylinders tutorial is broken, or the tutorial is missing, somehow. The link for `$FOAM_TUTORIALS/incompressible/simpleFoam/rotatingCylinders` on OpenFOAM User Guide rotatingCylinders tutorial [page](https://www.openfoam.com/documentation/guides/latest/doc/verification-validation-rotating-cylinders-2d.html) is not working and says:
`"tutorials/incompressible/simpleFoam/rotatingCylinders" did not exist on "master"`https://develop.openfoam.com/Development/openfoam/-/issues/2561Update value on codedFixedValue2022-09-28T07:18:06Zt RockUpdate value on codedFixedValue<!--
*** 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
I have found what appears to be a bug with the `codedFixedValue` boundary condition.
It appears that the BC does not update the field values when it is initialized.
<!-- Summarize the bug encountered concisely -->
### Steps to reproduce
As an example you can take the pitzDaily on `$FOAM_TUTORIALS/basic/scalarTransportFoam/pitzDaily/`.
Run the case as is.
Afterwards, change the U boundary condition to:
```
type codedFixedValue;
value uniform (0 0 0);
name U_tst;
code
#{
vectorField field (patch().Cf());
forAll(field, faceI)
{
field[faceI] = vector (10, 0, 0) ;
}
operator==(field);
#};
}
```
The results will not be the same because of the flux calculation. This happens because of the value given in the entry `value uniform (0 0 0); `
### Environment information
- OpenFOAM version : v2106
- Operating system : WSL
- Hardware info :
- Compiler : GCC 9.4
### Possible fixes
Since this is a fixed value condition, it should evaluate the field values once it is initialized. However, I do not know where is the best to place a fix. (U.correctBoundaryConditions() seems to do the trick, but it is not a good solution for this case as the BC itself should run the `updateCoeffs()` function when it is created.)https://develop.openfoam.com/Development/openfoam/-/issues/2560BUG: viewFactor-2D is silently deprecated2022-11-08T10:11:28ZKutalmış BerçinBUG: viewFactor-2D is silently deprecated!551 - 457979a silently deprecated the two-dimensional viewFactor calculations.
Compare [master:viewFactorsGen.C#L681](https://develop.openfoam.com/Development/openfoam/-/blob/master/applications/utilities/preProcessing/viewFactorsGen/v...!551 - 457979a silently deprecated the two-dimensional viewFactor calculations.
Compare [master:viewFactorsGen.C#L681](https://develop.openfoam.com/Development/openfoam/-/blob/master/applications/utilities/preProcessing/viewFactorsGen/viewFactorsGen.C#L681) vs [develop:viewFactorsGen.C#L1091](https://develop.openfoam.com/Development/openfoam/-/blob/develop/applications/utilities/preProcessing/viewFactorsGen/viewFactorsGen.C#L1091).Mattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comhttps://develop.openfoam.com/Development/openfoam/-/issues/2559GAMG for overset cases2022-12-23T14:57:02ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comGAMG for overset cases<!--
*** 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 -->
Solving overset with GAMG does not work since GAMGInterface is not agglomerated so stays zero size. Mapping to zero size is not supported.
### Steps to reproduce
<!-- How one can reproduce the issue - this is very important -->
Use any overset case. Switch on GAMG (needs algebraicPair as agglomerator). There will be error in GAMGSolverAgglomerateMatrix when trying to restrict the solution to the coarser level (since it has zero 'faces').
### 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 -->
Out of bounds indexing.
### 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 : feature-overset-coupledPatch branch
### 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
-->
Agglomerate GAMGInterface as e.g. cyclicAMIGAMGInterface.Mattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comhttps://develop.openfoam.com/Development/openfoam/-/issues/2558faceAgglomerate assumes viewFactorsDict entries are all patch names2022-08-11T13:44:33ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comfaceAgglomerate assumes viewFactorsDict entries are all patch names### Functionality to add/problem to solve
The `faceAgglomerate` app reads the `viewFactorsDict` (as does the `viewFactorsGen` app) . It iterates through the entries and checks if any are patch names. This gives big weirdness if e.g. a p...### Functionality to add/problem to solve
The `faceAgglomerate` app reads the `viewFactorsDict` (as does the `viewFactorsGen` app) . It iterates through the entries and checks if any are patch names. This gives big weirdness if e.g. a patch has the same name as one of the settings needed by `viewFactorsGen`.
### Target audience
Users of view factor radiation.
### Proposal
Put the patch information in `viewFactorsDict` in a sub dictionary:
```
writeViewFactorMatrix true;
writeFacesAgglomeration true;
writePatchViewFactors false;
//- Debug option
debug 1;
//- Dump connectivity rays
dumpRays false;
//- Optional per-patch agglomeration if faceAgglomerate is used
patchAgglomeration
{
".*"
{
nFacesInCoarsestLevel 100; // increase to get more radiation patches (coarse faces)
featureAngle 30; // 0: one radiation patch (coarse face) over one cell face
}
}
//- Maximum length for dynamicList. See /applications/utilities/preProcessing/viewFactorsGen/shootRays.H
maxDynListLength 1000000000;
```
### What does success look like, and how can we measure that?
- be backwards compatible
- use the patchAgglomeration subdictionary if it is thereMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comhttps://develop.openfoam.com/Development/openfoam/-/issues/2557Be able to choose the order of eigenvalues2022-08-11T07:26:55Zt RockBe able to choose the order of eigenvaluesCurrently the eigenvalue calculation returns the values in ascending order.
For several applications it is not uncommon to use them in descending order, which will require an additional operation to reverse the order.
If possible, I ...Currently the eigenvalue calculation returns the values in ascending order.
For several applications it is not uncommon to use them in descending order, which will require an additional operation to reverse the order.
If possible, I would like to request the possibility of selecting the order of the output.
Something like:
```
#include <iostream>
#include <vector>
#include <algorithm>
enum sortType{ascending, descending};
template<sortType S=ascending>
void sort (std::vector<double>& v)
{
std::sort(v.begin(), v.end());
}
template <>
void sort<descending> (std::vector<double>& v)
{
std::sort(v.begin(), v.end(), std::greater<>());
}
template<sortType S=ascending>
void foo(const std::vector<double>& v)
{
std::vector<double> v2 (v);
sort<S>(v2);
for (int i = 0; i< v.size(); i++)
{
std::cout << v2[i] << std::endl;
}
}
int main()
{
std::vector<double> tst = {1,3,4,2,5};
foo(tst);
foo<descending>(tst);
return 0;
}
```
This will keep the current code running as is, but with the flexibility of letting the user choose the order of the output.
It would also be nice to have the eigen vectors come out as column vectors. Currently they are row vectors. This would bring more similarity to other libraries, e.g., numpy, matlab
Best RegardsKutalmış BerçinKutalmış Berçinhttps://develop.openfoam.com/Development/ThirdParty-common/-/issues/65Incorrect download links for METIS during compilation2022-08-04T14:44:02ZDanyal MohaddesIncorrect download links for METIS during compilation# Summary
The download links for METIS provided during ThirdParty compilation are out of date.
# Steps to Reproduce
1. Download the latest version of ThirdParty (v2206)
2. `./Allwmake`
# Current Behavior
When METIS compilation is reach...# Summary
The download links for METIS provided during ThirdParty compilation are out of date.
# Steps to Reproduce
1. Download the latest version of ThirdParty (v2206)
2. `./Allwmake`
# Current Behavior
When METIS compilation is reached (and skipped), the links provided to download METIS are to [this link](http://glaros.dtc.umn.edu/gkhome/metis/metis/overview) and [this link](http://glaros.dtc.umn.edu/gkhome/fetch/sw/metis/metis-5.1.0.tar.gz). These links are out of date; the package has since moved.
# Correct Behavior
The link provided to download METIS should be [this one](https://github.com/KarypisLab/METIS).
# Possible fix
Update the links in `BUILD.md`https://develop.openfoam.com/Development/openfoam/-/issues/2555Small fixes for macOS2023-06-13T21:29:59ZAlexey MatveichevSmall fixes for macOS### Functionality to add/problem to solve
Fixes for small issues during compilation and execution of OpenFOAM v2206 on macOS
### Target audience
macOS OpenFOAM users willing to recompile software from sources.
### Proposal
Currentl...### Functionality to add/problem to solve
Fixes for small issues during compilation and execution of OpenFOAM v2206 on macOS
### Target audience
macOS OpenFOAM users willing to recompile software from sources.
### Proposal
Currently there are two main problems:
- `src/meshTools/triSurface/triSurfaceTools/geompack/geompack.C` causes segfault during compilation.
- Configuration scripts add unnecessary variable `LD_LIBRARY_PATH` for environment.
- `foamCleanPath` script operates on `DYLD_LIBRARY_PATH`, which is empty upon invocation of the script.
The patch solves these problems:
- `-ftrapping-math` is switched off using `#pragma`. This is enough to compile `geompack.C` without segfault.
- Configuration scripts operate on backup `FOAM_DYLD_LIBRARY_PATH`, which is then copied to `DYLD_LIBRARY_PATH`.
### What does success look like, and how can we measure that?
- Successful compilation of the software on macOS.
- Successful execution of cases with `Allrun` scripts (or any other).
Compilation and execution is tested on
```
$ sw_vers
ProductName: macOS
ProductVersion: 12.5
BuildVersion: 21G72
```
with
```
$ clang++ --version
Apple clang version 13.1.6 (clang-1316.0.21.2.5)
Target: x86_64-apple-darwin21.6.0
Thread model: posix
InstalledDir: /Library/Developer/CommandLineTools/usr/bin
```
Patch: [OpenFOAM-v2206-e1da9617.patch](/uploads/51326bb6d1ecb4a2fbb189966e9c287f/OpenFOAM-v2206-e1da9617.patch)Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/2554holding reference to copy2022-09-09T12:10:37ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comholding reference to copy<!--
*** 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 -->
Holding reference to e.g. HashTable<>::sortedToc
### 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
### 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
-->
Do not hold reference.Mattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comhttps://develop.openfoam.com/Development/openfoam/-/issues/2553BUG: binFields: writeFile is not being read2022-08-18T10:37:11ZKutalmış BerçinBUG: binFields: writeFile is not being read`writeFile::read(dict)` is missing.`writeFile::read(dict)` is missing.Kutalmış BerçinKutalmış Berçinhttps://develop.openfoam.com/Development/openfoam/-/issues/2551adjointOptimisation uses IOdictionary with processor-local scope2022-08-04T11:25:16ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comadjointOptimisation uses IOdictionary with processor-local scope<!--
*** 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 -->
adjointOptimisation uses localIOdictionary instead of plain IOdictionary
This is from visual inspection. The difference between the two is subtle and only in parallel : localIOdictionary is used to e.g. read a (decomposed) field, plain IOdictionary is used to read e.g. system/controlDict. The two versions have different IO behaviour - plain IOdictionary will look in the undecomposed directory, localIOdictionary will only look in the processorXXX directory. Can the IOdictionaries be different on different processors?
### What is the current *bug* behaviour?
<!-- What actually happens -->
We've seen this when using changeDictionary in parallel with `-fileHandler collated` - it does not change the correct file. Maybe it is not a problem for the adjointOptimisation.
### 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
### 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
-->
Use IOdictionary instead?Vaggelis PapoutsisVaggelis Papoutsishttps://develop.openfoam.com/Development/openfoam/-/issues/2550Abnormal velocity near the wall on overset mesh2022-08-13T08:45:54Zgrace wAbnormal velocity near the wall on overset 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 -->
I tried to use the developed version(feature-overset-couplepatch) to simlulate a wall-contact problem for piston-like flow. The object in this case has no motion (it is set by zero amplitude of periodic motion) so that the pressure should be constant and velocity is zero on both sides of the object. However, a false velocity near the wall contact area is computed. Similar phenomena occurs when the amplitude is set non-zero(e.g. 0.2) for periodic motion.
The abnormal velocity is next to the porous cell. The velocity from the donor may be ill-calculated in this region.
### Steps to reproduce
<!-- How one can reproduce the issue - this is very important -->
### 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
-->
Here is the case file.
[wallcontact-zeromotion.zip](/uploads/6b49113b64c0d2142f1d67d8076a66bb/wallcontact-zeromotion.zip)
### What is the current *bug* behaviour?
<!-- What actually happens -->
The abnormity of the velocity near the wall corner occurs at the very first timestep and it is increased with the time step.
### What is the expected *correct* behavior?
<!-- What you should see instead -->
The velocity near the wall corner should be zero.
### Relevant logs and/or images
Attach here is the results from the first timestep.
![celltype](/uploads/fe135b065002206a77ffa07c59c21661/celltype.png)
![U](/uploads/998363489f88d339f6ca676d84c629f2/U.png)
![p](/uploads/cd0f25cff44a8162ad8223352c2ea321/p.png)
![U-threshold](/uploads/504854ea8e675cab7d2cb25ee436f1aa/U-threshold.png)
![p-threshold](/uploads/90f4a928b64dfc775fb8574787fe6c10/p-threshold.png)
<!--
Paste any relevant logs - please use code blocks (```) to format console
output, logs, and code as it's very hard to read otherwise.
-->
Courant Number mean: 0.671294 max: 0.75
Time = 0.01
inverseDistance : detected 2 mesh regions
zone:0 nCells:1875 voxels:(400 400 1) bb:(-0.5 -0.5 0) (0.5 0.5 0.05)
zone:1 nCells:501 voxels:(400 400 1) bb:(-0.5 -0.5 0) (0.5 0.5 0.05)
void Foam::cellCellStencils::inverseDistance::findHoles(const Foam::globalIndex&, const Foam::fvMesh&, const labelList&, const labelListList&, Foam::labelList&) const : Starting hole flood filling
void Foam::cellCellStencils::inverseDistance::findHoles(const Foam::globalIndex&, const Foam::fvMesh&, const labelList&, const labelListList&, Foam::labelList&) const : Starting hole cells : 97
void Foam::cellCellStencils::inverseDistance::findHoles(const Foam::globalIndex&, const Foam::fvMesh&, const labelList&, const labelListList&, Foam::labelList&) const : Marked internal hole boundaries : 143
void Foam::cellCellStencils::inverseDistance::findHoles(const Foam::globalIndex&, const Foam::fvMesh&, const labelList&, const labelListList&, Foam::labelList&) const : Marked all hole boundaries : 143
void Foam::cellCellStencils::inverseDistance::findHoles(const Foam::globalIndex&, const Foam::fvMesh&, const labelList&, const labelListList&, Foam::labelList&) const : Determined regions : 12
void Foam::cellCellStencils::inverseDistance::findHoles(const Foam::globalIndex&, const Foam::fvMesh&, const labelList&, const labelListList&, Foam::labelList&) const : Done local analysis
void Foam::cellCellStencils::inverseDistance::findHoles(const Foam::globalIndex&, const Foam::fvMesh&, const labelList&, const labelListList&, Foam::labelList&) const : Converted stencil into compact form
void Foam::cellCellStencils::inverseDistance::findHoles(const Foam::globalIndex&, const Foam::fvMesh&, const labelList&, const labelListList&, Foam::labelList&) const : Gathered region type
void Foam::cellCellStencils::inverseDistance::findHoles(const Foam::globalIndex&, const Foam::fvMesh&, const labelList&, const labelListList&, Foam::labelList&) const : Interpolated region type
void Foam::cellCellStencils::inverseDistance::findHoles(const Foam::globalIndex&, const Foam::fvMesh&, const labelList&, const labelListList&, Foam::labelList&) const : Determined regions changed : 0
void Foam::cellCellStencils::inverseDistance::findHoles(const Foam::globalIndex&, const Foam::fvMesh&, const labelList&, const labelListList&, Foam::labelList&) const : Finished hole flood filling : 0
### 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 :v2112 feature-overset
- Operating system :ubuntu 20.04
- Hardware info :
- Compiler :gcc 9
### Possible fixes
<!--
If you can, link to the line of code that might be responsible for the
problem
In stencilWeights function, the inverse distance is used to calculate the weights of donor. It may need to consider the potential contribution from porous cell, e.g., the interpolate cell next to the porous cell in this case.
void Foam::cellCellStencils::inverseDistance::stencilWeights
(
const point& sample,
const pointList& donorCcs,
scalarList& weights
) const
{
// Inverse-distance weighting
weights.setSize(donorCcs.size());
scalar sum = 0.0;
forAll(donorCcs, i)
{
scalar d = mag(sample-donorCcs[i]);
if (d > ROOTVSMALL)
{
weights[i] = 1.0/d;
sum += weights[i];
}
else
{
// Short circuit
weights = 0.0;
weights[i] = 1.0;
return;
}
}
forAll(weights, i)
{
weights[i] /= sum;
}
}
The "/label ~bug" text is a gitlab flag that will add the "bug" label to this
issue
-->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!