Development issueshttps://develop.openfoam.com/groups/Development/-/issues2020-02-12T17:31:43Zhttps://develop.openfoam.com/Development/openfoam/-/issues/1582source etc/cshrc fails when given with more than 1 argument2020-02-12T17:31:43ZDavid Ludlowsource etc/cshrc fails when given with more than 1 argument<!--
*** 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 ...<!--
*** 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 -->
A syntax error is returned if `etc/cshrc` is sourced with more than 1 argument.
### Steps to reproduce
<!-- How one can reproduce the issue - this is very important -->
In a c-shell. running the command (for example):
`source ~/OpenFOAM/OpenFOAM-v1912/etc/cshrc WM_PRECISION_OPTION=DP WM_LABEL_SIZE=32`
### 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
-->
N/A
### What is the current *bug* behaviour?
<!-- What actually happens -->
The shell returns:
`Syntax Error.`
and OpenFOAM environment variables aren't set as expected.
### What is the expected *correct* behavior?
<!-- What you should see instead -->
No error returned and the environment variables set as expected!
### 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.
-->
N/A
### 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 : v1812, v1906, v1912
- Operating system : Centos6
- Hardware info : N/A
- Compiler : N/A
### 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
-->
This bug appears to be related to the movement of some lines from `etc/cshrc` to `etc/config.csh/setup` and the way that the command-line arguments are passed and then interpreted. One way to fix this is by replacing the line:
`source "$WM_PROJECT_DIR/etc/config.csh/setup" "${*}"`
in `etc/cshrc` by:
`source "$WM_PROJECT_DIR/etc/config.csh/setup" $argv:q`Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/1581transient solver with suitable ddtScheme2020-02-03T12:37:26ZPrashant Sonakartransient solver with suitable ddtScheme### Functionality to add/problem to solve
Trying to run a transient solver with 'steadyState' as ddtScheme usually causes a divide by zero (sigfpe). This is quite an easy mistake to make when starting from a steady-state solution.
###...### Functionality to add/problem to solve
Trying to run a transient solver with 'steadyState' as ddtScheme usually causes a divide by zero (sigfpe). This is quite an easy mistake to make when starting from a steady-state solution.
### Proposal
Would be nice to give a warning message. It still should be possible in general (e.g. to replace an outer loop with the time loop).
Cross Ref: EP#1204https://develop.openfoam.com/Development/openfoam/-/issues/1580Not Really an Issue more of a question/suggestion2020-06-19T21:05:49ZCole MuellerNot Really an Issue more of a question/suggestionI have been working with CHTmultiregionfoam pretty heavily and I have noticed on all the mapped boundaries there is no way to relax them. This then forces them to rely on the relaxation of the neighboring systems to remain stable at high...I have been working with CHTmultiregionfoam pretty heavily and I have noticed on all the mapped boundaries there is no way to relax them. This then forces them to rely on the relaxation of the neighboring systems to remain stable at high CFL or you are limited by the CFL or you are forced to perform large numbers of iterations to ensure convergence. This is due to the explicit nature of the mapping procedure. I could be mistaken but I have built custom boundary conditions from Mappedflowrate and then the mapped condition and the BC's I created were unstable unless I added relaxation in. So after that long winded explanation, my question, "Is there relaxation features for the coupled boundaries themselves?" and if the answer is no, "Is there any plans to include them in the future?" and just to clarify my boundaries are relaxed independently from the main equations with entirely different relaxation and allow for much faster equation convergence without having to reduce my time steps. In some cases in improved stability drastically at large time steps.https://develop.openfoam.com/Development/openfoam/-/issues/1579improvements foamToEnsightParts2020-06-22T10:10:10ZMark OLESENimprovements foamToEnsightPartsCurrently foamToEnsight and foamToEnsightParts perform somewhat differently.
- foamToEnsight works in serial/parallel, but does not handle cellZones
- foamToEnsightParts handles cellZone, but only works in serial
Desirable to retain ce...Currently foamToEnsight and foamToEnsightParts perform somewhat differently.
- foamToEnsight works in serial/parallel, but does not handle cellZones
- foamToEnsightParts handles cellZone, but only works in serial
Desirable to retain cellZone information in parallel as well, which implies making foamToEnsightParts parallel-aware. Explore the possibility of merging some foamToEnsightParts aspects into ensightMesh (ie, foamToEnsight) and enabling/disabling on a switch.
Cross-ref: EP1109v2006Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/1577typo in FULLDEBUG2020-04-22T20:57:59ZPer Jørgensentypo in FULLDEBUGsrc/OpenFOAM/expressions/exprResult/exprResultGlobals.C line 206
sortToc -> sortedTocsrc/OpenFOAM/expressions/exprResult/exprResultGlobals.C line 206
sortToc -> sortedTocMark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/1576coded FO does not support mesh changes2020-01-27T15:19:10ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comcoded FO does not support mesh changes### Functionality to add/problem to solve
coded FO never gets warned of mesh changes (movePoints, updateMesh). These calls are defaulted in functionObject but should be redirected instead.
Needs:
- functionObjectTemplate[CH] to specify...### Functionality to add/problem to solve
coded FO never gets warned of mesh changes (movePoints, updateMesh). These calls are defaulted in functionObject but should be redirected instead.
Needs:
- functionObjectTemplate[CH] to specify missing callbacks
- syntax inside codedFunctionObject to specify the missing code ('codeMovePoints'?)
- redirection callshttps://develop.openfoam.com/Development/openfoam/-/issues/1574native reduce for solveScalar2020-04-15T08:53:57ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comnative reduce for solveScalar### Functionality to add/problem to solve
Foam::reduce is specialised for summation of scalar but not solveScalar. Hence in SPDP mode it will fall back to non-native reduce (might be slower)
### Target audience
Parallel running### Functionality to add/problem to solve
Foam::reduce is specialised for summation of scalar but not solveScalar. Hence in SPDP mode it will fall back to non-native reduce (might be slower)
### Target audience
Parallel runninghttps://develop.openfoam.com/Development/openfoam/-/issues/1573Add support for automatically reading "fileName.orig" files if the correspond...2020-01-29T03:40:36ZAlberto PassalacquaAdd support for automatically reading "fileName.orig" files if the corresponding "fileName" is absentCurrently, .orig files are used to back files up before performing initialization with utilities such as setFields.
However, the .orig files either
1. Need to be rename with rm or a script
2. The utility foamRestoreFiles -method orig...Currently, .orig files are used to back files up before performing initialization with utilities such as setFields.
However, the .orig files either
1. Need to be rename with rm or a script
2. The utility foamRestoreFiles -method orig -withZero must be executed, which renames the .orig files on the 0 directory instead of renaming a copy of the same files, effectively destroying the .orig file
The .org version has implemented a feature to read the .orig files automatically if the corresponding "non .orig" file is missing: https://github.com/OpenFOAM/OpenFOAM-dev/commit/df6e2da2dd89227cee05c0bc0c1bf4f9b80849d5 This feature would make the process of preserving .orig files a lot simpler and transparent to the user.v2006https://develop.openfoam.com/Development/openfoam/-/issues/1572snappyHexMesh leak detection is prone to false positives2024-01-10T16:49:17ZJustin GraupmansnappyHexMesh leak detection is prone to false positives<!--
*** 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 ...<!--
*** 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
snappyHexMesh leak detection using the locationsOutsideMesh keyword is highly prone to false positives. In other words, a detected leak often doesn't actually cause the mesh to leak when meshed.
### Steps to reproduce
I've attached a simple model to demonstrate this issue. The model is simply a block inside of another block. The inner block has a triangle removed which snappyHexMesh detects as a leak.
On the attached model run...
* blockMesh
* snappyHexMesh -overwrite
You should get an error and a leak path is exported. Now...
* remove the locationsOutsideMesh keyword in the snappyHexMeshDict
* re-run snappyHexMesh
* Review mesh, you'll see that there is no leak into the inner box
### Example case
[boxLeakBug.zip](/uploads/48fe8be4c572aefea8a29b2dcc218453/boxLeakBug.zip)
### What is the current *bug* behaviour?
snappyHexMesh detects a leak when there isn't one.
### What is the expected *correct* behavior?
snappyHexMesh should only detect a leak if there actually is one.
### Environment information
- OpenFOAM version : v1906
- Operating system : RHEL/Windows 10
- Hardware info : Intel
- Compiler : gcc/minGW
### Possible fixes
I suspect the leak detection code is not using the same method that is used to find regions and remove cells during the castellation phase. If possible, the same walking method used to find regions and remove cells should be used to find leaks between the two points. The current method produces way too many false positives to be useful on more complex geometry.v2012https://develop.openfoam.com/Development/openfoam/-/issues/1571Incorrect Nastran surface value export2020-05-14T16:02:42ZPrashant SonakarIncorrect Nastran surface value exportCross Ref : EP#1210
Indexing error in writing as discussed with @markCross Ref : EP#1210
Indexing error in writing as discussed with @markMark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/1570Cloud post-processing data not written when steady case converges using resid...2020-01-28T09:28:57ZAndrew HeatherCloud post-processing data not written when steady case converges using residualControl<!--
*** 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 ...<!--
*** 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 using clouds in steady solvers combined with case termination controls set using `residualControl` in the `fvSolution` file, cloud post-processing data are not written on the last iteration.
### Steps to reproduce
<!-- How one can reproduce the issue - this is very important -->
Add `residualControl` settings to a steady flow solver with cloud functionality and cloud a post-processing object, e.g. `particleTracks`
```
particleTracks
{
type particleTracks;
trackInterval 5;
maxSamples 1000000;
resetOnWrite yes;
}
```
and notice that the cloud post-processing data are not written
### 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?
When the criteria specified in the `residualControls` dictionary are achieved the solver loop calls `time.writeAndEnd()` to write any objects registered with `AUTO_WRITE` and exits. Operations such as cloud post-processing are currently only triggered when evolving the cloud and intercept the `writeTime()` flag and are therefore missed.
### 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 : v1806|v1812|v1906 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
-->
Couple of options
- instead of exiting straight away, run for 1 more iteration with the `writeTime_` flag set (e.g. using `time.writeOnce()` and exit
- intercept the `write()` call to trigger other post-processing actionsv2006Andrew HeatherAndrew Heatherhttps://develop.openfoam.com/Development/openfoam/-/issues/1568waveModel.C fails in debug mode2020-12-10T19:25:20ZPer JørgensenwaveModel.C fails in debug mode<!--
*** 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 ...<!--
*** 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 debug mode a size check failing in src/waveModels/waveModel/waveModel.C
### Steps to reproduce
just run a waves tutorial in debug mode.
It fails in
const vectorField CfLocal(Rgl_ & Cf);
### Example case
e.g. the stokesV tutorial
### What is the current *bug* behaviour?
I don't know what happens and if it matters, but you can't run wave generation in debug mode.
### What is the expected *correct* behavior?
that size should be equal
### 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 :1906
- Operating system :ubuntu 1804
- Hardware info :intel i7-8700K
- Compiler :gcc 7.4
### 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
-->v2006Kutalmış BerçinKutalmış Berçinhttps://develop.openfoam.com/Development/openfoam/-/issues/1567searchableExtrudedCircle / extrudedCircle uses wrong search sphere2024-01-05T17:05:08ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comsearchableExtrudedCircle / extrudedCircle uses wrong search sphere<!--
*** 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 ...<!--
*** Please read this first! ***
Before opening a new issue, make sure to search for keywords in the issues
filtered by the "bug" label and check to see if it has already been reported
You can see how your report will be rendered on the platform by using the
"preview" tab above
-->
<!--
All text between these markers are comments and will not be present in the
report
-->
### Summary
<!-- Summarize the bug encountered concisely -->
The analytical shape 'extrudedCircle' does not interpret the search distance correctly. It is taken as the distance to the centre line instead of the distance to the cylinder itself.
### Steps to reproduce
<!-- How one can reproduce the issue - this is very important -->
Use in e.g. a snappyHexMeshDict. Set the snapping distance (`snapTol`) to e.g. 1. Make sure that the centre line is more than 1 edge distance away from the geometry. Now it will not be attracted to the extrusion, even when the extrusion itself might intersect the geometry.
### 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 -->
### What is the expected *correct* behavior?
<!-- What you should see instead -->
Re-work the search distance into distance-to-extrusion
@PrashantMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comhttps://develop.openfoam.com/Development/openfoam/-/issues/1566foamConfigurePath : update gcc removes entries till end of line2020-05-14T16:02:42ZPrashant SonakarfoamConfigurePath : update gcc removes entries till end of 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 ...<!--
*** 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
foamConfigurePath seems to setup gcc, but removes ;; at the end.
### 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 : 1912
- Compiler : gcc-4.8.5Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/1565How to control foamyQuadMesh bounding box?2020-01-21T08:52:56ZkilaHow to control foamyQuadMesh bounding box?Recently I'm playing with foamyQuadMesh. And I have a problem that my stl file contains a simple closed circle and their coordinates are **below 0.003**. However after using foamyQuadMesh, it automatically insert some points outside circ...Recently I'm playing with foamyQuadMesh. And I have a problem that my stl file contains a simple closed circle and their coordinates are **below 0.003**. However after using foamyQuadMesh, it automatically insert some points outside circle region. And it give a bounding box:
boundingBox : (-1.06e-01 -1.05e-01 0.00e+00) (1.10e-01 1.15e-01 0.00e+00)
The maximum x coordinate is **about 0.01** which is triple of maximum x coordinate of my circle so that the final MeshedSurface.obj looks very strange.
My foamyQuadMeshDict looks like:
-----------------------------
geometry
{
OutletPartSurface.stl
{
name outlet;
type closedTriSurfaceMesh;
}
}
surfaceConformation
{
// The z-coordinate of the plane is taken from here.
locationInMesh (0 0 0);
pointPairDistanceCoeff 0.1;
minEdgeLenCoeff 0.1;
maxNotchLenCoeff 1.0;
minNearPointDistCoeff 0.1;
maxQuadAngle 120;
// Insert near-boundary point mirror or point-pairs
insertSurfaceNearestPointPairs yes;
// Mirror near-boundary points rather than insert point-pairs
mirrorPoints no;
// Insert point-pairs vor dual-cell vertices very near the surface
insertSurfaceNearPointPairs yes;
// Maximum number of iterations used in boundaryConform.
maxBoundaryConformingIter 5;
geometryToConformTo
{
outlet
{
featureMethod extendedFeatureEdgeMesh;
extendedFeatureEdgeMesh "OutletPartSurface.extendedFeatureEdgeMesh";
}
}
additionalFeatures
{}
// Choose if to randomise the initial grid created by insertGrid.
randomiseInitialGrid no;
// Perturbation fraction, 1 = cell-size.
randomPerturbation 0.1;
}
motionControl
{
// This is a tolerance for determining whether to deal with surface
// protrusions or not.
minCellSize 0.0001;
// Assign a priority to all requests for cell sizes, the highest overrules.
defaultPriority 0;
shapeControlFunctions
{
}
relaxationModel adaptiveLinear;
adaptiveLinearCoeffs
{
relaxationStart 0.5;
relaxationEnd 0.0;
}
objOutput no;
meshedSurfaceOutput yes;
// Near-wall region where cells are aligned with the wall specified as a
// number of cell layers
nearWallAlignedDist 3;
}
shortEdgeFilter
{
// Factor to multiply the average of a face's edge lengths by.
// If an edge of that face is smaller than that value then delete it.
shortEdgeFilterFactor 0.2;
// Weighting for the lengths of edges that are attached to the boundaries.
// Used when calculating the length of an edge. Default 2.0.
edgeAttachedToBoundaryFactor 2.0;
}
extrusion
{
extrude off;
#include "extrude2DMeshDict"
}
---------------------------
OutletPartSurface is my stl file that contains a circle. First I use surfaceFeatureExtract to create "OutletPartSurface.extendedFeatureEdgeMesh". As my circle is very small, I set **minCellSize 0.0001;** which is about 0.1 mm.
I have attach a minimum sample to reproduce this problem.
I'm using v1912.
[foamycircle.rar](/uploads/33546ec93da9f4a16d3c934a2c82c570/foamycircle.rar)https://develop.openfoam.com/Development/openfoam/-/issues/1564limitTemperature functionObject does not work with compressibleInterFoam2020-06-19T07:07:20ZPawan GhildiyallimitTemperature functionObject does not work with compressibleInterFoam<!--
*** Please read this first! ***
-->
<!--
All text between these markers are comments and will not be present in the
report
-->
### Summary
limitTemperature functionObject does not work with compressibleInterFoam
### S...<!--
*** Please read this first! ***
-->
<!--
All text between these markers are comments and will not be present in the
report
-->
### Summary
limitTemperature functionObject does not work with compressibleInterFoam
### Steps to reproduce
<!-- How one can reproduce the issue - this is very important -->
### 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 -->
### 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 : v1806|v1812|v1906 etc
Operating system : ubuntu|openSUSE|centos etc
Hardware info : any info that may help?
Compiler : gcc|intel|clang etc
-->
- OpenFOAM version :v1906 and dev
- 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/1562Centos docker version of v1912 doesn't has foamyQuadMesh and foamyHexMesh tool.2021-07-06T17:03:07ZkilaCentos docker version of v1912 doesn't has foamyQuadMesh and foamyHexMesh tool.By check the folder /opt/OpenFOAM/OpenFOAM-v1912/platforms/linux64GccDPInt32Opt/bin/, I find that this folder doesn't contain foamyHexMesh and foamyQuadMesh so that if one using these commands, he would encounter "command not found".
Ho...By check the folder /opt/OpenFOAM/OpenFOAM-v1912/platforms/linux64GccDPInt32Opt/bin/, I find that this folder doesn't contain foamyHexMesh and foamyQuadMesh so that if one using these commands, he would encounter "command not found".
However in windows 10 ubuntu version, one wouldn't have this problem.https://develop.openfoam.com/Development/openfoam/-/issues/1559BUG: Some of the tutorial links in the web and PDF guides are broken2020-01-17T10:04:36ZKutalmış BerçinBUG: Some of the tutorial links in the web and PDF guides are brokenRelated to #975
For instance, the link at the beginning of the `Lid-driven cavity flow` is broken due to the repo migration:
https://www.openfoam.com/documentation/tutorial-guide/tutorialse2.php#x6-60002.1
**Fix:** Changing `OpenFOAM-...Related to #975
For instance, the link at the beginning of the `Lid-driven cavity flow` is broken due to the repo migration:
https://www.openfoam.com/documentation/tutorial-guide/tutorialse2.php#x6-60002.1
**Fix:** Changing `OpenFOAM-plus` to `openfoam`, e.g.
https://develop.openfoam.com/Development/OpenFOAM-plus/tree/master/tutorials/incompressible/icoFoam/cavity/cavity
https://develop.openfoam.com/Development/openfoam/tree/master/tutorials/incompressible/icoFoam/cavity/cavityv2006Andrew HeatherAndrew Heatherhttps://develop.openfoam.com/Development/openfoam/-/issues/1558BUG: cyclicACMI & redistributePar Error2022-02-10T13:47:10ZJustin GraupmanBUG: cyclicACMI & redistributePar Error### Summary
Running redistributePar after decomposing a model with cyclicACMI patches will result in this error...
`[0] --> FOAM FATAL ERROR:
[0] Inconsistent ACMI patches ACMI2_couple and ACMI2_blockage. Patches should have identical...### Summary
Running redistributePar after decomposing a model with cyclicACMI patches will result in this error...
`[0] --> FOAM FATAL ERROR:
[0] Inconsistent ACMI patches ACMI2_couple and ACMI2_blockage. Patches should have identical topology
[0]
[0] From function virtual Foam::label Foam::cyclicACMIPolyPatch::nonOverlapPatchID() const
[0] in file AMIInterpolation/patches/cyclicACMI/cyclicACMIPolyPatch/cyclicACMIPolyPatch.C at line 538.
[0]
FOAM parallel run exiting`
### Steps to reproduce
Modify the Allrun-parallel file in the oscillatingInletACMI2D tutorial, add a **runParallel redistributePar** line after the decomposePar line. Optionally comment out the solver and reconstruct lines since they aren't needed to reproduce the error. Should look like this...
* runApplication decomposePar
* runParallel redistributePar
* #runParallel $(getApplication)
* #runApplication reconstructPar
Run the Allrun-parallel file, you'll find the error in log.redistributePar
### Example case
oscillatingInletACMI2D tutorial
### What is the current *bug* behaviour?
`[0] --> FOAM FATAL ERROR:
[0] Inconsistent ACMI patches ACMI2_couple and ACMI2_blockage. Patches should have identical topology
[0]
[0] From function virtual Foam::label Foam::cyclicACMIPolyPatch::nonOverlapPatchID() const
[0] in file AMIInterpolation/patches/cyclicACMI/cyclicACMIPolyPatch/cyclicACMIPolyPatch.C at line 538.
[0]
FOAM parallel run exiting`
### What is the expected *correct* behavior?
I expect it to redistribute the already decomposed mesh.
### Environment information
- OpenFOAM version : v1906
- Operating system : RHEL/Windows 10
- Hardware info : Intel
- Compiler : GCC/minGW
~bugMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comhttps://develop.openfoam.com/Development/openfoam/-/issues/1556issue with surfaceFieldValue in v19122022-02-28T09:38:35ZJozsef Nagyissue with surfaceFieldValue in v1912I noticed an issue with surfaceFieldValue combination with dynamicMotionSolverFvMesh in v1912. The function writes out the header for all time steps into the dat file.
I upload the case as a zip file. [case.zip](/uploads/41bf0f56d1470d7...I noticed an issue with surfaceFieldValue combination with dynamicMotionSolverFvMesh in v1912. The function writes out the header for all time steps into the dat file.
I upload the case as a zip file. [case.zip](/uploads/41bf0f56d1470d7e32d6695b6d80ef2a/case.zip)
If you run it in v1812 the dat file in postProcessing is fine. If you run it in v1912 it writes out the header in each time step, however if you change in dynamicMeshDict "dynamicMotionSolverFvMesh" to "staticFvMesh", the output is fine again.
Please consider, that the case is a constructed one for this problem, so it has no real physical meaning.