Development issueshttps://develop.openfoam.com/groups/Development/-/issues2020-03-13T14:28:58Zhttps://develop.openfoam.com/Development/openfoam/-/issues/772simplify inplace ListOps2020-03-13T14:28:58ZMark OLESENsimplify inplace ListOpsWith all list types being movable, can now collapse out the code duplication of things like `inplaceReorder`.
Eg,
template<unsigned Width>
void Foam::inplaceReorder
(
const labelUList& oldToNew,
PackedList<Wi...With all list types being movable, can now collapse out the code duplication of things like `inplaceReorder`.
Eg,
template<unsigned Width>
void Foam::inplaceReorder
(
const labelUList& oldToNew,
PackedList<Width>& input,
const bool prune
)
{
input = reorder(oldToNew, input, prune);
}
since the rvalue returned from `reorder()` now hooks into the move assignment operatorv1806Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/773Typo: Smagorinsky in Extended Code Guide2018-03-21T15:11:12ZKutalmış BerçinTypo: Smagorinsky in Extended Code GuideHi,
Within the page: https://www.openfoam.com/documentation/cpp-guide/html/guide-turbulence-les-smagorinsky.html , the free term ***c*** of the quadratic function has the sub-term `(dev(D)⋅D)`.
But, the operation is a **double inner p...Hi,
Within the page: https://www.openfoam.com/documentation/cpp-guide/html/guide-turbulence-les-smagorinsky.html , the free term ***c*** of the quadratic function has the sub-term `(dev(D)⋅D)`.
But, the operation is a **double inner product** rather than an inner product.
Therefore, IMHO, this needs to be changed to `(dev(D):D)`.
Kind regardshttps://develop.openfoam.com/Development/openfoam/-/issues/774snappyMultiRegionHeater crashing2018-03-19T10:59:23ZMark OLESENsnappyMultiRegionHeater crashing- snappy crashes with gcc 4.8.5, runs with clang 3.8.0- snappy crashes with gcc 4.8.5, runs with clang 3.8.0Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/775isoAdvector broken by new meaning of pos and neg2023-12-07T19:03:27ZJohan RoenbyisoAdvector broken by new meaning of pos and negBUGFIX: In commit 7bdbab7f4eb7698f5967984186e342cac66a8e04 of the OpenFOAM Foundation code version, Henry changed the meaning of pos and neg and introduced pos0 and neg0 for the old functionality of these functions. The new meaning of p...BUGFIX: In commit 7bdbab7f4eb7698f5967984186e342cac66a8e04 of the OpenFOAM Foundation code version, Henry changed the meaning of pos and neg and introduced pos0 and neg0 for the old functionality of these functions. The new meaning of pos and neg after that commit has led isoAdvector to create small spurious bubbles in the water column when snapTol was larger than zero.
The bug can be fixed by the following two code changes:
grep -rl --include \*.C --include \*.H --exclude-dir \*Include\* "pos(" $FOAM_SRC/finiteVolume/fvMatrices/solvers/isoAdvection | xargs sed -i 's/pos(/pos0(/g'
grep -rl --include \*.C --include \*.H --exclude-dir \*Include\* "neg(" $FOAM_SRC/finiteVolume/fvMatrices/solvers/isoAdvection | xargs sed -i 's/neg(/neg0(/g'
Since the bug has pretty severe consequences for isoAdvector runs, I suggest making a hotfix out of this.https://develop.openfoam.com/Development/openfoam/-/issues/776Failed wmake for dynamicCode2020-03-13T14:28:06ZAdminFailed wmake for dynamicCodeRunning OpenFOAM-v1712 on windows10.
I was testing the floatingObject tutorial for interDyMFoam solver and got the error attached.
No changes have been made to dictionaries of the tutorial or anywhere else in the software (followed http...Running OpenFOAM-v1712 on windows10.
I was testing the floatingObject tutorial for interDyMFoam solver and got the error attached.
No changes have been made to dictionaries of the tutorial or anywhere else in the software (followed https://www.openfoam.com/download/install-windows-10.php for installation).
Any help would be great.
Best Regards,
Tommaso
[dynamicCode_error.cpp](/uploads/9103b781b0d8b5f5bdbd298a6375f6fc/dynamicCode_error.cpp)
\## Reattaching the author to the issue ticket: @acerbi ##https://develop.openfoam.com/Development/openfoam/-/issues/777enhancement: merge of foundation code for kinematic parcel2018-07-23T12:40:13ZAdminenhancement: merge of foundation code for kinematic parcelI am wondering what your merge strategy with the foundation code nowadays is. I found some nice improvements on kinematic parcels in the foundation code. Do you do a merge a while before a new release or is is it based on nice new featur...I am wondering what your merge strategy with the foundation code nowadays is. I found some nice improvements on kinematic parcels in the foundation code. Do you do a merge a while before a new release or is is it based on nice new feature you guys stumble on when viewing the foundation code? Is it useful for users to point out some improvements from the foundation code or will they end up eventually in this version?
I found some nice features for improving speed and accuracy for the kinematic parcel class:
1) Improving speed:
https://bugs.openfoam.org/view.php?id=2688
https://bugs.openfoam.org/view.php?id=2871
2) Improving tracking accuracy:
https://bugs.openfoam.org/view.php?id=2282
https://bugs.openfoam.org/view.php?id=2666
From what I read in the descriptions, these sounded as really nice improvements and therefore I wanted to point them out.AdminAdminhttps://develop.openfoam.com/Development/openfoam/-/issues/778snappy has issues with degenerate mesh distributions2023-12-07T19:03:27ZMark OLESENsnappy has issues with degenerate mesh distributionsTo reproduce:
- blockMesh
- manual decomposition with all cells on single processor
- snappy: fails during castellate
partial log:
Feature refinement iteration 0
------------------------------
[4] #0 Foam::error::printSta...To reproduce:
- blockMesh
- manual decomposition with all cells on single processor
- snappy: fails during castellate
partial log:
Feature refinement iteration 0
------------------------------
[4] #0 Foam::error::printStack(Foam::Ostream&)[5] #0 Foam::error::printStack(Foam::Ostream&)[1] #0 Foam::error::printStack(Foam::Ostream&)[2] #0 Foam::error::printStack(Foam::Ostream&)[3] #0 Foam::error::printStack(Foam::Ostream&) at ??:?
@Mattijs @Landmann @sma
[snappyMultiRegionHeater-debug.tar.bz2](/uploads/68eae17311da335e7f57d07b8099519e/snappyMultiRegionHeater-debug.tar.bz2)v1806Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/779Armclang support2023-12-07T19:03:27ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comArmclang supportAdd armclang support.Add armclang support.Mattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comhttps://develop.openfoam.com/Development/openfoam/-/issues/780issue with cast (dictionarySearch) with SGI compiler2018-07-02T09:36:32ZMark OLESENissue with cast (dictionarySearch) with SGI compiler- as reported on the [cfd-online] forum,
db/dictionary/dictionarySearch.C(327): error: invalid type conversion:
"Foam::dictionary::const_searcher" to "const Foam::dictionary::searcher &"
return static_cast<const...- as reported on the [cfd-online] forum,
db/dictionary/dictionarySearch.C(327): error: invalid type conversion:
"Foam::dictionary::const_searcher" to "const Foam::dictionary::searcher &"
return static_cast<const searcher&>(finder);
The conversion should be OK (we use it for switching between const and non-const forms of the searcher), but obviously not the case for SGI.
[cfd-online]: https://www.cfd-online.com/Forums/openfoam-installation/199668-openfoam-v1712-installation-intel-mpt-kahip.htmlv1806Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/781Change default flag for lagrangian post-processing in paraview2018-05-15T10:22:04ZRoger AlmenarChange default flag for lagrangian post-processing in paraviewRequest to change the default flag under $FOAM_ETC/controlDict
```
// Write lagrangian "positions" file in v1706 format (at earlier)
writeLagrangianPositions 0;
```
from 0 to 1. Otherwise it is not possible to post-process lagrangian...Request to change the default flag under $FOAM_ETC/controlDict
```
// Write lagrangian "positions" file in v1706 format (at earlier)
writeLagrangianPositions 0;
```
from 0 to 1. Otherwise it is not possible to post-process lagrangian cases in Paraview, loading directly the OpenFOAM case.v1806Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/782Problem in mean temperature and mean compressibility calculation in thermophy...2021-07-08T12:23:53ZAdminProblem in mean temperature and mean compressibility calculation in thermophysical library for premixed flameHello
The calculation of mean temeperature and mean compressibility i.e. T and psi, in the thermophysical library for a premixed turbulent flame has been problematic since an earlier version of OpenFOAM-v1.6. Please find the attached p...Hello
The calculation of mean temeperature and mean compressibility i.e. T and psi, in the thermophysical library for a premixed turbulent flame has been problematic since an earlier version of OpenFOAM-v1.6. Please find the attached pdf file for a detailed description. The latestest OpenFOAM-v1712 has the same problem.
The relavant code is $WM_PROJECT_DIR/src/thermophysicalModels/reactionThermo/psiuReactionThermo/heheuPsiThermo.C
in which the member function of calculation() calculates the mean temperatrue and compressibility psi.
Moreover, it is misleading to consider regress progress variable "b" in solver XiFoam as a mass fraction of some products in the premixed flame as implemented in OpenFOAM; see code $WM_PROJECT_DIR/src/thermophysicalModels/reactionThermo/mixtures/homogeneousMixture/homogeneousMixture.C.
The reason is that the regress progress variable "b" is based on the Bray-Mossy-Libby model of premixed flame in which the unburned and burned mixture is seperated by a infinitely thin flame front. The "b" has a physical meaning of probability of finding the unburned mixture, not some mass fraction.
I hope that I managed to explain the problem, otherwise please contact me if there is anything unclear.
Kind regards
Chen[ehsan_yasari_ab.pdf](/uploads/fe7807d8e465f774ff8b134d5ea0561b/ehsan_yasari_ab.pdf)
\#\# Reattaching the author to the issue ticket: @chenhu \#\#Sergio FerrarisSergio Ferrarishttps://develop.openfoam.com/Development/openfoam/-/issues/783surfaceFieldValue does not check for failure to open data file2023-12-07T19:03:27ZPrashant SonakarsurfaceFieldValue does not check for failure to open data fileWith >1024 surfaceFieldValue function objects you might run out of filedescriptors for the data file!
There is currently no error message if it cannot open a data file.With >1024 surfaceFieldValue function objects you might run out of filedescriptors for the data file!
There is currently no error message if it cannot open a data file.Prashant SonakarPrashant Sonakarhttps://develop.openfoam.com/Development/openfoam/-/issues/784wmkdep runs out of open file descriptors2023-12-07T19:03:27ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comwmkdep runs out of open file descriptorswmkdep.l runs out of open file descriptors, especially when using the -q option on wmake.wmkdep.l runs out of open file descriptors, especially when using the -q option on wmake.Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/785verbatim string (inbetween #{ .. #} , for e.g. code sections) is limited to 8...2023-12-07T19:03:27ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comverbatim string (inbetween #{ .. #} , for e.g. code sections) is limited to 8000 chars.Larger code sections might not fit inside a single verbatim string. Since it is a static char array there is no real limit on its size.
- workaround: move sections of code into included file
- solution: increase size (but this permanentl...Larger code sections might not fit inside a single verbatim string. Since it is a static char array there is no real limit on its size.
- workaround: move sections of code into included file
- solution: increase size (but this permanently increases memory usage)
- or : assign to stringMark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/786Bug or feature: Pimple solves pressure to final convergence on every iteration2020-07-31T15:13:36ZAdminBug or feature: Pimple solves pressure to final convergence on every iterationI've switched from the 1606+ version to the latest 1712+ version. I noticed that my pimpleFoam computations take a lot more time. When I looked at the pressure iterations the last nonOrthogonal correction solves the pressure to the final...I've switched from the 1606+ version to the latest 1712+ version. I noticed that my pimpleFoam computations take a lot more time. When I looked at the pressure iterations the last nonOrthogonal correction solves the pressure to the final convergence criterion. (See lines 7,15,23 in 1712log). The 1606 solver does not converge to the final convergence (see line 10 in 1606log). It is not the same simulation. These logs I had ready. I did do the test though.
If you would like to reproduce just take a pimple case (running in pimple mode) and see the difference between the two versions.
This is caused by a change in the pimplecontrol class. In older versions the finalInnerIter read:
`
inline bool Foam::pimpleControl::finalInnerIter() const
{
return
finalIter()
&& corrPISO_ == nCorrPISO_
&& corrNonOrtho_ == nNonOrthCorr_ + 1;
}
`
In the 1712 version it reads:
`
inline bool Foam::pimpleControl::finalInnerIter() const
{
return
corrPISO_ == nCorrPISO_
&& corrNonOrtho_ == nNonOrthCorr_ + 1;
}
`
When adding the `finalIter()` I see the previous (1606) behaviour again.
I have to admit that it is a bit of a black box for me, so I don't know what it does and what's the reason behind removing this statement. It does slow down my simulations with a factor 2-3, so it might be worth changing it back.[1606Log](/uploads/242f7062ba35c345938c5056c1daf4a8/1606Log)[1712Log][1606Log](/uploads/538a7fd214ba363e587989507379dd5a/1606Log)https://develop.openfoam.com/Development/openfoam/-/issues/787forceCoeff writeFields option producing strange values: areaIntegrate of forc...2020-11-07T16:15:14ZAdminforceCoeff writeFields option producing strange values: areaIntegrate of forceCoeff field != forceCoeffI have been using the forceCoeffs function object for a long time, and am trying the writeFields option in v1712. However, it produces very strange values. I have a test case with one wall patch, and from the solving log, I can see that ...I have been using the forceCoeffs function object for a long time, and am trying the writeFields option in v1712. However, it produces very strange values. I have a test case with one wall patch, and from the solving log, I can see that the forceCoeff for that patch is quite different from the areaIntegrate of forcesAll:forceCoeff on that patch. I would expect the integral to give a value close to Cd pressure+viscous.
When I plot contours of forcesAll:forceCoeff in paraview, I see very low max values (~0.0002), when I should see surface normal*Cp, and Cp is roughly between -2 and 1.
I can supply a solved test case, and the relevant /system files and log files are attached.
```
forceCoeffs forcesAll execute:
Coefficients
Cm : -239.9753 (pressure: 176.0671 viscous: 0.6762368 porous: -416.7187)
Cd : 2.021964 (pressure: 1.242636 viscous: 0.005935802 porous: 0.7733919)
Cl : 2.230875 (pressure: 0.2968915 viscous: 0.001180773 porous: 1.932802)
Cl(f) : -238.8599
Cl(r) : 241.0908
surfaceFieldValue surfaceFieldValue1 write:
total area = 2.59955
areaNormalIntegrate(wall_l_body) of forcesAll:forceCoeff = (-0.0001750436 0 0)
surfaceFieldValue surfaceFieldValue2 write:
total area = 2.59955
areaIntegrate(wall_l_body) of forcesAll:forceCoeff = (9.107523e-05 -9.712166e-06 2.222456e-05)
```
[forcesAll](/uploads/3e40a39f7e41c19ceb9658ac4428ec60/forcesAll)
[controlDict](/uploads/bba6ee01fbd6897c829fa71d341de1e7/controlDict)[log.solve_OF.log](/uploads/19fd0116aeba1926522729982229ff92/log.solve_OF.log)
\#\# Reattaching the author to the issue ticket: @aerogt3 \#\#Kutalmış BerçinKutalmış Berçinhttps://develop.openfoam.com/Development/openfoam/-/issues/788Feature: Option to print ClockTime in Day:Hour:Mins:Secs format instead of on...2020-08-10T16:02:44ZKutalmış BerçinFeature: Option to print ClockTime in Day:Hour:Mins:Secs format instead of only SecsHi,
I observed myself and my colleagues converting `ClockTime` (log file) of their computations by hand to other units (e.g. hours) to monitor their time advancement.
Consider a log file consisting the following:
`ExecutionTime = 1720...Hi,
I observed myself and my colleagues converting `ClockTime` (log file) of their computations by hand to other units (e.g. hours) to monitor their time advancement.
Consider a log file consisting the following:
`ExecutionTime = 172074.87 s ClockTime = 172789 s`
IMHO, if it is not performance demanding, it would be useful to give an option to a user to select the time format. For example, `slurm` uses the `Day-Hour:Mins:Secs` format, which, it seems, allowing some users to understand the time advancement more quickly:
`ClockTime = 1-16:41:34`
Kind regardsMark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/789BUG: distributedTriSurfaceMesh written to processor*/0/triSurface/2021-07-06T12:34:11ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comBUG: distributedTriSurfaceMesh written to processor*/0/triSurface/Runnning with distributedTriSurfaceMesh:
- runParallel surfaceRedistributePar independent
- rmpirun -np 6 snappyHexMesh -overwrite -parallel
and at end of run I discovered triSurface/ inside the 0/ folders. Don't know which one did it.Runnning with distributedTriSurfaceMesh:
- runParallel surfaceRedistributePar independent
- rmpirun -np 6 snappyHexMesh -overwrite -parallel
and at end of run I discovered triSurface/ inside the 0/ folders. Don't know which one did it.https://develop.openfoam.com/Development/openfoam/-/issues/790BUG: singleCellFvMesh does not support disconnected regions (i.e. only does o...2021-07-06T12:34:35ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comBUG: singleCellFvMesh does not support disconnected regions (i.e. only does one cell)Not tested.Not tested.Mattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comhttps://develop.openfoam.com/Development/openfoam/-/issues/791time-control function object does not respect underlying function object2020-03-13T13:46:29ZMark OLESENtime-control function object does not respect underlying function objectWhen a function-object uses `timeStart`, `timeEnd` to control its activation, these values are used to define if execution or writing occurs, but can also mean that the underlying `end()` function is never called.
This can be problematic...When a function-object uses `timeStart`, `timeEnd` to control its activation, these values are used to define if execution or writing occurs, but can also mean that the underlying `end()` function is never called.
This can be problematic if the `end()` method is being used to free up resources.Mark OLESENMark OLESEN