Development issueshttps://develop.openfoam.com/groups/Development/-/issues2022-02-11T19:03:34Zhttps://develop.openfoam.com/Development/openfoam/-/issues/2300odd behaviour with namedDictionary and/or SLList2022-02-11T19:03:34ZMark OLESENodd behaviour with namedDictionary and/or SLListStill under investigation - @Mattijs noticed that valgrind + topoSet was indicating some memory issues. v2012 is fine, v2106 and v2112 exhibit this problem. The main change between these versions is the handling of the topoSet entries. T...Still under investigation - @Mattijs noticed that valgrind + topoSet was indicating some memory issues. v2012 is fine, v2106 and v2112 exhibit this problem. The main change between these versions is the handling of the topoSet entries. There were previously a PtrList of entry, which meant that naming the action (looks like a dictionary) would not work - the reading would grab the entire content as a dictionary instead.
The problem seems to lie either with some assignment problems with namedDictionary itself, or slicing of the SLList types. Changing the List to an SLList in the topoSet application seems to indicate it might be the latter.
Testing on simpleFoam/pipeCyclic
Will investigate _after_ the v2112 release.v2206Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/2672odd/inconsistent handling of processor patches2023-02-22T10:17:23ZMark OLESENodd/inconsistent handling of processor patchesVarious items, in no particular order:
- processorFaPatchField updateInterfaceMatrix uses `add` to apply `+=` whereas the fv version calls addToInternal with the add value flipped. Looks like a long standing bug, which was inconsistent...Various items, in no particular order:
- processorFaPatchField updateInterfaceMatrix uses `add` to apply `+=` whereas the fv version calls addToInternal with the add value flipped. Looks like a long standing bug, which was inconsistently handled by scalar/non-scalar versions (see commit 0de1df7309).
- processor patchFields have hit/miss approach to transformCoupleField. In some cases the scalar versions are protected with an `is_arithmetic`, but not consistently.
@andy @Mattijs @kutiMark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/348Odd logic for treatment of blockMesh zones to sets2018-05-29T05:39:48ZMark OLESENOdd logic for treatment of blockMesh zones to setsIn the blockMesh application (around line 360 or so), the cell zones are written as sets (for ease of processing). Immediately *after* this, a `mesh.removeFiles()` is invoked prior to writing the mesh. Since the polyMesh::removeFiles als...In the blockMesh application (around line 360 or so), the cell zones are written as sets (for ease of processing). Immediately *after* this, a `mesh.removeFiles()` is invoked prior to writing the mesh. Since the polyMesh::removeFiles also removes the `sets` sub-directory, it doesn't look like the sets will survive very long.
Tagged in @Mattijs since he might have an idea.Version v1706https://develop.openfoam.com/Development/openfoam/-/issues/460odd sizing for hash tables.2017-06-29T20:38:04ZMark OLESENodd sizing for hash tables.Came across a few odd things, especially when copy/copy-constructing from other hash tables.
* HashPtrTable copy from HashPtrTable: uses default size, not related to what it is copying
* HashTable from initializer_list uses list size, n...Came across a few odd things, especially when copy/copy-constructing from other hash tables.
* HashPtrTable copy from HashPtrTable: uses default size, not related to what it is copying
* HashTable from initializer_list uses list size, not 2*list size for its table
* HashSet from HashTable uses number of keys, not the table size.Version v1706Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/1273odd timeset for ensight collated output2019-12-09T22:37:28ZMark OLESENodd timeset for ensight collated outputAs noted by @Prashant - there seem to be too many timesets when sampling.As noted by @Prashant - there seem to be too many timesets when sampling.Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/3109Odd use of ListListOps inplaceRenumber2024-02-29T15:35:33ZMark OLESENOdd use of ListListOps inplaceRenumberSighted in EnsightCellsIO.C - not clear what the compiler has even found.Sighted in EnsightCellsIO.C - not clear what the compiler has even found.Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/2675OF2212 compilation error2023-06-14T12:34:33ZThibault XAVIEROF2212 compilation error<!--
*** 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
Hi everyone,
I have an error while compiling OpenFOAM2212 on cluster using icpc. I can't really understand why and would need a hand ! Thanks for your time :smile:
Log file [log.linux64IccDPInt32Opt](/uploads/3e1f54d91bb519f7230dfde86eeb2d53/log.linux64IccDPInt32Opt) from "Allwmake -l".
Edit : same procedure applied to OpenFOAM2106 does not generate any error.
### Environment information
gcc version 4.8.5 20150623 (Red Hat 4.8.5-44) (GCC)
icpc (ICC) 19.1.0.166 20191121
mpirun (Open MPI) 4.1.4
GNU Make 3.82
cmake version 2.8.12.2
wmake version 2212
m4 (GNU M4) 1.4.16
flex 2.5.37
OS Red Hat Enterprise Linux Server version 7.9 (Maipo)https://develop.openfoam.com/Development/openfoam/-/issues/409Old changeDictionaryDict format in externalSolarLoad tutorial2020-08-31T13:08:28ZAdminOld changeDictionaryDict format in externalSolarLoad tutorialIn tutorial heatTransfer/chtMultiRegionFoam/externalSolarLoad, changeDictionaryDicts are written in the old format. No need of dictionaryReplacement sub-dict after commit 685afaafbf8ce9fe0d43bb7b6d40eb712531b617 "changeDictionary: Simpl...In tutorial heatTransfer/chtMultiRegionFoam/externalSolarLoad, changeDictionaryDicts are written in the old format. No need of dictionaryReplacement sub-dict after commit 685afaafbf8ce9fe0d43bb7b6d40eb712531b617 "changeDictionary: Simplified by removing the need for the superfluous dictionaryReplacement sub-dictionary."https://develop.openfoam.com/Development/openfoam/-/issues/1228old time field being read in postprocessing2020-01-08T14:36:46ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comold time field being read in postprocessing<!--
*** 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
-->
<!--
All text between these marker...<!--
*** 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
-->
<!--
All text between these markers are comments and will not be present in the
report
-->
### Summary
<!-- Summarize the bug encountered concisely -->
During post processing it reads the contents of the directory e.g. as volFields. There is no need to automatically read the old-time field as well. This is just an efficiency issue.
### Steps to reproduce
<!-- How one can reproduce the issue - this is very important -->
Use e.g. setFields. Copy a field to make an old-time one: ```cp zoneID zoneID_0```
Switch on debug flag for ```volScalarField``` and run ```setFields``` with relevant ```setFieldsDict```. It shows loading the old-time field.Mattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comhttps://develop.openfoam.com/Development/openfoam/-/issues/1385Old user/developer upgrade guide page should be removed2021-07-06T16:05:44ZAdminOld user/developer upgrade guide page should be removedThe user and developer upgrade guides have migrated to the wiki, but pages for older releases and https://www.openfoam.com/documentation still point to
[the old guides](https://www.openfoam.com/documentation/developer-upgrade-guide.php)...The user and developer upgrade guides have migrated to the wiki, but pages for older releases and https://www.openfoam.com/documentation still point to
[the old guides](https://www.openfoam.com/documentation/developer-upgrade-guide.php), which give a miserable impression of not being updated. The old web-pages should probably be removed and the release pages, as well as [https://www.openfoam.com/documentation](https://www.openfoam.com/documentation) should link to the Gitlab wiki.
I think the spread of parts of documentation across the Gitlab wiki, doxygen (the extended guide), ordinary web-pages, and wiki.openfoam.com is a concern. The above is an example of associated artefacts. Is there some vision for consolidation? In Python, the Sphinx package is commonly used to parse the code like doxygen and then build additional documentation using markdown/rst. There is a C++ parser in Sphinx working on top of doxygen output. Perhaps this approach could be considered?
\## Reattaching the author to the issue ticket: @timofeymukha ##AdminAdminhttps://develop.openfoam.com/Development/openfoam/-/issues/2472omegaWallFunction kinetic energy production term inconsistent with cited arti...2022-07-29T14:39:25ZPavel MačákomegaWallFunction kinetic energy production term inconsistent with cited articles<!--
*** 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 -->
This reference
_Exponential/Max blending of the viscous and inertial sublayers (tag:PH):
Popovac, M., & Hanjalić, K. (2007).
Compound wall treatment for RANS computation of complex
turbulent flows and heat transfer.
Flow, turbulence and combustion, 78(2), 177-202.
DOI:10.1007/s10494-006-9067-x_
from [omegaWallFunctionFvPatchScalarField.H](https://www.openfoam.com/documentation/guides/latest/api/omegaWallFunctionFvPatchScalarField_8H_source.html#l00046) recommends on page 193 that the production term _G0_ should be
![image](/uploads/137abb79bd529053f0c40d522588da4f/image.png).
However in code [omegaWallFunctionFvPatchScalarField.C](https://www.openfoam.com/documentation/guides/latest/api/omegaWallFunctionFvPatchScalarField_8C_source.html#l00301)
` G0[celli] +=
w
*(nutw[facei] + nuw[facei])
*magGradUw[facei]
*Cmu25*sqrt(k[celli])
/(nutw.kappa()*y[facei]);`
the term for _G0_ corresponds rather to ![image](/uploads/684346f9da580ddceaeb5f87b9296954/image.png).
### Environment information
- OpenFOAM version : v2112
### 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
-->
Change the _G0_ term to match the reference or add the reference from which the current relation was taken from.Kutalmış BerçinKutalmış Berçinhttps://develop.openfoam.com/Development/openfoam/-/issues/2214one error about a parameter in PilchErdman model for droplet breakup2021-10-05T10:50:18ZXiaoerone error about a parameter in PilchErdman model for droplet breakupHello,
In the Pilch Erdman model in OF, there is one error about the exponent of 0.25 for We > 25, see below. It should be -0.25. In the original paper by Pilch and Erdman in 1987, there was not correct for this parameter. The correct ...Hello,
In the Pilch Erdman model in OF, there is one error about the exponent of 0.25 for We > 25, see below. It should be -0.25. In the original paper by Pilch and Erdman in 1987, there was not correct for this parameter. The correct one can be found in the Eq. 2.20 from the book: https://www.routledge.com/Atomization-and-Sprays/Lefebvre-McDonell/p/book/9781498736251
else if (We > 45)
{
// bag-and-stamen breakup - eq (10)
taubBar = 14.1*pow(We - 12.0, 0.25);
}https://develop.openfoam.com/Development/openfoam/-/issues/2542Online documentation (user guide) sidebar broken2024-01-10T11:23:42ZChristian RohrOnline documentation (user guide) sidebar broken<!--
*** 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
The sidebar in the user guide is no longer functional. It doesn't show the headings or links to pages making it very difficult to find what you need, as you have to guess search terms. It stays collapsed listing only the main page no matter where you navigate or what you search for.
![image](/uploads/c4694e1879bc8c1e15060b9820c3898f/image.png)
### Steps to reproduce
Just go to the online [user guide](https://www.openfoam.com/documentation/guides/latest/doc/index.html) and try to navigate through.
Have reproduced on Edge, Firefox, Chrome.
### What is the expected *correct* behavior?
The sidebar should populate with the document structure as it does for the API guide. It did so up until about 2 weeks ago. Like this:
![image](/uploads/c180e7a6ffee807794506a23dc46dc20/image.png)https://develop.openfoam.com/Development/openfoam/-/issues/353openFOAM2018-05-29T05:39:48ZAdminopenFOAMhttps://develop.openfoam.com/Development/openfoam/-/issues/1379Openfoam 1812 over Infiniband2019-08-31T20:47:38ZAdminOpenfoam 1812 over Infiniband<!--
*** 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
-->
Hello evryone,
### Summary
I am trying to run OpenFoam 1812 over Infiniband (Mellanox) with OpenMPI 4 but it crashes at launch, I wonder if it is a compatibility issue between openfoam and openmpi.
With a simple C code I can use openmpi over infiniband (I am not exchanging data with this code though)
### Steps to reproduce
I have an openFoam case and use the following command:
`foamJob -p -s snappyHexMesh`
I add the following to my bashrc:
`export OMPI_MCA_btl_openib_allow_ib=1`
`export OMPI_MCA_btl_openib_if_include="mlx5_1:1"`
### Environment information
OpenFOAM version : v1812
Operating system : ubuntu 18.04
Hardware info : infiniband Mellanox
Compiler : gcc
### Possible fixes
I am using OpenMPI 4, but Openfoam doesn't accept it so I add a link from `libmpi.so.40` to `libmpi.so.20` because Openfoam is looking for the v2, but it is using the v4 with the link, for a calculation only on one server it is working perfectly (v4 faster than v2)
I tried to switch back to v2 but if I install it I get:
`[maui:16468] PMIX ERROR: UNPACK-PAST-END in file ../../../../../../../../../../opal/mca/pmix/pmix3x/pmix/src/mca/bfrops/v12/unpack.c at line 206`
### What is the current *bug* behaviour?
I get a segmentation fault from snappyHexMesh
```
cws@maui:~/Molokai/bench/run_32$ foamJob -p -s snappyHexMesh
Parallel processing using SYSTEMOPENMPI with 2 processors
Executing: /opt/openfoam1812/OpenFOAM-v1812/bin/mpirun -np 2 -hostfile hostfile -x FOAM_SETTINGS /opt/openfoam1812/OpenFOAM-v1812/bin/foamExec snappyHexMesh -parallel | tee log
[maui:22883] Warning: could not find environment variable "FOAM_SETTINGS"
--------------------------------------------------------------------------
WARNING: There is at least non-excluded one OpenFabrics device found,
but there are no active ports detected (or Open MPI was unable to use
them). This is most certainly not what you wanted. Check your
cables, subnet manager configuration, etc. The openib BTL will be
ignored for this job.
Local host: oahu
--------------------------------------------------------------------------
/*---------------------------------------------------------------------------*\
| ========= | |
| \\ / F ield | OpenFOAM: The Open Source CFD Toolbox |
| \\ / O peration | Version: v1812 |
| \\ / A nd | Web: www.OpenFOAM.com |
| \\/ M anipulation | |
\*---------------------------------------------------------------------------*/
Build : v1812 OPENFOAM=1812
Arch : "LSB;label=32;scalar=64"
Exec : snappyHexMesh -parallel
Date : Jul 18 2019
Time : 10:43:48
Host : maui
PID : 22891
I/O : uncollated
[maui:22891:0:22891] Caught signal 11 (Segmentation fault: address not mapped to object at address (nil))
==== backtrace ====
0 /usr/lib/libucs.so.0(+0x1ec4c) [0x7fc7ab995c4c]
1 /usr/lib/libucs.so.0(+0x1eec4) [0x7fc7ab995ec4]
===================
--------------------------------------------------------------------------
Primary job terminated normally, but 1 process returned
a non-zero exit code. Per user-direction, the job has been aborted.
--------------------------------------------------------------------------
--------------------------------------------------------------------------
mpirun noticed that process rank 0 with PID 0 on node maui exited on signal 11 (Segmentation fault).
--------------------------------------------------------------------------```https://develop.openfoam.com/Development/openfoam/-/issues/2247OpenFOAM2106 overInterDyMFoam issue2021-10-27T11:32:44ZAbhishek MukherjeeOpenFOAM2106 overInterDyMFoam issue<!--
*** 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
Unable to run the tutorial case of overInterDyMFoam floatingBody
### Steps to reproduce
In the tutorial case just execute Allrun (./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
-->
### What is the current *bug* behaviour?
(```/home/abhishek/Desktop/dam_break_test/openfoma_fsi_test/overInterDyMFoam/floatingBody/background/consta\
nt/dynamicMeshDict.sixDoFRigidBodyMotionCoeffs.#codeStream: In function ‘void Foam::codeStream_a63eab21\
7afa7dd34ef7da3a82ee21fc2b054ce0(Foam::Ostream&, const Foam::dictionary&)’:
/home/abhishek/Desktop/dam_break_test/openfoma_fsi_test/overInterDyMFoam/floatingBody/background/consta\
nt/dynamicMeshDict.sixDoFRigidBodyMotionCoeffs.#codeStream:58:17: error: ‘diagTensor’ was not declared \
in this scope; did you mean ‘DiagTensor’?
make: *** [/media/abhishek/WD-phd/OpenFOAM/OpenFoam-2106/OpenFOAM-v2106/wmake/rules/General/transform:3\
5: Make/linux64GccDPInt32Opt/codeStreamTemplate.o] Error 1
--> FOAM FATAL IO ERROR: (openfoam-2106)
Failed wmake "dynamicCode/_a63eab217afa7dd34ef7da3a82ee21fc2b054ce0/platforms/linux64GccDPInt32Opt/lib/\
libcodeStream_a63eab217afa7dd34ef7da3a82ee21fc2b054ce0.so"```)
### 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 : v2106
Operating system : ubuntu
Hardware info : any info that may help?
Compiler : gcc
-->
- OpenFOAM version : v2106
- Operating system : ubuntu
- Hardware info :
- 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
-->https://develop.openfoam.com/Development/openfoam/-/issues/2449OpenFOAM 2112 build issues - ld.lld: error: undefined symbol:referenced by MP...2022-06-03T13:21:46ZNaina PatilOpenFOAM 2112 build issues - ld.lld: error: undefined symbol:referenced by MPPICInterFoam.C<!--
*** 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
OpenFOAM 2112 completes the build with the following error-ld.lld: error: undefined symbol: typeinfo for Foam::regionModels::regionFaModel
referenced by MPPICInterFoam.C
This doesn't result in desired number of binaries end of build
### Steps to reproduce
```
export OPENFOAMROOT=<Path_to_OpenFOAM_Installtion> ##current working directory/ PWD ##
wget https://dl.openfoam.com/source/v2112/OpenFOAM-v2112.tgz
wget https://dl.openfoam.com/source/v2112/ThirdParty-v2112.tgz
cd $OPENFOAMROOT
tar -xzf OpenFOAM-v2112.tgz
tar -xzf ThirdParty-v2112.tgz
export WM_CXXFLAGS="$CFLAGS"
export WM_CFLAGS="$CXXFLAGS"
```
##### Edit/Modify these files as per AOCC
```
$OPENFOAMROOT/OpenFOAM-v2112/etc/bashrc
sed -i 's/WM_COMPILER=Gcc/WM_COMPILER=Amd/' $OPENFOAMROOT/OpenFOAM-v2112/etc/bashrc
$OPENFOAMROOT/OpenFOAM-v2112/etc/config.sh/mpi
export MPI_ARCH_PATH= Path to OpenMPI installation
source $OPENFOAMROOT/OpenFOAM-v2112/etc/bashrc
echo $WM_PROJECT_DIR
```
##### Build OpenFOAM-v2112
```
cd $OPENFOAMROOT/OpenFOAM-v2112
time ./Allwmake -j 64 all -k 2>&1 |tee OpenFOAM_AOCC_install.log
source $OPENFOAMROOT/OpenFOAM-v2112/etc/bashrc
```
### What is the current *bug* behaviour?
ldd error referencing MPPICInterFoam.C during build. This results in incorrect number of binaries.
### What is the expected *correct* behavior?
clean build without ldd error. 312 binaries are expected. But 311 entries are generated.
### Relevant logs and/or images
ld.lld: error: undefined symbol: typeinfo for Foam::regionModels::regionFaModel
referenced by MPPICInterFoam.C
v2112/build/linux64AmdDPInt32Opt/applications/solvers/multiphase/MPPICInterFoam/MPPICInterFoam.ovoid Foam::SurfaceFilmModel<Foam::KinematicCloud<Foam:: Cloud<Foam::KinematicParcel<Foam:article> > > >::inject<Foam::KinematicCloud<Foam::Cloud<Foam::K inematicParcel<Foam:article> > > >(Foam::KinematicCloud<Foam::Cloud<Foam::Kinematic Parcel<Foam:article> > >&))
referenced by MPPICInterFoam.C
### Environment information
Providing details of your set-up can help us identify any issues, e.g.
OpenFOAM version : v2112
Operating system : centos 8.3
Hardware info : AMD Epyc 7763
Compiler : clang/Aocc 3.2
### Possible fixes
We have currently found a workaround by linking -lregionFaModels in the line
"LINK_LIBS = $(c++DBUG) -Wl,--as-needed **-lregionFaModels**"
path - OpenFOAM-v2112/wmake/rules/General/Amd/link-c++
do we have any official fix for this ?Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/2927OpenFOAM 2306 build instructions and source tgz files2023-07-03T15:02:57ZDavid HuckabyOpenFOAM 2306 build instructions and source tgz files
The file for the current build instructions from source reference the v2212 files:
https://develop.openfoam.com/Development/openfoam/-/blob/master/doc/Build.md
```
* Source: https://dl.openfoam.com/source/v2212/OpenFOAM-v2212.tgz
* Thi...
The file for the current build instructions from source reference the v2212 files:
https://develop.openfoam.com/Development/openfoam/-/blob/master/doc/Build.md
```
* Source: https://dl.openfoam.com/source/v2212/OpenFOAM-v2212.tgz
* ThirdParty: https://dl.openfoam.com/source/v2212/ThirdParty-v2212.tgz
```
And the directory for the latest distribution: https://dl.openfoam.com/source/latest/
does not include a source file, e.g. "OpenFOAM-v2306.tgz" for the 2306 version.https://develop.openfoam.com/Development/openfoam/-/issues/68OPenFoam3.0+ on windows 7: blockMesh killed when using more than ~1M cells2016-02-11T12:13:13ZAdminOPenFoam3.0+ on windows 7: blockMesh killed when using more than ~1M cellsHello,
I have a problem with large meshes more than 1M cells.
I'm using OpenFoam on Windows 7. I copied the cavity tutorial to my working directory and gradually increased the number of nodes. When the resulting mesh is larger than a...Hello,
I have a problem with large meshes more than 1M cells.
I'm using OpenFoam on Windows 7. I copied the cavity tutorial to my working directory and gradually increased the number of nodes. When the resulting mesh is larger than about 1M cells, the process is killed without an error message. I checked that ulimit is unlimited and checked through task manager that there is enough memory available.
Does anyone have a clue?
Alexander Pawan GhildiyalPawan Ghildiyalhttps://develop.openfoam.com/Development/openfoam/-/issues/2799OpenFOAM applications depending on libOpenFOAM.so fail to link since commit 7...2023-06-19T09:19:09ZMartin BeaudoinOpenFOAM applications depending on libOpenFOAM.so fail to link since commit 73f6c7fe28c833445c2b907ae9b43ca867da2f5d when compiling with g++ and WM_COMPILE_OPTION=Debug<!--
*** 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
When using the 'develop' branch from the OpenFOAM Git repository, since commit 73f6c7fe28c833445c2b907ae9b43ca867da2f5d, all applications compiled with the g++ compiler using **WM_COMPILE_OPTION=Debug** cannot link with libOpenFOAM.so because of an undefined reference to `Foam::UPstream::selfComm'.
This problem is not present when using with the same compiler with the compilation optimization enabled (WM_COMPILE_OPTION=Opt)
<!-- Summarize the bug encountered concisely -->
### Steps to reproduce
- Checkout the latest version of the develop branch from the OpenFOAM Git repository : https://develop.openfoam.com/Development/openfoam/-/tree/develop?ref_type=heads
- Define WM_COMPILE_OPTION=Debug in your file etc/prefs.sh
- Recompile everything (libs and apps) from scratch
- All link operations of applications (using /usr/bin/ld) that depend on libOpenFOAM.so will fail.
- Using 'git bisect', one can isolate the problematic commit to 73f6c7fe28c833445c2b907ae9b43ca867da2f5d
<!-- How one can reproduce the issue - this is very important -->
### Example case
Error messages when trying to link the application laplacianFOAM with g++ in Debug mode:
`g++ -std=c++11 -m64 -pthread -DOPENFOAM=2302 -DWM_DP -DWM_LABEL_SIZE=32 -Wall -Wextra -Wold-style-cast -Wnon-virtual-dtor -Wno-unused-parameter -Wno-invalid-offsetof -Wno-attributes -Wno-unknown-pragmas -O0 -fdefault-inline -ggdb3 -DFULLDEBUG -DNoRepository -ftemplate-depth-100 -I/scratch/cfd/openfoam/ESI-OpenFOAM-dev_bug/src/finiteVolume/lnInclude -I/scratch/cfd/openfoam/ESI-OpenFOAM-dev_bug/src/meshTools/lnInclude -iquote. -IlnInclude -I/scratch/cfd/openfoam/ESI-OpenFOAM-dev_bug/src/OpenFOAM/lnInclude -I/scratch/cfd/openfoam/ESI-OpenFOAM-dev_bug/src/OSspecific/POSIX/lnInclude -fPIC -Xlinker --add-needed -Xlinker --no-as-needed /scratch/cfd/openfoam/ESI-OpenFOAM-dev_bug/build/linux64GccDPInt32Debug/applications/solvers/basic/laplacianFoam/laplacianFoam.o -L/scratch/cfd/openfoam/ESI-OpenFOAM-dev_bug/platforms/linux64GccDPInt32Debug/lib \
-lfiniteVolume -lfvOptions -lmeshTools -lOpenFOAM -ldl \
-ggdb3 -DFULLDEBUG -lm -o /scratch/cfd/openfoam/ESI-OpenFOAM-dev_bug/platforms/linux64GccDPInt32Debug/bin/laplacianFoam
/usr/bin/ld: /scratch/cfd/openfoam/ESI-OpenFOAM-dev_bug/platforms/linux64GccDPInt32Debug/lib/libOpenFOAM.so: **undefined reference to \`Foam::UPstream::selfComm'**
collect2: error: ld returned 1 exit status
make: *** [/scratch/cfd/openfoam/ESI-OpenFOAM-dev_bug/wmake/makefiles/general:170: /scratch/cfd/openfoam/ESI-OpenFOAM-dev_bug/platforms/linux64GccDPInt32Debug/bin/laplacianFoam] Error 1
`
<!--
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?
Cannot link any applications depending on libOpenFOAM.so when compiling the 'develop' version of OpenFOAM in debug mode.
<!-- What actually happens -->
### What is the expected *correct* behavior?
Proper linking of applications, as it is the case when the g++ compilation optimization is enabled (WM_COMPILE_OPTION=Opt)
<!-- What you should see instead -->
### Relevant logs and/or images
/usr/bin/ld: /scratch/cfd/openfoam/ESI-OpenFOAM-dev_bug/platforms/linux64GccDPInt32Debug/lib/libOpenFOAM.so: undefined reference to \`Foam::UPstream::selfComm'
<!--
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 : v2212|v2206|v2112|v2106|v2012 etc
Operating system : ubuntu|openSUSE|centos etc
Hardware info : any info that may help?
Compiler : gcc|intel|clang etc
-->
- OpenFOAM version : develop version using -DOPENFOAM=2302
- Operating system : Fedora release 33
- Hardware info : AMD Ryzen Threadripper 3970X
- Compiler : g++ (GCC) versions 10.3.1, 12.3.0 and 13.1.0. All 3 versions of the g++ compilers have the same behaviour.
### Possible fixes
The source of the problem is the following declaration of the static class member _Foam::UPstream::selfComm_ in src/OpenFOAM/db/IOstreams/Pstreams/UPstream.H
```
//- A communicator within the current rank only
static constexpr label selfComm = 1;
```
This kind of declaration of a class static data member is allowed since C++11, but it looks like the proper implementation by GNU g++ is only done when the compilation optimization is enabled (-O1, -O2, -O3), probably by converting 'selfComm' to an inline declaration. This inline conversion is probably not done when the g++ optimization is disabled (-O0).
When invoking g++ with C++17 enabled, then the linking problem in Debug mode goes away, probably because the data member _Foam::UPstream::selfComm_ gets inlined with or without the compiler code optimization being enabled.
See here : https://en.cppreference.com/w/cpp/language/static
And here: https://stackoverflow.com/questions/8016780/undefined-reference-to-static-constexpr-char
Possible solutions:
- Use the C++17 flavour of the language with g++ (-std=c++17) instead of the C++11 variant (-std=c++11).
- Declare and initialize the static data member the old way. For example, the following modifications will fix the compilation/linking problem:
```
diff --git a/src/OpenFOAM/db/IOstreams/Pstreams/UPstream.C b/src/OpenFOAM/db/IOstreams/Pstreams/UPstream.C
index e78777626f..9545ceb18b 100644
--- a/src/OpenFOAM/db/IOstreams/Pstreams/UPstream.C
+++ b/src/OpenFOAM/db/IOstreams/Pstreams/UPstream.C
@@ -61,6 +61,8 @@ Foam::UPstream::commsTypeNames
namespace Foam
{
+Foam::label Foam::UPstream::selfComm=1;
+
// Determine host grouping.
// Uses SHA1 of hostname instead of MPI_Comm_split or MPI_Comm_split_type
// for two reasons:
diff --git a/src/OpenFOAM/db/IOstreams/Pstreams/UPstream.H b/src/OpenFOAM/db/IOstreams/Pstreams/UPstream.H
index acbd44c17d..f006e73f4d 100644
--- a/src/OpenFOAM/db/IOstreams/Pstreams/UPstream.H
+++ b/src/OpenFOAM/db/IOstreams/Pstreams/UPstream.H
@@ -318,7 +318,7 @@ public:
static constexpr label globalComm = 0;
//- A communicator within the current rank only
- static constexpr label selfComm = 1;
+ static label selfComm;
//- Communicator for all ranks, irrespective of any local worlds
static constexpr label commGlobal() noexcept { return 0; }
```
<!--
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
-->Mark OLESENMark OLESEN