Development issueshttps://develop.openfoam.com/groups/Development/-/issues2021-11-29T11:01:03Zhttps://develop.openfoam.com/Development/openfoam/-/issues/2051Is Foam::multiphaseMixture::surfaceTensionForce() depends on phase order in t...2021-11-29T11:01:03ZRAHUL VADRABADEIs Foam::multiphaseMixture::surfaceTensionForce() depends on phase order in transportProperties?I am [debugging](https://github.com/Rvadrabade/Debugging-OpenFOAM-with-Visual-Studio-Code) multiphaseInterFoam solver to understand the underlying physics. However, it is observed that the order of phases in `constant/transportProperties...I am [debugging](https://github.com/Rvadrabade/Debugging-OpenFOAM-with-Visual-Studio-Code) multiphaseInterFoam solver to understand the underlying physics. However, it is observed that the order of phases in `constant/transportProperties.phases` affects the accurate calculation of surface tension force (`Foam::multiphaseMixture::surfaceTensionForce()`).
In spite of having contact angle boundary defined for air phase [alpha.air] with [original tutorial](https://develop.openfoam.com/Development/openfoam/-/blob/master/tutorials/multiphase/multiphaseInterFoam/laminar/damBreak4phase/constant/transportProperties), the `if(isA<alphaContactAngleFvPatchScalarField>(gbf[patchi]))` condition in `Foam::multiphaseMixture::correctContactAngle()` [ [multiphaseMixture.C ](https://develop.openfoam.com/Development/openfoam/-/blob/master/applications/solvers/multiphase/multiphaseInterFoam/multiphaseMixture/multiphaseMixture.C#L426) L:426] is always false.
Further, if the `air` phase defined first in constant/transportProperties.phases then Foam::multiphaseMixture::correctContactAngle() works as expected see attachment **damBreak4phaseModifiedCase**.
The effect of accurate calculation of surface tension force considering the contact angle might be very small. However, I would like to know if this behavior is as per the design of the multiphaseInterFoam solver and is as expected or there is scope for improvement?
[damBreak4phaseModifiedCase.zip](/uploads/f62f471485356710d6a890482bb5ff52/damBreak4phaseModifiedCase.zip)
[damBreak4phaseOriginalCase.zip](/uploads/3d9b0b5aa27c1f9f714c9bbacaa9e417/damBreak4phaseOriginalCase.zip)Kutalmış BerçinKutalmış Berçinhttps://develop.openfoam.com/Development/openfoam/-/issues/2047primitiveMesh::edgeFaces produces different results whether using cached or u...2021-07-01T09:37:08ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comprimitiveMesh::edgeFaces produces different results whether using cached or uncached data<!--
*** 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 -->
primitiveMesh::edgeFaces comes in two versions:
- calculate edgeFaces for all edges of the mesh. This is ok.
- calculate edgeFaces only for a single edge (i.e. uncached). This produces false positives for faces with difficult edge connectivity.
### Steps to reproduce
<!-- How one can reproduce the issue - this is very important -->
Run attached test program on motorBike tutorial.
### What is the current *bug* behaviour?
<!-- What actually happens -->
For some edges the uncached version returns 3 faces whereas the proper one returns 2 faces.
### 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 : v2012
### 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
-->
We're looping through pointFaces to see the common faces. However we do not check the edge is an edge (i.e. using consecutive vertices) on all the faces.Mattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comhttps://develop.openfoam.com/Development/openfoam/-/issues/2046splitMeshRegions : keep cellZones together2021-08-11T15:15:31ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comsplitMeshRegions : keep cellZones together### Functionality to add/problem to solve
splitMeshRegions currently always puts each cellZone into its separate region. Allow keeping cellZones together.
### Target audience
Generating multi-region cases (e.g. cht) from a single mes...### Functionality to add/problem to solve
splitMeshRegions currently always puts each cellZone into its separate region. Allow keeping cellZones together.
### Target audience
Generating multi-region cases (e.g. cht) from a single mesh.
### Proposal
Add additional option.Mattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comhttps://develop.openfoam.com/Development/openfoam/-/issues/2045fvOptions SemiImplicitSource issue2024-01-09T12:14:22Zsung won choifvOptions SemiImplicitSource issueI am simulating a conjugate heat transfer problem using chtMultiRegionTwoPhaseEulerFoam, a simple case of a solid being cooled by a fluid. However no matter how much I increase the value of heat flux for the solid in fvOptions, the outle...I am simulating a conjugate heat transfer problem using chtMultiRegionTwoPhaseEulerFoam, a simple case of a solid being cooled by a fluid. However no matter how much I increase the value of heat flux for the solid in fvOptions, the outlet water temperature or the temperature of the solid just does not change. it seems to be openfoam is just ignoring fvOptions file. Maximum value of temperature at the solid and outlet water temperature remains the same as the initial value and just does not change no matter how much I change heat flux(or Power) value in fvOptions. Thanks for any advice. Regards (Please see the attached file[solidQuench37T-UP.zip](/uploads/43e6e1275839edb3ce8f7e2c7c006684/solidQuench37T-UP.zip). This model is using V-2012))https://develop.openfoam.com/Development/openfoam/-/issues/2044Add Function suggestion: Add Fujitsu-MPI for A64FX.2021-03-31T06:57:59ZTomoki, KaratsuAdd Function suggestion: Add Fujitsu-MPI for A64FX.Hello, @mark.
Thank you for your cooperation in adding the Fujitsu compiler before. This time I would like to add a process to recognize the Fujitsu MPI library on A64FX.
Can I submit the PR this community? If I don't have the right to ...Hello, @mark.
Thank you for your cooperation in adding the Fujitsu compiler before. This time I would like to add a process to recognize the Fujitsu MPI library on A64FX.
Can I submit the PR this community? If I don't have the right to submit a PR, could you incorporate the following fixes?
```
diff --git a/etc/bashrc b/etc/bashrc
index 763f165..a6daac7 100644
--- a/etc/bashrc
+++ b/etc/bashrc
@@ -90,7 +90,7 @@ export WM_COMPILE_OPTION=Opt
# [WM_MPLIB] - MPI implementation:
# = SYSTEMOPENMPI | OPENMPI | SYSTEMMPI | MPI | MPICH | MPICH-GM |
-# HPMPI | CRAY-MPICH | FJMPI | QSMPI | SGIMPI | INTELMPI | USERMPI
+# HPMPI | CRAY-MPICH | FJMPI | FJMPI-A64FX | QSMPI | SGIMPI | INTELMPI | USERMPI
# Specify SYSTEMOPENMPI1, SYSTEMOPENMPI2 for internal tracking (if desired)
# Can also use INTELMPI-xyz etc and define your own wmake rule
export WM_MPLIB=SYSTEMOPENMPI
diff --git a/etc/config.sh/mpi b/etc/config.sh/mpi
index 69617b1..7531cc8 100644
--- a/etc/config.sh/mpi
+++ b/etc/config.sh/mpi
@@ -297,6 +297,15 @@ FJMPI)
_foamAddLib /opt/FJSVpnidt/lib
;;
+FJMPI-A64FX)
+ export FOAM_MPI=fjmpi-a64fx
+ export MPI_ARCH_PATH="$MPI_ROOT"
+
+ export OPAL_PREFIX="$MPI_ARCH_PATH"
+
+ _foamAddPath "$MPI_ARCH_PATH"/bin
+ _foamAddLib "$MPI_ARCH_PATH"/lib64
+ ;;
QSMPI)
export FOAM_MPI=qsmpi
diff --git a/wmake/rules/General/mplibFJMPI-A64FX b/wmake/rules/General/mplibFJMPI-A64FX
index e69de29..6e2ae4f 100644
--- a/wmake/rules/General/mplibFJMPI-A64FX
+++ b/wmake/rules/General/mplibFJMPI-A64FX
@@ -0,0 +1,7 @@
+#------------------------------------------------------------------------------
+
+PFLAGS = -DMPICH_SKIP_MPICXX -DOMPI_SKIP_MPICXX
+PINC = -isystem $(MPI_ARCH_PATH)/include/mpi/fujitsu/
+PLIBS = -L$(MPI_ARCH_PATH)/lib64 -lmpi
+
+#------------------------------------------------------------------------------
```Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/2043Renumbering mesh results in high non-orthogonality and skewness2021-04-15T08:57:40ZGhost UserRenumbering mesh results in high non-orthogonality and skewnessHello,
When I run the `checkMesh` utility in my case with the attached Grid `mesh.x`, it reports the following values of non-orthogonality and skewness (See the `checkMesh.beforeRenumbering` attached file for details):
**Before running...Hello,
When I run the `checkMesh` utility in my case with the attached Grid `mesh.x`, it reports the following values of non-orthogonality and skewness (See the `checkMesh.beforeRenumbering` attached file for details):
**Before running renumberMesh**:
```
Mesh non-orthogonality Max: 36.0957 average: 9.08335
Non-orthogonality check OK.
Face pyramids OK.
Max skewness = 2.03538 OK.
```
But when I run the renumberMesh utility, then checkMesh, I get the following (see `checkMesh.afterRenumbering` attached file):
**After running renumberMesh**:
```
Mesh non-orthogonality Max: 78.4614 average: 9.84955
*Number of severely non-orthogonal (> 70 degrees) faces: 26.
Non-orthogonality check OK.
<<Writing 26 non-orthogonal faces to set nonOrthoFaces
Face pyramids OK.
Max skewness = 3.322 OK.
Coupled point location match (average 0) OK.
Failed 1 mesh checks.
```
As you can see, the **max skewness becomes 3.322**, and the **max non-orthogonality becomes 78.4614**.
I wonder if this is a side-effect of renumbering the cells or is it a bug?
Thank you
**Note**:
to convert the mesh.x to OpenFOAM format, use: `plot3dToFoam -2D 0.01 -noBlank mesh.x`
**Attached files**:
[mesh.x](/uploads/398f669511ad3547d37385db6383b66b/mesh.x)
[checkMesh.beforeRenumbering](/uploads/1e6e09b3c8fbfab13039646c3db28f60/checkMesh.beforeRenumbering)
[checkMesh.afterRenumbering](/uploads/358d8b8b7eb0e0df2df265b343716c1b/checkMesh.afterRenumbering)https://develop.openfoam.com/Development/openfoam/-/issues/2039cannot use vector with 'calc' directive2021-03-29T14:30:14ZMark OLESENcannot use vector with 'calc' directiveNoted by @svilfaye
```
#calc "vector(1, 2, 3);
// or
#calc "doubleVector(1, 2, 3);
```
fail to compileNoted by @svilfaye
```
#calc "vector(1, 2, 3);
// or
#calc "doubleVector(1, 2, 3);
```
fail to compileMark OLESENMark OLESENhttps://develop.openfoam.com/Development/ThirdParty-common/-/issues/59Change default WM_NCOMPPROCS2021-03-23T16:55:17ZGuanyang XueChange default WM_NCOMPPROCSI was warned by the HPC manager that the third party make script uses all CPU cores in the head node.
Could you please consider adding a script to change the default behavior if it detects HPC environment?
For example, run `lscpu | gre...I was warned by the HPC manager that the third party make script uses all CPU cores in the head node.
Could you please consider adding a script to change the default behavior if it detects HPC environment?
For example, run `lscpu | grep Socket`. If the result is 2, ask the user if it's in HPC environment, then type in no. of cores (most HPC managers are OK with `-j 4`).https://develop.openfoam.com/Development/openfoam/-/issues/2036cyclicACMI checkMesh2023-12-13T17:03:48ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comcyclicACMI checkMesh<!--
*** 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 -->
checkMesh reports open cells if it detects different topology (i.e. presence of polyMesh/owner,boundary etc)
### Steps to reproduce
<!-- How one can reproduce the issue - this is very important -->
- run `tutorials/incompressible/pimpleFoam/RAS/oscillatingInletACMI2D`
- `cp constant/polyMesh/ 1/polyMesh/`
- `checkMesh` now reports open cells at time 1
### What is the current *bug* behaviour?
<!-- What actually happens -->
```
Checking geometry...
Overall domain bounding box (0 0 0) (3 1 0.1)
Mesh has 2 geometric (non-empty/wedge) directions (1 1 0)
Mesh has 2 solution (non-empty) directions (1 1 0)
All edges aligned with or perpendicular to non-empty directions.
***Boundary openness (-0.01030927835 3.144558878e-17 -4.584107381e-16) possible hole in boundary description.
***Open cells found, max cell openness: 0.3333333333, number of open cells 136
<<Writing 136 non closed cells to set nonClosedCells
```
### Environment information
- OpenFOAM version :v2012
### Possible fixes
It reports the AMI weights correctly. Maybe ordering of polyBoundaryMesh in polyMesh::readUpdate?
@Pawanhttps://develop.openfoam.com/Development/openfoam/-/issues/2033Bug: reactingTwoPhaseEulerFoam does not reproduce the analytical solution fo...2021-03-31T10:18:34ZFedericoBug: reactingTwoPhaseEulerFoam does not reproduce the analytical solution for the Sod Shock tube problem
**Description:**[SodShockTube-issue-v2012.zip](/uploads/e22fa311d55919076443c7a061dc3920/SodShockTube-issue-v2012.zip)
reactingTwoPhaseEulerFoam (OpenFOAM v2012) is not reproducing the exact solution for the single phase Sod shock tube...
**Description:**[SodShockTube-issue-v2012.zip](/uploads/e22fa311d55919076443c7a061dc3920/SodShockTube-issue-v2012.zip)
reactingTwoPhaseEulerFoam (OpenFOAM v2012) is not reproducing the exact solution for the single phase Sod shock tube benchmark. In particular, the temperature field is significantly different (see figure, dashed line representing the exact solution). reactingMultiPhaseEulerFoam is also affected and twoPhaseEulerFoam should not (although not tested for this repository)This issue is not observed in old OpenFOAM versions (OF<5).
**Solution:**
This Bug is now solved in multiphaseEulerFoam (OpenFOAM 8) and I strongly suggest to implement this fix also for reactingTwo/MultiPhaseEulerFoam (OF-v2012). Here all the details:
https://bugs.openfoam.org/view.php?id=3634
**Steps to Reproduce:**
1- Enter Sod shock tube test case for reactingTwoPhaseEulerFoam (OF-v2012,v2006). The analytical solution is also included.
2- ./Allclean; ./Allrun
3- paraview -> load state file -> ParaviewState/vsAnalytical.pvsm (paraview version
5.0-5.6)
4- select “thermo:rho.gas” and click “apply” to check gas density
![SodSchock_OFv2012_reactingTwophase](/uploads/5342d951c21d002ec9669e36a90445b5/SodSchock_OFv2012_reactingTwophase.png)Kutalmış BerçinKutalmış Berçinhttps://develop.openfoam.com/Development/openfoam/-/issues/2031atmFlatTerrain precursor atmAmbientTurbSource setup2021-04-26T14:55:37ZHassan KassematmFlatTerrain precursor atmAmbientTurbSource setupHello,
The ``precursor`` setup of ``atmFlatTerrain`` is inconsistent with the successor and other atmospheric cases. The ``atmAmbientTurbSource`` produces turbulent mixing length of 72m which is way too high even compared to the setup `...Hello,
The ``precursor`` setup of ``atmFlatTerrain`` is inconsistent with the successor and other atmospheric cases. The ``atmAmbientTurbSource`` produces turbulent mixing length of 72m which is way too high even compared to the setup ``Lmax = 41m``. This should not exceed few meters 1~2m. I think, ``kAmb`` should drop at least one order of magnitude to match the successor. Unless there is a specific reason for such choice which I missed.Kutalmış BerçinKutalmış Berçinhttps://develop.openfoam.com/Development/openfoam/-/issues/2027reading processor dirs can hang2021-12-03T15:40:32ZMark OLESENreading processor dirs can hangAs noted by @chiara in EP1528, processes can hang on startup.
Running with timeStampMaster with _non-distributed_ case directories, but with case directories that contain different portions of the processorNN structure. Eg,
```
node0:
/...As noted by @chiara in EP1528, processes can hang on startup.
Running with timeStampMaster with _non-distributed_ case directories, but with case directories that contain different portions of the processorNN structure. Eg,
```
node0:
/scratch/job10/constant, /scratch/job10/system, /scratch/processor{0,1,2,3}
node1:
/scratch/job10/constant, /scratch/job10/system, /scratch/processor{4,5,6,7}
...
```
The startup optimization logic added in #1946 results in a false listing since the directory information is scattered from node0, which only has processors (0-3).
Proposed fix is to place the optimization onto a switch, and restore the previous behaviour of polling on all nodes by default.Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/2026twoPhaseMixtureThermo + solidificationMeltingSource2021-12-09T20:12:06ZRegő SimontwoPhaseMixtureThermo + solidificationMeltingSource### Functionality to add/problem to solve
compressibleInterFoam + solidificationMeltingSource does not work together but as I see they could.
### Target audience
Multiphase cases with solidification and melting.
### Proposal
This co...### Functionality to add/problem to solve
compressibleInterFoam + solidificationMeltingSource does not work together but as I see they could.
### Target audience
Multiphase cases with solidification and melting.
### Proposal
This combination (twoPhaseMixtureThermo (compressibleInterFoam) + solidificationMeltingSource) currently raises the following error:
```
--> FOAM FATAL ERROR: (openfoam-2012)
Not implemented
From virtual const volScalarField& Foam::twoPhaseMixtureThermo::he() const
in file twoPhaseMixtureThermo.H at line 143.
FOAM aborting
```
This error comes from line 211 ([source](https://www.openfoam.com/documentation/guides/latest/api/solidificationMeltingSource_8C_source.html)):
```
fieldNames_[1] = thermo.he().name();
```
I can't see if this variable is used anywhere else, but with an additional switch or using the default value (TName_) this problem vanishes.
**EDIT**:
There is a lookup thermo mode which resolve this issue. I missed it, sorry. But I found another problem with dynamic mesh refinement and solidificationMelting (see my 1st comment).Kutalmış BerçinKutalmış Berçinhttps://develop.openfoam.com/Development/openfoam/-/issues/2025flowrate(Inlet/Outlet)velocity division by zero2021-12-03T15:40:56ZHenning Scheuflerflowrate(Inlet/Outlet)velocity division by zero### Summary
the flow rate can be zero resulting in a division by zero
relevant files:
- flowRateOutletVelocityFvPatchVectorField.C
- flowRateInletVelocityFvPatchVectorField.C
```
template<class RhoType>
void Foam::flowRateInletVeloci...### Summary
the flow rate can be zero resulting in a division by zero
relevant files:
- flowRateOutletVelocityFvPatchVectorField.C
- flowRateInletVelocityFvPatchVectorField.C
```
template<class RhoType>
void Foam::flowRateInletVelocityFvPatchVectorField::updateValues:
const scalar flowRate = flowRate_->value(t);
const scalar estimatedFlowRate = -gSum(rho*(this->patch().magSf()*nUp));
if (estimatedFlowRate/flowRate > 0.5) // division by zero possible
{
nUp *= (mag(flowRate)/mag(estimatedFlowRate));
}
```
### Possible fixes
[flowRateDivisionByZero.patch](/uploads/911e37bacc46ab63642ab29a2498b64b/flowRateDivisionByZero.patch)
```
scalar flowRate = stabilize(flowRate_->value(t),SMALL);
```
Would be the "cleaner" coding option compared to:
```
scalar flowRate = flowRate_->value(t);
if (flowRate == 0)
{
flowRate = SMALL
}
```
But the flowrate might be tiny in the same region as SMALL (e.g. micro scale simulation) and this might be problematic to debug by the userMark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/2023checkMesh write surface fields2022-12-23T15:02:41ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comcheckMesh write surface fields### Functionality to add/problem to solve
checkMesh to write surface fields for face-based mesh parameters### Functionality to add/problem to solve
checkMesh to write surface fields for face-based mesh parametersMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comhttps://develop.openfoam.com/Development/openfoam/-/issues/2020Feature Branch : Tutorial updates2021-03-09T14:16:34ZPrashant SonakarFeature Branch : Tutorial updates - [x] [flamePropagationWithObstacles](https://develop.openfoam.com/Development/openfoam/-/tree/PDRFoam-rc1/tutorials/combustion/PDRFoam/flamePropagationWithObstacles) tutorial fails with error `0/combustFlag` not found
- [x] [Allrun#L1... - [x] [flamePropagationWithObstacles](https://develop.openfoam.com/Development/openfoam/-/tree/PDRFoam-rc1/tutorials/combustion/PDRFoam/flamePropagationWithObstacles) tutorial fails with error `0/combustFlag` not found
- [x] [Allrun#L14](https://develop.openfoam.com/Development/openfoam/-/blob/PDRFoam-rc1/tutorials/combustion/PDRFoam/pipeLattice/Allrun#L14) needs `runApplication PDRMesh` as noted by @pratap
- [x] Case pipeLattice fails in parallel when doing decomposition just before solver with error `cannot find file processor*/constant/combustFlag` - please revisit instance to find runTime or ? in createFields.H (similar issue for other fields as well)
(Cross Ref EP#1473)Sergio FerrarisSergio Ferrarishttps://develop.openfoam.com/Development/openfoam/-/issues/2016interIsoFoam runs into an endless loop2021-12-07T08:55:41ZMichael AllettointerIsoFoam runs into an endless loopHello,
when testing interIsofoam i found a parameter set for which it runs in an endless loop. I made same flags to find out where this happens and it is in the file plicRDF.c at line 470 in the while loop starting which while (resIter....Hello,
when testing interIsofoam i found a parameter set for which it runs in an endless loop. I made same flags to find out where this happens and it is in the file plicRDF.c at line 470 in the while loop starting which while (resIter.found()).
I uploaded a case file with an allrun script to reproduce the error. In my case it got stuck at the time 0.609626.
Best
Michael
[nOuter2nInner2nAlphaBounds6send.tar.gz](/uploads/3c1a44feb69d18bbfd79d2e4fdea9c97/nOuter2nInner2nAlphaBounds6send.tar.gz)https://develop.openfoam.com/Development/openfoam/-/issues/2014Usability enhancements for expression based BC's and utilities2021-03-18T13:05:34ZRyan DanksUsability enhancements for expression based BC's and utilities### Functionality to add/problem to solve
The functionality of the expression-based tools is handy for some basic things and it has the potential to be a really powerful addition to OF, but I've run in to multiple issues relating to acc...### Functionality to add/problem to solve
The functionality of the expression-based tools is handy for some basic things and it has the potential to be a really powerful addition to OF, but I've run in to multiple issues relating to accessing other fields after only a little bit of playing (other than the bug I reported in issue #2012 ):
1. The setExpr(Boundary)Fields tools do not automatically load fields referenced in the equations, only the field(s) being manipulated. There are workarounds of course (the readFields FO for example) but this is not ideal and is different from the functionality of funkySet(Boundary)Fields.
2. A similar issue arises when using an expression as a BC for one field that relies on data from another field. My use case was calculate the exiting temperature at an outlet, based on an assumed heat flux and the temperature/flow rate at the inlet. So my T boundary conditions needed to know phi.
- The first challenge was the fact that the order in which the solver reads the fields now matters (i.e. if phi is read before T, then everything works; but if T is read into the solver before phi is loaded, the expression BC throws an error because phi doesn't exist yet). I was able to work around that in my test case by just reordering the reading of the fields in my solver, but this is obviously not a general fix.
- I then ran into a similar issue when trying to decompose my case. (decomposePar decomposed T before phi and failed). This ended up being a kind of fatal issue because the readFields FO doesn't work with decomposePar. I suppose the other other workaround would be to change the expression to the point that it decomposes, then change the expression in each processor folder after...
### Target audience
Fixing these two issues will make the expressions a lot more powerful and useful for cases like the one I described above where we can model heat exchange in a relatively simple way. I could also see uses for it in transient cases where you would want to 'control' windows or fans or something as a function of temperature or scalar concentration (i.e. fires).
### Proposal
Item 1 is the more straightforward of the two to fix. The easiest would be including an optional fieldsToLoad parameter to the utilities which would read in a list of field names the utilities need to know about. A second, cleaner option would be to do a first pass with the parser to pick off all the field names and then load them into memory.
Item 2 is trickier. I've done some BC coding but I'm not really sure where you would start with this. A simple fix could be to just have decomposePar ignore expression fields. I'm not sure if there is anything more sophisticated to do beyond that. Perhaps some inspiration from groovyBC?
### What does success look like, and how can we measure that?
Success would be the issues I noted above not occuring to allow more flexibility with the expressions.
### Links / references
N/A
### Funding
I would imagine that similar functionality could be found in the funkySetFields/groovyBC libraries.Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/2013wmake-with-bear doesn't work with macOS properly2021-07-08T09:46:42ZGuanyang Xuewmake-with-bear doesn't work with macOS properly### Summary
wmake-with-bear doesn't work with macOS properly
### Steps to reproduce
Use the patch provided by https://github.com/mrklein/openfoam-os-x (tested with normal installation, no problem).
```
$ brew install bear
$ bear --ver...### Summary
wmake-with-bear doesn't work with macOS properly
### Steps to reproduce
Use the patch provided by https://github.com/mrklein/openfoam-os-x (tested with normal installation, no problem).
```
$ brew install bear
$ bear --version
bear 3.0.8
$ ./Allwmake -with-bear > log.Allwmake 2>&1
```
### 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?
```
sed: 1: "1{ s/^[^0-9]*\([1-9]\)/ ...": bad flag in substitute command: '}'
Warning: bear not found
Stopping
```
This is caused by the macOS variant of `sed`.
Need to install `gnu-sed` in Homebrew and add `PATH="/usr/local/opt/gnu-sed/libexec/gnubin:$PATH"`
However installing too many conflicting packages is not a good idea.
### What is the expected *correct* behavior?
### Relevant logs and/or images
### Environment information
<!--
Providing details of your set-up can help us identify any issues, e.g.
OpenFOAM version : v2012
Operating system : ubuntu|openSUSE|centos etc
Hardware info : any info that may help?
Compiler : gcc|intel|clang etc
-->
- OpenFOAM version : v2012
- Operating system : macOS
- Hardware info : x86
- Compiler : Clang
### Possible fixes
Implement a universal command (or consider `awk`) to extract the version number.
For example, removing the curly brackets {} works in macOS.https://develop.openfoam.com/Development/openfoam/-/issues/2012SetExprFields fails when run from the command line2021-03-18T16:57:13ZRyan DanksSetExprFields fails when run from the command line<!--
*** 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
There is a typo on line 774 of setExprFields.C that causes the tool to fail when specifying an expression via the command line rather than a dict.
### Steps to reproduce
It occurs for any scenario where the command line interface is used
### Example case
### What is the current *bug* behaviour?
the command fails with an out of range error.
### What is the expected *correct* behavior?
The setExpField command should run correctly and set/create the field.
### 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 : v2012
- Operating system : ubuntu
- Hardware info :
- Compiler : gcc
### Possible fixes
change line 774 of setExprFields.C from `args[expression],` to `args["expression"],`Mark OLESENMark OLESEN