Development issueshttps://develop.openfoam.com/groups/Development/-/issues2023-12-29T11:28:04Zhttps://develop.openfoam.com/Development/openfoam/-/issues/2716OpenFOAM-v1912 with ParaView-5.10.1 with error: Cannot use ParaView reader mo...2023-12-29T11:28:04ZC SOpenFOAM-v1912 with ParaView-5.10.1 with error: Cannot use ParaView reader module library (PVFoamReader) The PV_PLUGIN_PATH environment value is not setI've installed **OpenFOAM-v1912** in Linux desktop environment with **ParaView version 5.10.1** along with **Aerosolved library**.
I tried to test run the cavity tutorial from foam, but failed with errors shown as:
**Cannot use ParaView...I've installed **OpenFOAM-v1912** in Linux desktop environment with **ParaView version 5.10.1** along with **Aerosolved library**.
I tried to test run the cavity tutorial from foam, but failed with errors shown as:
**Cannot use ParaView reader module library (PVFoamReader)
The PV_PLUGIN_PATH environment value is not set**
May I know why?
The steps were entering directory cavity in $FOAM_RUN directory,
then blockMesh
then paraFoam &
and the errors popped up as shown in the figure below.
![image](/uploads/c6e56bf1fd00085b0683395e74284865/image.png)
It does linking to the ParaView, but with no figure there.
![image](/uploads/51211298e86de260f628f46aa45a09b9/image.png)
May I know where I did wrongly? Please correct me.
Thank you in advanced.
Regards,
Cindyhttps://develop.openfoam.com/Development/openfoam/-/issues/2715Improved point-cell and cell-point topology methods2023-03-05T09:57:06ZMark OLESENImproved point-cell and cell-point topology methodsOptimization potential when building cell/point and point/cell connectivity. !596Optimization potential when building cell/point and point/cell connectivity. !596https://develop.openfoam.com/Development/openfoam/-/issues/2714compilation changes for gcc-13 and/or c++17/20 etc2023-03-05T09:56:24ZMark OLESENcompilation changes for gcc-13 and/or c++17/20 etccross-refs
- https://bugzilla.redhat.com/show_bug.cgi?id=1816301
- https://gcc.gnu.org/gcc-13/porting_to.htmlcross-refs
- https://bugzilla.redhat.com/show_bug.cgi?id=1816301
- https://gcc.gnu.org/gcc-13/porting_to.htmlMark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/2712Add thousand separators to meshing utility output2023-02-28T23:15:09ZGuanyang XueAdd thousand separators to meshing utility output### Functionality to add/problem to solve
Adding thousand separators to the output so it's easier for human to read long integers.
### Target audience
All meshing utilities (and probably some other applications)
### Proposal
Add s...### Functionality to add/problem to solve
Adding thousand separators to the output so it's easier for human to read long integers.
### Target audience
All meshing utilities (and probably some other applications)
### Proposal
Add some code to `messageStream` when printing integers
### What does success look like, and how can we measure that?
For example the current output of `blockMesh` is like
```
Mesh Information
----------------
boundingBox: (0 -0.0005 0) (0.012 0.0005 5e-05)
nPoints: 4911759
nCells: 4729600
nFaces: 14369360
nInternalFaces: 14008240
----------------
```
Adding thousand separators to integers will make it much easier to read.
```
Mesh Information
----------------
boundingBox: (0 -0.0005 0) (0.012 0.0005 5e-05)
nPoints: 4,911,759
nCells: 4,729,600
nFaces: 14,369,360
nInternalFaces: 14,008,240
----------------
```
### Links / references
You don't need to write any code to parse numbers. C++ has built-in functions to do that.
https://cplusplus.com/reference/locale/numpunct/https://develop.openfoam.com/Development/openfoam/-/issues/2710GAMG + processorAgglomeration + interpolateCorrection fails2024-01-08T11:02:44ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comGAMG + processorAgglomeration + interpolateCorrection fails<!--
*** 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 -->
Divide by zero when
- GAMG
- processorAgglomerator masterCoarsests;
- interpolateCorrection true;
### Steps to reproduce
<!-- How one can reproduce the issue - this is very important -->
Any parallel case using GAMG. E.g. `pitzDaily` tutorial.
### What is the current *bug* behaviour?
<!-- What actually happens -->
Sigfpe since coarseLevel correction is not sent across when processor agglomerating. Instead the coarse-level correction stays zero for the missing/remote elements. This causes a divide by zero when normalising.
### What is the expected *correct* behavior?
<!-- What you should see instead -->
No failure.
### 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
-->
Avoid accessing coarse-level when interpolating correction. Or send across coarse-level correction.Mattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comhttps://develop.openfoam.com/Development/openfoam/-/issues/2709[Feature request] Macro expansion: Access keywords from separate files2024-01-10T16:36:52Zs1291[Feature request] Macro expansion: Access keywords from separate filesHello,
If I am not mistaken, It appears that OpenFOAM ESI versions do not provide a way to access external keywords from separate files.
OpenFOAM 9 and newer versions allow accessing keywords from separate files with the following synt...Hello,
If I am not mistaken, It appears that OpenFOAM ESI versions do not provide a way to access external keywords from separate files.
OpenFOAM 9 and newer versions allow accessing keywords from separate files with the following syntax:
```
aValue $FOAM_CASE/otherFile!foo;
```
`aValue` will have the value of `$foo` from the file `otherFile` within the case.
My workaround is to use a temporary dictionary with include to access the external keyword, e.g:
```
temp_dict
{
#include "otherFile"
}
aValue $temp_dict/foo;
#remove temp_dict
```
Is this feature already available that I am not aware of?
Thank youhttps://develop.openfoam.com/Development/openfoam/-/issues/2708Wrong equation of volume of injectedParticleInjection model and injectedParti...2023-06-12T14:31:12ZJunichi MukaiWrong equation of volume of injectedParticleInjection model and injectedParticleDistributionInjection model### Summary
The correct coefficient would be 1/6, not 1/16.
[InjectedParticleInjection.C](https://develop.openfoam.com/Development/openfoam/-/blob/master/src/lagrangian/intermediate/submodels/Kinematic/InjectionModel/InjectedParticleIn...### Summary
The correct coefficient would be 1/6, not 1/16.
[InjectedParticleInjection.C](https://develop.openfoam.com/Development/openfoam/-/blob/master/src/lagrangian/intermediate/submodels/Kinematic/InjectionModel/InjectedParticleInjection/InjectedParticleInjection.C#:~:text=scalar%20vol%20%3D%20pow3(diameter_%5Bi%5D)*mathematical%3A%3Api/16.0%3B)
[InjectedParticleDistributionInjection.C](https://develop.openfoam.com/Development/openfoam/-/blob/master/src/lagrangian/intermediate/submodels/Kinematic/InjectionModel/InjectedParticleDistributionInjection/InjectedParticleDistributionInjection.C#:~:text=const%20scalar%20volume%20%3D%20sumPow3*mathematical%3A%3Api/16.0%3B)v2306https://develop.openfoam.com/Development/openfoam/-/issues/2706globalIndex gather fails with multi-world2023-02-22T10:17:23ZMark OLESENglobalIndex gather fails with multi-worldAs noted in discussions with @andy - the globalIndex gather uses procIDs, but these are the subranks (in the parent), not the actual ranks for the communicator.
@MattijsAs noted in discussions with @andy - the globalIndex gather uses procIDs, but these are the subranks (in the parent), not the actual ranks for the communicator.
@MattijsMark OLESENMark OLESENhttps://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/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/2696vtkWrite ignoring "excludeFields"2023-02-16T07:04:46ZMark OLESENvtkWrite ignoring "excludeFields"Mark OLESENMark OLESENhttps://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/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/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/2683(more) parallel consistency issues with finiteArea2023-02-22T08:29:36ZMark OLESEN(more) parallel consistency issues with finiteAreaAs noted in EP2074 by Jiri and @kuti.As noted in EP2074 by Jiri and @kuti.https://develop.openfoam.com/Development/openfoam/-/issues/2681model cofficients not read2023-02-14T13:00:13ZMark OLESENmodel cofficients not readMark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/2679Bug in limitVelocity with latest release v2212 - Uname_ not set if keyword U ...2023-02-14T13:00:13ZTobias HolzmannBug in limitVelocity with latest release v2212 - Uname_ not set if keyword U is not specified<!--
*** 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
Hey everybody,
just found a bug in the limitVelocity fvOptions introduced with the commit https://develop.openfoam.com/Development/openfoam/-/commit/48f86809419c2e14883f9390fba4d7f3f95ffe72 by @kuti specifically by removing this line https://develop.openfoam.com/Development/openfoam/-/commit/48f86809419c2e14883f9390fba4d7f3f95ffe72#0ed39fecc176429fc7e14900a867f502ffca27ff_56_73
In the new version, if we don´t specify the U entry, the UName_ variable is not set and we get an warning:
--> FOAM Warning :
From virtual void Foam::fv::option::checkApplied() const
in file cfdTools/general/fvOptions/fvOption.C at line 137
Source limitVelocity defined for field but never used
https://develop.openfoam.com/Development/openfoam/-/blob/master/src/fvOptions/corrections/limitVelocity/limitVelocity.C#L91
### What is the expected *correct* behavior?
Default initialisation for UName_ with "U".
### 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 :
### Possible fixes
Given above.
Thanks, TobiKutalmış BerçinKutalmış Berçin