Development issueshttps://develop.openfoam.com/groups/Development/-/issues2021-08-22T19:03:50Zhttps://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çinhttps://develop.openfoam.com/Development/openfoam/-/issues/1760mingw :test case fail2021-07-06T17:36:26ZPawan Ghildiyalmingw :test case fail
@mark
Creating a list of tutorial(except multiphase) which fail in windows version.
I will keep on updating the list.
1. heatTransfer/buoyantBoussinesqSimpleFoam/iglooWithFridges/
The tutorial fail in windows mingw versi...
@mark
Creating a list of tutorial(except multiphase) which fail in windows version.
I will keep on updating the list.
1. heatTransfer/buoyantBoussinesqSimpleFoam/iglooWithFridges/
The tutorial fail in windows mingw version while running snappyHexMesh
It was unable to find "displacementLaplacian" Solver
Adding libs(libfvMotionSolvers) in controlDict, resolve the issue .
2. incompressible/pimpleFoam/LES/surfaceMountedCube/initChannel (Edited)
functionObject surface: to output turbulenceProperties:L,turbulenceProperties:R, turbulenceProperties:R
write variablefile as turbulenceProperties and not turbulenceProperties:Rhttps://develop.openfoam.com/Development/openfoam/-/issues/1759mergeOrSplitBaffles : not identiying -dict arguments2020-07-28T15:15:56ZPawan GhildiyalmergeOrSplitBaffles : not identiying -dict argumentsHello ,
when i am running mergeOrSplitBaffles, with -dict argument , it throw error with latest
v2006.
i.e
> mergeOrSplitBaffles -dict system/mergeOrSplitBafflesDict_boundary
>
> Expected 0 arguments but found 1
Regard...Hello ,
when i am running mergeOrSplitBaffles, with -dict argument , it throw error with latest
v2006.
i.e
> mergeOrSplitBaffles -dict system/mergeOrSplitBafflesDict_boundary
>
> Expected 0 arguments but found 1
Regards
PawanMark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/1757dash bug with string expansion and assignment of default values2020-11-26T13:55:23ZMark OLESENdash bug with string expansion and assignment of default valuesNoticed when compiling OpenFOAM-v2006 modules with ubuntu _bionic_ (18.04) that the module prefix is not being correctly set. Seems to be a weird bug in the `dash` shell expansions.
Starting from any non-root directory
```
echo "$PWD"
-...Noticed when compiling OpenFOAM-v2006 modules with ubuntu _bionic_ (18.04) that the module prefix is not being correctly set. Seems to be a weird bug in the `dash` shell expansions.
Starting from any non-root directory
```
echo "$PWD"
-> /home/user/openfoam/BuildEnv/scratch
```
dash 0.5.8-2.10 (bionic) shows this
```
unset test1
echo "${test1:=${PWD%/*}}"
-> /home/user/openfoam/BuildEnv/scratch <-- WHAT?? Not what we expected
```
The additional quotes cause incorrect expansion. Whereas
```
unset test1
echo ${test1:=${PWD%/*}}
-> /home/user/openfoam/BuildEnv <-- Expected
```
- bash and dash 0.5.10.2-6 (focal) work as expected, with/without quotes
- quoted expansion with `:-` works as expected.
Possible fixes?
- https://git.kernel.org/pub/scm/utils/dash/dash.git/commit/?id=48ca00863af909461d1372998bb90549f27abaaf
- https://git.kernel.org/pub/scm/utils/dash/dash.git/commit/?id=a29e9a1738a4e7040211842f3f3d90e172fa58ce
- https://git.kernel.org/pub/scm/utils/dash/dash.git/commit/?id=878514712c5d21f675c45d99d2f8a04098ea4a19
Possible workarounds
- use unqoted version, but risk fixing it on the next shellcheck
- explicit `if [ -z VAR ]; then ...; fi` construct
- with dirname as `: "${VAR:=$(dirname xxx)}`Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/1755strange behaviour when comparing SixDoFRigidBodyMotion, RigidBodyDynamics and...2021-07-07T08:56:01ZGabriel Barajasbarajasg@unican.esstrange behaviour when comparing SixDoFRigidBodyMotion, RigidBodyDynamics and Overset libraries.Hi,
While working in new developments I have come up with an expected results when comparing the three main libraries for rigid body motions (**SixDoFRigidBodyMotion**, **RigidBodyDynamics** and **Overset**) with the tutorial provided i...Hi,
While working in new developments I have come up with an expected results when comparing the three main libraries for rigid body motions (**SixDoFRigidBodyMotion**, **RigidBodyDynamics** and **Overset**) with the tutorial provided in the oficial release.
Please, note that I assume that the **RigidBodyDynamics** gives the correct results, as it has been widely validated.
If I compare (for a sligthly modified version of the tutorial), the results using the **SixDoFRigidBodyMotion** library (in green), and the **RigidBodyDynamics** library (in red), I get the same results (as expected).
![image1](/uploads/7bf3aed75cee43fad50920df823f3774/image1.jpg)
![image2](/uploads/85f4a21dfba6fe134ec865094499892c/image2.jpg)
Then, If I compare (using the same case), the **RigidBodyDynamics** library (in green) against the **Overset** library (in red), I get this weird result in the YAW rotation.
![image3](/uploads/b632116d481366117c67f62f4f7d0d93/image3.jpg)
![image4](/uploads/379d82af50372f0dceb9fae13c608b38/image4.jpg)
If I vary the constraint in the displacement (along axis Z or along axis X), I get the same weird results in the YAW rotation.
![image5](/uploads/ff8fbeacb44873edd3925d5dc3b96c63/image5.jpg)
![image6](/uploads/c62b6515e0ec4ded29e84536e75cb897/image6.jpg)
Please, can you clarify me if it is working correctly the Overset library?
Regards,
Gabihttps://develop.openfoam.com/Development/openfoam/-/issues/1754LES without any SGS model2020-06-30T05:44:57ZSeo Dong-HoLES without any SGS modelHi
I'd like to do a large eddy simulation **without any SGS model** to compare with the results with it.
How can I set up "turbuleceProperties", etc. on OpenFOAM?
Thank you.Hi
I'd like to do a large eddy simulation **without any SGS model** to compare with the results with it.
How can I set up "turbuleceProperties", etc. on OpenFOAM?
Thank you.https://develop.openfoam.com/Development/openfoam/-/issues/1753TableBase copy constructor does not clear out interpolationWeights / no clone...2021-07-07T08:55:02ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comTableBase copy constructor does not clear out interpolationWeights / no clone() functionality<!--
*** 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 -->
TableBase might allocate an interpolator (interpolationWeights). interpolationWeights holds a reference to the set of input samples. When copying the TableBase it copies these interpolationWeights which now has a reference to some outside data. If this has gone out of scope the interpolator will access invalid data.
### Steps to reproduce
<!-- How one can reproduce the issue - this is very important -->
Not trivial. Use copy construct on Table (or TableFile). Could not replicate it on e.g. damBreakWithObstacle (topo changes) with U set to uniformFixedValue with a table.
### 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 : v2006
- Operating system : any
### 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
-->
Reset autoPtrs in copy constructor. This will trigger rebuilding the interpolator
```
template<class Type>
Foam::Function1Types::TableBase<Type>::TableBase(const TableBase<Type>& tbl)
:
Function1<Type>(tbl),
name_(tbl.name_),
bounding_(tbl.bounding_),
interpolationScheme_(tbl.interpolationScheme_),
table_(tbl.table_),
tableSamplesPtr_(nullptr),
interpolatorPtr_(nullptr)
{}
```Mattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comhttps://develop.openfoam.com/Development/openfoam/-/issues/1750SemiImplicitSource takes constant values for Su,Sp2020-06-30T11:22:06ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comSemiImplicitSource takes constant values for Su,Sp### Functionality to add/problem to solve
The fvOption SemiImplicitSource allows one to directly specify a source term in any equation. It currently only takes constant values for Su (source), Sp (linearisation of source)
### Target au...### Functionality to add/problem to solve
The fvOption SemiImplicitSource allows one to directly specify a source term in any equation. It currently only takes constant values for Su (source), Sp (linearisation of source)
### Target audience
This fvOption is quite often used to model a heat source in the temperature eqn.
### Proposal
Make Su,Sp into Function1
@PrashantMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comhttps://develop.openfoam.com/Development/openfoam/-/issues/1747mask handling in ensight surface reader2020-06-25T10:08:18ZMark OLESENmask handling in ensight surface readerNoted by @Prashant in testing, seems to fail if the geometry name _does not_ contain any `*` chars.Noted by @Prashant in testing, seems to fail if the geometry name _does not_ contain any `*` chars.v2006Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/1746Dynamic contact angle does not limit to advancing or receding contact angles ...2023-01-17T12:07:49ZMike WorthDynamic contact angle does not limit to advancing or receding contact angles at high speed<!--
*** 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
When using dynamicAlphaContactAngle, I enter 3 values - an equalibrium CA, plus advancing and receding CA. From everything I've read on the topic, at high speeds the contact angle should limit to the advancing/receding angles, while at rest it will relax to the equilibrium CA.
### Steps to reproduce
Use a VOF solver (e.g. interFoam) and set a boundary to dynamicAlphaContactAngle. Create a geometry/flow condition that results in a moving contact line along this boundary.
### What is the current *bug* behaviour?
Contact angle limits to values that are not the advancing or receding contact angles specified in the boundary condition.
<!-- What actually happens -->
### What is the expected *correct* behavior?
<!-- What you should see instead -->
Contact angle should limit to advancing and receding contact angles specified in the boundary condition.
### 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 plot shows a simple case of contact angle hysteresis - equalibrium of 90deg and advancing and receding of 100 and 80 respectively. The current calculation limits to 110 and 70, while my code (below) correctly limits to the values specified.
![DVA_symmetric](/uploads/55671a2411173d2a0550292225e87580/DVA_symmetric.png)
In this case the angles are set asymetrically; my code again limits to the specified values, while the existing code does not. (It does not produce asymmetry at all, as it only really has two parameters: theta0 and (thetaA - thetaR)).
![DVA_asymmetric](/uploads/b5120f645fe5654c8a682dd92a80fe3f/DVA_asymmetric.png)
### Environment information
- OpenFOAM version : v1912
- Operating system : Ubuntu 18.04
### 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
-->
[Line 145 of dynamicAlphaContactAngleFvPatchScalarField](https://develop.openfoam.com/Development/openfoam/blob/OpenFOAM-v1912/src/transportModels/twoPhaseProperties/alphaContactAngle/dynamicAlphaContactAngle/dynamicAlphaContactAngleFvPatchScalarField.C#L145) is where the calculation is being done. I suggest changing it to:
` return theta0_ * (1 - tanh(uwall/uTheta_) * sign(uwall/uTheta_) )
- thetaA_ * neg(uwall) * tanh(uwall/uTheta_)
+ thetaR_ * pos(uwall) * tanh(uwall/uTheta_);`
It is probably worthwhile to do some sanity checking on thetaA>=theta0>=thetaR as if this is violated then it will probably give non-physical results.Kutalmış BerçinKutalmış Berçinhttps://develop.openfoam.com/Development/openfoam/-/issues/1743wallHeatFlux does not show region2022-08-10T16:48:13ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comwallHeatFlux does not show regionIn previous versions the header ('wallHeatFlux wallHeatFlux-solid write:') would appear before printing of the statistics so it would make it clear to which region the statistics belonged. This seems to be no longer the case:
```
mi...In previous versions the header ('wallHeatFlux wallHeatFlux-solid write:') would appear before printing of the statistics so it would make it clear to which region the statistics belonged. This seems to be no longer the case:
```
min/max/integ(walls) = 0, 0, 0
min/max/integ(solid_to_fluid) = -0.100497, -0.100095, -0.100296
wallHeatFlux wallHeatFlux-solid write:
writing field wallHeatFlux
min/max/integ(walls) = 0, 0, 0
min/max/integ(fluid_to_solid) = 0.100096, 0.100497, 0.100296
wallHeatFlux wallHeatFlux-fluid write:
writing field wallHeatFlux
```Kutalmış BerçinKutalmış Berçinhttps://develop.openfoam.com/Development/openfoam/-/issues/1741mingw: case failure: change writeFormat to binary2020-07-01T17:10:53ZPawan Ghildiyalmingw: case failure: change writeFormat to binaryHi @mark @Prashant
In windows, using mingw compiled binaries, there are some testcase which shows failure
with following messages. By changing writing format to binary or increasing writePrecesion resolve
the issue.
> --> FOAM FATAL...Hi @mark @Prashant
In windows, using mingw compiled binaries, there are some testcase which shows failure
with following messages. By changing writing format to binary or increasing writePrecesion resolve
the issue.
> --> FOAM FATAL ERROR:
> Your current settings specify ASCII writing with 6 digits precision.
> Your merging tolerance (1e-06) is finer than this.
> Change to binary writeFormat, or increase the writePrecision
> or adjust the merge tolerance (mergeTol).
My request is to change writeFormat to binary for following testcase which shows failure
. It will ensure smooth testing for following testcases.
combustion/fireFoam/LES/compartmentFire
compressible/rhoPimpleFoam/RAS/annularThermalMixer
buoyantBoussinesqSimpleFoam/iglooWithFridges
buoyantSimpleFoam/simpleCarSolarPanel
incompressible/pimpleFoam/RAS/wingMotion/wingMotion_snappyHexMesh
mesh/snappyHexMesh/flange
mesh/snappyHexMesh/addLayersToFaceZone
mesh/snappyHexMesh/iglooWithFridgesDirectionalRefinement
multiphase/interFoam/laminar/sloshingCylinder
multiphase/interPhaseChangeFoam/cavitatingBulletMark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/1740include in fvOption2020-06-22T14:36:16Zchristoph irrenfriedinclude in fvOption### Functionality to add/problem to solve
for automation purposes it would be convenient, if the "#include" would also be possible in the **fvOption** files
### Example
````c++
#include "${FOAM_CASE}/system/SetupDict"
momentumSource...### Functionality to add/problem to solve
for automation purposes it would be convenient, if the "#include" would also be possible in the **fvOption** files
### Example
````c++
#include "${FOAM_CASE}/system/SetupDict"
momentumSource
{
type meanVelocityForce;
selectionMode cellZone;
cellZone inletCellZone;
fields (U);
Ubar (0 $:BC.Uin 0); //<--- does not work!
}
````
The file **${FOAM_CASE}/system/SetupDict** reads:
````c++
/*--------------------------------*- C++ -*----------------------------------*\
| ========= | |
| \ / F ield | OpenFOAM: The Open Source CFD Toolbox |
| \ / O peration | @ Virtual Vehicle |
| \ / \ / A nd | Web: www.OpenFOAM.org |
| \/ \/ M anipulation | |
\*---------------------------------------------------------------------------*/
FoamFile
{
version 2.0;
format ascii;
class dictionary;
location "system";
object SetupDict;
}
// * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * //
BC
{
Uin 0.060455;
}
````
Which causes the following error:
````c++
[0]
[1] [0]
[0] --> FOAM FATAL IO ERROR:
[0]
[1]
[1] --> FOAM FATAL IO ERROR:
[1] Entry 'type' not found in dictionary "IOstream.BC"
[1]
[1]
[1] file: [2]
[2]
Entry 'type' not found in dictionary "/data/P2P/channel_v01_3/system/fvOptions.BC"
[0]
[0]
[0] file: /data/P2P/channel_v01_3/system/fvOptions.BC
[0]
[0] From function bool Foam::dictionary::readEntry(const Foam::word&, T&, Foam::keyType::
option, bool) const [with T = Foam::word]
[0] in file [2] --> FOAM FATAL IO ERROR:
[2] Entry 'type' not found in dictionary "IOstream.BC"
IOstream.BC
[1]
[1] From function bool Foam::dictionary::readEntry(const Foam::word&, T&, Foam::keyType::
option, bool) const [with T = Foam::word]
[1] /software/OpenFOAM/OpenFOAM-v1912/src/OpenFOAM/lnInclude/dictionaryTemplates.C at line 33
4.
[0]
FOAM parallel run exiting
[0] [3]
[3]
[3] --> FOAM FATAL IO ERROR:
[3] Entry 'type' not found in dictionary "IOstream.BC"
[3]
[3]
[3] file: in file /software/OpenFOAM/OpenFOAM-v1912/src/OpenFOAM/lnInclude/dictionaryTemp
lates.C at line 334.
[1]
FOAM parallel run exiting
[1]
[2]
[2]
[2] file: IOstream.BC
[2]
[2] From function bool Foam::dictionary::readEntry(const Foam::word&, T&, Foam::keyType::
option, bool) const [with T = Foam::word]
[2] in file /software/OpenFOAM/OpenFOAM-v1912/src/OpenFOAM/lnInclude/dictionaryTemplates.
C at line 334.
[2]
FOAM parallel run exiting
[2]
IOstream.BC
[3]
[3] From function bool Foam::dictionary::readEntry(const Foam::word&, T&, Foam::keyType::
option, bool) const [with T = Foam::word]
[3] in file /software/OpenFOAM/OpenFOAM-v1912/src/OpenFOAM/lnInclude/dictionaryTemplates.
C at line 334.
[3]
FOAM parallel run exiting
[3]
--------------------------------------------------------------------------
MPI_ABORT was invoked on rank 1 in communicator MPI_COMM_WORLD
with errorcode 1.
NOTE: invoking MPI_ABORT causes Open MPI to kill all MPI processes.
You may or may not see output from other processes, depending on
exactly when Open MPI kills them.
--------------------------------------------------------------------------
````
If I hard code the value for Ubar it works!