Development issueshttps://develop.openfoam.com/groups/Development/-/issues2023-12-21T15:56:08Zhttps://develop.openfoam.com/Development/openfoam/-/issues/2963add non-blocking communication for cyclic AMI2023-12-21T15:56:08ZMark OLESENadd non-blocking communication for cyclic AMIcross-ref: EP2240cross-ref: EP2240https://develop.openfoam.com/Development/openfoam/-/issues/2962icoFoam fails to install on CentOS 7.8 installation2023-08-18T07:48:03ZTom LehmannicoFoam fails to install on CentOS 7.8 installation<!--
*** 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 -->
### 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 : v2306|v2212|v2206|v2112|v2106 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/2961OpenFOAM v2306 gives YY_BUF_SIZE declare in scope error2023-10-28T14:01:38ZAziz ÖğütlüOpenFOAM v2306 gives YY_BUF_SIZE declare in scope errorI'm trying to compile openfoam v2306 on Centos 7.9 and I got YY_BUF_SIZE declare in scope error. Compiling process is attached to issue.[compiling_openfoam_v2306.txt](/uploads/cca81faecd94e20e0dc701f607057409/compiling_openfoam_v2306.txt)I'm trying to compile openfoam v2306 on Centos 7.9 and I got YY_BUF_SIZE declare in scope error. Compiling process is attached to issue.[compiling_openfoam_v2306.txt](/uploads/cca81faecd94e20e0dc701f607057409/compiling_openfoam_v2306.txt)https://develop.openfoam.com/Development/openfoam/-/issues/2959snappyHexMesh -dryRun fails2023-08-22T07:50:10ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comsnappyHexMesh -dryRun fails<!--
*** 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 -->
`snappyHexMesh -dryRun` should checks (most) settings and give an estimate of expected cell count. It fails on the leak-path detection.
### Steps to reproduce
<!-- How one can reproduce the issue - this is very important -->
Any case with `locationsOutsideMesh`. Run `snappyHexMesh -dryRun`.
### What is the current *bug* behaviour?
<!-- What actually happens -->
segmentation error
### Environment information
<!--
Providing details of your set-up can help us identify any issues, e.g.
OpenFOAM version : v2306|v2212|v2206|v2112|v2106 etc
Operating system : ubuntu|openSUSE|centos etc
Hardware info : any info that may help?
Compiler : gcc|intel|clang etc
-->
- OpenFOAM version : v2306
Fix provided by @Prashant
@Prashanthttps://develop.openfoam.com/Development/openfoam/-/issues/2957Could not load libfieldFunctionObjects.so and user created library2023-08-08T07:38:02ZNicolas CharalambousCould not load libfieldFunctionObjects.so and user created libraryHi,
I have created a user defined object using the wmake in OPENFOAM 20.06. The in Make the files contained the following:
Helicity.C
LIB = $(FOAM_USER_LIBBIN)/helicity
Therefore, the new created object was helicity.so.
I included bo...Hi,
I have created a user defined object using the wmake in OPENFOAM 20.06. The in Make the files contained the following:
Helicity.C
LIB = $(FOAM_USER_LIBBIN)/helicity
Therefore, the new created object was helicity.so.
I included both helicity.so and libfieldFunctionObjects.so in controldict. However,
when running interphaseChangeFoam I am getting the following:
```
--> FOAM Warning :
From void* Foam::dlLibraryTable::openLibrary(const Foam::fileName&, bool)
in file db/dynamicLibrary/dlLibraryTable/dlLibraryTable.C at line 65
Could not load "libfieldFunctionObjects.so"
/home/ncharala/OpenFOAMv2006/OpenFOAM-v2006/platforms/linux64GccDPInt32Opt/lib/libfieldFunctionObjects.so: undefined symbol: _ZTIN4Foam15functionObjects15fieldExpressionE
--> FOAM Warning :
From void* Foam::dlLibraryTable::openLibrary(const Foam::fileName&, bool)
in file db/dynamicLibrary/dlLibraryTable/dlLibraryTable.C at line 65
Could not load "helicity.so"
```
How can I fix this?
Thank you
Nicolashttps://develop.openfoam.com/Development/openfoam/-/issues/2956Enabling SIGFPE on macOS arm642023-12-22T22:02:38ZGuanyang XueEnabling SIGFPE on macOS arm64### Summary
Enabling `SIGFPE` on macOS arm64
### Example case
Compile and run `applications/test/sigFpe` on ARM Mac it will print `Inf` instead of trapping `SIGFPE`.
### What is the current *bug* behaviour?
Results from `applications/t...### Summary
Enabling `SIGFPE` on macOS arm64
### Example case
Compile and run `applications/test/sigFpe` on ARM Mac it will print `Inf` instead of trapping `SIGFPE`.
### What is the current *bug* behaviour?
Results from `applications/test/sigFpe`
```
trapFpe: Floating point exception trapping - not supported on this platform
Provoking sigFpe (division by zero)
Infinity inf
```
Currently the code implemented by Tatsuya Shimizu https://develop.openfoam.com/Development/openfoam/-/commit/85760cbc347c4d5af01dd166084d452accd0b28e is not working, because:
1. On ARM64, `__fpcr` is the control register and `__fpsr` is the status register, see https://help.totalview.io/current/PDFs/TotalView_Reference_Guide.pdf page 453-454
2. On ARM64, the shift is 8 bits instead of 7 bits.
3. On ARM64, the mask definition is opposite to x86.
4. Even if everything is correct, Apple M1 throws `SIGILL` instead of `SIGFPE`. It terminates the executable and prints `illegal hardware instruction`.
I have fixed problem 1,2,3 in `feexceptErsatz.H`. For Problem 4, I did some dirty hack in `sigFpe.C` to enforce `SIGILL` in the handler. Currently there's no better way to implement this due to hardware/operating system limitations.
### What is the expected *correct* behavior?
After setting FPE masks, the CPU can trigger floating point exceptions, but throw 'SIGILL'. My fix picks up `SIGILL` and handles it as `SIGFPE` (only for macOS ARM64).
### Relevant logs and/or images
Results from `applications/test/sigFpe`
```
trapFpe: Floating point exception trapping enabled (FOAM_SIGFPE).
Provoking sigFpe (division by zero)
Infinity [stack trace]
=============
#1 Foam::sigFpe::sigHandler(int) in /Volumes/OpenFOAM/OpenFOAM-v2306/platforms/darwin64ClangDPInt32Opt/lib/libOpenFOAM.dylib
#2 _sigtramp in /usr/lib/system/libsystem_platform.dylib
#3 main in Test-sigFpe
#4 start in /usr/lib/dyld
=============
zsh: floating point exception ./Test-sigFpe
```
Results from cavity tutorial case (set viscosity to negative number gives you immediate `SIGFPE`)
```
Starting time loop
Time = 0.005
Courant Number mean: 0 max: 0
smoothSolver: Solving for Ux, Initial residual = 1, Final residual = 3.87689e+220, No Iterations 1000
smoothSolver: Solving for Uy, Initial residual = 0, Final residual = 0, No Iterations 0
[stack trace]
=============
#1 Foam::sigFpe::sigHandler(int) in /Volumes/OpenFOAM/OpenFOAM-v2306/platforms/darwin64ClangDPInt32Opt/lib/libOpenFOAM.dylib
#2 _sigtramp in /usr/lib/system/libsystem_platform.dylib
#3 Foam::PCG::scalarSolve(Foam::Field<double>&, Foam::Field<double> const&, unsigned char) const in /Volumes/OpenFOAM/OpenFOAM-v2306/platforms/darwin64ClangDPInt32Opt/lib/libOpenFOAM.dylib
#4 Foam::PCG::solve(Foam::Field<double>&, Foam::Field<double> const&, unsigned char) const in /Volumes/OpenFOAM/OpenFOAM-v2306/platforms/darwin64ClangDPInt32Opt/lib/libOpenFOAM.dylib
#5 Foam::fvMatrix<double>::solveSegregated(Foam::dictionary const&) in /Volumes/OpenFOAM/OpenFOAM-v2306/platforms/darwin64ClangDPInt32Opt/lib/libfiniteVolume.dylib
#6 Foam::fvMatrix<double>::solveSegregatedOrCoupled(Foam::dictionary const&) in /Volumes/OpenFOAM/OpenFOAM-v2306/platforms/darwin64ClangDPInt32Opt/lib/libfiniteVolume.dylib
#7 main in /Volumes/OpenFOAM/OpenFOAM-v2306/platforms/darwin64ClangDPInt32Opt/bin/icoFoam
#8 start in /usr/lib/dyld
=============
zsh: floating point exception icoFoam
```
### Environment information
- OpenFOAM version : All
- Operating system : macOS arm64
- Hardware info : Apple M1
- Compiler : Clang
### Possible fixes
I'm attaching two modified files in `src/OSspecific/POSIX/signals`. It shouldn't change anything on other platforms including x86 Macs. OpenFOAM SIGFPE can be successfully triggered on macOS arm64.
~~[feexceptErsatz.H](/uploads/5daae02b07e49ad02418463ec66ec342/feexceptErsatz.H)~~
~~[sigFpe.C](/uploads/ccdd9fb1744c206d6ddf79a5634e3751/sigFpe.C)~~
See comment for second versionhttps://develop.openfoam.com/Development/openfoam/-/issues/2955BUG: filmPyrolysisRadiativeCoupledMixed parallel error2023-09-08T10:48:52ZAndrew HeatherBUG: filmPyrolysisRadiativeCoupledMixed parallel 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
As reported via @Prashant for EP#2050
### Steps to reproduce
See tutorial `combustion/fireFoam/LES/flameSpreadWaterSuppressionPanel`
- decompose each region (primary, film, pyrolysis) into 8 procs (used scotch)
- parallel failure at runtime due to operating on fields of different sizesv2312Andrew HeatherAndrew Heatherhttps://develop.openfoam.com/Development/openfoam/-/issues/2953provision for delayed reading of compound tokens2023-08-19T06:46:01ZMark OLESENprovision for delayed reading of compound tokensIn work initiated by @serge and @gregorweiss, the files are read and the compound token is tagged as such, but allocated with zero size. This maintains the token stream elements to allow delayed reading.In work initiated by @serge and @gregorweiss, the files are read and the compound token is tagged as such, but allocated with zero size. This maintains the token stream elements to allow delayed reading.Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/2952objectRegistry::readModifiedObjects segfaults with collated file handler2024-01-02T15:56:06ZMortesinsobjectRegistry::readModifiedObjects segfaults with collated file handler### Summary
When using the collated file handler, if a non-collated `regIOobject` gets re-read by the `objectRegistry::readModifiedObjects`, OpenFOAM sometimes segfaults because the iterator object is pointing to freed memory.
In the fo...### Summary
When using the collated file handler, if a non-collated `regIOobject` gets re-read by the `objectRegistry::readModifiedObjects`, OpenFOAM sometimes segfaults because the iterator object is pointing to freed memory.
In the following function:
```
void Foam::objectRegistry::readModifiedObjects()
{
for (iterator iter = begin(); iter != end(); ++iter)
{
if (objectRegistry::debug)
{
Pout<< "objectRegistry::readModifiedObjects() : "
<< name() << " : Considering reading object "
<< iter.key() << endl;
}
iter.val()->readIfModified();
}
}
```
The `readIfModified` of a `regIOobject` causes the `regIOobject` to be checked out and checked back in when using the collated file handler. This is caused by `operator=` which is called in `masterUncollatedFileOperation::readStream` function: https://develop.openfoam.com/Development/openfoam/-/blob/master/src/OpenFOAM/global/fileOperations/masterUncollatedFileOperation/masterUncollatedFileOperation.C#L1939
However, the iterator is still pointing at the memory location of the old `HashTablePair` of the checked out `regIOobject`. Because of this, when calling the `increment` function of the iterator, the `next_` pointer is the `next_` of the old `HashTablePair` which has been deleted already, and so sometimes the value of `next_` will be garbage, and when it gets dereferenced a segfault happens.
Either the `regIOobject` should not be checked out and checked back in, or some different handling should be done with the iterator.
### Steps to reproduce
An example would be to use the `timeActivatedFileUpdate` to cause a solver to re-read the `fvSolution` file. When the `fvSolution` gets re-read, sometimes OpenFOAM will segfault (it does not happen every time since sometimes the old freed memory is still in "a good state").
### What is the current *bug* behaviour?
OpenFOAM reads freed memory which sometimes causes a segfault.
### What is the expected *correct* behavior?
OpenFOAM should not read freed memory.
### Environment information
- OpenFOAM version :v2306
- Operating system :centos
- Compiler :gcc 12.2.0
### Possible fixes
This is a possible workaround even though I think the real issue is the checking out and checking back in of the `regIOobject` in the `masterUncollatedFileOperation::readStream` function:
```
void Foam::objectRegistry::readModifiedObjects()
{
iterator iter = begin();
while (iter != end())
{
if (objectRegistry::debug)
{
Pout<< "objectRegistry::readModifiedObjects() : "
<< name() << " : Considering reading object "
<< iter.key() << endl;
}
regIOobject* currentObjPtr = iter.val();
// Increment iterator before potentially changing the entry in the table
++iter;
currentObjPtr->readIfModified();
}
}
```Mattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comhttps://develop.openfoam.com/Development/openfoam/-/issues/2951Deb package with Ubuntu 23.042023-08-02T18:58:36ZMarkus TowaraDeb package with Ubuntu 23.04### Summary
I followed the instructions here on XUbuntu 23.04
https://develop.openfoam.com/Development/openfoam/-/wikis/precompiled/debian
After this apt-get update complains:
```
E: The repository 'https://dl.openfoam.com/repos/deb...### Summary
I followed the instructions here on XUbuntu 23.04
https://develop.openfoam.com/Development/openfoam/-/wikis/precompiled/debian
After this apt-get update complains:
```
E: The repository 'https://dl.openfoam.com/repos/deb lunar Release' does not have a Release file.
N: Updating from such a repository can't be done securely, and is therefore disabled by default.
```
### Possible fixes
This path exists, however the release codename is lunar not luna
https://dl.openfoam.com/repos/deb/dists/luna/
Workaround: change lunar to luna in /etc/apt/sources.list.d/openfoam.listhttps://develop.openfoam.com/Development/openfoam/-/issues/2949BUG - AMI - areaNormalisationMode not written2023-09-01T10:39:30ZAndrew HeatherBUG - AMI - areaNormalisationMode not written`areaNormalisationMode` can be `project` or `mag` - but these values are not written in the boundary file for (re-)start`areaNormalisationMode` can be `project` or `mag` - but these values are not written in the boundary file for (re-)startv2312Andrew HeatherAndrew Heatherhttps://develop.openfoam.com/Development/openfoam/-/issues/2948rpath compilation rules for Darwin2024-02-07T13:22:03ZAlexey Matveichevrpath compilation rules for Darwin### Functionality to add/problem to solve
Work-around for empty `DYLD_LIBARY_PATH` variable (which is cleared by System Integrity Protection).
### Target audience
OpenFOAM users on macOS operating system.
### Proposal
Correct Open...### Functionality to add/problem to solve
Work-around for empty `DYLD_LIBARY_PATH` variable (which is cleared by System Integrity Protection).
### Target audience
OpenFOAM users on macOS operating system.
### Proposal
Correct OpenFOAM execution depends on the right contents of the
`DYLD_LIBRARY_PATH` environment variable. On Darwin System Integrity
Protection clears this variable for protected binaries. For the reason
`Allrun` scripts become useless.
Previous solution for the problem was to restore values of the
`DYLD_LIBRARY_PATH` variable from backup environment variable
`FOAM_LD_LIBRARY_PATH` in the beginning of `RunFunctions` file. The
approach was limited to the scripts, which use `RunFunctions` file and
execute utulities and solvers with shell functions. I.e. it only partly
solved the problem.
In the new approach `-rpath` flag is used during link phase to
compile-in list of paths to search for the dynamic libraries. The
following list is used:
- `$FOAM_USER_LIBBIN` (usually OpenFOAM is compiled manually on Darwin,
so I think this location is known during compilation and relevant to
user).
- `$FOAM_SITE_LIBBIN`
- `$FOAM_LIBBIN`
- `$FOAM_LIBBIN/$FOAM_MPI`
- `$FOAM_LIBBIN/dymmy`
The first two folders are used as absolute paths. The last three entries
are substituted, using dynamic linker variables: `@loader_path` and
`@executable_path`. `@loaded_path` is used in dynamic libraries and it
usually points to `$FOAM_LIBBIN`. `@executable_path` is used in
executables and there `$FOAM_LIBBIN` is encoded as
`@executable_path/../lib` (so it assumes, that `bin` and `lib` folders
are at the same directory tree level).
This approach still allows us to use `DYLD_LIBRARY_PATH` environment
variable to override dynamic libraries search paths, while maintaining
OpenFOAM in functional state if the variable is empty.
We still need to maintain backup variable `FOAM_LD_LIBRARY_PATH` as it is used by `dlOpen` function as a fallback.
### What does success look like, and how can we measure that?
OpenFOAM solvers and utilities are correctly executed in shell scripts (ex. `Allrun`, `foamJob`) without workarounds with restoration of `DYLD_LIBRARY_PATH` from backup variable.
### Links / references
1. The Library Search Process section in https://developer.apple.com/library/archive/documentation/DeveloperTools/Conceptual/DynamicLibraries/100-Articles/DynamicLibraryUsageGuidelines.html#//apple_ref/doc/uid/TP40001928-SW10
2. Run-path dependent libraries section https://developer.apple.com/library/archive/documentation/DeveloperTools/Conceptual/DynamicLibraries/100-Articles/RunpathDependentLibraries.html
Functionality is implemented in attached [01-feature-darwin-rpath-wmake-rules.patch](/uploads/8cda483cfe274bfed38b9f9700f96cd5/01-feature-darwin-rpath-wmake-rules.patch).Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/2947subsetMesh -patches with wildcard also selects e.g. processor patches2023-08-03T06:47:40ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comsubsetMesh -patches with wildcard also selects e.g. processor patches### Functionality to add/problem to solve
subsetMesh accepts wildcard to select patches for exposed faces. This also selects e.g. processor patches. This is generally not the expected behaviour. Can probably be worked around by using
- ...### Functionality to add/problem to solve
subsetMesh accepts wildcard to select patches for exposed faces. This also selects e.g. processor patches. This is generally not the expected behaviour. Can probably be worked around by using
- patchGroups, e.g. `wall`
- anti-patterns to deselect any "processor.*"
### Target audience
Users of subsetMesh
### Proposal
Deselect all processor patches. Guess no need to deselect all constraint patches since we might still want to select e.g. `symmetry`.
@Prashant
cross-ref: EP1904Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/2946Use UPtrList for managing objective functions2023-12-21T11:54:41ZMark OLESENUse UPtrList for managing objective functionsStumbled across these when examining other code...
The incompressiblePrimalSolver uses a List of pointers for the objective functions. I think that a UPtrList would make more sense. The primary reason being to encapsulate the pointer de...Stumbled across these when examining other code...
The incompressiblePrimalSolver uses a List of pointers for the objective functions. I think that a UPtrList would make more sense. The primary reason being to encapsulate the pointer dereference, as well as other methods (eg, test(), get(), ...).
The code that may need to be modified in any case is the use of lookupClass. This is usually OK, but there is no absolute guarantee about the iteration order.
Here's a code snippet using `sorted` instead, which generates a UPtrList as an intermediate type (a couple of allocations fewer than sending back a HashTable).
```
Foam::UPtrList<Foam::objective>
Foam::incompressiblePrimalSolver::getObjectiveFunctions() const
{
DynamicList<objective*> objectives;
for (auto& adjoint : mesh_.sorted<adjointSolver>())
{
if (adjoint.primalSolverName() == solverName_)
{
PtrList<objective>& managerObjectives =
adjoint.getObjectiveManager().getObjectiveFunctions();
for (objective& obj : managerObjectives)
{
objectives.push_back(&obj);
}
}
}
return UPtrList<objective>(objectives);
}
```Vaggelis PapoutsisVaggelis Papoutsishttps://develop.openfoam.com/Development/openfoam/-/issues/2944mapFieldsPar - source and target swapped - WIP code2023-09-01T11:13:55ZPrashant SonakarmapFieldsPar - source and target swapped - WIP codeDeveloped for [EP#944](https://exchange.openfoam.com/node/944)
and another [comment ](https://exchange.openfoam.com/node/2025#comment-21802)to be noted while integration
Only internal note.Developed for [EP#944](https://exchange.openfoam.com/node/944)
and another [comment ](https://exchange.openfoam.com/node/2025#comment-21802)to be noted while integration
Only internal note.Andrew HeatherAndrew Heatherhttps://develop.openfoam.com/Development/openfoam/-/issues/2941Missing Debian 12 (bookworm) release2023-07-20T09:08:25ZDiego MagelaMissing Debian 12 (bookworm) releaseThere are no precompiled packages for debian bookworm.
Is there a workaround to install precompiled OpenFOAM in Debian 12?
Error:
`The repository 'https://dl.openfoam.com/repos/deb bookworm Release' does not have a Release file.`There are no precompiled packages for debian bookworm.
Is there a workaround to install precompiled OpenFOAM in Debian 12?
Error:
`The repository 'https://dl.openfoam.com/repos/deb bookworm Release' does not have a Release file.`https://develop.openfoam.com/Development/openfoam/-/issues/2940weightedFluxExample validation case does not plot anything2023-07-13T15:09:02ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comweightedFluxExample validation case does not plot anything<!--
*** 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 -->
functionObject produces line_T.xy or line_T_flux.xy. `plot` script expects `line_flux.xy`.
### Environment information
<!--
Providing details of your set-up can help us identify any issues, e.g.
OpenFOAM version : v2306|v2212|v2206|v2112|v2106 etc
Operating system : ubuntu|openSUSE|centos etc
Hardware info : any info that may help?
Compiler : gcc|intel|clang etc
-->
- OpenFOAM version : v2306-rc2
- Operating system :
- Hardware info :
- Compiler :Kutalmış BerçinKutalmış Berçinhttps://develop.openfoam.com/Development/openfoam/-/issues/2938bash: cannot set terminal process group (-1): Inappropriate ioctl for device2024-01-04T07:29:53ZGeon-Hongbash: cannot set terminal process group (-1): Inappropriate ioctl for deviceHi,
I'm not sure if it is appropriate to raise docker issue here, but I need your help.
Recently I tried to run OpenFOAM on Windows by following the instruction described here: https://develop.openfoam.com/Development/openfoam/-/wikis/...Hi,
I'm not sure if it is appropriate to raise docker issue here, but I need your help.
Recently I tried to run OpenFOAM on Windows by following the instruction described here: https://develop.openfoam.com/Development/openfoam/-/wikis/precompiled/windows
I installed WSL and docker on a Windows system and run the OpenFOAM-default image on it.
But when I run the image, I faced the following error message and the status of the container turned to exited.
```
---------------------------------------------------------------------------
========= |
\\ / F ield | OpenFOAM in a container [from OpenCFD Ltd.]
\\ / O peration |
\\ / A nd | www.openfoam.com
\\/ M anipulation |
---------------------------------------------------------------------------
Release notes: https://www.openfoam.com/news/main-news/openfoam-v2306
Documentation: https://www.openfoam.com/documentation/
Issue Tracker: https://develop.openfoam.com/Development/openfoam/issues/
Local Help: more /openfoam/README
---------------------------------------------------------------------------
System : Ubuntu 22.04.2 LTS (admin user: sudofoam)
OpenFOAM : /usr/lib/openfoam/openfoam2306
Build : _fbf00d6b-20230626 OPENFOAM=2306 patch=0
Note
Different OpenFOAM components and modules may be present (or missing)
on any particular container installation.
Eg, source code, tutorials, in-situ visualization, paraview plugins,
external linear-solver interfaces etc.
---------------------------------------------------------------------------
bash: cannot set terminal process group (-1): Inappropriate ioctl for device
bash: no job control in this shell
root@399e74dd484f:~# exit
```
I set the WSL distro to be Ubuntu but it doesn't help for me.
How can I handle this problem?
Many thanks in advance.
Regards,
Geon-Hong.https://develop.openfoam.com/Development/openfoam/-/issues/2937Generating uniformly sampling on a sphere for StochasticDispersionRAS2023-07-29T06:26:40ZVictor PozzobonGenerating uniformly sampling on a sphere for StochasticDispersionRAS### Functionality to add/problem to solve
The current implementation of the sampling to get a random direction for the turbulent velocity perturbation seems faulty.
Indeed, the current sampling draws number for angle from [0, 2pi] and [...### Functionality to add/problem to solve
The current implementation of the sampling to get a random direction for the turbulent velocity perturbation seems faulty.
Indeed, the current sampling draws number for angle from [0, 2pi] and [0, pi] uniform distributions. Yet, on a sphere the Jacobian makes the angle correlated and the second angle should not be chosen independently from the first angle value.
File: lagrangian/turbulence/submodels/Kinematic/DispersionModel/StochasticDispersionRAS/StochasticDispersionRAS.C
### Target audience
(Who will benefit from the changes?) -> Users
(What type of cases?) -> Lagrangian cases
### Proposal
The current sampling method could be replaced by a corrected one such as: http://corysimon.github.io/articles/uniformdistn-on-sphere/
### What does success look like, and how can we measure that?
By projecting the drawn vector on a plane. Currently, we should get a square. After the correction, we should get a disk.
### Links / references
http://corysimon.github.io/articles/uniformdistn-on-sphere/
### Funding
NAhttps://develop.openfoam.com/Development/openfoam/-/issues/2936redistributePar creates unnecessary directories2023-12-21T15:58:19ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comredistributePar creates unnecessary directories<!--
*** 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 -->
`redistributePar -fileHandler collated` in distributed mode creates unnecessary directories
### Steps to reproduce
<!-- How one can reproduce the issue - this is very important -->
- decompose a case
- move processorDDD to different directories
- and adjust decomposeParDict:roots accordingly
- run redistributePar to redistribute the case `mpirun -np 4 redistributePar -parallel -fileHandler collated`
- it will have created a `processsors4` directory on every root
### 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 : v2306|v2212|v2206|v2112|v2106 etc
Operating system : ubuntu|openSUSE|centos etc
Hardware info : any info that may help?
Compiler : gcc|intel|clang etc
-->
- OpenFOAM version : v2306
### 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
-->Mattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.com