Development issueshttps://develop.openfoam.com/groups/Development/-/issues2020-05-08T08:41:31Zhttps://develop.openfoam.com/Development/openfoam/-/issues/1662potential divide-by-zero for x3d surface writer2020-05-08T08:41:31ZMark OLESENpotential divide-by-zero for x3d surface writercross-ref EP1212
[0001-BUG-potential-divide-by-zero-in-x3d-surface-output-1.patch](/uploads/363fd934ab95c7ba9643873bd83b6de5/0001-BUG-potential-divide-by-zero-in-x3d-surface-output-1.patch)cross-ref EP1212
[0001-BUG-potential-divide-by-zero-in-x3d-surface-output-1.patch](/uploads/363fd934ab95c7ba9643873bd83b6de5/0001-BUG-potential-divide-by-zero-in-x3d-surface-output-1.patch)Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/1663build commit in solver/application log2020-06-19T14:27:28ZHenning Scheuflerbuild commit in solver/application log### Functionality to add
In the development process of a library, one will encounter plenty of bugs. In that case it is extremely useful to know which version of the library was used to produce some results.
An option to achieve this ...### Functionality to add
In the development process of a library, one will encounter plenty of bugs. In that case it is extremely useful to know which version of the library was used to produce some results.
An option to achieve this would be to store the custom library commit hash and name in the log file
e.g.
```
/*---------------------------------------------------------------------------*\
| ========= | |
| \\ / F ield | OpenFOAM: The Open Source CFD Toolbox |
| \\ / O peration | Version: com |
| \\ / A nd | Website: www.openfoam.com |
| \\/ M anipulation | |
\*---------------------------------------------------------------------------*/
Build : 00425fe658-20200403 OPENFOAM=2002 patch=200316
Custom Build : <commit hash>-date libraryName=<name of the library> // proposed
Arch : "LSB;label=32;scalar=64"
Exec : interIsoFoam -parallel
```
### Target audience
### Proposal
Print the custom commit in the log file of the application
### What does success look like, and how can we measure that?
### Links / references
### Fundinghttps://develop.openfoam.com/Development/openfoam/-/issues/1664Could not load dynamic library such as "fieldFunctionObjects" on macOS2023-05-31T11:06:38ZShigeki FujiiCould not load dynamic library such as "fieldFunctionObjects" on macOS<!--
*** 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 one application (use dynamic library) execute, it could not load this library on macOS.
### Steps to reproduce
<!-- How one can reproduce the issue - this is very important -->
In the directory of "tutorials/incompressible/icoFoam/cavityMappingTest",
execute the script of "Allrun".
### 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
-->
`% ./Allrun
Running blockMesh on /opt/OpenFOAM/OpenFOAM-v1912/tutorials/incompressible/icoFoam/cavityMappingTest
Running blockMesh on /opt/OpenFOAM/OpenFOAM-v1912/tutorials/incompressible/icoFoam/cavityMappingTest
Running icoFoam on /opt/OpenFOAM/OpenFOAM-v1912/tutorials/incompressible/icoFoam/cavityMappingTest`
### What is the current *bug* behaviour?
<!-- What actually happens -->
In the file of "log.icoFoam", there is the following message.
`--> FOAM Warning :
From function void *Foam::dlLibraryTable::openLibrary(const Foam::fileName &, bool)
in file db/dynamicLibrary/dlLibraryTable/dlLibraryTable.C at line 65
Could not load "fieldFunctionObjects"
dlopen(libfieldFunctionObjects.dylib, 9): image not found`
### What is the expected *correct* behavior?
<!-- What you should see instead -->
There is no warning.
### 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 : v1912
- Operating system : macOS 10.15.4
- Hardware info : MacBook Pro
- Compiler : Apple clang version 11.0.3 (clang-1103.0.32.29)
### 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
-->
When SPI(System Integrity Protection) is enabled, we can not use the environment value of DYLD_LIBRARY_PATH. So another environment value is introduced and it used before call dlopen(). it is patch for this.
[dl-search-paths.patch](/uploads/6d78336585c7094774f856c4d0634dfe/dl-search-paths.patch)Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/1667etc/cshrc on Mac OS X2023-05-31T11:06:54ZAlexey Matveichevetc/cshrc on Mac OS X<!--
*** 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
`etc/cshrc` does not work on Mac OS X.
1. Original version exists with
```sh
% source etc/cshrc
sed: 1: "s@^[^/]*@@;\@/OpenFOAM[ ...": extra characters at the end of q command
Error: did not locate installation path for OpenFOAM-v1912
No directory:
```
2. It sets up `LD_LIBRARY_PATH` instead of `DYLD_LIBRARY_PATH`.
### Steps to reproduce
`source etc/cshrc`
### What is the current *bug* behaviour?
Error:
```sh
sed: 1: "s@^[^/]*@@;\@/OpenFOAM[ ...": extra characters at the end of q command
Error: did not locate installation path for OpenFOAM-v1912
No directory:
```
### What is the expected *correct* behavior?
1. Environment is set up.
2. `DYLD_LIBRARY_PATH` is set instead of `LD_LIBRARY_PATH`.
### 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
- Operating system : Mac OS X (10.15.4)
- tcsh version : tcsh 6.21.00 (Astron) 2019-05-08 (x86_64-apple-darwin) options wide,nls,dl,bye,al,kan,sm,rh,color,filec
### Possible fixes
1. `sed` issue can be fixed by adding `;` after `q` command. I.e.
```sh
set projectDir=`lsof +p $$ |& \
sed -ne 's@^[^/]*@@;\@/'"$projectName"'[^/]*/etc/cshrc@{s@/etc/cshrc.*@@p; q; }'`
```
On Linux (tested on Ubuntu 19.10) this addition does not change behaviour.
2. Use `DYLD_LIBRARY_PATH` on Mac OS X. I have tried to fix the issue, see attached [config.csh.patch](/uploads/db8227db9df7e50455d1fd9e2d8d8b0f/config.csh.patch). Not sure if it conforms with tcsh programming style guide. Also it is not quite clean what to do if system Open MPI is installed in `/usr/local/...`: it is added to `[DY]LD_LIBRARY_PATH` during environment setup but is not cleaned during `wmUnset`.
As a side-note: `etc/cshrc` works only in `tcsh`. With real `csh` (Ubuntu's `20110502-5`, which is based on `csh` from `OpenBSD` source tree) it exits with `Invalid null command.` error.Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/1668Avoid line-continuation in cshell assignment2020-06-19T14:24:48ZMark OLESENAvoid line-continuation in cshell assignmentAs noted during #1667, there is an issue with BSD-csh.
The following construct _looks_ ok, and works fine with tcsh but fails with BSD csh.
```
# Obtain major.minor from `paraview --version`
set pv_api=`paraview --version | \
sed -n...As noted during #1667, there is an issue with BSD-csh.
The following construct _looks_ ok, and works fine with tcsh but fails with BSD csh.
```
# Obtain major.minor from `paraview --version`
set pv_api=`paraview --version | \
sed -ne 's/^[^0-9]*\([0-9][0-9]*\.[0-9][0-9]*\).*$/\1/p'`
```
Need to use the uglier form, without continuations
```
set pv_api=`paraview --version | sed -ne 's/^[^0-9]*\([0-9][0-9]*\.[0-9][0-9]*\).*$/\1/p'`
```
Not entirely clear why this is.
@alexeyMark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/1669How to use Rans Results as an initial solution for LES calculation under Open...2020-04-13T16:00:11ZTENE HEDJE patrickHow to use Rans Results as an initial solution for LES calculation under OpenfoamI performed RANS calculations with simpleFoam and K-omega SST as a turbulence model, and, I want to use the obtained converged result as the initial solution for the LES calculation.
I did a first try, I used only the RANS P and U solut...I performed RANS calculations with simpleFoam and K-omega SST as a turbulence model, and, I want to use the obtained converged result as the initial solution for the LES calculation.
I did a first try, I used only the RANS P and U solutions while for k, nut and nuTilda I put initial conditions as indicated in the tutorial : tutorials\incompressible\pimpleFoam\LES\channel395
the problem is that it runs as if the results were converged, I have for example lines with 0 iterations as below
Courant Number mean: 1.57492e-05 max: 0.200074
deltaT = 1.57492e-08
Time = 5000
smoothSolver: Solving for Ux, Initial residual = 1.97659e-09, Final residual = 1.97659e-09, No terations 0
smoothSolver: Solving for Uy, Initial residual = 6.373e-09, Final residual = 6.373e-09, No Iterations 0
smoothSolver: Solving for Uz, Initial residual = 6.87469e-08, Final residual = 6.87469e-08, No Iterations 0
GAMG: Solving for p, Initial residual = 0.000502593, Final residual = 5.01657e-05, No Iterations 608
time step continuity errors : sum local = 4.97769e-17, global = 8.82671e-20, cumulative = 1.2001e-13
GAMG: Solving for p, Initial residual = 0.000805539, Final residual = 4.7532e-06, No Iterations 1000
time step continuity errors : sum local = 4.7178e-18, global = 1.59872e-19, cumulative = 1.2001e-13
smoothSolver: Solving for k, Initial residual = 3.33989e-06, Final residual = 3.33989e-06, No Iterations 0
ExecutionTime = 49262.5 s ClockTime = 49362 s
@timofeymukhahttps://develop.openfoam.com/Development/openfoam/-/issues/1671handle Fujitsu compiler2022-08-17T07:54:12ZMark OLESENhandle Fujitsu compilerIssue raised as a [github spack issue](https://github.com/spack/spack/pull/15941).
From the changes, the Fujitsu compiler seems to be a pure clang derivative.
If so, we might try something like the following:
```
WM_COMPILER=Clang10Fuji...Issue raised as a [github spack issue](https://github.com/spack/spack/pull/15941).
From the changes, the Fujitsu compiler seems to be a pure clang derivative.
If so, we might try something like the following:
```
WM_COMPILER=Clang10Fujitsu
```
Within the rules setup, the compiler-family is determined by stripping out numbers etc
(this could be modified to look nicer).
```
COMPILER_FAMILY = $(shell echo "$(WM_COMPILER)" | sed -e 's/[0-9].*//')
```
Within the `rules/linuxARM64Clang/general` we could then add in some custom handling. For example,
```
# Override compiler calls for fujitsu compiler
ifneq (,$(findstring jitsu,$(WM_COMPILER)))
cc = fjclang
CC = fjclang++-10 -std=c++11
endif
```Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/1672waveMaker MultiPaddleFlap crashes if the boundary normal is in the Y direction.2020-07-02T07:43:53ZJaap StolkwaveMaker MultiPaddleFlap crashes if the boundary normal is in the Y direction.### Summary
<!-- Summarize the bug encountered concisely -->
waveMaker MultiPaddleFlap crashes if the boundary normal is in the Y direction.
### Steps to reproduce
in version v1912, copy the multiphase\interFoam\laminar\waves\waveMake...### Summary
<!-- Summarize the bug encountered concisely -->
waveMaker MultiPaddleFlap crashes if the boundary normal is in the Y direction.
### Steps to reproduce
in version v1912, copy the multiphase\interFoam\laminar\waves\waveMakerMultiPaddleFlap example.
- I have swapped X and Y of verices in system/blockMeshDict (attached) and adjusted the vertex order to keep the hex () definition CCW.
- I swapped the X and Y decomposition in system/decomposeParDict
- in 0.orig/pointDisplacement, I changed the normal vector to: n (0 1 0)
- then ran the case using the Allrun script.
### Example case
place the attached system/blockMeshDict in the v1912 multiphase\interFoam\laminar\waves\waveMakerMultiPaddleFlap example, and make the 2 additional modifications mentioned above.
### What is the current *bug* behaviour?
It results in a floatingpoint-error in Foam::waveMakerPointPatchVectorField::initialiseGeometry()
without any other errors or warnings logged. (see attached log.interFoam)
### What is the expected *correct* behavior?
The calculation should run as the original example, or produce an error message when the waveMaker normal vector is outside the supported range.
I tried to reproduce with minimal changes to an example case. In my original case I had the waveMaker boundary on the -Y side and swapping everything in my case in the x=y line resolved my crash, but now the postprocessing does not follow my other cases that have the waveMaker boundary on the -X side.
### Relevant logs and/or images
[blockMeshDict](/uploads/ecde43c3bda4ea4dbc9d45ab7a45423e/blockMeshDict)
[log.interFoam](/uploads/ac80e7fd15e51b2884e8eb6c2302b5b7/log.interFoam)
### Environment information
- OpenFOAM version : v1912 (compiled from source)
- Operating system : ubuntu
- Hardware info : 2x Intel(R) Xeon(R) E5-2690 2.9 GHz
- Hardware info : 1x AMD 1950X
- Compiler : gccv2012Kutalmış BerçinKutalmış Berçinhttps://develop.openfoam.com/Development/openfoam/-/issues/1673small error in rotatedBoxToCell documentation2020-06-08T14:54:22ZJaap Stolksmall error in rotatedBoxToCell documentationIn the rotatedBoxToCell documentation:
>>>
k ( 0.0 0.0 100);
>>>
should be:
>>>
k ( 0.0 0.0 200);
>>>
To be consistent with the text above it, indicating a 200 box height. (the -100 starting point does not affect the box ...In the rotatedBoxToCell documentation:
>>>
k ( 0.0 0.0 100);
>>>
should be:
>>>
k ( 0.0 0.0 200);
>>>
To be consistent with the text above it, indicating a 200 box height. (the -100 starting point does not affect the box height)v2006Kutalmış BerçinKutalmış Berçinhttps://develop.openfoam.com/Development/openfoam/-/issues/1674add rotatedBoxToCell vector order check and warning.2022-04-26T16:10:00ZJaap Stolkadd rotatedBoxToCell vector order check and warning.### Functionality to add/problem to solve
In the rotatedBoxToCell cell selection, the box is defined using an origin and 3 vectors.
if the vectors are not in the correct left/right-hand order, the selection box will be inside-out and no...### Functionality to add/problem to solve
In the rotatedBoxToCell cell selection, the box is defined using an origin and 3 vectors.
if the vectors are not in the correct left/right-hand order, the selection box will be inside-out and not select any cells.
This problem is not easy to spot since no errors or warnings are generated for this situation.
### Proposal
If possible, add a check to the code and produce a warning if this situation is encountered.
And make the importance of the vector order more clear in the rotatedBoxToCell documentation.
### Note
I have since switched to using an external .STL file with a surfaceToCell for more complex selections, but decided to at least share my experience with the rotatedBoxToCell.v2206Kutalmış BerçinKutalmış Berçinhttps://develop.openfoam.com/Development/openfoam/-/issues/1675fieldCoordinateSystemTransform fails to write "U:Transformed" field on a Wind...2022-07-28T04:30:32ZJustin GraupmanfieldCoordinateSystemTransform fails to write "U:Transformed" field on a Windows OS### Summary
fieldCoordinateSystemTransform function object attempts to write "U:Transformed" field on Windows OS even though the ":" character it not supported in file names. This results in the field not being written.
### Steps to r...### Summary
fieldCoordinateSystemTransform function object attempts to write "U:Transformed" field on Windows OS even though the ":" character it not supported in file names. This results in the field not being written.
### Steps to reproduce
This can be reproduced using a modified version of the simpleFoam pipeCyclic tutorial.
1. Open a OpenFOAM-MS-DOSPrompt.bat window
2. Navigate to the attached slightly modified pipeCyclic tutorial
3. Run simpleFoam
The log will show that the field is trying to be written, but it never shows up in the time directory.
`functionObjects::fieldCoordinateSystemTransform coordinateTransform writing field: U:Transformed`
### Example case
[pipeCyclic.zip](/uploads/3059de4c995aef7c3ea9153da8be9610/pipeCyclic.zip)
### What is the current *bug* behaviour?
The U:Transformed is not written like it should be due to the Windows OS not supporting the ":" character in a file name.
### What is the expected *correct* behavior?
U:Transformed needs to be written with a compatible file name.
### Environment information
- OpenFOAM version : v1912
- Operating system : Windows 10
- Hardware info : Intel
- Compiler : MinGW
- Prompt : OpenFOAM-MS-DOSPrompt.bat
### Possible fixes
The simplest fix in my opinion would be to add the ability to change the name of the written field in the fieldCoordinateSystemTransform function object using an option like...
fields ( (U U_Transformed) );Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/1676mappedPatchBase is not updated if the sampleMesh is topochanging2022-11-02T20:33:08ZHenning ScheuflermappedPatchBase is not updated if the sampleMesh is topochanging<!--
*** 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 -->
This could be an issue in the imaginable solver: chtMultiRegionDyMFoam.
mappedPatchBase should recalculate the addressing to the sampledPatch if the sampledMesh changes its topology. The addressing should also be recalculated if the mesh owning the patch changes its topolology. This would be the case with dynamicMotionSolverFvMesh with e.g. displacementLaplacian motion solver. In case of AMR, the fields are remapped after calling mappedPatchBase::clearOut
### 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
-->
mappedPatchBaseI.H:
```
inline const Foam::mapDistribute& Foam::mappedPatchBase::map() const
{
const polyMesh& thisMesh = patch_.boundaryMesh().mesh();
bool topoChange = sampleMesh().topoChanging() || thisMesh.topoChanging();
if (topoChange)
{
mapPtr_.clear();
}
if (mapPtr_.empty())
{
calcMapping();
}
return *mapPtr_;
}
inline const Foam::AMIPatchToPatchInterpolation& Foam::mappedPatchBase::AMI
(
bool forceUpdate
) const
{
const polyMesh& thisMesh = patch_.boundaryMesh().mesh();
bool topoChange = sampleMesh().topoChanging() || thisMesh.topoChanging();
if (topoChange || forceUpdate)
{
AMIPtr_.clear();
}
if (AMIPtr_.empty())
{
calcAMI();
}
return *AMIPtr_;
}
```
mappedPatchBase.C:
```
const Foam::autoPtr<Foam::searchableSurface>& Foam::mappedPatchBase::surfPtr()
const
{
const polyMesh& thisMesh = patch_.boundaryMesh().mesh();
bool topoChange = thisMesh.topoChanging();
if (topoChange)
{
surfPtr_.clear();
}
const word surfType(surfDict_.lookupOrDefault<word>("type", "none"));
if (!surfPtr_.valid() && surfType != "none")
{
...
...
```https://develop.openfoam.com/Development/openfoam/-/issues/1677Support rigidBodyMotionState object in writeObjects2021-07-07T08:16:22ZJaap StolkSupport rigidBodyMotionState object in writeObjects### Functionality to add/problem to solve
To reduce the number of fields files written by openFoam, the normal writes can be disabled with a very large write interval and a custom "writeObjects" can be used instead. This makes it possib...### Functionality to add/problem to solve
To reduce the number of fields files written by openFoam, the normal writes can be disabled with a very large write interval and a custom "writeObjects" can be used instead. This makes it possible to specify exactly which field(s) need to be written to disk. For users interested in the rigidBodyMotionState this does not work because it is not an "Available objects in database".
### Target audience
Anyone wanting more control over which fields are written to disk, and needing the rigidBodyMotionState.
Note that re-staring a case from a saved data point requires the rigidBodyMotionState file.
It can also be used for transformations in paraFoam, to invert or match the object motion.
(as workaround, a user could try to recreate the missing rigidBodyMotionState files from the orientation information in the log.interFoam file. And maybe there are other workarounds.)
### Proposal
If it is a database object but it is not listed for some reason, make sure rigidBodyMotionState is listed when available.
If rigidBodyMotionState is not a "real" database object, it may be possible to add an option to "writeObjects" to enable writing of non-real-databse-objects, similar to how the normal write writes these files, and probably similar to how the "time" file is not listed but is written automatically.
I don't know how complex this is to add. During a normal write they are written and in the rigidBodyMotionState files header claim to be a database object.
### What does success look like, and how can we measure that?
The rigidBodyMotionState(.gz) file appearing in the processor0/0.1/uniform folders.
### example case
Using the normal write:
- start with the multiphase/interFoam/RAS/DTCHullMoving example
- change endTime to 0.2 and writeInterval to 0.1 (to speed up the test)
- Allrun
- there now is a processor0/0.1/uniform/rigidBodyMotionState file.
Using a custom write with just "U" and "points":
- copy the attached controlDict in the multiphase/interFoam/RAS/DTCHullMoving example
- Allrun
- processor0/0.1 folder now only contains the selected (U) file.
Including "rigidBodyMotionState" results in warning and no file:
- copy the attached controlDict in the multiphase/interFoam/RAS/DTCHullMoving example
- uncomment the rigidBodyMotionState line in controlDict
- Allrun
- log.interFoam contains a warning for rigidBodyMotionState, and lists the 56 objects available in the database.
### Links / references
example [controlDict](/uploads/d5a3043780580a578e69e4fa655d64d2/controlDict)
resulting warning: [log.interFoam_snippet](/uploads/d01e48fe4aee07ebd258f57adfc593b2/log.interFoam_snippet)
typical result object file: [rigidBodyMotionState](/uploads/7551e066077c035de70b75d519199051/rigidBodyMotionState)https://develop.openfoam.com/Development/openfoam/-/issues/1678isoSurfaceTopo does not respect bounds keyword2024-01-11T17:56:06ZTimofey MukhaisoSurfaceTopo does not respect bounds keyword<!--
*** 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 -->
isoSurface and isoSurfaceCell are properly truncated using `bounds`, but isoSurfaceTopo is not, the keyword seems to be ignored. Since I see
`const boundBox& bounds = boundBox::invertedBox` as a parameter to the constructor, I figure this is a bug, and not a missing feature.
### Steps to reproduce
<!-- How one can reproduce the issue - this is very important -->
- Grab the damBreak tutorial and run it.
- Put the attached `test` file into `system`.
- Run `postProcess -func test`
- Open the generated vtp files in Paraview and observe that the interfaceIsoSurfaceTopo.vtp is not truncated and x = 0.25, whereas the other two are.
### 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 : irrelevant
- Hardware info : irrelevant
- Compiler : irrelevant
[test](/uploads/f88a41f679921874c347ea132502f42a/test)https://develop.openfoam.com/Development/openfoam/-/issues/1679collated fileHandler does not adjust timePrecision2020-10-04T19:58:13ZTimofey Mukhacollated fileHandler does not adjust timePrecision<!--
*** 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
Unlike the uncollated filehandler, the collated one does not adjust the timePrecision value to be able to read the time directory.
Instead, it just crashes the run.
### Steps to reproduce
<!-- How one can reproduce the issue - this is very important -->
- Grab pretty much any tutorial case, I took pitzDaily.
- Replace the 0 directory with something like 0.1234567
- Change the file handler to collated in the controlDict, and timePrecision to something small, like 3.
- Decompose and run, it will crash.
Note that the decomposition works, and you will see the warning about adjusting timePrecision. But the solver will crash.
### What is the expected *correct* behavior?
That the timePrecision is adjusted, or at least crash with a clear error message.
### 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.
-->
```
/*---------------------------------------------------------------------------*\
| ========= | |
| \\ / F ield | OpenFOAM: The Open Source CFD Toolbox |
| \\ / O peration | Version: v1912 |
| \\ / A nd | Website: www.openfoam.com |
| \\/ M anipulation | |
\*---------------------------------------------------------------------------*/
Build : _f3950763fe-20191219 OPENFOAM=1912
Arch : "LSB;label=32;scalar=64"
Exec : simpleFoam -parallel
Date : Apr 13 2020
Time : 12:19:08
Host : DESKTOP-MPTRIAD
PID : 1600
I/O : uncollated
Case : /mnt/c/Users/tiamm/OpenFOAM/timofey-v1912/run/tests/pitzDaily
nProcs : 2
Hosts :
(
(DESKTOP-MPTRIAD 2)
)
Pstream initialized with:
floatTransfer : 0
nProcsSimpleSum : 0
commsType : nonBlocking
polling iterations : 0
trapFpe: Floating point exception trapping enabled (FOAM_SIGFPE).
fileModificationChecking : Monitoring run-time modified files using timeStampMaster (fileModificationSkew 10)
allowSystemOperations : Allowing user-supplied system call operations
// * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * //
Create time
Overriding OptimisationSwitches according to controlDict
fileHandler (unregistered)
Overriding fileHandler to collated
I/O : collated (maxThreadFileBufferSize 0)
Threading not activated since maxThreadFileBufferSize = 0.
Writing may run slowly for large file sizes.
Create mesh for time = 0.123
SIMPLE: convergence criteria
field p tolerance 0.01
field U tolerance 0.001
field "(k|epsilon|omega|f|v2)" tolerance 0.001
Reading field p
--------------------------------------------------------------------------
MPI_ABORT was invoked on rank 0 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.
--------------------------------------------------------------------------
[0]
[0]
[0] --> FOAM FATAL IO ERROR:
[0] cannot find file "/mnt/c/Users/tiamm/OpenFOAM/timofey-v1912/run/tests/pitzDaily/processor0/0.123/p"
[0]
[0] From function static Foam::autoPtr<Foam::ISstream> Foam::fileOperations::masterUncollatedFileOperation::read(Foam::IOobject&, Foam::label, bool, const fileNameList&, const boolList&)
[0] in file global/fileOperations/masterUncollatedFileOperation/masterUncollatedFileOperation.C at line 617.
[0]
FOAM parallel run exiting
[0]
```
Note that the error message is also confusing because it searches in processor0, which is not something one expects from the collated fileHandler. Easy to miss the fact that the time directory is wrong in a more practical case.
### Environment information
<!--
Providing details of your set-up can help us identify any issues, e.g.
OpenFOAM version : v1912
Operating system : ubuntu|openSUSE|centos etc
Hardware info : any info that may help?
Compiler : gcc|intel|clang etc
-->
- OpenFOAM version : v1912Mattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comhttps://develop.openfoam.com/Development/openfoam/-/issues/1680gpart: contradiction between OpenFOAM's scotch documentation and makeSCOTCH2020-07-17T11:20:49ZLouisgpart: contradiction between OpenFOAM's scotch documentation and makeSCOTCH<!--
*** 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 [documentation](https://www.openfoam.com/documentation/guides/latest/api/classFoam_1_1scotchDecomp.html#details) says on point 6 that the gpart executable can be called from `$SCOTCH_ARCH_PATH/bin` but the binaries of the scotch library are not built by the makeSCOTCH script.
My personal workaround was to modify the make command from `make libscotch` to `make` because the *libscotch* directive excludes the binaries. I also eliminate the `rm` on the compiled bin folder. I'm attaching a patch file, although I'm not sure this is the type of solution the developers are looking for (I've read that a the binaries cannot be built with a renamed scotch).
### Steps to reproduce
Taken from step 6. [here](https://www.openfoam.com/documentation/guides/latest/api/classFoam_1_1scotchDecomp.html#details):
```
source $(foamEtcFile config.sh/scotch)
export PATH=$PATH:$SCOTCH_ARCH_PATH/bin
gpart
```
### Example case
A case is not necessary because the gpart binary is not compiled.
### What is the current *bug* behaviour?
No gpart binary is available when compiled from $WM_THIRD*
### What is the expected *correct* behavior?
A gpart binary should be in `$WM_THIRD_PARTY_DIR/platforms/$WM_ARCH$WM_COMPILER$WM_PRECISION_OPTION$WM_LABEL_OPTION/$SCOTCH_VERSION/bin` aka `$SCOTCH_ARCH_PATH/bin`
### 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 : v1912 ( OpenFOAM-v1912.200403 ) [I think the issue affects many versions]
Operating system : ubuntu 20.04
### Possible fixes
See attachment (the same trick does not work for ptscotch).[makeSCOTCH.patch](/uploads/ddbaf2005a61ef074a8f957f24849d5c/makeSCOTCH.patch)
<!--
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/1681SPDP : time precision2021-11-02T09:38:58ZPrashant SonakarSPDP : time precision### Functionality to add/problem to solve
The time is stored as scalar, which can accumulate truncation errors. This can show problems with follow-on applications e.g. noise
### Proposal
- Change storage of time as e.g. solveScalar an...### Functionality to add/problem to solve
The time is stored as scalar, which can accumulate truncation errors. This can show problems with follow-on applications e.g. noise
### Proposal
- Change storage of time as e.g. solveScalar and adjust API accordingly.
- look at interpolating times e.g. temporalInterpolate
### What does success look like, and how can we measure that?
- damBreak tutorial example with changes in controlDict writeControl = runTime, adjustableTimeStep=false
- run in SPDP or SP mode.
- till 0.3 folders are good, but later have fractions e.g. 0.349999
@andy @Mattijs https://develop.openfoam.com/Development/openfoam/-/issues/1682interCondensatingEvaporatingFoam: pressure equation mass transfer source term2020-05-19T23:53:31ZDanial KhazaeiinterCondensatingEvaporatingFoam: pressure equation mass transfer source term### Summary
I was going through interCondensatingEvaporatingFoam equations derivation including constant phase change model. Considering the mass balance equation of the liquid phase (e.g. $`\alpha_{1}`$) and positive mass transfer defi...### Summary
I was going through interCondensatingEvaporatingFoam equations derivation including constant phase change model. Considering the mass balance equation of the liquid phase (e.g. $`\alpha_{1}`$) and positive mass transfer defined as being from the vapor to the liquid:
```math
\frac{\partial \left ( \alpha_{1}\rho_{1} \right )}{\partial t} + \bigtriangledown\cdot \left ( \alpha_{1}\rho_{1}\vec{U} \right ) = -\dot{m_{12}} + \dot{m_{21}}
```
with $`\dot{m_{12}} , \dot{m_{21}}> 0`$.
By summing over both phases one can derive the statement for total mass balance equation:
```math
\bigtriangledown\cdot \left ( \vec{U} \right ) = \left [ -\dot{m_{12}} + \dot{m_{21}} \right ] \left ( \frac{1}{\rho_{1}} - \frac{1}{\rho_{2}} \right )
```
Converting to the solver implementation notations, we have:
```math
\dot{m_{v}} = -\dot{m_{12}}
```
```math
\dot{m_{c}} = \dot{m_{21}}
```
Keeping in mind that the current implementation returns the mass transfer calculated for each phase with the correct sign, we can re-write the total mass balance equation with OpenFOAM notations as follow:
```math
\bigtriangledown\cdot \left ( \vec{U} \right ) = \left [ -\dot{m_{12}} + \dot{m_{21}} \right ] \left ( \frac{1}{\rho_{1}} - \frac{1}{\rho_{2}} \right ) = \dot{v_{21}} - \dot{v_{12}} = \dot{v_{c}} + \dot{v_{v}}
```
However, instead of $`\dot{v_{c}} + \dot{v_{v}}`$ the current pEqn implementation reads:
```
fvScalarMatrix p_rghEqn
(
fvc::div(phiHbyA)
- fvm::laplacian(rAUf, p_rgh)
==
vDotv - vDotc
);
```
Can you explain why the solver is using $`\dot{v_{v}} - \dot{v_{c}}`$?
It is worth to mention that the mass transfer source terms for alphaEqn and TEqn are following the correct analogy as the sign of the terms are consistent. However, there seems to be a another problem regarding how energy sources are calculated for TEqn which I try to explain below.
### Steps to reproduce
1. Run condensatingVessel tutorial with the current configuration
1. Run condensatingVessel tutorial with the coeffE = 0
The result is completely different.
### Example case
condensatingVessel
### What is the current *bug* behaviour?
When simulating a condensation only problem, the evaporation coefficient affects the solution.
### What is the expected *correct* behavior?
The evaporation coefficient should not affect the condensation only problems and vice-versa.
### Environment information
- OpenFOAM version : develop
- Operating system : Ubuntu
- Hardware info : irrelevant
- Compiler : gcc-7
### Possible fixes
The reason for this behaviour is that the constant model defines the evaporation and condensation sources simultaneously. Based on the implemented mass transfer mechanisms, a cell can only have one of the following conditions:
1. no phase change
2. evaporation
3. condensation
However, the current implementation includes phase change energy sources without considering the cell condition:
```
const volScalarField Vcoeff
(
coeffE_*mixture_.rho1()*limitedAlpha1*L
);
const volScalarField Ccoeff
(
coeffC_*mixture_.rho2()*limitedAlpha2*L
);
TSource =
fvm::Sp(Vcoeff, T) - Vcoeff*TSat
- fvm::Sp(Ccoeff, T) + Ccoeff*TSat;
```
I think the correct implementation should consider the cell condition as follow, e.g. we should not have evaporation energy source when the cell is actually condensing.
```
const volScalarField Vcoeff
(
coeffE_*mixture_.rho1()*limitedAlpha1*L*pos(T - TSat)
);
const volScalarField Ccoeff
(
coeffC_*mixture_.rho2()*limitedAlpha2*L*pos(TSat - T)
);
TSource =
fvm::Sp(Vcoeff, T) - Vcoeff*TSat
- fvm::Sp(Ccoeff, T) + Ccoeff*TSat;
```Sergio FerrarisSergio Ferrarishttps://develop.openfoam.com/Development/openfoam/-/issues/1683Overset, inverseDistance and wall contact, possible fix2021-11-19T15:19:03ZNicolas EdhOverset, inverseDistance and wall contact, possible fix### Summary
cellTypes isn't calculated correctly when walls are close or overlaps. This is a known issue. I'm proposing a fix below for inverseDistance.
### Steps to reproduce
Run the attached testcase with inverseDistance. Any other t...### Summary
cellTypes isn't calculated correctly when walls are close or overlaps. This is a known issue. I'm proposing a fix below for inverseDistance.
### Steps to reproduce
Run the attached testcase with inverseDistance. Any other tutorial is also fine just move overset meshes outside the domain.
### Example case
I’m attaching a small test case with two zones. The second zone is object that slides along the wall of the background mesh. This case works with my proposed fixes to inverseDistance. It also works with cellVolumeWeight but one has to copy cellTypes from a fixed inverseDistanceStencil to the first time step.
[wallcontact.tgz](/uploads/56c7f38dc21a0c3dda2abf907f850a7b/wallcontact.tgz)
### What is the current *bug* behaviour?
cellTypes isn't calculated correctly when walls are close or overlaps. This is a known issue, e.g. buggs [1636](https://develop.openfoam.com/Development/openfoam/issues/1636) or [1288](https://develop.openfoam.com/Development/openfoam/issues/1288).
### What is the expected *correct* behavior?
Something like the attached animation =)
[proof.avi](/uploads/9ddb09c777b3eda6ca42c0199b2b25e6/proof.avi)
Due to the coarseness of the mesh of the attached case a rather large part of where the walls intersect is cut out. I think this could be improved by a better selection of nDivs. Currently we select the number of divisions bases on sqrt(nCells) (2D). nCells is based on the entire mesh. A better choice would be sqrt(nCells) for each zone. Still this would not guarantee the same size of the voxels across processors. However for this type of case refining the mesh near the wall should be enough or manually setting nDivs.
### Environment information
OpenFOAM version : v1912
Operating system : any
Hardware info : Intel Xeon
Compiler : gcc
### Possible fixes
A first step to allowing wall contact is to make sure the cellCellStencils calculate cellTypes correctly. This is a proposed fix: [inverseDistanceCellCellStencil.C](/uploads/cf528a31bcb8523b8bcd21766d44f08a/inverseDistanceCellCellStencil.C)
There are three changes needed to inverseDistance in order for it to work and two more which I find convenient when debugging. I’m attaching a version with all five fixes.
* In markDonors we exclude primary donors that are HOLE. It’s better to include them. See attached figure of “allStencil_hole”. The near wall cells are considered HOLE. This will create a gap for walkFront to spill out from. When walkFront “spills out” we kill the entire background mesh.
There are two checks in markDonors;
`if (srcCelli != -1 && allCellTypes[srcCellMap[srcCelli]] != HOLE)`
That should be changed to
`if (srcCelli != -1)`
![badStencil_hole](/uploads/b9d48393d66b5241cd6d1fd53efe2de0/badStencil_hole.png)
* In createStencil, HOLE cells are excluded. Meaning if the primary donor is a HOLE we don’t even try to find suitable donors among its neighbours. We have two options here that both work,
1. Try to find donors and keep them even if they are all holes. It seems like nonsense but it will work. This is what’s done in cellVolumeWeight. In order to accomplish this just keep isValidDonor true for all cells. I.e. skip the loop right after it’s created.
2. The other option is to set the amount of interpolation to zero, i.e. set
cellInterpolationWeight to zero. For this to work, we still need to have isValidDonor true otherwise the cell will be removed by globalCellCells and set to HOLE.
After createStencil we need to set the “amount of interpolation to zero”. This option is what is included in the attaced file.
* In update(), right after allCellType_patch is written a check with cellTypes from the previous time step is performed. If cells have changed from HOLE to calculated they are set to interpolated. This check is no longer necessary for inverseDistance (but is what makes cellVolumeWeight work). In fact the check should be removed. The check can cause additional layers of interpolation cells which aren’t need nor wanted. This will happen for mesh courant numbers above one. To illustrate, imagine a cylinder which in one time step move say half its diameter. Half the cells where the cylinder was the prevous time step but isn’t now would be interpolated. Wolfdynamics has a nice illustration of this here: https://youtu.be/kVMA7_1YvH0?list=PLoI86R1JVvv_rDlODjff5LUWD4WX9G9vc&t=1218
* The fourth change isn’t necessary but makes debugging easier. The stencil is written out as an wavefront file. I would prefer if one file is written per region.
* I also find it use full to create a field with the size of the final stencil.
### Disclaimer
These patches just make inverseDistance behave with some sort of decency if walls between meshes are close. It’s not a guarantee that it will work. Mass won’t be preserved at all if there is a large change in volume. Change the movement to y direction instead in the test case. But I still think these patches should be included. There are many cases were only a moderate change in volume takes place when walls interact.
Secondly another solution is required for where walls intersect. The currently solution doesn’t crash and should be stable but an additional error will be introduced. For the cases I’ve tried this error is still smaller than the general mass preservation problem already present. I’ve been looking in to that with little success. At the moment I take note that overset in foam-extend is *exact* in terms of mass balance. For the same case (where no wall-to-wall interaction occurs) v1912 might have 5% error in mass while extend has an error in the order of the tolerance in the pressure equation. If there is interest I could file a different bug with my findings but I have no fix only indications to where the problem is.https://develop.openfoam.com/Development/openfoam/-/issues/1684Mixing planes in future openFOAM releases2021-11-02T09:37:31ZLorenzo CozziMixing planes in future openFOAM releases### Mixing planes at MRF interfaces
Dear developers,
I'd like to know if there are plans about introducing mixing planes in future releases of openFOAM. At least for for people working with turbomachines, this lack is a crucial limit.
Th...### Mixing planes at MRF interfaces
Dear developers,
I'd like to know if there are plans about introducing mixing planes in future releases of openFOAM. At least for for people working with turbomachines, this lack is a crucial limit.
This feature will highly benefit all those who are generally dealing with MRF steady-state RANS simulations.
As mixing planes are already available in the community-driven fork FOAM-extend, that implementation could be probably used as starting point for an introduction of this feature in the official version.
### Links / references
[https://sourceforge.net/projects/foam-extend](https://sourceforge.net/projects/foam-extend)