Development issueshttps://develop.openfoam.com/groups/Development/-/issues2023-06-12T14:31:12Zhttps://develop.openfoam.com/Development/openfoam/-/issues/2704Reverse reaction rate in ReversibleReaction artificially restricted - might d...2023-06-12T14:31:12ZDaveReverse reaction rate in ReversibleReaction artificially restricted - might deliver wrong results### Summary
Reversible reactions in OpenFOAM deliver wrong results when the backward/ reverse reaction acts strongly.
### Steps to reproduce
Run appended test case and display generated `lineplot.png` file.
### Example case
Below te...### Summary
Reversible reactions in OpenFOAM deliver wrong results when the backward/ reverse reaction acts strongly.
### Steps to reproduce
Run appended test case and display generated `lineplot.png` file.
### Example case
Below test case features the reacting flow in a channel (0,1 x 0,1 x 1 m³) at $`T_\mathrm{in}=300\,\mathrm{°C}`$, $`U_\mathrm{in}=10\frac{\mathrm m}{\mathrm s}`$, $`(x_{\mathrm H_2}=x_{\mathrm H_2\mathrm O}=x_\mathrm{CO}=x_{\mathrm{CO}2})_\mathrm{in}=0.25`$ and adiabatic free-slip walls considering both water-gas shift as well as methane-steam reforming reaction:
[Arrhenius_Parameter.zip](/uploads/54a95386ef602dced0e582ad6fc51af8/Arrhenius_Parameter.zip)
### What is the current *bug* behaviour?
The backward reaction rate is currently limited by limiting the concentration-based equilibrium constant `Kc` to an (arbitrary) value of 1e-6:
```
Foam::scalar Foam::ReversibleReaction
<
ReactionType,
ReactionThermo,
ReactionRate
>::kr
(
const scalar kfwd,
const scalar p,
const scalar T,
const scalarField& c
) const
{
return kfwd/max(this->Kc(p, T), 1e-6);
}
```
The unit of this value differs with depending the stoichiometric coefficients of the reaction educts and products, which further points out the arbitrariness of this value:
$`K_c=K_{(p)}\left(\frac{p^\ominus}{\bar RT}\right)^{\sum_k{\nu_k''-\nu_k'}}=e^{-\frac{\Delta_{\mathrm R}G^\ominus}{\bar RT}}\left(\frac{p^\ominus}{\bar RT}\right)^{\sum_i{\nu_i''}-\sum_k{\nu_k'}}`$
$`[K_c]=\left(\frac{\mathrm{kmol}}{\mathrm m^3}\right)^{\sum_i{\nu_i''}-\sum_k{\nu_k'}}`$
In contrast to this, the forward reaction coefficient is **not** restricted at all.
Especially for reactions, where the direction of reaction is not clear at a first glance or strongly depends on the temperature, this can lead to wrong results which are hard to identify.
### What is the expected *correct* behavior?
The backward reaction rate should remain unrestricted just as the forward reaction rate.
### Relevant logs and/or images
The left picture shows the results of the test case for the original reversible reaction implementation in OpenFOAM. The reaction does nearly not take place as the backward reaction of the methane steam reaction is restricted. This also leads to nearly no change in the temperature.
The right picture shows the results of the same test case for the correct reversible reaction implementation. Both the development of the species and the temperature are in perfect agreement with results generated in Ansys CFX, Ansys Fluent, StarCCM+ and analytical calculation.
<table><tr>
<td>
<figure>
<img src="/uploads/358ed4fd30a9ea6b72ead34c5d1b4176/grafik.png"/><figcaption>Test case results for temperature and gas species development using original ReversibleReaction.C</figcaption>
</figure>
</td>
<td>
<figure>
<img src="/uploads/be7bde53cd5680d5f78fac8180a82e3d/lineplot.png"/><figcaption>Test case results for temperature and gas species development using patched ReversibleReaction.C</figcaption>
</figure>
</td>
</tr></table>
<figure>
<img src="/uploads/96ba5dafe917e8667172fba1e8f52b3d/grafik.png" width="50%"/><figcaption>Comparison of test case results between CFX, Fluent, StarCCM+, analytical solution and OpenFOAM with correct reversible reaction implementation</figcaption>
</figure>
### Environment information
- OpenFOAM version : v2212, 10 and all previous
- Operating system : Ubuntu 2204 LTS @ WSL2.0 and all other systems
### Possible fixes
In `$FOAM_SRC/thermophysicalModels/specie/reaction/Reactions/ReversibleReaction/ReversibleReaction.C`, the 1e-6 in line [131](https://develop.openfoam.com/Development/openfoam/-/blob/master/src/thermophysicalModels/specie/reaction/Reactions/ReversibleReaction/ReversibleReaction.C#L131) should simply be replaced by `VSMALL`:
```
Foam::scalar Foam::ReversibleReaction
<
ReactionType,
ReactionThermo,
ReactionRate
>::kr
(
const scalar kfwd,
const scalar p,
const scalar T,
const scalarField& c
) const
{
return kfwd/max(this->Kc(p, T), VSMALL);
}
```v2306https://develop.openfoam.com/Development/openfoam/-/issues/2703mixedExpr boundary condition not working2023-06-19T21:11:33ZPhilippose RajanmixedExpr boundary condition not working### Summary
Using the **exprMixed** boundary condition in OpenFOAM-v2212 causes the solver to throw up the following error:
```
--> FOAM FATAL IO ERROR: (openfoam-2212)
Entries 'valueExpr' and 'gradientExpr' (mixed-conditon) no...### Summary
Using the **exprMixed** boundary condition in OpenFOAM-v2212 causes the solver to throw up the following error:
```
--> FOAM FATAL IO ERROR: (openfoam-2212)
Entries 'valueExpr' and 'gradientExpr' (mixed-conditon) not found in dictionary "D:/SmallProjects/999_Temp/001_OpenFOAM_Tests /002_exprMixed_Bug_001/0/U.boundaryField.(plateOut_01)"
file: 0/U.boundaryField.(plateOut_01) at line 48 to 58.
From void Foam::expressions::patchExprFieldBase::readExpressions(const Foam::dictionary&, Foam::expressions::patchExprFieldBase::expectedTypes, bool)
in file expressions/fields/base/patchExprFieldBase.C at line 91.
FOAM exiting
```
The same case works as expected without any errors when run using OpenFOAM-v2206.
### Steps to reproduce
<!-- How one can reproduce the issue - this is very important -->
This issue can be reproduced every time, when using the **exprMixed** boundary condition in any of the boundary field files, for example:
```
"(plateOut_01)"
{
type exprMixed;
value $internalField;
variables
(
"qOut{plateIn_01} = -sum(phi)"
"qIn = sum(phi)"
);
valueExpr "(qIn + 0.1*(qOut - qIn))/sum(area())*face()/area()";
fractionExpr "(phi > 0) ? 0 : 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
-->
An example case hat been attached along with this bug report which reproduces the problem when run using OpenFOAM-v2212, but runs fine when using OpenFOAM-v2206
[002_exprMixed_Bug_001.zip](/uploads/cc7cae3c8c93d62ada53d6fcb9b3edb9/002_exprMixed_Bug_001.zip)
### What is the current *bug* behaviour?
<!-- What actually happens -->
The OpenFOAM solver exits with as error while setting up the boundary fields right in the beginning of the solve, before the first iteration has been run.
### What is the expected *correct* behavior?
<!-- What you should see instead -->
If the bug is fixed, the expectation is that the solver goes through the initial boundary field setup and starts the solve iterations, as seen when the case is run using OpenFOAM-v2206.
### 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.
-->
See inserted text in the summary section and example case uploaded along with this issue report.
### 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 : Windows 11 (OpenFOAM native cross-compile)
- Hardware info : -na-
- Compiler : minGW Cross-compile (OpenSUSE)
### 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
-->
There has been a change in the file:
[patchExprFieldBase.C](https://develop.openfoam.com/Development/openfoam/-/blob/cc6ba5c1a04873d902534fcd6167b1a8bed52930/src/finiteVolume/expressions/fields/base/patchExprFieldBase.C#L73)
At the line pointed to by the link, between OpenFOAM-v2206 and OpenFOAM-v2212, which makes both the ***valueExpr*** and ***gradientExpr*** mandatory for the exprMixed boundary condition. In OpenFOAM-v2206, this error was only thrown when both, ***valueExpr*** and ***gradientExpr*** were missing from the definition, but worked if either one of the keywords were present (and when relevant, along with ***fractionExpr***).
The problem can be solved by using an empty string for the ***gradientExpr*** in the patch boundary definition.
Is this an intended change? Using an empty string for an entry which is not required, is not an elegant solution.Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/2702UPtrList iterator does not skip empty entries2023-03-09T10:20:27ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comUPtrList iterator does not skip empty entries### Functionality to add/problem to solve
Looping over an UPtrList:
```
const lduInterfacePtrsList patches(lMesh.interfaces());
for (const auto& pp : patches)
{
Pout<< "Patch:" << pp.type() << endl;
}
```
it do...### Functionality to add/problem to solve
Looping over an UPtrList:
```
const lduInterfacePtrsList patches(lMesh.interfaces());
for (const auto& pp : patches)
{
Pout<< "Patch:" << pp.type() << endl;
}
```
it does not skip the empty entries (from uncoupled patches).
### Target audience
Coders.
### Proposal
Q: what if we want to set the entries so require walking over all.
Attached a little test app.
[Test-lduMeshInterfacesCompilationError.C](/uploads/be94f8ada6f3b72724e44fe3a9106799/Test-lduMeshInterfacesCompilationError.C)Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/2701add-debian-repo.sh is hard coded for amd64 architecture2023-03-16T08:12:59ZBen Kenneyadd-debian-repo.sh is hard coded for amd64 architecture### Functionality to add/problem to solve
Hello, I have been experimenting with installing OpenFOAM2112 on arm cpus. I noticed that the `add-debian-repo.sh` script (https://dl.openfoam.com/add-debian-repo.sh) is hardcoded for amd64 but ...### Functionality to add/problem to solve
Hello, I have been experimenting with installing OpenFOAM2112 on arm cpus. I noticed that the `add-debian-repo.sh` script (https://dl.openfoam.com/add-debian-repo.sh) is hardcoded for amd64 but it could easily be updated to support arm64.
### Target audience
Target audience is anybody who is trying to install OpenFOAM on an ARM cpu (like AWS graviton).
### Proposal
In the `add-debian-repo.sh` script (https://dl.openfoam.com/add-debian-repo.sh), replace the hardcoded `amd64` with `$(dpkg --print-architecture)`
For example, change:
```
echo "### THIS FILE IS AUTOMATICALLY CONFIGURED ###
# You may comment out this entry, but any other modifications may be lost.
deb [arch=amd64] ${repos_url} ${codeName} main" \
> "$apt_source_path"
```
to this
```
echo "### THIS FILE IS AUTOMATICALLY CONFIGURED ###
# You may comment out this entry, but any other modifications may be lost.
deb [arch=$(dpkg --print-architecture)] ${repos_url} ${codeName} main" \
> "$apt_source_path"
```
### What does success look like, and how can we measure that?
After this update, those who are running on an arm architecture will have the correct repository and can easily install OpenFOAM.Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/2700coincidentBaffleInteraction missing from the source code (but present in the ...2024-01-04T09:46:28ZFranz DcoincidentBaffleInteraction missing from the source code (but present in the documentation?)In the files multiInteraction.C and multiInteraction.H, there is some reference to a feature / keyword "coincidentBaffleInteraction". While it is documented, it seems that the feature has not been implemented and the keyword is not worki...In the files multiInteraction.C and multiInteraction.H, there is some reference to a feature / keyword "coincidentBaffleInteraction". While it is documented, it seems that the feature has not been implemented and the keyword is not working.
Seems to be a long-standing issue:
https://bugs.openfoam.org/view.php?id=2939
https://www.cfd-online.com/Forums/openfoam-solving/141571-cyclic-boundary-conditions-particles.htmlAndrew HeatherAndrew Heatherhttps://develop.openfoam.com/Development/openfoam/-/issues/2699Max droplet volume calculation misses a factor of \pi2023-03-22T17:02:47ZKonstantinos MissiosMax droplet volume calculation misses a factor of \piIn the regionSizeDistribution function object
[Here](https://develop.openfoam.com/Development/openfoam/-/blob/master/src/functionObjects/field/regionSizeDistribution/regionSizeDistribution.C#L100),the calculation of the max droplet diam...In the regionSizeDistribution function object
[Here](https://develop.openfoam.com/Development/openfoam/-/blob/master/src/functionObjects/field/regionSizeDistribution/regionSizeDistribution.C#L100),the calculation of the max droplet diameter misses a factor of \pi.
Instead of
`maxDropletVol = 1.0/6.0*pow3(maxDiam_);`
it should be something like
`maxDropletVol = 1.0/6.0*mathematical::pi*pow3(maxDiam_);`Kutalmış BerçinKutalmış Berçinhttps://develop.openfoam.com/Development/openfoam/-/issues/2698jouleHeating and electric contact resistance is delivering wrong results - co...2023-02-03T15:48:26ZAndreas SchützenbergerjouleHeating and electric contact resistance is delivering wrong results - comparison between openFoam, Comsol and theory - turbulentTemperatureRadCoupledMixedThe description of the problem is in the attachted pdf file.
OpenFOAM version : v2212
Operating system : ubuntu
solver: chtMultiRegionSimpleFoam
[bug_jouleheating.pdf](/uploads/ea26a9667581e90cf77eb97d0c20024a/bug_...The description of the problem is in the attachted pdf file.
OpenFOAM version : v2212
Operating system : ubuntu
solver: chtMultiRegionSimpleFoam
[bug_jouleheating.pdf](/uploads/ea26a9667581e90cf77eb97d0c20024a/bug_jouleheating.pdf)[stab_joule.zip](/uploads/5ead128f3cad12a49668f60893c7c7d6/stab_joule.zip)https://develop.openfoam.com/Development/openfoam/-/issues/2697solverInfo function object: U_converged flag is always false2023-02-03T09:05:03Zs1291solverInfo function object: U_converged flag is always falseHello,
I have used the `solverInfo` function object in many examples, including the official tutorials, such as `$FOAM_TUTORIALS/tutorials/compressible/rhoSimpleFoam/aerofoilNACA0012`. Even though the linear solvers for velocity converg...Hello,
I have used the `solverInfo` function object in many examples, including the official tutorials, such as `$FOAM_TUTORIALS/tutorials/compressible/rhoSimpleFoam/aerofoilNACA0012`. Even though the linear solvers for velocity converge, the `U_converged` flag is always `false`.
Attached is an example of `solverInfo` log file.
Could you please confirm if this is a bug within the function object itself? or am I missing something?
[solverInfo.dat](/uploads/59596761e8a22e6160833c3f4a14039d/solverInfo.dat)https://develop.openfoam.com/Development/openfoam/-/issues/2696vtkWrite ignoring "excludeFields"2023-02-16T07:04:46ZMark OLESENvtkWrite ignoring "excludeFields"Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/2695Links in snappyHexMesh section in online userguide not working2023-03-14T17:10:27ZJohan RoenbyLinks in snappyHexMesh section in online userguide not workingGo here:
https://www.openfoam.com/documentation/user-guide/4-mesh-generation-and-conversion#x14-570004.4.7
and try to click "4.4 Mesh generation with the snappyHexMesh utility" or any of its subsections.
I tried in Chrome and Firefox ...Go here:
https://www.openfoam.com/documentation/user-guide/4-mesh-generation-and-conversion#x14-570004.4.7
and try to click "4.4 Mesh generation with the snappyHexMesh utility" or any of its subsections.
I tried in Chrome and Firefox where nothing happens when I click the links.https://develop.openfoam.com/Development/openfoam/-/issues/2694Sourcecode Links in Extended Code Guide (API Guide) are broken2023-02-03T09:05:21ZFranz DSourcecode Links in Extended Code Guide (API Guide) are brokenFor example on this page: https://www.openfoam.com/documentation/guides/latest/api/classFoam_1_1functionObjects_1_1filmFlux.html#details
In the "detailed description" section, in the Source Files box, there are two links given to this r...For example on this page: https://www.openfoam.com/documentation/guides/latest/api/classFoam_1_1functionObjects_1_1filmFlux.html#details
In the "detailed description" section, in the Source Files box, there are two links given to this repo:
![image](/uploads/8cbbbdf92d8a673c133d33038b72325f/image.png)
This is actually where it links (and 404s) `https://develop.openfoam.com/Development/OpenFOAM-plus/blob/OpenFOAM-v2112/src/regionModels/surfaceFilmModels/functionObjects/filmFlux/filmFlux.H`
This is happening for all links to the Repo that I have tried.https://develop.openfoam.com/Development/openfoam/-/issues/2693cyclicAMI with transformations not supported for wall distance2023-06-26T10:33:39ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comcyclicAMI with transformations not supported for wall distance<!--
*** 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 -->
Wall distance uses internally the FaceCellWave class. This operates on cyclicAMI on a slice of the face-based data, i.e. it modifies in-place the face-based data. This means that when the neighbour patch gets evaluated it operates on the modified data and this gives problems.
- only with cyclicAMI, cyclic is ok
- only if transformations are applied
### Steps to reproduce
<!-- How one can reproduce the issue - this is very important -->
Below case is a hack of the pipeCyclic tutorial. It puts additional walls inside the domain (see ./Allrun script). Run `checkMesh -writeFields '(wallDistance)'` to trigger wall distance evaluation. It will give an error about same transformation applied with different signs.
### Example case
[pipeCyclic_with_baffles.tgz](/uploads/e0ec13f06a6ea24bb889bce4f9e0540c/pipeCyclic_with_baffles.tgz)
<!--
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 -->
Error inside globalIndexAndTransform.
### 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 :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
-->Mattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comhttps://develop.openfoam.com/Development/openfoam/-/issues/2692Patch buckling using velocityLaplacian motionSolver on specified patches2023-01-31T20:21:30ZManuel ZeitlerPatch buckling using velocityLaplacian motionSolver on specified patches<!--
*** 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
If a rotating motion is enforced on only a few patches (not the whole object; used to "grow" the object during the simulation) using the motionSolver velocityLaplacian, some patches start to buckle in on themselves.
### Steps to reproduce
My test case can be found here: https://github.com/ZeitM/SurfaceBuckling
>There are also 2 png-files included, showing the problem
1. Clone the given repository
2. Execute using overInterDyMFoam
3. inspect the results in paraview (area of interest: the 2ircleSections defined as arc...)
### What is the current *bug* behaviour?
After a few timesteps the moving patches start to buckle in on themselves, resulting in a very jagged geometry. (Important: The problem is considered only if the patches buckle in on themselves, not if the mesh/geometry bends between two patches)
### What is the expected *correct* behavior?
It is expected that the patches don't buckle in on themselves and stay "straight"/stay as one flat plane.
### Environment information
OpenFOAM version : v2206https://develop.openfoam.com/Development/openfoam/-/issues/2691expressions support for patch face normals2023-02-05T10:56:22ZMark OLESENexpressions support for patch face normals- seems to be frequently needed: provide as `normal()`- seems to be frequently needed: provide as `normal()`Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/2690contactAngle BC in contactAngleCavity tutorial is not working as expected2023-06-13T11:42:29ZIason TsiapkiniscontactAngle BC in contactAngleCavity tutorial is not working as expected<!--
*** 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
In the tutorial case contactAngleCavity, the free surface of a cavity is simulated with the `interfaceTrackingFvMesh` library. In the simulation a contact angle of 70° is set at the walls via the file `0.orig/contactAngle`. The contact angle after running the tutorial, however, is ~80°.
### Steps to reproduce
1. Copy the case `$FOAM_TUTORIALS/incompressible/pimpleFoam/laminar/contactAngleCavity`
2. Add the following function objects for post-processing (this writes out the first two and last two points on the free surface):
```
pointHistoryLeft1
{
type pointHistory;
refHistoryPoint (0 0.01 0);
fileName leftPoint.txt;
}
pointHistoryLeft2
{
type pointHistory;
refHistoryPoint (0.00025 0.01 0);
fileName leftPointRef.txt;
}
pointHistoryRight1
{
type pointHistory;
refHistoryPoint (0.01 0.01 0);
fileName rightPoint.txt;
}
pointHistoryRight2
{
type pointHistory;
refHistoryPoint (0.00975 0.01 0);
fileName rightPointRef.txt;
}
```
3. Calculate the angle between the first two and the last two points respectively. This can be done by running the accompanied script `postProcessing.py` inside the simulation directory.
### Example case
<!--
If possible, please create a SMALL example and attach it to your report
If you are using an older version of OpenFOAM this will also determine
whether the bug has been fixed in a more recent version
-->
I attached the tutorial case with slight modifications in the `functionObjects`, together with the post-processing script.
Run the case using the `Allrun` script.
[contactAngleCavity.tar](/uploads/2bee417aad9c1e7704685b1632fd4804/contactAngleCavity.tar)
### What is the current *bug* behaviour?
The contact angle at the specified locations is not equal to the set contact angle.
### What is the expected *correct* behavior?
The contact angle should be 70°, as specified in `0.orig/contactAngle`.
### 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.
-->
The Figure below shows the calculated angle between the first two and the last two mesh points. Note that the angle does not change with a longer run time. The tutorial runs only for 0.2s.
![contactAngle](/uploads/d64c2e7a4cbb976a264e470ab9c7a47b/contactAngle.png)
### Environment information
<!--
Providing details of your set-up can help us identify any issues, e.g.
OpenFOAM version : v2212
Operating system : ubuntu docker container on windows
Hardware info : any info that may help?
Compiler : gcc|intel|clang etc
-->
OpenFOAM version : v2212
Operating system : ubuntu docker container on windows
### 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
-->
The calculations regarding the contact angle can be found in the file
```$FOAM_SRC/dynamicFaMesh/interfaceTrackingFvMesh/freeSurfacePointDisplacement.C```
in lines 120-197. In this approach, the vector `N` is rotated by the value of `contactAngle` at the specified boundaries. The `patchMirrorPoints` at this boundary are then moved using (line 225f.):
```
patchMirrorPoints[patchI] =
peCentres + ((I - 2*N*N)&delta);
```
Maybe the innermost `controlPoints` have to be moved as well to satisfy the contact angle.https://develop.openfoam.com/Development/openfoam/-/issues/2688mappedPatchBase is not updated if for topochange after commit 945405c32dca568...2023-02-08T02:40:51ZDarrin StephensmappedPatchBase is not updated if for topochange after commit 945405c32dca5682827356d29fa5557abb3d88d8### Summary
After a recent commit (945405c32dca5682827356d29fa5557abb3d88d8) mappedPatchBase isn't recalculating the map after a topological change to the mesh.
### Steps to reproduce
I'm using the chtMultiRegionDyMFoam solver and libra...### Summary
After a recent commit (945405c32dca5682827356d29fa5557abb3d88d8) mappedPatchBase isn't recalculating the map after a topological change to the mesh.
### Steps to reproduce
I'm using the chtMultiRegionDyMFoam solver and library from https://develop.openfoam.com/Henning86, although it has been updated to work with V2212.
My fork of this can be found here https://github.com/darrinl2t/multiDimAMR/tree/v2212
1. Clone the repository given above.
2. Source OF-v2212
3. Execute the Allwmake script from the multiDimAMR repository
4. Run the heatedRoom tutorial. This will crash at 0.8s when the mesh is changed.
### Example case
An example case is heatedRoom tutorial in the repository link provided above.
### What is the current *bug* behaviour?
The solver crashes after the mesh has been changed. I have isolated this to the Foam::mappedPatchBase::upToDate() function in mappedPatchBaseI.H not returning false after the sampleMesh has been changed.
### What is the expected *correct* behavior?
The expected behaviour is the solver should run. To confirm this checkout commit 013f3cccc41a25b12eb13b32e5e07c09bb3cac3c from the OpenFOAM repository, this is the commit before the changes to mappPatchase. Compile with this commit and recompile the multDimAMR library and solver.
Run the tutorial with the code at this commit, the solver will run fine and the mesh will be adapted to the fluid temperature as expected.
### Environment information
OpenFOAM version : v2212
### Possible fixes
I don't have a fix for this. What I have determined is that after the fluid side mesh has been changed its eventNo() isn't updated, so the test sampleMesh().upToDatePoints(updateSampleMeshTime() returns True when it should be false.https://develop.openfoam.com/Development/openfoam/-/issues/2687Inconsistency in ATCModel treatment2023-05-30T17:05:36ZMartin WertherInconsistency in ATCModel treatment<!--
*** 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 comparing sensitivity maps obtained with "globally" cancelling the ATC term (ATCModel cancel) to 'standard' formulation with wall-near zeroing operating on both parameters, extraConvection and nSmooth, it was seen that results differ more and more from 'cancel' with increasing values for masking. One would assume the opposite since propagating the masking towards the interior of the domain comes close to cancelling globally.
### Steps to reproduce
<!-- How one can reproduce the issue - this is very important -->
Simply compare results obtained with 'cancel' option to
- ATCModel {ATCModel standard; zeroATCPatchTypes (wall patch); extraConvection n; nSmooth n; }
- ATCModel {ATCModel standard; zeroATCPatchTypes (wall patch); extraConvection n; nSmooth n+10; }
- ATCModel {ATCModel standard; zeroATCPatchTypes (wall patch); extraConvection n; nSmooth n*100; }
e.g., n = 7.
<!-- ### 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 -->
The current implementation
extraConvection * (adjointConvection - mask * altDiscrAdjointConvection)
leads to an unmatched extraConvection*adjointConvection term in the cells affected by the mask.
### What is the expected *correct* behavior?
<!-- What you should see instead -->
@vaggelisp already proposed patching to
extraConvection * mask * (adjointConvection - altDiscrAdjointConvection)
to ensure consistency in the difference causing the aimed for numerical dissipation.
<!-- ### 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 :
- Operating system :
- Hardware info :
- Compiler :
-->
<!-- ### Possible fixes -->
<!--
If you can, link to the line of code that might be responsible for the
problem
The "/label ~bug" text is a gitlab flag that will add the "bug" label to this
issue
-->https://develop.openfoam.com/Development/openfoam/-/issues/2686Improve length calculation of a spline2023-02-11T18:51:20ZGuanyang XueImprove length calculation of a spline### Functionality to add/problem to solve
Improve the length calculation of a spline. Currently it's using a simple 5-point Gauss-Legendre quadrature without tolerance control.
This is a follow-up of https://develop.openfoam.com/Develo...### Functionality to add/problem to solve
Improve the length calculation of a spline. Currently it's using a simple 5-point Gauss-Legendre quadrature without tolerance control.
This is a follow-up of https://develop.openfoam.com/Development/openfoam/-/issues/1983
### Target audience
Extruding mesh with a spline.
### Proposal
Change the current code to Gauss–Kronrod quadrature with tolerance control.
The algorithm is available in boost library. However to make it independent, it's better to implement the code within [CatmullRomSpline.C](https://develop.openfoam.com/Development/openfoam/-/blob/master/src/mesh/blockMesh/blockEdges/splineEdge/CatmullRomSpline.C).
I can try to implement a very basic code then you change details to meet your c++ requirements.
Also I would like to implement the length for B-spline as it will be similar. For Bezier I don't have any good idea.
### What does success look like, and how can we measure that?
With tolerance control the curve length can be accurately estimated, so the extruded mesh will be smoother.
### Links / references
https://en.wikipedia.org/wiki/Gauss–Kronrod_quadrature_formula
https://www.boost.org/doc/libs/1_67_0/libs/math/doc/html/math_toolkit/gauss_kronrod.html
### Funding
(Does the functionality already exist/is sponsorship available?)https://develop.openfoam.com/Development/openfoam/-/issues/2685Wrong flux with externalWallHeatFluxTemperature2023-01-30T15:51:54ZRémi BoninWrong flux with externalWallHeatFluxTemperature<!--
*** Please read this first! ***
Before opening a new issue, make sure to search for keywords in the issues
filtered by the "bug" label and check to see if it has already been reported
You can see how your report will be re...<!--
*** Please read this first! ***
Before opening a new issue, make sure to search for keywords in the issues
filtered by the "bug" label and check to see if it has already been reported
You can see how your report will be rendered on the platform by using the
"preview" tab above
-->
<!--
All text between these markers are comments and will not be present in the
report
-->
### Summary
When using the boundary condition _externalWallHeatFluxTemperature_ in _coefficient_ mode and with _thicknessLayers_, _kappaLayers_ and _emissivity_ different from 0, the computed flux is wrong.
### Steps to reproduce
1. Mesh a solid square
2. Left wall and right wall both using _externalWallHeatFluxTemperature_ in _coefficient_ mode with the same _Ta_, same _h_ and _emissivity_ at 0.9 for both.
3. On the right wall, add one _thicknessLayers_ at 0.1 and _kappaLayers_ at 1
3. Top and bottom walls using _zeroGradient_
4. Run the case with _chtMultiRegionSimpleFoam_ (_laplacianFoam_ does not accept _externalWallHeatFluxTemperature_, so you have to manipulate the mesh files a little bit, or you can set up a fluid simulation instead with buoyantSimpleFoam, the same behavior appears).
5. Check the heat flux at both boundaries
### Example case
[case_report.zip](/uploads/a7020df1d2405effedd353c50cbb8d19/case_report.zip)
### What is the current *bug* behaviour?
The heat flux converges to around 2000 W
### What is the expected *correct* behavior?
The heat flux should converge towards 0 W
### 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 : Windows 10
- Hardware info : 28 cores / 128 GB
- Compiler : -
### Possible fixes
<!--
If you can, link to the line of code that might be responsible for the
problem
The "/label ~bug" text is a gitlab flag that will add the "bug" label to this
issue
-->https://develop.openfoam.com/Development/ThirdParty-common/-/issues/66When I compile ADIOS2 using makeAdios script and the dev tool set from CENTOS...2023-01-27T11:19:57ZJuan Díaz GonzálezWhen I compile ADIOS2 using makeAdios script and the dev tool set from CENTOS in CENTOS I am get in an errorWhen I compile ADIOS2 using makeAdios script and the dev tool set from CENTOS in CENTOS I am get in an error.
The error that I have is this:
`[ 46%] Building C object testing/utils/cwriter/CMakeFiles/Test.Utils.CWriter.dir/TestUtilsCWri...When I compile ADIOS2 using makeAdios script and the dev tool set from CENTOS in CENTOS I am get in an error.
The error that I have is this:
`[ 46%] Building C object testing/utils/cwriter/CMakeFiles/Test.Utils.CWriter.dir/TestUtilsCWriter.c.o`
[ 46%] Building C object testing/adios2/performance/manyvars/CMakeFiles/PerfManyVars.dir/PerfManyVars.c.o`
[ 46%] Linking C executable ../../../bin/Test.Utils.CWriter`
[ 46%] Linking C executable ../../../../bin/PerfManyVars`
`/opt/rh/devtoolset-8/root/usr/libexec/gcc/x86_64-redhat-linux/8/ld: /opt/rh/devtoolset-8/root/usr/lib/gcc/x86_64-redhat-linux/8//libstdc++_nonshared.a(functexcept48.o): undefined reference to symbol '__cxa_free_exception@@CXXABI_1.3'`
`/usr/lib64/libstdc++.so.6: error adding symbols: DSO missing from command line`
`make[2]: *** [testing/utils/cwriter/CMakeFiles/Test.Utils.CWriter.dir/build.make:99: bin/Test.Utils.CWriter] Error 1`
`make[1]: *** [CMakeFiles/Makefile2:8571: testing/utils/cwriter/CMakeFiles/Test.Utils.CWriter.dir/all] Error 2`
`make[1]: *** Waiting for unfinished jobs....`
`/opt/rh/devtoolset-8/root/usr/libexec/gcc/x86_64-redhat-linux/8/ld: /opt/rh/devtoolset-8/root/usr/lib/gcc/x86_64-`redhat-linux/8//libstdc++_nonshared.a(functexcept48.o): undefined reference to symbol '__cxa_free_exception@@CXXABI_1.3'`
`/usr/lib64/libstdc++.so.6: error adding symbols: DSO missing from command line`
make[2]: *** [testing/adios2/performance/manyvars/CMakeFiles/PerfManyVars.dir/build.make:99: bin/PerfManyVars] `Error 1`
`make[1]: *** [CMakeFiles/Makefile2:8253: testing/adios2/performance/manyvars/CMakeFiles/PerfManyVars.dir/all] Error 2`
`[ 46%] Linking CXX executable ../../bin/adios2_reorganize_mpi`
`[ 46%] Built target adios_reorganize_mpi`
`[ 46%] Linking CXX executable ../../bin/bpls`
`[ 46%] Built target bpls`
`[ 46%] Linking CXX shared library ../../lib64/libadios2_cxx11.so`
`[ 46%] Built target adios2_cxx11`
`make: *** [Makefile:146: all] Error 2`
`Error building: ADIOS2-2.8.3`