Development issueshttps://develop.openfoam.com/groups/Development/-/issues2023-06-13T14:34:10Zhttps://develop.openfoam.com/Development/openfoam/-/issues/2789FMU4FOAM coupling OpenFOAM with FMU2023-06-13T14:34:10ZHenning ScheuflerFMU4FOAM coupling OpenFOAM with FMU@MakisH @andy @mark
The Library FMU4FOAM enables coupling of OpenFOAM with the FMU's and can greatly improve the capabilites of OpenFOAM as shown in the example:
https://dlr-ry.github.io/FMU4FOAM/doc_TempControlFlange.html
The Librar...@MakisH @andy @mark
The Library FMU4FOAM enables coupling of OpenFOAM with the FMU's and can greatly improve the capabilites of OpenFOAM as shown in the example:
https://dlr-ry.github.io/FMU4FOAM/doc_TempControlFlange.html
The Library consists of two repos:
* https://github.com/DLR-RY/FMU4FOAM
* https://github.com/DLR-RY/ECI4FOAM
The first one implements the coupling with FMU's by utilizing python as coupler*. The second one tries to improve the coupling with external tools like precice library and could simplify the OpenFOAM adapter of the precice library
The goal would be to start a discussion how coupling to external tools can be simplified and possiblty integrated into a release
* I also created python bindings for OpenFoam: https://github.com/HenningScheufler/pybFoamhttps://develop.openfoam.com/Development/openfoam/-/issues/2788openfoam conda2023-11-26T17:23:29ZHenning Scheufleropenfoam condaA possibility to install OpenFOAM without admin rights is conda:
https://github.com/HenningScheufler/conda-openfoam
The installation process would be quite straightforward. Download and install the miniconda then run following commands...A possibility to install OpenFOAM without admin rights is conda:
https://github.com/HenningScheufler/conda-openfoam
The installation process would be quite straightforward. Download and install the miniconda then run following commands:
```bash
conda create -n openfoam # create new env named openfoam
conda activate openfoam # activate the enviroment
conda install openfoam -c conda-forge # download and install openfoam from conda forge
```
This could simplify the installation on workstations. For HPC spack is probably the better optionhttps://develop.openfoam.com/Development/openfoam/-/issues/2786Overcompensation of anisotropy in porous models (DarcyForchheimer and fixedCo...2023-07-20T08:24:49ZBernhard GschaiderOvercompensation of anisotropy in porous models (DarcyForchheimer and fixedCoeff)The porous media models add the porous resistance to the matrix of the velocity equation. To do this they have to reduce the resistance tensor to a scalar that is added to the diagonal of the matrix and compensate with an explicit source...The porous media models add the porous resistance to the matrix of the velocity equation. To do this they have to reduce the resistance tensor to a scalar that is added to the diagonal of the matrix and compensate with an explicit source term that models the rest of the resistance tensor. For an isotropic porosity (where the tensor is the identity tensor times a factor) no explicit correction should be necessary.
The current implementation uses the trace of the tensor. For an isotropic porosity (where all three diagonal elements have the same value) this is three times higher than the term that should be actually added. This leads to a significant (unnecessary) explicit correction. This is stable (high diagonal term) but may lead to slower convergence (high source term that works against the diagonal)
The attached patch fixes this by using the biggest diagonal element of the tensor as the implicit part
- for isotropic porosity the explicit correction is almost zero
- for anisotropic porosity the explicit correction for the direction with the greatest contribution is zero (assuming the isotropy is oriented along the cartesian coordinates). For the others there is a correction
Applying the patch doesn't change the results but increases the convergence (in the `compressible/rhoSimpleFoam/angledDuctExplicitFixedCoeff` tutorial applying the patch lowers the number of timesteps till convergence from 639 to 392)
PS: this behaviour has been in OpenFOAM at least since 1.5 and nobody complained so there is a chance that there is a reason for that factor 3 (but I doubt it)
[darcyImplicitCoeffFix.patch](/uploads/ff6265825d1f119e1295f7799194ed37/darcyImplicitCoeffFix.patch)Kutalmış BerçinKutalmış Berçinhttps://develop.openfoam.com/Development/openfoam/-/issues/2780BUG: PrimitivePatch::nInternalEdges includes non-manifold edges2023-05-15T15:18:33ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comBUG: PrimitivePatch::nInternalEdges includes non-manifold edges<!--
*** 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 -->
The PrimitivePatch edge sorting should put internal edges (= edges connected to 2 faces) first, followed by boundary edges (= edges connected to 1 face). It also seems to order/include any edges with >2 faces into the nInternalEdges slice.
### Steps to reproduce
<!-- How one can reproduce the issue - this is very important -->
See below.
### 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
-->
[cavity.tgz](/uploads/39298bb461c3b51188ed1d53b9fd03b7/cavity.tgz)
- use ./Allrun to construct
- is a 2x2 cavity blockMesh with bottom left and top-right cell removed
### What is the current *bug* behaviour?
<!-- What actually happens -->
The non-manifold edge with 4 patch faces gets reported as an internal edge.
See attached checkMesh hack
[checkTopology.C](/uploads/297943004793eed52da2421284f490b3/checkTopology.C)
### 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 : 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 : v2306
### 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
-->
Might have side effects for
- snappyHexMesh
- patch extrusion
so not to be fixed before v2306.
### See also:
https://develop.openfoam.com/Development/openfoam/-/issues/2771Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/2779OpenFOAM overset restart not working2024-02-28T12:15:17ZGabriel Barajasbarajasg@unican.esOpenFOAM overset restart not working**Summary**
Dear all,
If I run the floating Object tutorials with the deforming mesh approach, either with the _rigidBodyMeshMotion_ library or the _sixDoFRigidBodyMotion_ library, I can stop and restart the simulation and everything w...**Summary**
Dear all,
If I run the floating Object tutorials with the deforming mesh approach, either with the _rigidBodyMeshMotion_ library or the _sixDoFRigidBodyMotion_ library, I can stop and restart the simulation and everything works correctly. I enclose figures of both cases: in purple a simulation starting in 0.0s and ending in 6.0s, and in green a simulation starting in 1.0s (copied from the previous case) and ending in 6.0s.
Deforming Mesh + rigidBodyMeshMotion:
![deforming_rigidBodyMotion_1.5s](/uploads/b2c69cea59114aff9b1f196bbbdb1877/deforming_rigidBodyMotion_1.5s.png)
![deforming_rigidBodyMotion_4.5s](/uploads/3d020d36c5a95cd92e2d892010b62468/deforming_rigidBodyMotion_4.5s.png)
Deforming Mesh + sixDoFRigidBodyMotion:
![deformingMesh_6DoF_1.5s](/uploads/b1d6691d5153372a7ce7d841d08afd17/deformingMesh_6DoF_1.5s.png)
![deformingMesh_6DoF_4.5s](/uploads/e3a0bd519467085eb62955b598b1d1a9/deformingMesh_6DoF_4.5s.png)
But, when I I try to the same within the overset framework, it does not work:
![overset_6DoF_1.2s](/uploads/b5977f8947a31015ff67dea697abe711/overset_6DoF_1.2s.png)
I believe that the code is not reading correctly all the variables and probably using some default values that normally are zero, as if it was starting from a rest position.
**Steps to reproduce**
I enclose the case to reproduce the issue. First run the case normally, afterwards try to re-run it starting from the time t=1.0s.
Check the motion of the floating body in both cases.
**Example case**
[floatingBody.tar.xz](/uploads/6a915eca6e10f51ee77e9f99e38e2015/floatingBody.tar.xz)
Thanks,
Gabihttps://develop.openfoam.com/Development/openfoam/-/issues/2776Error in the documentation2023-05-11T15:37:00ZGiorgio GiorgianiError in the documentationNot sure this is the place to post this. In the Programmer's Guide (Version v2206) the formula for the tensor divergence is wrong.
I am referring to formula 3.5 at page 30, the expansion in the right.
Now it looks like:
$$
\begin{pmat...Not sure this is the place to post this. In the Programmer's Guide (Version v2206) the formula for the tensor divergence is wrong.
I am referring to formula 3.5 at page 30, the expansion in the right.
Now it looks like:
$$
\begin{pmatrix}
\partial T_{11}/\partial x_{1} + \partial T_{21}/\partial x_{1} +\partial T_{31}/\partial x_{1} \\
\partial T_{12}/\partial x_{2} + \partial T_{22}/\partial x_{2} +\partial T_{32}/\partial x_{2} \\
\partial T_{13}/\partial x_{3} + \partial T_{23}/\partial x_{3} +\partial T_{33}/\partial x_{3}
\end{pmatrix}
$$
should be
$$
\begin{pmatrix}
\partial T_{11}/\partial x_{1} + \partial T_{21}/\partial x_{2} +\partial T_{31}/\partial x_{3} \\
\partial T_{12}/\partial x_{1} + \partial T_{22}/\partial x_{2} +\partial T_{32}/\partial x_{3} \\
\partial T_{13}/\partial x_{1} + \partial T_{23}/\partial x_{2} +\partial T_{33}/\partial x_{3}
\end{pmatrix}
$$https://develop.openfoam.com/Development/openfoam/-/issues/2771finite-area issues with multiply connected edges2023-06-14T12:08:54ZMark OLESENfinite-area issues with multiply connected edgescross-ref EP2148
- multiply-connected edges can arise at the centre of a "star"
connection or because the patch faces are actually baffles.
- In the serial case these internal edges are also rather dubious in
terms of modelling...cross-ref EP2148
- multiply-connected edges can arise at the centre of a "star"
connection or because the patch faces are actually baffles.
- In the serial case these internal edges are also rather dubious in
terms of modelling. However, when they are split across multiple
processors there can only be a single processor-to-processor
connectivity.Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/2767Let user define the output field name in the wallShearStress FO2023-04-27T08:13:12ZTimofey MukhaLet user define the output field name in the wallShearStress FO### Functionality to add/problem to solve
Would it be OK to extend the functionality of the `wallShearStress` FO to support other output field names rather than `wallShearStress`?
The latter would still be the default, thus not braking ...### Functionality to add/problem to solve
Would it be OK to extend the functionality of the `wallShearStress` FO to support other output field names rather than `wallShearStress`?
The latter would still be the default, thus not braking any workflows or tutorials.
I realize that not a lot of people will need that, but I guess it cannot hurt? The reason I want this implemented is that my WMLES library also uses `wallShearStress`, and if one also uses the FO, there is a name collision, which leads to a nasty looking crash, as discovered by Tobias.
### Proposal
Add an optional `field` or `fieldName` keyword for the user to set, and use that in the constructor, which allocates the `volVectorField`.
### Funding
I am reasonably sure I can implement this myself without any help. Impact on code maintenance should be negligible.https://develop.openfoam.com/Development/openfoam/-/issues/2765humidityTemperatureCoupledMixedFvPatchScalarField documentation2023-04-25T19:58:49ZDaan JongeriushumidityTemperatureCoupledMixedFvPatchScalarField documentationDocumentation of "humidityTemperatureCoupledMixedFvPatchScalarField Class Reference" possibly wrong.
myInterfacePatchName
{
type thermalHumidityCoupledMixed; _**-> should be humidityTemperatureCoupledMixed;**_...Documentation of "humidityTemperatureCoupledMixedFvPatchScalarField Class Reference" possibly wrong.
myInterfacePatchName
{
type thermalHumidityCoupledMixed; _**-> should be humidityTemperatureCoupledMixed;**_
kappaMethod fluidThermo;
kappa none;
// Modes of operation: inert, condensation, vaporization, condEvap
mode condEvap;_ **-> should be condensationAndEvaporation;**_https://develop.openfoam.com/Development/openfoam/-/issues/2740Heat imbalance at multiregional boundary in chtMultiRegionFoam2023-05-07T23:39:54ZShinji TakeharaHeat imbalance at multiregional boundary in chtMultiRegionFoam<!--
*** 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 specific heat has a temperature dependence, heat flux imbalance occurs at the multiregional boundary.
I confirmed this phenomenon using wall heat flux in Field function objects.
※This imbalance occurs in not only *compressible::turbulentTemperatureRadCoupledMixed* but also in * externalWallHeatFluxTemperature*
### Steps to reproduce
<!-- How one can reproduce the issue - this is very important -->
1. Download the attached file(one is constant Cp, another is temperature dependent Cp)
2. run `chtMultiReigonFoam` in each directory
3. compare postprocessing/l/wallHeatFlux1/0.0/wallHeatFlux.dat and postprocessing/r/wallHeatFlux1/0.0/wallHeatFlux.dat
### 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
-->
[imbalancedHeatFluxWhenTemperatureDependentCp.tar.gz](/uploads/1c54286d2349419bc05c4e2427e4ac8b/imbalancedHeatFluxWhenTemperatureDependentCp.tar.gz)
[balancedHeatFluxWhenTemperatureIndependentCp.tar.gz](/uploads/ba90fb0986ad3c1248a4996f19f7c9bd/balancedHeatFluxWhenTemperatureIndependentCp.tar.gz)
### What is the current *bug* behaviour?
<!-- What actually happens -->
Heat flux imbalance occurs at the multiregional boundary.
### What is the expected *correct* behavior?
<!-- What you should see instead -->
Heat flux is balanced at the multiregional boundary.
### Relevant logs and/or images
<!--
Paste any relevant logs - please use code blocks (```) to format console
output, logs, and code as it's![image](/uploads/67b582ce7e531a3cdca56cceb8e209aa/image.png) 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
-->
- 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
-->
I thought that the bug was caused by robin boundary condition.
Three parameters(*valueFraction*, *refValue*, *refGrad*) related robin boundary condition is calculated in *turbulentTemperatureRadCoupledMixedFvPatchScalarField.C*.
After that, since these are based on temperature, it is converged to an enthalpy based value at *mixedEnergyFvPatchScalarField.C*.
The conversion of *valueFraction* seems to assume constant specific heat. When I modified like below, the heat flux at multiregional boundary can be balanced.
original :
*turbulentTemperatureRadCoupledMixedFvPatchScalarField.C*
valueFraction() = KDeltaNbr/(KDeltaNbr + alpha);
modified :
*turbulentTemperatureRadCoupledMixedFvPatchScalarField.C*
valueFraction() = KDeltaNbr/(KDeltaNbr + alpha) * myThermo->Cp(pp, Tp, patchi) *(TcNbr-Tc)/(myThermo->he(pcn, TcNbr, samplePatchi) - myThermo->he(pc, Tc, patchi));Kutalmış BerçinKutalmış Berçinhttps://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/2735BUG: function object: Failed to store pointer: grad(U). Risk of memory leakage2023-04-05T14:45:47ZJuan SalazarBUG: function object: Failed to store pointer: grad(U). Risk of memory leakage<!--
*** 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 running grad function object on U field, the following error is issued (occurs with postProcess option and/or during simulation):
"Failed to store pointer: grad(U). Risk of memory leakage"
Possibly related to Development/openfoam#2381, recommendation of including `useNamePrefix true;` in function object did not make the bug go away.
### Steps to reproduce
<!-- How one can reproduce the issue - this is very important -->
Run grad function object on turbulentFlatPlate tutorial (solver simpleFoam). I ran it on the setup with kOmegaSST with y plus = 1.
`postProcess -func "grad(U)"`
or
`simpleFoam -postProcess -latestTime`
with FO grad included in controlDict.
### 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
-->
As explained above. Below is modified controlDict from standard turbulentFlatPlateTutorial.
```
/*--------------------------------*- C++ -*----------------------------------*\
| ========= | |
| \\ / F ield | OpenFOAM: The Open Source CFD Toolbox |
| \\ / O peration | Version: v2206 |
| \\ / A nd | Website: www.openfoam.com |
| \\/ M anipulation | |
\*---------------------------------------------------------------------------*/
FoamFile
{
version 2.0;
format ascii;
class dictionary;
object controlDict;
}
// * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * //
application simpleFoam;
startFrom startTime;
startTime 0;
stopAt endTime;
endTime 5000;
deltaT 1;
writeControl timeStep;
writeInterval 100;
purgeWrite 1;
writeFormat ascii;
writePrecision 8;
writeCompression off;
timeFormat general;
timePrecision 8;
runTimeModifiable true;
functions
{
minMax
{
type fieldMinMax;
libs ("libfieldFunctionObjects.so");
writeControl timeStep;
fields (U);
}
yPlus
{
type yPlus;
libs ("libfieldFunctionObjects.so");
patches (fixedWall);
writeControl writeTime;
}
#includeFunc "writeCellCentres"
#includeFunc "wallShearStress"
#include "FOgrad"
}
```
The file "FOgrad" is in system folder.
```
/*--------------------------------*- C++ -*----------------------------------*\
| ========= | |
| \\ / F ield | OpenFOAM: The Open Source CFD Toolbox |
| \\ / O peration | Version: v2212 |
| \\ / A nd | Website: www.openfoam.com |
| \\/ M anipulation | |
\*---------------------------------------------------------------------------*/
grad1
{
// Mandatory entries
type grad;
libs ("libfieldFunctionObjects.so");
field U;
// Optional (inherited) entries
useNamePrefix true;
//result gradientU;
log true;
writeControl outputTime;
}
grad2
{
// Mandatory entries
type grad;
libs ("libfieldFunctionObjects.so");
field phi;
// Optional (inherited) entries
result gradPhi;
log true;
writeControl outputTime;
}
// ************************************************************************* //
```
### What is the current *bug* behaviour?
Error `Failed to store pointer: grad(U). Risk of memory leakage` is issued.
<!-- What actually happens -->
### What is the expected *correct* behavior?
<!-- What you should see instead -->
gradient of U field should be computed and file created in time folder. Tested on v2212, v2206, v2112. Works as expected with version v1706.
### 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.
-->
OpenFOAM v2206
```
--> FOAM Warning :
From bool Foam::regIOobject::store()
in file /Users/jsalazar/openfoam/OpenFOAM-v2206/src/OpenFOAM/lnInclude/regIOobjectI.H at line 51
Refuse to store unregistered object: grad(U)
--> FOAM FATAL ERROR: (openfoam-2206)
Failed to store pointer: grad(U). Risk of memory leakage
From static Type &Foam::regIOobject::store(Type *) [Type = Foam::GeometricField<Foam::Tensor<double>, Foam::fvPatchField, Foam::volMesh>]
in file /Users/jsalazar/openfoam/OpenFOAM-v2206/src/OpenFOAM/lnInclude/regIOobjectI.H at line 73.
FOAM aborting
#0 Foam::error::printStack(Foam::Ostream&) in /Volumes/OpenFOAM/OpenFOAM-v2206/platforms/darwinARM64ClangDPInt32Opt/lib/libOpenFOAM.dylib
#1 Foam::error::simpleExit(int, bool) (.cold.2) in /Volumes/OpenFOAM/OpenFOAM-v2206/platforms/darwinARM64ClangDPInt32Opt/lib/libOpenFOAM.dylib
#2 Foam::error::simpleExit(int, bool) in /Volumes/OpenFOAM/OpenFOAM-v2206/platforms/darwinARM64ClangDPInt32Opt/lib/libOpenFOAM.dylib
#3 Foam::error::exiting(int, bool) in /Volumes/OpenFOAM/OpenFOAM-v2206/platforms/darwinARM64ClangDPInt32Opt/lib/libOpenFOAM.dylib
#4 Foam::GeometricField<Foam::Tensor<double>, Foam::fvPatchField, Foam::volMesh>& Foam::regIOobject::store<Foam::GeometricField<Foam::Tensor<double>, Foam::fvPatchField, Foam::volMesh> >(Foam::GeometricField<Foam::Tensor<double>, Foam::fvPatchField, Foam::volMesh>*) in /Volumes/OpenFOAM/OpenFOAM-v2206/platforms/darwinARM64ClangDPInt32Opt/lib/libfieldFunctionObjects.dylib
#5 bool Foam::functionObjects::regionFunctionObject::store<Foam::GeometricField<Foam::Tensor<double>, Foam::fvPatchField, Foam::volMesh> >(Foam::word&, Foam::tmp<Foam::GeometricField<Foam::Tensor<double>, Foam::fvPatchField, Foam::volMesh> > const&, bool) in /Volumes/OpenFOAM/OpenFOAM-v2206/platforms/darwinARM64ClangDPInt32Opt/lib/libfieldFunctionObjects.dylib
#6 bool Foam::functionObjects::grad::calcGrad<Foam::Vector<double> >() in /Volumes/OpenFOAM/OpenFOAM-v2206/platforms/darwinARM64ClangDPInt32Opt/lib/libfieldFunctionObjects.dylib
#7 Foam::functionObjects::fieldExpression::execute() in /Volumes/OpenFOAM/OpenFOAM-v2206/platforms/darwinARM64ClangDPInt32Opt/lib/libfieldFunctionObjects.dylib
#8 Foam::functionObjects::timeControl::execute() in /Volumes/OpenFOAM/OpenFOAM-v2206/platforms/darwinARM64ClangDPInt32Opt/lib/libOpenFOAM.dylib
#9 Foam::functionObjectList::execute() in /Volumes/OpenFOAM/OpenFOAM-v2206/platforms/darwinARM64ClangDPInt32Opt/lib/libOpenFOAM.dylib
#10 main in /Volumes/OpenFOAM/OpenFOAM-v2206/platforms/darwinARM64ClangDPInt32Opt/bin/simpleFoam
#11 start in /usr/lib/dyld
zsh: abort simpleFoam -postProcess -latestTime
```
OpenFOAM v2212
```
--> FOAM Warning :
From bool Foam::regIOobject::store()
in file /Volumes/OpenFOAM-v2212/src/OpenFOAM/lnInclude/regIOobjectI.H at line 51
Refuse to store unregistered object: grad(U)
--> FOAM FATAL ERROR: (openfoam-2212)
Failed to store pointer: grad(U). Risk of memory leakage
From static Type &Foam::regIOobject::store(Type *) [Type = Foam::GeometricField<Foam::Tensor<double>, Foam::fvPatchField, Foam::volMesh>]
in file /Volumes/OpenFOAM-v2212/src/OpenFOAM/lnInclude/regIOobjectI.H at line 73.
FOAM aborting
#0 Foam::error::printStack(Foam::Ostream&) in /Volumes/OpenFOAM-v2212/platforms/darwin64ClangDPInt32Opt/lib/libOpenFOAM.dylib
#1 Foam::error::simpleExit(int, bool) (.cold.2) in /Volumes/OpenFOAM-v2212/platforms/darwin64ClangDPInt32Opt/lib/libOpenFOAM.dylib
#2 Foam::error::simpleExit(int, bool) in /Volumes/OpenFOAM-v2212/platforms/darwin64ClangDPInt32Opt/lib/libOpenFOAM.dylib
#3 Foam::error::exiting(int, bool) in /Volumes/OpenFOAM-v2212/platforms/darwin64ClangDPInt32Opt/lib/libOpenFOAM.dylib
#4 Foam::GeometricField<Foam::Tensor<double>, Foam::fvPatchField, Foam::volMesh>& Foam::regIOobject::store<Foam::GeometricField<Foam::Tensor<double>, Foam::fvPatchField, Foam::volMesh> >(Foam::GeometricField<Foam::Tensor<double>, Foam::fvPatchField, Foam::volMesh>*) in /Volumes/OpenFOAM-v2212/platforms/darwin64ClangDPInt32Opt/lib/libfieldFunctionObjects.dylib
#5 bool Foam::functionObjects::regionFunctionObject::store<Foam::GeometricField<Foam::Tensor<double>, Foam::fvPatchField, Foam::volMesh> >(Foam::word&, Foam::tmp<Foam::GeometricField<Foam::Tensor<double>, Foam::fvPatchField, Foam::volMesh> > const&, bool) in /Volumes/OpenFOAM-v2212/platforms/darwin64ClangDPInt32Opt/lib/libfieldFunctionObjects.dylib
#6 bool Foam::functionObjects::grad::calcGrad<Foam::Vector<double> >() in /Volumes/OpenFOAM-v2212/platforms/darwin64ClangDPInt32Opt/lib/libfieldFunctionObjects.dylib
#7 Foam::functionObjects::fieldExpression::execute() in /Volumes/OpenFOAM-v2212/platforms/darwin64ClangDPInt32Opt/lib/libfieldFunctionObjects.dylib
#8 Foam::functionObjects::timeControl::execute() in /Volumes/OpenFOAM-v2212/platforms/darwin64ClangDPInt32Opt/lib/libOpenFOAM.dylib
#9 Foam::functionObjectList::execute() in /Volumes/OpenFOAM-v2212/platforms/darwin64ClangDPInt32Opt/lib/libOpenFOAM.dylib
#10 main in /Volumes/OpenFOAM-v2212/platforms/darwin64ClangDPInt32Opt/bin/simpleFoam
#11 start in /usr/lib/dyld
Abort trap: 6
```
OpenFOAM v2112
```
--> FOAM FATAL ERROR: (openfoam-2112)
Failed to store pointer: grad(U). Risk of memory leakage
From static Type &Foam::regIOobject::store(Type *) [Type = Foam::GeometricField<Foam::Tensor<double>, fvPatchField, Foam::volMesh>]
in file /Users/jsalazar/openfoam/OpenFOAM-v2112/src/OpenFOAM/lnInclude/regIOobjectI.H at line 67.
FOAM aborting
#0 Foam::error::printStack(Foam::Ostream&) in /Volumes/OpenFOAM/OpenFOAM-v2112/platforms/darwin64ClangDPInt32Opt/lib/libOpenFOAM.dylib
#1 Foam::error::simpleExit(int, bool) (.cold.2) in /Volumes/OpenFOAM/OpenFOAM-v2112/platforms/darwin64ClangDPInt32Opt/lib/libOpenFOAM.dylib
#2 Foam::error::simpleExit(int, bool) in /Volumes/OpenFOAM/OpenFOAM-v2112/platforms/darwin64ClangDPInt32Opt/lib/libOpenFOAM.dylib
#3 Foam::error::exiting(int, bool) in /Volumes/OpenFOAM/OpenFOAM-v2112/platforms/darwin64ClangDPInt32Opt/lib/libOpenFOAM.dylib
#4 Foam::GeometricField<Foam::Tensor<double>, Foam::fvPatchField, Foam::volMesh>& Foam::regIOobject::store<Foam::GeometricField<Foam::Tensor<double>, Foam::fvPatchField, Foam::volMesh> >(Foam::GeometricField<Foam::Tensor<double>, Foam::fvPatchField, Foam::volMesh>*) in /Volumes/OpenFOAM/OpenFOAM-v2112/platforms/darwin64ClangDPInt32Opt/lib/libfieldFunctionObjects.dylib
#5 bool Foam::functionObjects::regionFunctionObject::store<Foam::GeometricField<Foam::Tensor<double>, Foam::fvPatchField, Foam::volMesh> >(Foam::word&, Foam::tmp<Foam::GeometricField<Foam::Tensor<double>, Foam::fvPatchField, Foam::volMesh> > const&, bool) in /Volumes/OpenFOAM/OpenFOAM-v2112/platforms/darwin64ClangDPInt32Opt/lib/libfieldFunctionObjects.dylib
#6 bool Foam::functionObjects::grad::calcGrad<Foam::Vector<double> >() in /Volumes/OpenFOAM/OpenFOAM-v2112/platforms/darwin64ClangDPInt32Opt/lib/libfieldFunctionObjects.dylib
#7 Foam::functionObjects::fieldExpression::execute() in /Volumes/OpenFOAM/OpenFOAM-v2112/platforms/darwin64ClangDPInt32Opt/lib/libfieldFunctionObjects.dylib
#8 Foam::functionObjects::timeControl::execute() in /Volumes/OpenFOAM/OpenFOAM-v2112/platforms/darwin64ClangDPInt32Opt/lib/libOpenFOAM.dylib
#9 Foam::functionObjectList::execute() in /Volumes/OpenFOAM/OpenFOAM-v2112/platforms/darwin64ClangDPInt32Opt/lib/libOpenFOAM.dylib
#10 main in /Volumes/OpenFOAM/OpenFOAM-v2112/platforms/darwin64ClangDPInt32Opt/bin/simpleFoam
#11 start in /usr/lib/dyld
```
### 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 : v2212 or v2206 or v2112
- Operating system : macOS. Also tested with OpenFOAM v2112 on docker container (Ubuntu 20.04)
- Hardware info : MacBookPro Apple M1 Max 2021.
- Compiler : clang (gcc on docker container)
### 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/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/2728fvGeometryScheme parallel does not handle transformations2023-03-23T14:15:07ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comfvGeometryScheme parallel does not handle transformations<!--
*** 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 -->
The parallel fvGeometryScheme does not handle transformations.
### Steps to reproduce
<!-- How one can reproduce the issue - this is very important -->
- switch in system/fvSchemes the geometry scheme to use parallel
- in annularCombustor tutorial use ./Allrun.pre to run snappyHexMesh
- it will fail reporting a problem about hexRef8 anchors.
- works fine with `basic` scheme
### 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 : v2212
### 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/2726createPatch removes newly added patches2023-03-22T11:23:39ZDarren GarveycreatePatch removes newly added patchesI am using [CfdOf](https://github.com/jaheyns/CfdOF) to which in my use-case creates an empty patch using `createPatch` before extruding it with `extrudeMesh`. This approach appears to have broken between v2106 and v2206. I think the com...I am using [CfdOf](https://github.com/jaheyns/CfdOF) to which in my use-case creates an empty patch using `createPatch` before extruding it with `extrudeMesh`. This approach appears to have broken between v2106 and v2206. I think the commit ad6d3a088eb5bfeab806e159f25526a102deb3bc changed the behaviour, specifically with the removal of
```
void filterPatches(polyMesh& mesh, const wordHashSet& addedPatchNames)
```
Where `addPatchNames` was there to make sure that `createPatch` doesn't remove newly created patches when they have no faces.
The `system/createPatchDict` to reproduce this is simple:
```
pointSync false;
patches
(
{
name patch_0_1_back;
patchInfo
{
type patch;
}
constructFrom patches;
patches ();
}
);
```
The newer versions of `createPatch` (since v2206) add then remove this patch:
```
Removed zero-sized patch patch_0_1_back type patch at position 9
```
It is possible that this use-case isn't supported and/or there is a Better Way to do it. Is there a good reason this feature should not be added back into `createPatch` (before I look at doing that)?https://develop.openfoam.com/Development/openfoam/-/issues/2725changeDictionary does not work for multiple regions (i. e. for chtMultiRegion...2023-06-30T15:04:24ZMarco MüllerchangeDictionary does not work for multiple regions (i. e. for chtMultiRegionFoam) on mingw cross compilation### Summary
based on what I see, only the last solid region in the regionProperties lists can be handled with changeDictionary. All other regions abort.
### Steps to reproduce
run i. e. chtMultiRegionFoam\multiRegionHeater tutorial
...### Summary
based on what I see, only the last solid region in the regionProperties lists can be handled with changeDictionary. All other regions abort.
### Steps to reproduce
run i. e. chtMultiRegionFoam\multiRegionHeater tutorial
### What is the current *bug* behaviour?
changeDictionary sets the dictionaries correctly
### What is the expected *correct* behavior?
changeDictionary aborts
### Relevant logs and/or images
i.e. log.changeDictionary.leftSolid (unicode character 0x80 at the end):
...
Create mesh leftSolid
for time = 0
fileName::stripInvalid() called for invalid fileName leftSolid
For debug level (= 2) > 1 this is considered fatal
### Environment information
- OpenFOAM version : tested v2212|v2206|v2112|v2106|v2012|v2006
- Operating system : Win 10
- Hardware info :
- Compiler :https://develop.openfoam.com/Development/openfoam/-/issues/2723avoid register/deregister of tmp fields2024-02-21T13:32:54ZMark OLESENavoid register/deregister of tmp fieldsBy default IOobject uses (REGISTER). When a tmp field is created, its name will be registered in the corresponding objectRegistry (invoking an allocation to add to the HashTable, plus calculation of a hash value etc). If the tmp leaves s...By default IOobject uses (REGISTER). When a tmp field is created, its name will be registered in the corresponding objectRegistry (invoking an allocation to add to the HashTable, plus calculation of a hash value etc). If the tmp leaves scope immediately, it is removed from the registry which incurs another delete in addition to that of the tmp itself.https://develop.openfoam.com/Development/openfoam/-/issues/2722BUG: Error in setReference behaviour with moving mesh, correctPhi and paralle...2023-04-06T12:16:12ZJohan RoenbyBUG: Error in setReference behaviour with moving mesh, correctPhi and parallel runI have noticed generation of spurious bubble generation in the bulk of the liquid when working with interIsoFoam or interFoam combined with moving mesh in parallel and using correctPhi in fvSolution->PIMPLE. My investigations indicate th...I have noticed generation of spurious bubble generation in the bulk of the liquid when working with interIsoFoam or interFoam combined with moving mesh in parallel and using correctPhi in fvSolution->PIMPLE. My investigations indicate that there is a bug in the setting of the reference pressure (fvMatrix::setReference).
I have attached a minimal test case to this issue report which illustrates the problem. The case is based on v2206. The case is a simple square domain filled water and oscillating sinusoidally back and forth with a coded dynamicMeshDict. The case only includes 1 time step since this is enough for the problem to arise. To reproduce the problem, simply run the Allrun script in the case and look with paraview at the alpha.water values in the bottom of the domain (load the state.pvsm file to also see phi vectors). What you see is overshoot in the leftmost cell, which is cell 0 in processor0, and a corresponding undershoot in the leftmost cell (label 0) at the bottom of processor1:
![Udklip](/uploads/b95d10e0d21fc6361fd4f40110f3601f/Udklip.JPG)
The problem happens with both interFoam and interIsoFoam.
The flow is not solved (frozenFlow), but the correctPhi is set to "yes" in fvSolution->PIMPLE.
If correctPhi is set to "no" the problem disappears.
If the case is run in serial, the problem disappears.
If an "atmosphere" inlet/outlet is added to the top, so that no reference pressure is set, the problem disappears.
If I use 4 or 16 subdomains in decomposeParDict instead of 2, it is clear that it is the 0'th cell on each processor that is over- or undershooting in alpha.water:
![Picture1](/uploads/8e90bd9852dfe04ca193d2c1d0460e30/Picture1.png)
In the case, phi is corrected in the first time step using CorrectPhi(...). The Foam::CorrectPhi function has hardcoded cell 0 to be the reference cell:
pcorrEqn.setReference(0, 0);
If I change this to pcorrEqn.setReference(2, 0), I observe that the problematic cells move two cells to the right.
I assume that there should not be a reference cell for each processor, but a single reference cell on the entire domain to which all other cell pressures should refer.
Plotting phi-vectors in paraview, as done with the state.pvsm file supplied with the case, I have confirmed that the alpha.water over- and undershooting arise due to nonzero div(phi) where phi is the corrected phi from CorrectPhi.
Does anyone have an idea for how to fix this problem?
Test case: [oscillatingTank.zip](/uploads/50eae14bdb13ea752164a5845bee446e/oscillatingTank.zip)https://develop.openfoam.com/Development/openfoam/-/issues/2718Proposal: Meson Build System2023-09-07T19:03:22ZVolker WeißmannProposal: Meson Build SystemIn [this issue](https://develop.openfoam.com/Development/openfoam/-/issues/1936) we first talked about meson as an alternative build system. In [this issue](https://develop.openfoam.com/Development/openfoam/-/issues/1984#note_57979) I p...In [this issue](https://develop.openfoam.com/Development/openfoam/-/issues/1936) we first talked about meson as an alternative build system. In [this issue](https://develop.openfoam.com/Development/openfoam/-/issues/1984#note_57979) I presented the first prototype. Now we need to talk about how this project should continue. Please either respond in writing, or we can arrange a Jitsi-Meeting in English or German, whatever you prefer.
Example How to build and run:
```shell
git clone https://develop.openfoam.com/Development/openfoam.git
cd openfoam
git checkout 988ec18ecc
wget https://codeberg.org/Volker_Weissmann/foam_meson_patches/raw/branch/trunk/for_openfoam_commit_hash_988ec18ecc.diff
git apply ../for_openfoam_commit_hash_988ec18ecc.diff
meson setup ../build # Takes about 10 seconds
cd ../build
ninja # Takes hours
meson devenv # Launches a subshell that has some environmental variables (among others: $PATH) set.
cd ../openfoam/tutorials/basic/laplacianFoam/flange
./Allrun
```
(You can replace ../build with any path you like, no matter if its inside of the openfoam folder or not.)
Note that the above is a debug build, i.e. equivalent to setting "WM_COMPILE_OPTION=Debug". If you want a release build, i.e. equivalent to "WM_COMPILE_OPTION=Opt", you need to add a flag like this:
```
meson setup ../build --buildtype=release
```
I generated patches for the openfoam version with the commit hash 988ec18ecc, but I can generate patches for other versions too, just tell me what versions you need patches for.
# Open Issues
I have not looked at the ThirdParty folder yet, but that can follow.
I know that the OpenFOAM project needs to generate binary packages for different distributions. I have not looked closer at that yet, but that can follow.
The following dependencies are currently never used:
- zoltan
- mgrid
- ccmio
- kahip
- scotch
Again, fixing this is possible, but I want to fix this after we know what direction the project is gonna take.
## Build Subfolders seperately
One good thing about wmake is that you can copy e.g. the `applications/solvers/lagrangian/reactingParcelFoam/simpleReactingParcelFoam` folder to some other path outside of the openfoam folder, modify the contents a bit and run `wmake` inside that folder to build it. I think we will have to talk about that more than about any other feature. Currently, my build system offers no similar feature, but I have ideas on how to implement something like that.
## OS Support
I only tested it on my ArchLinux machine, and on a debian docker container, with the following additional packages installed:
```sh
apt-get install -y git g++ zlib1g-dev libfftw3-dev mpi-default-dev libboost-system-dev flex
```
I installed meson from source, since the packaged version is too old (we need at least 0.59.0).
This was the script I ran on Debian:
```
set -euo pipefail
IFS=$'\n\t'
cd /root
apt update
apt install -y git g++ zlib1g-dev libfftw3-dev mpi-default-dev libboost-system-dev flex python3 ninja-build wget
wget https://codeberg.org/Volker_Weissmann/foam_meson_patches/raw/branch/trunk/for_openfoam_commit_hash_988ec18ecc.diff
git clone https://github.com/mesonbuild/meson || true
cd meson
git checkout 0.59.0
cd ..
git clone https://develop.openfoam.com/Development/openfoam.git
cd openfoam
git checkout 988ec18ecc
git apply ../for_openfoam_commit_hash_988ec18ecc.diff
../meson/meson.py setup ../build
cd ../build
ninja
../meson/meson.py devenv bash -c "cd ../openfoam/tutorials/basic/laplacianFoam/flange && ./Allrun"
```
Support for other OS's should not be much work.
If we decide to continue this project, I will setup proper testing on different OS's.
# Advantages over wmake
While wmake is only used by the openfoam project, meson is used by many different projects and has way more/better documentation that wmake. So if you know how to use meson, you know how to use it in the OpenFOAM project.
The meson.build files are very easy to read.
`meson setup` generates a compilation_commands.json file with can be [useful to IDE's](https://openfoamwiki.net/index.php/HowTo_Use_OpenFOAM_with_Visual_Studio_Code). No need for any slow hacks anymore.
I have not confirmed the following with measurements yet, but I will do so if we decide to continue this project:
A clean compile is about as fast as a clean compile with Allwmake. Incremental builds however, are *way* faster. If nothing has changed and you run `ninja` again, this takes 2-5 seconds (and we could further reduce that time). In contrast, running `./Allwmake` in the top-level directory will take over a minute on the same machine.
Afaik, meson is better at knowing what needs to be rebuilt and what does not. This results in faster incremental builds and less wrong builds (I vaguely remembering having trouble that wmake did not recompile stuff that changed, leading to a confusing debugging session).
Afaik, if you build openfoam, then do `git pull` and run `./Allwmake` again, it is possible that this will fail and you have to manually run `wclean`. This happened to me, when I upgraded from `0031cb1efac0d550334108346f26dde5e707b6fd` to `988ec18ecca76aa0cef65acbab765374416d61b6`:
```
make: *** No rule to make target 'fields/faPatchFields/constraint/processor/processorFaPatchScalarField.H', needed by '/home/volker/Documents/foam/openfoam/build/linux64GccDPInt32Opt/src/finiteArea/fields/faPatchFields/constraint/processor/processorFaPatchFields.C.dep'. Stop.
```
Meson on the other hand, is afaik quite robust in such cases. The only thing that ever forced manual intervention or a clean rebuild was if I made changes to the OS (e.g. removing a package that is an optional dependency of OpenFOAM, or when I built in on one machine and copied the build folder to a different machine).
If you just want to build a single binary, you ran run `ninja targetname` and it will build this binary and all of its dependencies. With wmake, you either have to run `./Allwmake` in the top directory, which is slow, or manually go into each directory that is a dependency of this binary and run `wmake` there.
If you add "#include something.C" to a source file, then run `wmake`, then remove that line and the file, `wmake` will fail with
```
make: *** No rule to make target 'something.C', needed by '/home/volker/Sync/git/foam_meson/legacy/build/linux64GccDPInt32Opt/src/parallel/reconstruct/faReconstruct/processorFaMeshes.C.dep'. Stop.
```
You have to run `wclean` to fix this. The same thing works fine with meson/ninja.
If you build (at least a part of) OpenFOAM, then change `WM_COMPILE_OPTION`, and run `./Allwmake`, it will not recompile the things that were compiled with the old `WM_COMPILE_OPTION`. Ninja will recompile everything that is necessary. (With wmake, I had to delete my build folder many times because I forget if I had always set WM_COMPILE_OPTION correctly.)
If your machine is missing a dependency of OpenFOAM, meson will error during the first few seconds and tell you that you are missing that dependency. With wmake on the other hand, it might compile for hours until you see that some header file cannot be found. (Trying to build OpenFOAM on a machine that uses musl-libc instead of glibc was fun.)
With meson, you can do out-of-tree builds.
Make interleaves the output of multiple cores, Ninja does not.https://develop.openfoam.com/Development/openfoam/-/issues/2717SelectionMode geometric requires cellZone name in DarcyForchheimer fvOptions2023-03-13T13:49:27ZTobias HolzmannSelectionMode geometric requires cellZone name in DarcyForchheimer fvOptions<!--
*** 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
-->
As described by @Prashant in EP2090 the selectionMode namely geometric can be used within the DarcyForchheimer model but we need also to specify the keyword "cellZone" while specifying a cellZone in addition. This does not make sense and is inconsistent as the cellZone is comming from the geometric selection mode.
<!--
All text between these markers are comments and will not be present in the
report
-->
### Summary
<!-- Summarize the bug encountered concisely -->
### Steps to reproduce
Add an fvOption in such a way:
```
porousity
{
type explicitPorositySource;
active true;
explicitPorositySourceCoeffs
{
type DarcyForchheimer;
d d [0 -2 0 0 0 0 0] (1e12 1e12 1e12);
f f [0 -1 0 0 0 0 0] (0 0 0);
coordinateSystem
{
origin (0 0 0);
e1 (1 0 0);
e2 (0 1 0);
}
selectionMode geometric;
selection
{
box
{
action use;
source box;
min (0 -1 -1);
max (1 0 1);
}
}
}
}
```
<!-- How one can reproduce the issue - this is very important -->
### Example case
Any tutorial 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?
Selection mode "geometric" requires a cellZone in addition.
<!-- What actually happens -->
### What is the expected *correct* behavior?
Selection mode "geometric" should be usable without specification of a cellZone
<!-- 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 : 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 : v2212
- Operating system :
- Hardware info :
- Compiler :Mark OLESENMark OLESEN