Development issueshttps://develop.openfoam.com/groups/Development/-/issues2020-12-11T17:39:02Zhttps://develop.openfoam.com/Development/openfoam/-/issues/1949BUG: globalSum needed in the directional derivative of the merit function2020-12-11T17:39:02ZVaggelis PapoutsisBUG: globalSum needed in the directional derivative of the merit function### Summary
When the derivative of the merit function is computed the global (instead of the local) sum of the objective derivative and the correction should be calculated.
This bug does not actually affect the current functionality o...### Summary
When the derivative of the merit function is computed the global (instead of the local) sum of the objective derivative and the correction should be calculated.
This bug does not actually affect the current functionality of the code since, with volumetric B-Splines, all design variables (and their derivatives and corrections) are known by all processors. It will, however, affect cases in which the design variables are distributed, like topology optimisation or when considering the movement of each boundary point as a design variable in shape optimisation.v2012Andrew HeatherAndrew Heatherhttps://develop.openfoam.com/Development/openfoam/-/issues/8BUG: graphics (runTimePostProcessing) compilation issue2023-08-19T21:13:19ZPrashant SonakarBUG: graphics (runTimePostProcessing) compilation issueDevelop branch fails to compile runTimePostprocessing.
/home/alex2/prashant/OpenFOAM/OpenFOAM-dev-OpenCFD.develop/log.allwmake_25Nov_IST0955
(line 5763)
@andy @Mattijs Develop branch fails to compile runTimePostprocessing.
/home/alex2/prashant/OpenFOAM/OpenFOAM-dev-OpenCFD.develop/log.allwmake_25Nov_IST0955
(line 5763)
@andy @Mattijs Functionality migration from internal development lineAdminAdminhttps://develop.openfoam.com/Development/openfoam/-/issues/190BUG: icorrect mapping for processor patch2016-12-23T12:44:52ZPrashant SonakarBUG: icorrect mapping for processor patchAttached case replicating the issue [cavityMappingTest.tgz](/uploads/178c05d27197c3a247e02bce402c6943/cavityMappingTest.tgz)
```
procBoundary0to1
{
type processor;
value nonuniform List<s...Attached case replicating the issue [cavityMappingTest.tgz](/uploads/178c05d27197c3a247e02bce402c6943/cavityMappingTest.tgz)
```
procBoundary0to1
{
type processor;
value nonuniform List<scalar> 5(9.95865e-317 -nan -nan -nan -nan);
}
```
Issue was not observed for vector field mapping in tutorial.
Version v1612AdminAdminhttps://develop.openfoam.com/Development/openfoam/-/issues/2360Bug in activePressureForceBaffleVelocity boundary condition2022-05-06T10:02:50ZTobias HolzmannBug in activePressureForceBaffleVelocity boundary condition<!--
*** 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
The activePressureForceBaffleVelocity boundary condition calculates the pressure difference between the two blocked cyclic patches in a wrong matter if we use a NONE forced-based approach because the weighting area is wrong. The set-up for such a boundary condition is as follows:
- two cyclic patches
- duplicate the two cyclic patches and merged them together to get one patch -> blocking wall
In the updateCoeffs function of the activePressureForceBaffleVelocity condition, we first calculate the force at the cyclic (master) patch and subtract the force at the cyclic (slave) patch. This force difference gets divided by the patch area which is the wall-patch (the wall patch has the master and slave area; so it's double as large as a single cyclic patch). The result is, the BC condition does not open at the user-defined threshold but rather when we reached the doubled delta value.
I found this issue a while ago while creating this case: https://holzmann-cfd.com/community/training-cases/tank-with-safety-valve
; same behavior for the OpenFOAM tutorial: $FOAM_TUTORIALS/combustion/PDRFoam/flamePropagationWithObstacles
<!-- Summarize the bug encountered concisely -->
### Steps to reproduce
Download either the case I provided on my website or use the tutorial case and check the output of the log -> activation is not given within the specified threshold.
<!-- How one can reproduce the issue - this is very important -->
### Example case
https://holzmann-cfd.com/community/training-cases/tank-with-safety-valve
$FOAM_TUTORIALS/combustion/PDRFoam/flamePropagationWithObstacles
<!--
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?
Wrong area (division) is used in the calculation of the dp calculation and hence, the BC condition does not switch its behavior when we reach the user-defined threshold.
<!-- What actually happens -->
### What is the expected *correct* behavior?
The condition should switch its behavior after the user-defined threshold is reached.
<!-- 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 : v2112|v2106|v2012|v2006|v1912|v1906 etc
Operating system : ubuntu|openSUSE|centos etc
Hardware info : any info that may help?
Compiler : gcc|intel|clang etc
-->
- OpenFOAM version : v2106 and v2112
- Operating system : Ubuntu 21.04
- Hardware info : Not relevant
- Compiler : Not relevant
### Possible fixes
Correct the used area for NONE forced-based calculations.
Patch attached - additionally I added some more information to the output (for transparency reasons)
Code line which is wrong: https://develop.openfoam.com/Development/openfoam/-/blob/master/src/finiteVolume/fields/fvPatchFields/derived/activePressureForceBaffleVelocity/activePressureForceBaffleVelocityFvPatchVectorField.C#L278
<!--
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
-->
[0001-BUG-activePressureForceBaffleVelocity-wrong-area-in-.patch](/uploads/68fae4aa17583ff777cd90fb8e46cc73/0001-BUG-activePressureForceBaffleVelocity-wrong-area-in-.patch)Kutalmış BerçinKutalmış Berçinhttps://develop.openfoam.com/Development/openfoam/-/issues/2343bug in atmPlantCanopyUSource2022-05-06T10:02:08ZNima Samkhanianibug in atmPlantCanopyUSourceThe current explicit implementation of source term leads to numerical divergence,
writing the source terms in the implicit format will solve the issue, a new implementation of the source term with a sample test case is attached
[atmPlan...The current explicit implementation of source term leads to numerical divergence,
writing the source terms in the implicit format will solve the issue, a new implementation of the source term with a sample test case is attached
[atmPlantCanopyUSource.zip](/uploads/5c992f90db1fe1542d8cca08aed19d22/atmPlantCanopyUSource.zip)
[test-case.zip](/uploads/8c9bfe352a0ca89c64f37a007f8fdc4d/test-case.zip)Kutalmış BerçinKutalmış Berçinhttps://develop.openfoam.com/Development/openfoam/-/issues/7[BUG]: incompatible files (motorBike case)2023-08-19T21:13:19ZPrashant Sonakar[BUG]: incompatible files (motorBike case)Tried dev-OpenCFD.develop files into dev.master, but even after few manual changes, case fails.
/home/alex2/prashant/QA/MD2014/motorBike-dev.master_files-From-dev-OpenCFD
@andy @Mattijs Tried dev-OpenCFD.develop files into dev.master, but even after few manual changes, case fails.
/home/alex2/prashant/QA/MD2014/motorBike-dev.master_files-From-dev-OpenCFD
@andy @Mattijs Functionality migration from internal development lineAdminAdminhttps://develop.openfoam.com/Development/openfoam/-/issues/365BUG: inconsistency in fvOptions ->directionalPressureGradientExplicitSource2018-05-29T05:39:49ZPrashant SonakarBUG: inconsistency in fvOptions ->directionalPressureGradientExplicitSourceIt still refers to old *Name* style?
```
keyword fieldNames is undefined
```
@SergioIt still refers to old *Name* style?
```
keyword fieldNames is undefined
```
@SergioAdminAdminhttps://develop.openfoam.com/Development/openfoam/-/issues/124BUG: inconsistent argument specification- surface* utilities2016-06-13T12:19:12ZPrashant SonakarBUG: inconsistent argument specification- surface* utilitiesThe input argument specification, specifically triSurface geometry is inconsistent
```
surfaceAdd constant/triSurface/a.stl constant/triSurface/b.stl
surfaceBooleanFeatures union a.stl b.stl
```
@Mattijs The input argument specification, specifically triSurface geometry is inconsistent
```
surfaceAdd constant/triSurface/a.stl constant/triSurface/b.stl
surfaceBooleanFeatures union a.stl b.stl
```
@Mattijs AdminAdminhttps://develop.openfoam.com/Development/openfoam/-/issues/119BUG: inconsistent configuation files in develop branch2016-11-24T07:34:55ZPrashant SonakarBUG: inconsistent configuation files in develop branchSome setup configuration files are missing in etc/config.csh
e.g. scotch
@Mattijs Some setup configuration files are missing in etc/config.csh
e.g. scotch
@Mattijs AdminAdminhttps://develop.openfoam.com/Development/openfoam/-/issues/349BUG: Inconsistent library name in Header files2018-05-29T05:39:48ZPrashant SonakarBUG: Inconsistent library name in Header filesFollowing FO should have libfieldFunctionObjects.so in respective documentation header files.
- DESModelRegions/DESModelRegions.H
- PecletNo/PecletNo.H
- Q/Q.H
- vorticity/vorticity.H
- yPlus/yPlus.H
Similarly perhaps following also nee...Following FO should have libfieldFunctionObjects.so in respective documentation header files.
- DESModelRegions/DESModelRegions.H
- PecletNo/PecletNo.H
- Q/Q.H
- vorticity/vorticity.H
- yPlus/yPlus.H
Similarly perhaps following also need update
- src/functionObjects/lagrangian/cloudInfo/postProcessingDict
@andyVersion v1612Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/49BUG: inconsistent result for Third-party test case (DEShybrid)2016-01-08T12:41:03ZPrashant SonakarBUG: inconsistent result for Third-party test case (DEShybrid)- blending factor seems to behave differently for processor boundries
![img1](/uploads/73230aaf7101ae18a2291cafa7b8d7c8/img1.jpg)
- reconfirm the blending factor calculation (seem to show some differences)
![img2](/uploads/69bb743...- blending factor seems to behave differently for processor boundries
![img1](/uploads/73230aaf7101ae18a2291cafa7b8d7c8/img1.jpg)
- reconfirm the blending factor calculation (seem to show some differences)
![img2](/uploads/69bb7432c31f58403412bc62e931c545/img2.jpg)
@Sergio @Mattijs @Koushik Functionality migration from internal development lineAdminAdminhttps://develop.openfoam.com/Development/openfoam/-/issues/123BUG: inconsistent specification for -dict2016-07-27T12:16:16ZPrashant SonakarBUG: inconsistent specification for -dictargument specification should be consistent. Present syntax
```
noise -dict noiseDict
execFlowFunctionObjects -dict system/postProcessingDict
```
expected
```
noise -dict system/noiseDict
```
@Mattijs argument specification should be consistent. Present syntax
```
noise -dict noiseDict
execFlowFunctionObjects -dict system/postProcessingDict
```
expected
```
noise -dict system/noiseDict
```
@Mattijs AdminAdminhttps://develop.openfoam.com/Development/openfoam/-/issues/341BUG: inconsitent settings for compiler (csh/sh)2018-05-29T05:39:49ZPrashant SonakarBUG: inconsitent settings for compiler (csh/sh)Revisit settings in csh/sh with recent merge.
e.g. sh compatible with Gcc-4[8-9] whereas csh files still have older version lists!
@andyRevisit settings in csh/sh with recent merge.
e.g. sh compatible with Gcc-4[8-9] whereas csh files still have older version lists!
@andyVersion v1706Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/99BUG: incorrect camera position for nFrames>1 (runTimePostProcessing)2023-12-07T19:01:59ZPrashant SonakarBUG: incorrect camera position for nFrames>1 (runTimePostProcessing)It seems the position should be
position_ = currentFrameI_*dPosition_;
instead of
position_ += currentFrameI_*dPosition_;
in $FOAM_SRC/postProcessing/functionObjects/graphics/runTimePostProcessing/scene.CIt seems the position should be
position_ = currentFrameI_*dPosition_;
instead of
position_ += currentFrameI_*dPosition_;
in $FOAM_SRC/postProcessing/functionObjects/graphics/runTimePostProcessing/scene.CAdminAdminhttps://develop.openfoam.com/Development/openfoam/-/issues/685BUG: incorrect dimensions for pressureTools2017-12-30T21:27:47ZPrashant SonakarBUG: incorrect dimensions for pressureToolsThe attached case replicates the issue.
- dimensions are incorrect for second iteration.
[cavity.tgz](/uploads/484b28a50405eb27e12492834fb953fb/cavity.tgz)
@Sergio @andy @MattijsThe attached case replicates the issue.
- dimensions are incorrect for second iteration.
[cavity.tgz](/uploads/484b28a50405eb27e12492834fb953fb/cavity.tgz)
@Sergio @andy @Mattijshttps://develop.openfoam.com/Development/openfoam/-/issues/359BUG: incorrect documentation2018-05-29T05:39:49ZPrashant SonakarBUG: incorrect documentationblendingFactor.H specifes
```
fieldName U;
```
but expects
```
field U;
```blendingFactor.H specifes
```
fieldName U;
```
but expects
```
field U;
```Version v1612AdminAdminhttps://develop.openfoam.com/Development/openfoam/-/issues/360BUG: incorrect documentation2018-05-29T05:39:49ZPrashant SonakarBUG: incorrect documentationIn file valueAverage.H
1) Change functionObjectName-> functionObject
2) Also, it seems `resetOnRestart` is compulsory input required (which is missing in documentation)
3) fieldAveage has `restartOnRestart` whereas valueAverage has...In file valueAverage.H
1) Change functionObjectName-> functionObject
2) Also, it seems `resetOnRestart` is compulsory input required (which is missing in documentation)
3) fieldAveage has `restartOnRestart` whereas valueAverage has `resetOnRestart` ?
4) fieldAverage -> restartOnRestart -> optional argument whereas
valueAverage -> resetOnRestart -> compulsory?
@andy : Mark is looking at theseVersion v1706Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/2566BUG: incorrect order for output scaling (transformPoints, ...)2022-08-18T11:57:47ZMark OLESENBUG: incorrect order for output scaling (transformPoints, ...)Noticed while working on #2565, the output write scaling should be applied *after* undoing the effects of the specified rotation centre. Currently the scaling applied before undoing the rotation centre, which means the resulting output w...Noticed while working on #2565, the output write scaling should be applied *after* undoing the effects of the specified rotation centre. Currently the scaling applied before undoing the rotation centre, which means the resulting output would be entirely wrong if rotation centre *and* output scaling are combined!Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/990BUG: Incorrect points reported in multiSolidBody motion2019-12-09T22:22:46ZPrashant SonakarBUG: Incorrect points reported in multiSolidBody motionsrc/dynamicMesh/motionSolvers/displacement/solidBody/multiSolidBodyMotionSolver.C
should report total points being used. It reports only from master at the moment.
```
Info<< "Applying solid body motion " << SBMFs_[zonei]....src/dynamicMesh/motionSolvers/displacement/solidBody/multiSolidBodyMotionSolver.C
should report total points being used. It reports only from master at the moment.
```
Info<< "Applying solid body motion " << SBMFs_[zonei].type()
<< " to "
<< returnReduce(pointIDs_[zonei].size(), sumOp<label>())
<< " points of cellZone " << iter().keyword() << endl;
```
@Mattijs @andy @Sergio
Cross reference: EP#793https://develop.openfoam.com/Development/openfoam/-/issues/137BUG: incorrect switch output for 'prime2Mean' in fieldAverage function obj2016-06-02T13:02:11ZMark OLESENBUG: incorrect switch output for 'prime2Mean' in fieldAverage function objIncorrect variable referenced in output of "prime2Mean" switch setting.Incorrect variable referenced in output of "prime2Mean" switch setting.