Development issueshttps://develop.openfoam.com/groups/Development/-/issues2017-01-02T12:22:58Zhttps://develop.openfoam.com/Development/openfoam/-/issues/296Native ofs format appears to be broken.2017-01-02T12:22:58ZMark OLESENNative ofs format appears to be broken.This format is little-used, but relying on raw stream operators for the native format breaks down when different face types (face vs. triFace vs. labelledFace) are being used. It is still reasonable to have stream operators for pass arou...This format is little-used, but relying on raw stream operators for the native format breaks down when different face types (face vs. triFace vs. labelledFace) are being used. It is still reasonable to have stream operators for pass around data (eg, between processors), but they shouldn't be used for files. Otherwise we can easily create a binary file using triFace or labelledFace and not be able to read it back with normal face.
Additionally, the static OFSsurfaceFormat::read functions are too fragile (broken).
Suggest removing entirely. @andyVersion v1612Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/1574native reduce for solveScalar2020-04-15T08:53:57ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comnative reduce for solveScalar### Functionality to add/problem to solve
Foam::reduce is specialised for summation of scalar but not solveScalar. Hence in SPDP mode it will fall back to non-native reduce (might be slower)
### Target audience
Parallel running### Functionality to add/problem to solve
Foam::reduce is specialised for summation of scalar but not solveScalar. Hence in SPDP mode it will fall back to non-native reduce (might be slower)
### Target audience
Parallel runninghttps://develop.openfoam.com/Development/openfoam/-/issues/2290Native Windows binaries using MSYS22022-02-11T19:04:35ZFoadNative Windows binaries using MSYS2It appears as if the [natively](https://develop.openfoam.com/Development/openfoam/-/wikis/precompiled/windows#native-windows) compiled OpenFOAM package using MSYS2 and MinGW compilers/toolchain, requires [admin rights](https://www.cfd-on...It appears as if the [natively](https://develop.openfoam.com/Development/openfoam/-/wikis/precompiled/windows#native-windows) compiled OpenFOAM package using MSYS2 and MinGW compilers/toolchain, requires [admin rights](https://www.cfd-online.com/Forums/openfoam-installation/221673-question-opencfd-openfoam-v1906-dp-mingw-crosscompiled-windowsinstaller-exe.html#post751113). This is counterproductive as anyone having admin privileges would rather WSL immediately.
Trying to install the package on a Windows machine without the admin rights leads to the infamous
> path/to/folder/v2106/msys64/home/ofuser/OpenFOAM/OpenFOAM-v2106/platforms/win64MingwDPInt32Opt/bin/blockMesh.exe: error while loading shared libraries: libstdc++-6.dll: cannot open shared object file: No such file or directory
errors and others as I have explained [here](https://stackoverflow.com/q/70256103/4999991). MSYS2 folks tried helping me [here](https://discordapp.com/channels/792780131906617355/794889490941476915/918068453057921025) on their Discord server, to no avail. The MSYS2 now updates, but we are stuck at `msmpi` dependency. It would be great if you could
- provide a temporary workaround to solve the missing `libstdc++-6.dll` and `msmpi.dll`
- update/upgrade the underlying MSYS2 layer of the package
- provide some versions without MPI or use the MSYS2/MinGW native packages over externally installed ones.Pawan GhildiyalPawan Ghildiyalhttps://develop.openfoam.com/Development/openfoam/-/issues/1464nearWallFields does not produce correct sampling location2019-12-23T14:53:36ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comnearWallFields does not produce correct sampling 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
<!-- Summarize the bug encountered concisely -->
nearWallFields uses mappedPatchBase::facePoint to find a starting location which is on a tet-face when using the FACE_DIAG cell decomposition. Even on e.g. pitzDaily this might not find a point for all wall faces. Run e.g. nearWallFields with
```
type nearWallFields;
fields
(
(U UNear)
);
// Patches/groups to sample (regular expressions)
patches (wall);
// Distance to sample
distance 0.00001;
```
the fourth face on the top-wall is not found correctly and it falls back to the cell centre.
2) the destination for tracking is calculated from the fall-back cell centre in above case instead of the wanted location on the wall face.
See the UNear on the top-wall. Above tiny distance (0.00001) should produce near-zero.
![topWall](/uploads/b303ab599ba14ba04a2e14c2341252ae/topWall.png)https://develop.openfoam.com/Development/openfoam/-/issues/1620nearWallFields function object fails2020-03-13T12:44:54ZMatej FormannearWallFields function object failsnearWallFiedls (version 1912) fails and particular geometry reporting error message:
```
--> FOAM FATAL ERROR:
object of type N4Foam14PatchFunction1INS_6VectorIdEEEE is unallocated
From function T* Foam::autoPtr<T>::operator->() [w...nearWallFiedls (version 1912) fails and particular geometry reporting error message:
```
--> FOAM FATAL ERROR:
object of type N4Foam14PatchFunction1INS_6VectorIdEEEE is unallocated
From function T* Foam::autoPtr<T>::operator->() [with T = Foam::PatchFunction1<Foam::Vector<double> >]
in file /scratch/pss/2010560/OpenFOAM/OpenFOAM.master.int32DP/src/OpenFOAM/lnInclude/autoPtrI.H at line 222.
FOAM aborting
#0 Foam::error::printStack(Foam::Ostream&) in /nisprod/openfoam/release/latest/OpenFOAM-v1912/platforms/linux64Gcc48DPInt32Opt/lib/libOpenFOAM.so
#1 Foam::error::abort() in /nisprod/openfoam/release/latest/OpenFOAM-v1912/platforms/linux64Gcc48DPInt32Opt/lib/libOpenFOAM.so
#2 Foam::uniformFixedValueFvPatchField<Foam::Vector<double> >::write(Foam::Ostream&) const in /nisprod/openfoam/release/latest/OpenFOAM-v1912/platforms/linux64Gcc48DPInt32Opt/lib/libfiniteVolume.so
#3 Foam::GeometricField<Foam::Vector<double>, Foam::fvPatchField, Foam::volMesh>::Boundary::writeEntries(Foam::Ostream&) const in /nisprod/openfoam/release/latest/OpenFOAM-v1912/platforms/linux64Gcc48DPInt32Opt/bin/simpleFoam
#4 Foam::Ostream& Foam::operator<< <Foam::Vector<double>, Foam::fvPatchField, Foam::volMesh>(Foam::Ostream&, Foam::GeometricField<Foam::Vector<double>, Foam::fvPatchField, Foam::volMesh> const&) in /nisprod/openfoam/release/latest/OpenFOAM-v1912/platforms/linux64Gcc48DPInt32Opt/bin/simpleFoam
#5 Foam::GeometricField<Foam::Vector<double>, Foam::fvPatchField, Foam::volMesh>::writeData(Foam::Ostream&) const in /nisprod/openfoam/release/latest/OpenFOAM-v1912/platforms/linux64Gcc48DPInt32Opt/bin/simpleFoam
#6 Foam::fileOperation::writeObject(Foam::regIOobject const&, Foam::IOstreamOption::streamFormat, Foam::IOstreamOption::versionNumber, Foam::IOstreamOption::compressionType, bool) const in /nisprod/openfoam/release/latest/OpenFOAM-v1912/platforms/linux64Gcc48DPInt32Opt/lib/libOpenFOAM.so
#7 Foam::regIOobject::writeObject(Foam::IOstreamOption::streamFormat, Foam::IOstreamOption::versionNumber, Foam::IOstreamOption::compressionType, bool) const in /nisprod/openfoam/release/latest/OpenFOAM-v1912/platforms/linux64Gcc48DPInt32Opt/lib/libOpenFOAM.so
#8 Foam::functionObjects::nearWallFields::write() in /nisprod/openfoam/release/latest/OpenFOAM-v1912/platforms/linux64Gcc48DPInt32Opt/lib/libfieldFunctionObjects.so
#9 Foam::functionObjects::timeControl::write() in /nisprod/openfoam/release/latest/OpenFOAM-v1912/platforms/linux64Gcc48DPInt32Opt/lib/libOpenFOAM.so
#10 Foam::functionObjectList::execute() in /nisprod/openfoam/release/latest/OpenFOAM-v1912/platforms/linux64Gcc48DPInt32Opt/lib/libOpenFOAM.so
#11 ? in /nisprod/openfoam/release/latest/OpenFOAM-v1912/platforms/linux64Gcc48DPInt32Opt/bin/simpleFoam
#12 __libc_start_main in /lib64/libc.so.6
#13 ? in /nisprod/openfoam/release/latest/OpenFOAM-v1912/platforms/linux64Gcc48DPInt32Opt/bin/simpleFoam
```
Apparently fails only with velocity (vector) and runs ok on e.g. pressure field.
checkMesh does not report any unusual error on a mesh coming from SHM.https://develop.openfoam.com/Development/openfoam/-/issues/272Need base64 encoding layer for vtk xml formats.2017-01-02T12:24:52ZMark OLESENNeed base64 encoding layer for vtk xml formats.Need to move to XML-based formats in order to properly support 64-bit labels (see issue #270).Need to move to XML-based formats in order to properly support 64-bit labels (see issue #270).Version v1612Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/2220needing threaded mpi for maxThreadFileBufferSize>02021-12-22T14:48:50ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comneeding threaded mpi for maxThreadFileBufferSize>0### Functionality to add/problem to solve
Currently enabling threaded writing (using maxThreadFileBufferSize > 0) automatically triggers threaded MPI support though in most cases this not needed since the buffer is big enough to avoid a...### Functionality to add/problem to solve
Currently enabling threaded writing (using maxThreadFileBufferSize > 0) automatically triggers threaded MPI support though in most cases this not needed since the buffer is big enough to avoid additional comms. Problem is that we don't know in advance how much the user is writing.
Using threaded MPI can incur a runtime penalty.
### Target audience
Using threaded writing
### Proposal
E.g. if user specifies it explicitly (maybe through negating the buffer size specification)
maxThreadFileBufferSize < 0
assume that the buffer space is big enough to write all.
@mark @andy @Prashanthttps://develop.openfoam.com/Development/openfoam/-/issues/115Need leaner methods than currently provided by the string-stream classes2017-12-18T23:17:16ZMark OLESENNeed leaner methods than currently provided by the string-stream classesCurrently no simple means to reuse buffer space with the string-stream classes, nor is there a simple means of just counting how many bytes a streamed representation requires.Currently no simple means to reuse buffer space with the string-stream classes, nor is there a simple means of just counting how many bytes a streamed representation requires.Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/195Need means of distinguishing between openfoam versions for user-coding2016-12-23T12:44:52ZMark OLESENNeed means of distinguishing between openfoam versions for user-codingWhen migrating user code between versions, there are some changes in OpenFOAM that may require alteration in the user code.
If this code exists in a codeStream, for example, it may not be possible to run the same case with slightly diff...When migrating user code between versions, there are some changes in OpenFOAM that may require alteration in the user code.
If this code exists in a codeStream, for example, it may not be possible to run the same case with slightly different OpenFOAM versions.
It is proposed to supply a pre-processor define to reflect the current base-level compatibility. This type of define could also be used to distinguish between OpenFOAM+ and other variants. This type of definition would also greatly simplify other third-party applications that may be built for various OpenFOAM versions.
For example,
#ifdef OPENFOAM_PLUS
...
#endif
The `OPENFOAM_PLUS` define would have a numerical value corresponding to the newly introduced version numbers (eg, `1606`) since these provide a simple, consistent, linear numbering without any additional effort.
#ifdef OPENFOAM_PLUS
#if (OPENFOAM_PLUS >= 1612)
...
#endif
#endif
This type of code naturally becomes quite cluttered and thus should only be used when strictly necessary.
It remains at the discretion of the developers to bump the number between release cycles, to indicate a newer functionality. Finer granularity than one month is not intended.
Version v1612Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/558need settings for cray compilers and cray-mpich2017-12-18T23:18:22ZMark OLESENneed settings for cray compilers and cray-mpichMark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/893Need stderr or equivalent alternative to Info2020-05-23T11:04:36ZMark OLESENNeed stderr or equivalent alternative to InfoIn some situations informative output gets in the way of desired output (eg, foamDictionary output - EP702).
We can avoid some of this output with `argList::noBanner()`. In the .org version they have replace this with a dedicated InfoHe...In some situations informative output gets in the way of desired output (eg, foamDictionary output - EP702).
We can avoid some of this output with `argList::noBanner()`. In the .org version they have replace this with a dedicated InfoHeader message stream, which handles the same problem. However, we may also to have a more general solution (cf. #881).
In similar cases it could also be helpful to have a Serr that only outputs on the master.
With dynamic code generation (eg `#calc`) the process generated copious quantities of output, all of which land on stdout.
Perhaps we need a version of `system()` with a `dup2()` to redirect.
@Mattijsv1812Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/939Negative Normal Components in UPrime2Mean Patch Fields - channel395DFSEM2020-06-16T16:22:58ZKutalmış BerçinNegative Normal Components in UPrime2Mean Patch Fields - channel395DFSEMHi,
**Problem**: I observed **negative** values in the normal components of UPrime2Mean, e.g. u'u', on *patch fields* (not internal fields) in a tutorial as well as in-house case. These components, however, are by definition positive.
...Hi,
**Problem**: I observed **negative** values in the normal components of UPrime2Mean, e.g. u'u', on *patch fields* (not internal fields) in a tutorial as well as in-house case. These components, however, are by definition positive.
**MWE**: Please run `OpenFOAM-v1712/channel395DFSEM` tutorial with `UPrime2Mean` on. For an arbitrary instant of solution, executing
`postProcess -func minMaxComponents'(UPrime2Mean)' -latestTime` yields:
```
...
Executing functionObjects
fieldMinMax minMaxComponents(UPrime2Mean) write:
min(UPrime2Mean) = (-110.6187451010895 -71.67069008796911 -57.02833388170411 -15.05621144511252 -12.23325724312694 -8.60988994091587) in cell 17517 at location (0 1.869010129293147 3.122436600824001)
max(UPrime2Mean) = (6.906486416596863 1.071684114359736 0.9375168777607903 0.7322488089670033 0.1589319170416081 1.301374985649687) in cell 1529601 at location (50.83096913508285 1.891711244092694 0.3256528970184543)
...
```
As can be seen, negative values appear in the UPrime2Mean normal components. Manual inspection showed me that these negative values exist in patch fields, rather than internal fields.
Kind regards,v2006Kutalmış BerçinKutalmış Berçinhttps://develop.openfoam.com/Development/openfoam/-/issues/1424new cannot satisfy memory request2019-09-04T08:39:47ZAdminnew cannot satisfy memory request<!--
*** 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 -->
### 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 -->
### What is the expected *correct* behavior?
<!-- What you should see instead -->
### Relevant logs and/or images
<!--
Paste any relevant logs - please use code blocks (```) to format console
output, logs, and code as it's very hard to read otherwise.
-->
### Environment information
<!--
Providing details of your set-up can help us identify any issues, e.g.
OpenFOAM version : v1806|v1812|v1906 etc
Operating system : ubuntu|openSUSE|centos etc
Hardware info : any info that may help?
Compiler : gcc|intel|clang etc
-->
- OpenFOAM version :
- Operating system :
- Hardware info :
- Compiler :
### Possible fixes
<!--
If you can, link to the line of code that might be responsible for the
problem
The "/label ~bug" text is a gitlab flag that will add the "bug" label to this
issue
-->https://develop.openfoam.com/Development/openfoam/-/issues/288Newer CGAL versions build into lib64, breaking current CGAL make rules.2017-01-02T12:24:17ZMark OLESENNewer CGAL versions build into lib64, breaking current CGAL make rules.On 64-bit systems, the system installations of boost, cgal are under `lib64/`.
The behaviour for a ThirdParty build is *mostly* `lib/` but this can also be changing.
- Boost 1_62_0 and older build into 'lib/'.
- CGAL-4.9 builds into ...On 64-bit systems, the system installations of boost, cgal are under `lib64/`.
The behaviour for a ThirdParty build is *mostly* `lib/` but this can also be changing.
- Boost 1_62_0 and older build into 'lib/'.
- CGAL-4.9 builds into 'lib64/', older versions into 'lib/'.
Future-proof things by using `lib$WM_COMPILER_LIB_ARCH` for boost and cgal build rules, and forcing these as build targets in the ThirdParty makeCGAL as well.
Cross-referenced as ThirdParty issue https://develop.openfoam.com/Development/ThirdParty-plus/issues/8Version v1612Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/2678newer coordSet writer with VTK legacy - incorrect entries2023-02-22T08:29:36ZMark OLESENnewer coordSet writer with VTK legacy - incorrect entriesReported by @PrashantReported by @PrashantMark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/1019New patches allowed in subsetMesh2018-12-21T18:03:00ZRoger AlmenarNew patches allowed in subsetMeshUtility subsetMesh assigns all (old) internal faces to a new patch called "oldInternalFaces". When using the option -patch, it only allows existing patches.
Would it be possible to allow a new patch being introduced with the -patch opti...Utility subsetMesh assigns all (old) internal faces to a new patch called "oldInternalFaces". When using the option -patch, it only allows existing patches.
Would it be possible to allow a new patch being introduced with the -patch option? Just specifying a non-existent name, the utility would create the patch as new, with the corresponding information in the log.v1812Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/2727New sigma turbulence model not included for compressible LES2023-04-13T10:14:13ZJulius BergmannNew sigma turbulence model not included for compressible LES<!--
*** 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 new 'sigma' turbulence model introduced in v2206 for LES is not applicable for compressible simulations, but only for incompressible simulations. Maybe it was forgotten to be implemented in commit 54806ea7 , as the file [/src/TurbulenceModels/incompressible/turbulentTransportModels/turbulentTransportModels.C](https://develop.openfoam.com/Development/openfoam/-/blob/master/src/TurbulenceModels/incompressible/turbulentTransportModels/turbulentTransportModels.C) was altered but not [/src/TurbulenceModels/compressible/turbulentFluidThermoModels/turbulentFluidThermoModels.C](https://develop.openfoam.com/Development/openfoam/-/blob/master/src/TurbulenceModels/compressible/turbulentFluidThermoModels/turbulentFluidThermoModels.C).
### Possible fixes
Add the following lines to line 134 of the file [/src/TurbulenceModels/compressible/turbulentFluidThermoModels/turbulentFluidThermoModels.C](https://develop.openfoam.com/Development/openfoam/-/blob/master/src/TurbulenceModels/compressible/turbulentFluidThermoModels/turbulentFluidThermoModels.C):
```
#include "sigma.H"
makeLESModel(sigma);
```Kutalmış BerçinKutalmış Berçinhttps://develop.openfoam.com/Development/openfoam/-/issues/1214new surface writer losing serial/parallel preference2019-02-22T17:42:17ZMark OLESENnew surface writer losing serial/parallel preference- as noted in nightly by @Prashant- as noted in nightly by @PrashantMark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/1447nFaces differ in faces and owner files for binary writes2019-10-30T16:04:28ZAdminnFaces differ in faces and owner files for binary writesWhen writing binary, nFaces in polyMesh/faces is one larger than the nFaces value in polyMesh/owner.When writing binary, nFaces in polyMesh/faces is one larger than the nFaces value in polyMesh/owner.https://develop.openfoam.com/Development/openfoam/-/issues/2964No base point for face... produces a valid tet decomposition.2023-08-18T07:28:42ZCesar CNo base point for face... produces a valid tet decomposition.I've been trying to run a case by using picFOAM and I'm getting this warning:
--> FOAM Warning :
From function Foam::triFace Foam::tetIndices::faceTriIs(const Foam::polyMesh&) const
in file /apps/easybuild/software/tinkercliff...I've been trying to run a case by using picFOAM and I'm getting this warning:
--> FOAM Warning :
From function Foam::triFace Foam::tetIndices::faceTriIs(const Foam::polyMesh&) const
in file /apps/easybuild/software/tinkercliffs-rome/OpenFOAM/9-foss-2021a/OpenFOAM-9/src/OpenFOAM/lnInclude/tetIndicesI.H at line 76
No base point for face 7468, 3(16 40 200), produces a valid tet decomposition.
When I run the solver it does not show me errors but it seems that it can not solve anything and no results are obtained. Any help will be appreciated. Thanks