Development issueshttps://develop.openfoam.com/groups/Development/-/issues2020-07-17T11:20:49Zhttps://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/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/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/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/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/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/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/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/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/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/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/1661Dummy library such as Pstream is used on macOS2023-05-31T11:06:18ZShigeki FujiiDummy library such as Pstream is used 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
While executing in parallel mode, the dummy Pstream library is used.
But there is correct Pstream library in $FOAM_LIBBIN/$FOAM_MPI.
### Steps to reproduce
After building the ThirdPaty code, it is necessary for the following command.
`for i in $FOAM_EXT_LIBBIN/*.dylib ;do
install_name_tool -id $i $i
done`
After that, build the OpenFOAM code.
On the directory of tutorials/incompressible/icoFoam/cavityMappingTest.
`./Allrun-parallel`
<!-- How one can reproduce the issue - this is very important -->
### Example case
In the "log.icoFOAM,
` --> FOAM FATAL ERROR:
The dummy Pstream library cannot be used in parallel mode
From function static bool Foam::UPstream::init(int &, char **&, const bool)
in file UPstream.C at line 50.
FOAM exiting`
<!--
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 -->
FOAM FATAL ERROR.
### What is the expected *correct* behavior?
<!-- What you should see instead -->
Normal exiting in parallel mode.
### 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
-->
Current macOS ignores the path of LD_LIBRARY_PATH and DYLD_LIBRARY_PATH.
So dummy library was loaded instead of correct library.
On macOS, it has to use the library path explicitly.
I attached the patch file.
[parallel.patch](/uploads/1fa8e514ec6dc0db3e1e357889bdf82a/parallel.patch)https://develop.openfoam.com/Development/openfoam/-/issues/1660argList destructor circumvents main return2020-04-01T16:53:54ZMark OLESENargList destructor circumvents main returnAs discussed with @andy and now @Mattijs, using `return` from `main()` circumvents the exit-code.
Traced to the use of Pstream::exit() from the ParRunControl.
Will fix by adding in a separate Pstream::shutdown method.As discussed with @andy and now @Mattijs, using `return` from `main()` circumvents the exit-code.
Traced to the use of Pstream::exit() from the ParRunControl.
Will fix by adding in a separate Pstream::shutdown method.Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/1659wallHeatFlux and P1 radiation2020-04-06T05:59:03ZTj KimwallHeatFlux and P1 radiation<!--
*** 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 postProcessing with wallHeatFlux, P1 radiation heat flux is not added. So only the convective heat flux is calculated and saved in the field of "wallHeatFlux"
### Steps to reproduce
<!-- How one can reproduce the issue - this is very important -->
### Example case
<!--
If possible, please create a SMALL example and attach it to your report
If you are using an older version of OpenFOAM this will also determine
whether the bug has been fixed in a more recent version
-->
### What is the current *bug* behaviour?
<!-- What actually happens --> WallHeatFlux function gives same heat flux in the cases without radiation and with P1 radiation
### What is the expected *correct* behavior?
<!-- What you should see instead -->
WallHeatFlux in the case with P1 radiation must be larger than WallHeatFlux in the case without radiation.
### Relevant logs and/or images
<!--
Paste any relevant logs - please use code blocks (```) to format console
output, logs, and code as it's very hard to read otherwise.
-->
### Environment information
<!--
Providing details of your set-up can help us identify any issues, e.g.
OpenFOAM version : v1806|v1812|v1906 etc
Operating system : ubuntu|openSUSE|centos etc
Hardware info : any info that may help?
Compiler : gcc|intel|clang etc
-->
- OpenFOAM version : v1906
- Operating system : ubuntu
- Hardware info : Intel I7 PC
- Compiler : gcc
### 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
-->
The problem is from that in P1.C code read-option of qr is NO_READ. On the contrary in FvDOM.C read-option of qr is READ_IF_PRESENT.
When the read-option of qr in P1.C code is changed to READ_IF_PRESENT, wallHeatFlux function gives the sum of convective and radiative heat flux.https://develop.openfoam.com/Development/openfoam/-/issues/1658STL-incompatible labelHashSet iterators2020-04-02T15:18:55ZAlexey MatveichevSTL-incompatible labelHashSet iterators# Error description
Implementation of labelHashSet iterators produces the following compilation error:
```
In file included from containers/HashTables/HashOps/HashOps.C:28:
In file included from containers/HashTables/HashOps/HashOps.H:...# Error description
Implementation of labelHashSet iterators produces the following compilation error:
```
In file included from containers/HashTables/HashOps/HashOps.C:28:
In file included from containers/HashTables/HashOps/HashOps.H:46:
In file included from lnInclude/HashSet.H:68:
In file included from lnInclude/HashTable.H:86:
In file included from lnInclude/word.H:46:
In file included from lnInclude/string.H:55:
In file included from /Library/Developer/CommandLineTools/usr/bin/../include/c++/v1/string:504:
In file included from /Library/Developer/CommandLineTools/usr/bin/../include/c++/v1/string_view:175:
In file included from /Library/Developer/CommandLineTools/usr/bin/../include/c++/v1/__string:56:
/Library/Developer/CommandLineTools/usr/bin/../include/c++/v1/algorithm:2587:66: error: no type named 'value_type' in
'std::__1::iterator_traits<Foam::HashTable<Foam::zero::null, long long, Foam::Hash<Foam::label>
>::key_iterator_base<Foam::HashTable<Foam::zero::null, long long, Foam::Hash<Foam::label> >::const_iterator> >'
__less<typename iterator_traits<_ForwardIterator>::value_type>());
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~
containers/HashTables/HashOps/HashOps.C:84:27: note: in instantiation of function template specialization
'std::__1::max_element<Foam::HashTable<Foam::zero::null, long long, Foam::Hash<Foam::label>
>::key_iterator_base<Foam::HashTable<Foam::zero::null, long long, Foam::Hash<Foam::label> >::const_iterator> >' requested here
auto const max = std::max_element(locations.begin(), locations.end());
^
1 error generated.
```
The error happens in two locations - HashOps.C:84 and bitSetTemplates.C:79 - during invocation of std::max_element.
# Environment
OpenFOAM(R) version: 1912
OS: macOS (10.15.4)
Compiler: Apple clang version 11.0.3 (clang-1103.0.32.29)
# Possible fix
Unfortunately I was not able to find the root of the error, so I have changed max_element invocations to its naive implementation:
```cpp
#ifndef __APPLE__
auto const max = std::max_element(locations.begin(), locations.end());
#else
auto max = locations.begin();
auto first = locations.begin();
auto last = locations.end();
for (; first != last; ++first)
if (*max < *first) max = first;
#endif
```Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/1657deprecated attribute location2020-04-02T15:53:02ZAlexey Matveichevdeprecated attribute location<!--
*** 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
Location of `FOAM_DEPRECATED` and `FOAM_DEPRECATED_FOR` macros invocations is incorrect. It is placed between type and method name, while according to [1] it should be before type.
1. https://en.cppreference.com/w/cpp/language/attributes/deprecated
### Steps to reproduce
Build OpenFOAM v1912 with `std=c++14`. Yes, currently code should be built with std=c++11 but eventually it will be upgraded to newer standard.
### Example case
This change resolve the issue (example from `dictionary.H`):
```patch
- ITstream& FOAM_DEPRECATED_FOR(2018-07, "lookup() method")
- operator[](const word& keyword) const
+ FOAM_DEPRECATED_FOR(2018-07, "lookup() method")
+ ITstream& operator[](const word& keyword) const
```
### What is the current *bug* behaviour?
If code is compiled with `std=c++14` current location of macros invocation produces the error:
```
~/OpenFOAM/OpenFOAM-v1912/src/OpenFOAM/lnInclude/SLListBase.H:223:18: error: 'deprecated' attribute cannot be applied to
types
bool FOAM_DEPRECATED_FOR(2019-01, "good() method") found() const
^
~/OpenFOAM/OpenFOAM-v1912/src/OpenFOAM/lnInclude/stdFoam.H:59:52: note: expanded from macro 'FOAM_DEPRECATED_FOR'
# define FOAM_DEPRECATED_FOR(since, replacement) [[deprecated("Since " #since "; use " #replacement)]]
```
### What is the expected *correct* behavior?
Compilation with correct location of the attribute does not produce error.
### 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 : N/A
- Compiler : Apple clang version 11.0.3 (clang-1103.0.32.29)
### Possible fixes
Move macros invocation to correct location. See: [deprecated-attribute.patch](/uploads/0c7814dfce119ceca223aa5b65d59f68/deprecated-attribute.patch).Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/1656OpenMP flags on macOS2022-09-13T04:12:17ZAlexey MatveichevOpenMP flags on macOS### Functionality to add/problem to solve
Current wmake rules for OpenMP produce compilation error on macOS. As a consequence cfMesh is not built.
### Target audience
People, who would like to build and use OpenFOAM(R) on macOS.
##...### Functionality to add/problem to solve
Current wmake rules for OpenMP produce compilation error on macOS. As a consequence cfMesh is not built.
### Target audience
People, who would like to build and use OpenFOAM(R) on macOS.
### Proposal
Add the following to `wmake/rules/General/darwin64Clang/openmp`:
```
COMP_OPENMP = -DUSE_OMP -Xpreprocessor -fopenmp
LINK_OPENMP = -lomp
```
libomp (https://openmp.llvm.org/) should be installed separately.
### What does success look like, and how can we measure that?
cfMesh is built.
### Links / references
1. https://stackoverflow.com/questions/40095958/apple-clang-fopenmp-not-working
### Funding
N/AMark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/1655support alternative expansion schemes2020-06-19T14:28:10ZMark OLESENsupport alternative expansion schemesNotably in PDRblockMesh, but perhaps also for regular blockMesh it can be confusing to have the geometric expansion factor. A relative expansion factor might be more user-friendly.
@pratapNotably in PDRblockMesh, but perhaps also for regular blockMesh it can be confusing to have the geometric expansion factor. A relative expansion factor might be more user-friendly.
@pratapMark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/1653MarshakRadiation bc not mapped correctly2020-04-08T05:54:11ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comMarshakRadiation bc not mapped correctly<!--
*** 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 -->
MarshakRadiation bc not mapped correctly. You can see this e.g. in redistributePar of a case with radiation and marshakRadiation bcs.
### Steps to reproduce
<!-- How one can reproduce the issue - this is very important -->
Any case with marshakRadiation bcs:
```
mpirun redistributePar -parallel -decompose
```Mattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comhttps://develop.openfoam.com/Development/openfoam/-/issues/1651Missing "interface.correct();" in interCondensatingEvaporatingFoam2020-03-30T17:35:58ZSebastian BorrmannMissing "interface.correct();" in interCondensatingEvaporatingFoam<!--
*** 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 interface in interCondensatingEvaporatingFoam is not reproduced correctly if sigma > 0
### Steps to reproduce
<!-- How one can reproduce the issue - this is very important -->
Run the example case with interCondensatingEvaporatingFoam. After 1 s you will already see a deformed interface in paraview.
### 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
-->
[buggedCase.tar.gz](/uploads/81d0b0736377ea0cdc1c6cdd0b8fd0d5/buggedCase.tar.gz)
### What is the current *bug* behaviour?
<!-- What actually happens -->
The interface between liquid and gas deforms (see Figure 1). The deformation in the testcase might actually happen due to parasitic currents. But the surface tension doesn't correct the interface as it would do in interFoam.
### What is the expected *correct* behavior?
<!-- What you should see instead -->
See Figure 2
### 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.
-->
![bugged](/uploads/11133c9f0b9d4323714c9534ad528af9/bugged.png)
Figure 1
![fixed](/uploads/6d9a5c11d1a8e305532dedb9c5f06873/fixed.png)
Figure 2
### 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 : Debian
### 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
-->
Add the folowing line to interCondensatingEvaporatingFoam (I added it behind #include "alphaEqnSubCycle.H"):
```C++
121 interface.correct();
```