Development issueshttps://develop.openfoam.com/groups/Development/-/issues2020-08-05T10:33:56Zhttps://develop.openfoam.com/Development/openfoam/-/issues/1780FOAM_ABORT pre-empts throwing exceptions2020-08-05T10:33:56ZMark OLESENFOAM_ABORT pre-empts throwing exceptionsAs noted prior to release by @andy, running with FOAM_ABORT means that failed loading of function objects translates into a real failure instead of being generous and emitting a warning. With issue #1779, it looks like time to make a min...As noted prior to release by @andy, running with FOAM_ABORT means that failed loading of function objects translates into a real failure instead of being generous and emitting a warning. With issue #1779, it looks like time to make a minor adjustment to the `error` class.
I think that if code has requested `throwExceptions()` this should be honoured by the internals of `error`. Ie, swap the order of if/else if in error.C around line 240.
Opinions, objections? @andy and @MattijsMark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/1779additional handling of function object failure2022-05-29T15:09:02ZMark OLESENadditional handling of function object failureAs raised in EP1338, the change of sampled surfaces causes a different in later OpenFOAM versions.
In the earlier versions, if the surface was out-of-domain (wrong location, but most likely incorrect scaling), this would fail on constru...As raised in EP1338, the change of sampled surfaces causes a different in later OpenFOAM versions.
In the earlier versions, if the surface was out-of-domain (wrong location, but most likely incorrect scaling), this would fail on construction which would emit a warning and discard the function object.
More recent updates for sampling are much _"lazier"_ - they only construct the surface as required. This is particularly useful in cases of an iso-surface for a field that does not exist until later in the simulation.
However, as a side-effect of this, the failure can now occur during execute() or write() of the functionObject, which means that even if the dry-run was successful, the job can crash because of the bad function object.Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/1778Function1Expression vector2020-07-20T14:15:05ZMatej FormanFunction1Expression vectorExample in file Function1Expression.H
for vector is not working (tested on cavity case in U file as is).
Entry in U:
```
movingWall
{
type uniformFixedValue;
uniformValue
{
typ...Example in file Function1Expression.H
for vector is not working (tested on cavity case in U file as is).
Entry in U:
```
movingWall
{
type uniformFixedValue;
uniformValue
{
type expression;
variables
(
"start = 0.5"
"stop = 1"
);
expression #{mag(arg() > start && arg() < stop) * vector(1, 0, 0) #};
}
}
```
Error message:
```
Reading field U
--> FOAM Warning :
From virtual Foam::Istream& Foam::ISstream::read(Foam::word&)
in file db/IOstreams/Sstreams/ISstream.C at line 482
Reading "/home/matej/PROJECTS/release2006/cavity/0/U" at line 35
Missing 1 closing ')' while parsing
mag(arg()
--> FOAM Warning :
Reading "/home/matej/PROJECTS/release2006/cavity/0/U" at line 35
Imbalanced '{' with ')'
--> FOAM Warning :
From virtual Foam::Istream& Foam::ISstream::read(Foam::word&)
in file db/IOstreams/Sstreams/ISstream.C at line 482
Reading "/home/matej/PROJECTS/release2006/cavity/0/U" at line 35
Missing 1 closing ')' while parsing
vector(1,
```Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/1777primitiveMesh::pointInCell(const point& p, label celli) may fail on non-conve...2020-07-22T10:27:36ZPhilip CardiffprimitiveMesh::pointInCell(const point& p, label celli) may fail on non-convex cells### Summary
<!-- Summarize the bug encountered concisely -->
### Steps to reproduce
The function primitiveMesh::pointInCell(const point& p, label celli) may fail on non-convex cells i.e. if p is inside the cell, this function may retu...### Summary
<!-- Summarize the bug encountered concisely -->
### Steps to reproduce
The function primitiveMesh::pointInCell(const point& p, label celli) may fail on non-convex cells i.e. if p is inside the cell, this function may return false if the cell is non-convex.
I understand that OpenFOAM expects convex cells but there are cases where slightly convex cells can be used without introducing significant errors.
### Example case
Consider a mesh with one non-convex hexahedral cell, and the coordinates (given in blockMesh compatible ordering):
(0 0 0)
(1 0 0)
(0.2 0.2 0)
(0 1 0)
(0 0 1)
(1 0 1)
(0.2 0.2 1)
(0 1 1)
The point (0.3 0.1 0.5) is within the cell, but pointInCell will return false.
### What is the current *bug* behaviour?
Valid points are incorrectly characterised as outside the cell.
### What is the expected *correct* behavior?
Valid points should be correctly characterised as inside the cell.
### Relevant logs and/or images
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 : ALL
- Operating system : N/A
- Hardware info : N/A
- Compiler : N/A
### Possible fixes
I can think of at least two fixes:
1. Print a warning if there are non-convex cells letting the user know that this function may fail
2. Create a pointInNonConvexCell function, for example, using an algorithm like the one described here https://stackoverflow.com/questions/44513525/testing-whether-a-3d-point-is-inside-a-3d-polyhedron
I have implemented 2 in [pointInNonConvexCell.C](/uploads/5133e9c7fde3a1e0d1bbdf15bf5dff90/pointInNonConvexCell.C) and it works on the test cases I have tried.https://develop.openfoam.com/Development/openfoam/-/issues/1776Instructions to build Paraview FoamReader plugin2021-07-07T09:01:40ZGhost UserInstructions to build Paraview FoamReader pluginHello,
I've compiled OpenFOAM v2006 on Ubuntu 20.04. However, I have already Paraview 5.7 installed on my machine, so I didn't compile Paraview, because that will take more than 10 hours on my machine.
I can't figure out how to compile t...Hello,
I've compiled OpenFOAM v2006 on Ubuntu 20.04. However, I have already Paraview 5.7 installed on my machine, so I didn't compile Paraview, because that will take more than 10 hours on my machine.
I can't figure out how to compile the Paraview Foam Reader Plugin alone to be able to use `paraFoam`, I can't find instructions on your website.
Thank youhttps://develop.openfoam.com/Development/openfoam/-/issues/1775cleanup of autoPtr, tmp classes2020-08-11T17:17:55ZMark OLESENcleanup of autoPtr, tmp classesShould remove some slight inconsistencies between autoPtr and tmp, and reduce some coding verbosity.
- For autoPtr, can use assignment from `nullptr` to effect a reset. Should also be allowed for tmp.
- Reduce use of autoPtr `empty()` a...Should remove some slight inconsistencies between autoPtr and tmp, and reduce some coding verbosity.
- For autoPtr, can use assignment from `nullptr` to effect a reset. Should also be allowed for tmp.
- Reduce use of autoPtr `empty()` and `valid()` methods.
The autoPtr empty() method was introduced (Jan-2009) to reduce these types of constructs:
```
if (!myPtr.valid()) ...
if (myPtr.empty()) ...
```
But now there are some places with this type of thing:
```
if (!myPtr.empty()) ...
```
Since we now have an explicit `bool` operator, probably makes sense to use that instead:
```
if (myPtr) ...
if (!myPtr) ...
```Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/1774questionable code in shortestPathSet genSamples2020-07-15T06:43:41ZMark OLESENquestionable code in shortestPathSet genSamplesFrom inspection looks like size mismatch or funny comments
// Seed faces and points on 'real' boundary
bitSet isBlockedPoint(mesh.nPoints());
{
// Real boundaries
const polyBoundaryMesh& pbm = mesh.boundaryMe...From inspection looks like size mismatch or funny comments
// Seed faces and points on 'real' boundary
bitSet isBlockedPoint(mesh.nPoints());
{
// Real boundaries
const polyBoundaryMesh& pbm = mesh.boundaryMesh();
for (label patchi : wallPatches)
{
const polyPatch& pp = pbm[patchi];
forAll(pp, i)
{
isBlockedPoint.set(pp[i]);
}
}
// Meshed boundaries
forAll(isBlockedFace, facei)
{
if (isBlockedFace[facei])
{
isBlockedPoint.set(mesh.faces()[facei]);
}
}
syncTools::syncPointList
(
mesh,
isBlockedPoint,
orEqOp<unsigned int>(),
0u
);
Looks to be seeding with faces, but treating as points?
@Mattijshttps://develop.openfoam.com/Development/openfoam/-/issues/1772snappyHexMesh creates disconnected regions2024-01-05T17:03:11ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comsnappyHexMesh creates disconnected regions### Functionality to add/problem to solve
snappyHexMesh is sometimes used to create multiple regions which later on get 'connected' through e.g. cyclicAMI. This does make it impossible to detect what is a properly resolved region and wh...### Functionality to add/problem to solve
snappyHexMesh is sometimes used to create multiple regions which later on get 'connected' through e.g. cyclicAMI. This does make it impossible to detect what is a properly resolved region and what is just a dangling few cells.
### Target audience
Cases with faceZones that are intersecting the geometry.
### Proposal
For now have option to remove small regions. This should be expressed as a fraction of 'main' region for a given zone.
@PrashantMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comhttps://develop.openfoam.com/Development/openfoam/-/issues/1771checkMesh -writeAllFields does not handle faceZones with boundary faces in them2020-07-28T15:15:56ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comcheckMesh -writeAllFields does not handle faceZones with boundary faces in them<!--
*** Please read this first! ***
Before opening a new issue, make sure to search for keywords in the issues
filtered by the "bug" label and check to see if it has already been reported
You can see how your report will be re...<!--
*** Please read this first! ***
Before opening a new issue, make sure to search for keywords in the issues
filtered by the "bug" label and check to see if it has already been reported
You can see how your report will be rendered on the platform by using the
"preview" tab above
-->
<!--
All text between these markers are comments and will not be present in the
report
-->
### Summary
<!-- Summarize the bug encountered concisely -->
`checkMesh -writeAllFields` does not handle faceZones with boundary faces in them. It fills a surfaceScalarField without checking if the faceZone does not contain any boundary faces.
### Steps to reproduce
<!-- How one can reproduce the issue - this is very important -->
Use topoSet or setSet to put some boundary faces in a faceZone. In setSet on e.g. the lid-driven cavity tutorial:
```
faceSet f0 new labelToFace (0 100 200 300 400 800 1000 1639)
faceZoneSet f0Zone new setToFaceZone f0
```
### 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 : developMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comhttps://develop.openfoam.com/Development/openfoam/-/issues/1770Make usage of valueAverage function object clearer / improve documentation / ...2022-04-26T16:10:01ZDaniel HummelMake usage of valueAverage function object clearer / improve documentation / extend tutorials### Functionality to add/problem to solve
The usage of the value average function object is shown exemplarily for the forceCoeffs function object, which has a quite clear naming of the resulting variables. When usage with different func...### Functionality to add/problem to solve
The usage of the value average function object is shown exemplarily for the forceCoeffs function object, which has a quite clear naming of the resulting variables. When usage with different function objects is intended, the user has to figure out the "resultName" from the source code of the desired function object.
### Target audience
Any user that wishes to apply the valueAverage function object easily and quickly.
Any cases that benefit from the valueAverage function object.
### Proposal
Adding examples where the valueAverage function object is used in conjuction with different function objects than forceCoeffs. For example:
~~~
functions
{
uni
{
type surfaceFieldValue;
libs (fieldFunctionObjects);
writeControl timeStep;
writeInterval 1;
log yes;
writeTotalArea yes;
writeFields no;
regionType patch;
name outlet;
operation uniformity;
fields (U);
}
valueAverage1
{
type valueAverage;
libs ("libfieldFunctionObjects.so");
writeToFile yes;
log yes;
functionObject uni;
fields ("uniformity(outlet,U)");
window 20;
}
}
~~~
### What does success look like, and how can we measure that?
The completion of extended tutorials, happy users.
### Funding
The functionality already exists for all relevant function objects, if not all. If you want me to come up with some regular use cases worthy of being added to tutorials, I will happily work out some examples and provide them.v2206Kutalmış BerçinKutalmış Berçinhttps://develop.openfoam.com/Development/openfoam/-/issues/1769CrankNicolson ddtScheme gives wrong results for even nOuterCorrectors2020-08-03T15:39:05ZHenning ScheuflerCrankNicolson ddtScheme gives wrong results for even nOuterCorrectorsIn order to increase the numerical stability or accuracy of the scheme, we have the possibility to solve the equation multiple times during a time step. A common example for this is the pimple algorithm. However, the combination multiple...In order to increase the numerical stability or accuracy of the scheme, we have the possibility to solve the equation multiple times during a time step. A common example for this is the pimple algorithm. However, the combination multiple nOuterCorrectors with the CrankNicolson scheme leads to wrong results:
**CrankNicolson nOuter 1:**
![CNNouter1_damBreak_U](/uploads/3a5a989261c43afa604bcd820c7e2a84/CNNouter1_damBreak_U.png)
![CNNouter1_damBreak_alpha](/uploads/da84dec4c018050d1536086fc948df65/CNNouter1_damBreak_alpha.png)
**CrankNicolson nOuter 2:**
![CNNouter2_damBreak_U](/uploads/c329af32ac84586bbd566dcfae0aa56d/CNNouter2_damBreak_U.png)
![CNNouter2_damBreak_alpha](/uploads/3eb9ecd54af0243c1a1a917fe3ed3159/CNNouter2_damBreak_alpha.png)
**CrankNicolson nOuter 2 with fix:**
![CNNouter2_damBreak_U_fixed](/uploads/3b38acbf9a994a9d8cac5ac6ff4b867e/CNNouter2_damBreak_U_fixed.png)
![CNNouter2_damBreak_alpha_fixed](/uploads/5967cde4a3db48021b3be137cf304f05/CNNouter2_damBreak_alpha_fixed.png)
Solving the equations with the CrankNicolson time scheme results in wrong values if nOuterCorrectors is an even number. The reason is that (evaluate(ddt0)) in fvmDDt is always true:
```
{
if (evaluate(ddt0))
{
ddt0 = rDtCoef0_(ddt0)*rho*(vf.oldTime() - vf.oldTime().oldTime())
- offCentre_(ddt0());
}
fvm.source() =
(
rDtCoef*rho.value()*vf.oldTime().primitiveField()
+ offCentre_(ddt0.primitiveField())
)*mesh().V();
}
```
as the timeIndex of the geometricField is not update in the above scenario.
A possible solution might be:
```
template<class Type>
template<class GeoField>
bool CrankNicolsonDdtScheme<Type>::evaluate
(
DDt0Field<GeoField>& ddt0
)
{
bool evaluated = ddt0.timeIndex() != mesh().time().timeIndex();
ddt0.timeIndex() = mesh().time().timeIndex();
return evaluated;
}
```
### Reproduce
interFoam -> damBreak
ddtSchemes -> CrankNicolson 0.9;
nOuterCorrectors -> 2;
### Environment information
- OpenFOAM version : v1806
- Operating system : ubuntu
- Hardware info :
- Compiler :https://develop.openfoam.com/Development/openfoam/-/issues/1768update lemon version and syntax2020-11-09T14:45:35ZMark OLESENupdate lemon version and syntax- newer lemon is available with minor bugfixes and additional `%else` handling.
- change patch to handle `%static` directive instead of `%namespace` directive.
After [forum discussions](https://sqlite.org/forum) there is no foreseeable ...- newer lemon is available with minor bugfixes and additional `%else` handling.
- change patch to handle `%static` directive instead of `%namespace` directive.
After [forum discussions](https://sqlite.org/forum) there is no foreseeable upstream acceptable for the `%namespace` patches we have introduced (the `-e` option might still be open to debate). Since OpenFOAM only uses the anonymous namespace to encapsulate the Lemon parser routines, just use a simpler static linkage instead. This results in a smaller, less intrusive patch, with the vague possibility that it could be upstreamed.v2012Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/1767Particle erosion issue when injecting lagrangian particles into overset mesh.2021-08-22T19:03:50ZBrandon CoxParticle erosion issue when injecting lagrangian particles into overset mesh.<!--
*** 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 -->
Lagrangian particles fail to identify surfaces within the overset region when using overPimpleDyMFoam or overInterDyMFoam. Because surfaces are not recognized in the overset region, particle erosion cannot be recorded. The particles simply pass through the surfaces within the overset region.
### Steps to reproduce
<!-- How one can reproduce the issue - this is very important -->
Add Lagrangian particle functionality through the basicKinematicCloud library into overPimpleDyMFoam solver.
Copy the $FOAM_TUTORIAL/incompressible/overPimpleFoam/simpleRotor tutorial.
Add kinematicCloud file to constant directory.
- particles can be injected manually which requires adding another file to specify locations
Add particleErosion to the kinematicCloud file and specify the patch "hole"
Add g file to constant directory
add rhoInf variable to constant/transportProperties file
Run simulation.
### 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
-->
Here is the overPimpleDyMFoam solver with particles built in.
[overLaPimpleDyMFoam.gz](/uploads/82edbe2949d2ae99dde95caf114f3cdb/overLaPimpleDyMFoam.gz)
Below is the simpleRotor case with a basic kinematic cloud particles added.
[simpleRotorParticleErosion.gz](/uploads/226f3b1eb716ae770af6b43b6ad73c97/simpleRotorParticleErosion.gz)
### What is the current *bug* behaviour?
<!-- What actually happens -->
As the particles approach the hole patch (the physical rotor), the particles pass through the rotor and don't register any impact with the erosion model.
### What is the expected *correct* behavior?
<!-- What you should see instead -->
The particles should rebound off the rotor and erosion should appear on the impacted cells.
### 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.
-->
This image shows a particle passing through the rotor without showing erosion. Erosion is shown on the outer walls to demonstrate that particle erosion is in place.
![simpleRotorErosion](/uploads/3c8f84e618ac7b537aa6ada503911021/simpleRotorErosion.png)
### 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 : v1912
- Operating system : ubuntu
- 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/1766HashTable completely broken in OF-v20062020-07-10T07:37:29ZVasu JaganathHashTable completely broken in OF-v2006`HashTable<vector, label> testHash;
testHash.insert(1,vector(0,2,1));
`
when I compile this, I get the following error
error: function "Foam::string::hash::operator()" cannot be called with the given argument list
argume...`HashTable<vector, label> testHash;
testHash.insert(1,vector(0,2,1));
`
when I compile this, I get the following error
error: function "Foam::string::hash::operator()" cannot be called with the given argument list
argument types are: (const Foam::label)
object type is: Foam::string::hash
return Hash()(key) & (capacity_ - 1);
I am using the exact syntax recommended in the API and as it worked in OF-6 and below.
https://www.openfoam.com/documentation/guides/latest/api/classFoam_1_1HashTable.htmlMark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/1765collated fileHandler hangs when using #include clause in decomposeParDict2020-07-09T14:13:58ZMiguel Castellanocollated fileHandler hangs when using #include clause in decomposeParDict<!--
*** 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 running the case with collated output, for any given solver, if there is an #include clause into the decomposeParDict, introducing for example an external dictionary with variables but also EVEN if it is a empty dictionary, the run will hang forever. Just the fact that there is an #include clause into the decomposeParDict causes the run to hang indefinitely.
### Steps to reproduce
<!-- How one can reproduce the issue - this is very important -->
For ANY OpenFOAM tutorial (or at least/tested on sineWaveDamping(rhoPimpleFoam) and damBreak(interFoam)):
1. Just add an #include clause into your decomposeParDict (#include myDict)
2. RUN:
blockMesh -fileHandler collated
decomposePar -fileHandler collated
mpirun -np $CORES $SOLVER -parallel -fileHandler collated
HANGS INDEFINITELY ...
3. Remove the #include clause and try again.
4. RUNS SMOOTHLY.
### Example case
ANY OPENFOAM TUTORIAL
<!--
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
-->
### 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 : v5. , v6. , v1912
- Operating system : SUSE Linux Enterprise, Arch Linux
- Hardware info :
- Compiler : icc, gcchttps://develop.openfoam.com/Development/openfoam/-/issues/1764PBICGStab does not set residualField under some conditions2020-07-09T15:36:28ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comPBICGStab does not set residualField under some conditions<!--
*** 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 -->
Inspection of `PBICGStab.C` shows that
```
matrix().setResidualField
(
ConstPrecisionAdaptor<scalar, solveScalar>(rA)(),
fieldName_,
false
);
```
is not called if sA convergence test succeeds.
### 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 : v2006
### 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
-->
Update residual and call setResidualField before exiting.https://develop.openfoam.com/Development/openfoam/-/issues/1763columnAverage2021-07-07T08:56:50ZSeo Dong-HocolumnAverageLooking into a directory "controlDict" in a tutorial "periodicHill', to apply "columnAverage", patches is set "patches (front "proc.*throughfront");". By the way, I do not clearly understand what "proc.*throughfront" means. Actually, thi...Looking into a directory "controlDict" in a tutorial "periodicHill', to apply "columnAverage", patches is set "patches (front "proc.*throughfront");". By the way, I do not clearly understand what "proc.*throughfront" means. Actually, this case has two patches "front" and "back" at the ends of the spanwise direction. Please let me know this.
Moreover, do I have to include two patches "front" and "back" together to do the spanwise average?, otherwise, only one patch "front" or "back" should be included like "patches (front);"?
Thank you.v2112Kutalmış BerçinKutalmış Berçinhttps://develop.openfoam.com/Development/openfoam/-/issues/1762libs with word instead of filenames fails re-reading2020-07-06T07:41:13ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comlibs with word instead of filenames fails re-reading<!--
*** 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 -->
In case (pisoFoam/LES/pitzDaily) the library loading (in e.g. the `functions` functionObjectList) uses the new syntax:
```
libs (sampling)
```
When forcing re-reading by touching system/controlDict it gives an error since it expects a fileName.
### Steps to reproduce
<!-- How one can reproduce the issue - this is very important -->
- take above tutorial
- comment out functions section
- start running
- uncomment functions section & save
### 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.
-->
```
Re-reading object controlDict from file "ep_1328_fileModification/pitzDaily/system/controlDict"
Overriding OptimisationSwitches according to controlDict
fileModificationSkew 1;
--> FOAM FATAL IO ERROR:
Wrong token type - expected string, found on line 58: word 'sampling'
file: ep_1328_fileModification/pitzDaily/system/controlDict.functions.probes.libs at line 58.
From function Foam::Istream& Foam::operator>>(Foam::Istream&, Foam::fileName&)
in file primitives/strings/fileName/fileNameIO.C at line 58.
FOAM aborting (FOAM_ABORT set)
```
### 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 : v1812Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/ThirdParty-common/-/issues/53Paraview- with python and openmpi>42020-07-09T15:11:49ZPrashant SonakarParaview- with python and openmpi>4Placeholder to resolve issues when building
- Paraview-5.6.3
- Python-2.7
- Openmpi-4.0.3
This fails with mp4py issue as reported in https://gitlab.kitware.com/vtk/vtk/-/issues/17544
We might need a patch for 5.6.3 version or upgrade t...Placeholder to resolve issues when building
- Paraview-5.6.3
- Python-2.7
- Openmpi-4.0.3
This fails with mp4py issue as reported in https://gitlab.kitware.com/vtk/vtk/-/issues/17544
We might need a patch for 5.6.3 version or upgrade to new Paraview ??
@mark @andyv2012https://develop.openfoam.com/Development/openfoam/-/issues/1761possible bug in `pressureDirectedInletOutletVelocity` BC2020-09-06T10:25:43ZArashpossible bug in `pressureDirectedInletOutletVelocity` BC<!--
*** 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
`pressureDirectedInletOutletVelocity` is a mixed BC. Yet, I'm not sure if [this](https://develop.openfoam.com/Development/openfoam/-/blob/OpenFOAM-v1912/src/finiteVolume/fields/fvPatchFields/derived/pressureDirectedInletOutletVelocity/pressureDirectedInletOutletVelocityFvPatchVectorField.C#L205) operator is assigning the correct value. I didn't dig in the code, yet, `pvf` must be either a `refValue` or `refGrad` and in either case, this expression doesn't satisfy the following properties stated [here](https://www.openfoam.com/documentation/guides/latest/doc/guide-bcs-outlet-pressure-inlet-outlet.html):
>- Flow out of the domain: assigns a zero gradient condition
>- Flow into the domain: assigns a velocity based on the flux in the patch-normal direction [or in this case the `inletDir`]
### What is the expected *correct* behavior?
It should be something like [this](https://develop.openfoam.com/Development/openfoam/blob/OpenFOAM-v1912/src/finiteVolume/fields/fvPatchFields/derived/pressureInletOutletVelocity/pressureInletOutletVelocityFvPatchVectorField.C#L212) from the `pressureInletOutletVelocity`v2012Kutalmış BerçinKutalmış Berçin