Development issueshttps://develop.openfoam.com/groups/Development/-/issues2020-06-30T11:20:28Zhttps://develop.openfoam.com/Development/openfoam/-/issues/1738mingw: code failing in one tutorial : develop branch2020-06-30T11:20:28ZPawan Ghildiyalmingw: code failing in one tutorial : develop branchHi @mark
with latest develop branch as compiled on Friday, I saw one tutorial is failing .
* simpleFoam/pitzDailyExptInlet* .
** The same case is working fine with v1912. **
```
/*---------------------------------------------------...Hi @mark
with latest develop branch as compiled on Friday, I saw one tutorial is failing .
* simpleFoam/pitzDailyExptInlet* .
** The same case is working fine with v1912. **
```
/*---------------------------------------------------------------------------*\
| ========= | |
| \\ / F ield | OpenFOAM: The Open Source CFD Toolbox |
| \\ / O peration | Version: com |
| \\ / A nd | Website: www.openfoam.com |
| \\/ M anipulation | |
\*---------------------------------------------------------------------------*/
Build : 86cd5400ce-20200618 OPENFOAM=2006
Arch : "LSB;label=32;scalar=64"
Exec : C:\Users\pgh\Desktop\OF-1912-master-windows\msys64\home\ofuser\OpenFOAM\OpenFOAM-v1912 \platforms\linux64MingwDPInt32Opt\bin\simpleFoam.exe
Date : Jun 22 2020
Time : 11:40:08
Host : LONLAP003
PID : 36748
I/O : uncollated
Case : C:/Users/pgh/Desktop/OF-1912-master-windows/msys64/home/ofuser/OpenFOAM/OpenFOAM-v1912/tutorials/incompressible/simpleFoam/pitzDailyExptInlet
nProcs : 1
trapFpe: Floating point exception trapping enabled (FOAM_SIGFPE).
fileModificationChecking : Monitoring run-time modified files using timeStampMaster (fileModificationSkew 10)
allowSystemOperations : Allowing user-supplied system call operations
// * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * //
Create time
Create mesh for time = 0
SIMPLE: convergence criteria
field p tolerance 0.01
field U tolerance 0.001
field "(k|epsilon|omega)" tolerance 0.001
Reading field p
Reading field U
--> FOAM FATAL IO ERROR:
Trying to read raw field
file: C:/Users/pgh/Desktop/OF-1912-master-windows/msys64/home/ofuser/OpenFOAM/OpenFOAM-v1912/tutorials/incompressible/simpleFoam/pitzDailyExptInlet/C:/Users/pgh/Desktop/OF-1912-master-windows/msys64/home/ofuser/OpenFOAM/OpenFOAM-v1912/tutorials/incompressible/simpleFoam/pitzDailyExptInlet/constant/boundaryData/inlet/points at line 1.
From Foam::rawIOField<Type>::rawIOField(const Foam::IOobject&, bool) [with Type = Foam::Vector<double>]
in file /home/buzz2/pawan/OpenFOAM/mingw-windows/OpenFOAM-dev/src/meshTools/lnInclude/rawIOField.C at line 110.
FOAM exiting
```Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/1482MinGW doesn't appear to have a download link2019-11-09T16:01:41ZAdminMinGW doesn't appear to have a download linkhttps://www.openfoam.com/download/install-binary-windows-mingw.php
@Pawan @andyhttps://www.openfoam.com/download/install-binary-windows-mingw.php
@Pawan @andyAdminAdminhttps://develop.openfoam.com/Development/openfoam/-/issues/1760mingw :test case fail2021-07-06T17:36:26ZPawan Ghildiyalmingw :test case fail
@mark
Creating a list of tutorial(except multiphase) which fail in windows version.
I will keep on updating the list.
1. heatTransfer/buoyantBoussinesqSimpleFoam/iglooWithFridges/
The tutorial fail in windows mingw versi...
@mark
Creating a list of tutorial(except multiphase) which fail in windows version.
I will keep on updating the list.
1. heatTransfer/buoyantBoussinesqSimpleFoam/iglooWithFridges/
The tutorial fail in windows mingw version while running snappyHexMesh
It was unable to find "displacementLaplacian" Solver
Adding libs(libfvMotionSolvers) in controlDict, resolve the issue .
2. incompressible/pimpleFoam/LES/surfaceMountedCube/initChannel (Edited)
functionObject surface: to output turbulenceProperties:L,turbulenceProperties:R, turbulenceProperties:R
write variablefile as turbulenceProperties and not turbulenceProperties:Rhttps://develop.openfoam.com/Development/openfoam/-/issues/2385minor cleanup (declutter) of List, DynamicList header2022-03-14T16:18:00ZMark OLESENminor cleanup (declutter) of List, DynamicList header- do not need move from SortableList methods
- the return value on append() is not used anywhere. A bit of an original design mistake with the idea that we would wish to chain together multiple class (like Java). Should just be \c void.- do not need move from SortableList methods
- the return value on append() is not used anywhere. A bit of an original design mistake with the idea that we would wish to chain together multiple class (like Java). Should just be \c void.Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/721minor cleanup of lagrangian writing etc2018-02-22T12:17:21ZMark OLESENminor cleanup of lagrangian writing etc- the writeLagrangianPositions switch is not registered (so local system/controlDict changes are ignored).
- the writeLagrangianCoordinate switch should now be dropped. No longer transition, things won't restart if `coordinates` aren't t...- the writeLagrangianPositions switch is not registered (so local system/controlDict changes are ignored).
- the writeLagrangianCoordinate switch should now be dropped. No longer transition, things won't restart if `coordinates` aren't there.
- relocate geometryType enum from IOPosition to particle. This will make it non-templated.
- consolidate oldParticle struct into one place (eg, in particle) and rename as something like `compat1706` so that its compatibility level is transparently documented via the API.
Optional: add `-write-positions` command-line option that forces writeLagrangianPositions on. This could be useful for things like reconstructPar, foamToVTK, foamToEnsight etc, when the user needs the information for external consumption, but only realized it after the simulation was complete.
@andy @Rogerv1806Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/2435Minor error with mappedFile PatchFunction12022-04-08T14:50:49ZBen MalinMinor error with mappedFile PatchFunction1
### Summary
When a field name is specified other than the default, the format of the write function is incorrect
### Steps to reproduce
Run a case using the PatchFunction1 mappedFile with a non-default fieldTable entry. The result is...
### Summary
When a field name is specified other than the default, the format of the write function is incorrect
### Steps to reproduce
Run a case using the PatchFunction1 mappedFile with a non-default fieldTable entry. The result is then output in the format:
```
patch
{
type ...;
fieldTable "[non-default name]";
value
{
type mappedField;
...
}
}
```
If this result is then used to run another case, the fieldTable entry gets missed and an error will be thrown that the field can't be found at constant/boundaryData/patch/...
The correct behavior is:
```
patch
{
type ...;
value
{
type mappedField;
fieldTable "[non-default name]";
...
}
}
```
### Possible fixes
Easy fix, minor change to writeData function. Just need to move the os.writeEntryIfDifferent("fieldTable") to be within the os.beginBlock(word(this->name() + "Coeffs")) section.https://develop.openfoam.com/Development/openfoam/-/issues/210Minor flaw in etc/config.sh/FFTW leads to always assuming it's not system-ins...2019-12-09T22:04:10ZAdminMinor flaw in etc/config.sh/FFTW leads to always assuming it's not system-installedI was writing and testing detailed installation steps for Ubuntu 16.04, when I stumbled upon two issues while building:
1. There is a typo in the variable checked, where `FFTW_ARCH_PATH_PATH` has one too many "_PATH" ;) Patch after ...I was writing and testing detailed installation steps for Ubuntu 16.04, when I stumbled upon two issues while building:
1. There is a typo in the variable checked, where `FFTW_ARCH_PATH_PATH` has one too many "_PATH" ;) Patch after the list below.
2. `ThirdParty-*/makeFFTW` was missing `-f` when calling `unset`, which @mark has already solved in Development/ThirdParty-plus#2.
The patch for fixing `etc/config.sh/FFTW`:
```
diff --git a/etc/config.sh/FFTW b/etc/config.sh/FFTW
index 7c0a488..f3cb4ea 100644
--- a/etc/config.sh/FFTW
+++ b/etc/config.sh/FFTW
@@ -64,7 +64,7 @@ then
# it is either located within ThirdParty, or a central installation
# outside of ThirdParty and must be added to the lib-path.
- ending="${FFTW_ARCH_PATH_PATH##*-}"
+ ending="${FFTW_ARCH_PATH##*-}"
if [ "$ending" != none -a "$ending" != system ]
then
_foamAddLib $FFTW_ARCH_PATH/lib$WM_COMPILER_LIB_ARCH
```https://develop.openfoam.com/Development/openfoam/-/issues/441Minor improvements to profiling2018-05-03T18:08:12ZAdminMinor improvements to profilingFirst patch has two minor improvements:
* Make it possible to switch on profiling via `site/vXXX+/controlDict` (I like to always have profiling)
* For multi-region cases add the region-name to the name of the profiling-information
[pr...First patch has two minor improvements:
* Make it possible to switch on profiling via `site/vXXX+/controlDict` (I like to always have profiling)
* For multi-region cases add the region-name to the name of the profiling-information
[profilingImprovements.patch](/uploads/d0ccbbef5254485e88c758521f550b60/profilingImprovements.patch)
The second patch adds profiling to the time loop by deleting/creating a new profiling::Trigger-object at every call to run(). That way in the profiling information it can now be seen how much time was spent inside and outside the time-loop (usually should be in the order of 99% to 1). The ProfilingTrigger-class was necessary as apparently C++ does not allow the forward-declaration of interior classes like profiling::Trigger
[profilingProfileTimeLoop.patch](/uploads/cde3f5058ae4e86fc90357f680fc22f1/profilingProfileTimeLoop.patch)
I split this into two patches because obviously fiddling with the Time-class is always controverialMark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/1246minor issue: pressureDifference.cfg2019-12-09T22:37:28ZAdminminor issue: pressureDifference.cfgThere is a semi colon missing after the line
writeInterval 1
in
etc/caseDicts/postProcessing/pressure/pressureDifference.cfgThere is a semi colon missing after the line
writeInterval 1
in
etc/caseDicts/postProcessing/pressure/pressureDifference.cfgMark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/416minor spelling in scalarTransport.C2019-12-09T21:29:27ZAdminminor spelling in scalarTransport.CI am guessing that in scalarTransport.C (in OpenFOAM-v1612+/src/functionObjects/solvers/scalarTransport), the variable
"limitedPhiAlpa" is supposed to be "limitedPhiAlpha" (i.e. "h" is missing), right!?I am guessing that in scalarTransport.C (in OpenFOAM-v1612+/src/functionObjects/solvers/scalarTransport), the variable
"limitedPhiAlpa" is supposed to be "limitedPhiAlpha" (i.e. "h" is missing), right!?https://develop.openfoam.com/Development/openfoam/-/issues/446Minor typo in profiling macro2021-03-30T17:34:18ZAdminMinor typo in profiling macroFoam::profiling mixed up with Foam::Profiling
suggested fix:
[profiling.patch](/uploads/8c4c7209fdb7a08057d49761993dcbd7/profiling.patch)Foam::profiling mixed up with Foam::Profiling
suggested fix:
[profiling.patch](/uploads/8c4c7209fdb7a08057d49761993dcbd7/profiling.patch)Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/3071Minor typo in the documentation link2024-01-18T12:48:14Zs1291Minor typo in the documentation linkThe webpage https://doc.openfoam.com/ lists version 2312 twice instead of 2306 and 2312.
![image](/uploads/1c71968fc14bf589ac5cd76849b7a8a6/image.png)The webpage https://doc.openfoam.com/ lists version 2312 twice instead of 2306 and 2312.
![image](/uploads/1c71968fc14bf589ac5cd76849b7a8a6/image.png)https://develop.openfoam.com/Development/openfoam/-/issues/587mirrorMesh seems to fail in parallel2017-12-19T06:29:50ZAdminmirrorMesh seems to fail in parallelThe below dummy case seems to work fine in serial (./Allrun) but when using mirrorMesh in parallel (./Allrun.parallel) on a decomposed case mirrorMesh gives a warning:
> Mirroring faces on coupled patches destroys the ordering. This mi...The below dummy case seems to work fine in serial (./Allrun) but when using mirrorMesh in parallel (./Allrun.parallel) on a decomposed case mirrorMesh gives a warning:
> Mirroring faces on coupled patches destroys the ordering. This might be fixed by running a dummy createPatch afterwards.
However, running createPatch yields
> ***Inconsistent patches across processors, processor 0 has patch names:
and then it runs forever.
If the parallel option is given I would think it should work in principal, but I have not been able to get it to work in any parallel case, so I would consider it a bug... Or is there a work around?
Thanks,
Pal
[case.tgz](/uploads/3943f1c356bef25aca1c341cdf6abb55/case.tgz)https://develop.openfoam.com/Development/openfoam/-/issues/1103Misleading Log Info: fieldAverage timeStart Option2020-01-16T18:14:30ZKutalmış BerçinMisleading Log Info: fieldAverage timeStart Option### Summary
When **fieldAverage** functionObject's *timeStart* is *on*, the solver misleadingly informs the user as if the averaging is started:
For example:
```
functions
{
fieldAverage1
{
type fieldAver...### Summary
When **fieldAverage** functionObject's *timeStart* is *on*, the solver misleadingly informs the user as if the averaging is started:
For example:
```
functions
{
fieldAverage1
{
type fieldAverage;
libs ("libfieldFunctionObjects.so");
writeControl writeTime;
timeStart 60;
...
```
The solver informs the user at 0 time-step with the following:
```
fieldAverage fieldAverage1:
Restarting averaging for fields:
U: starting averaging at time 0
p: starting averaging at time 0
yPlus: starting averaging at time 0
wallShearStress: starting averaging at time 0
```
### Steps to reproduce
Please run `tutorials/incompressible/pimpleFoam/LES/channel395DFSEM` case.
### What is the expected *correct* behavior?
The solver should inform the user that the averaging will start at time **timeStart** of **fieldAverage**.Kutalmış BerçinKutalmış Berçinhttps://develop.openfoam.com/Development/openfoam/-/issues/724misleading name for two-parameter Foam::name()2018-02-22T12:18:23ZMark OLESENmisleading name for two-parameter Foam::name()- currently accepts a printf-style format string. It should probably be renamed as `format` instead. Since this is reasonably infrequently used, I think that it should be relegated to the stringOps namespace as well. Eg,
stringOps::...- currently accepts a printf-style format string. It should probably be renamed as `format` instead. Since this is reasonably infrequently used, I think that it should be relegated to the stringOps namespace as well. Eg,
stringOps::format("fmt%d", 10);
In fact, probably want to make the whole thing templated:
template<class Primitive, class StringType=string>
StringType format(const char* fmt, const Primitive& val)
If desired, could have convenience static `word::format` as part of the word class, etc.
Might also consider with Args... forwarding.v1806Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/2328Mismatch between user and physical time when adapting the time precision2022-01-21T12:33:30ZIvor CliffordMismatch between user and physical time when adapting the time precision<!--
*** 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
I am developing a new solver in which I derive from Foam::Time and override the virtual functions Foam::TimeState::userTimeToTime, etc. While doing this, I noticed that OpenFOAM unexpectedly increases the write precision, which seems to be due to mismatches between user- and physical time in OpenFOAM's time classes. See the proposed source of problem below.
### Steps to reproduce
This bug is not related to any specific usage of the code.
### Environment information
<!--
Providing details of your set-up can help us identify any issues, e.g.
OpenFOAM version : v2112|v2106|v2012|v2006|v1912|v1906 etc
Operating system : ubuntu|openSUSE|centos etc
Hardware info : any info that may help?
Compiler : gcc|intel|clang etc
-->
- OpenFOAM version : v2112
- Operating system : Ubuntu 20.04
- Hardware info : Intel 64 bit
- Compiler : Gcc 8.2
### 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
-->
After some debugging, I think I found the issue. At [Time.C:1287](../9a2a22a03/src/OpenFOAM/db/Time/Time.C#L1287)
```c
// Tolerance used when testing time equivalence
const scalar timeTol =
max(min(pow(10.0, -precision_), 0.1*deltaT_), SMALL);
```
Here the physical time is used to define the tolerance for increasing the time precision, but a few lines down (1302) this is compared against the user time. This mismatch causes the precision to unexpectedly increase.
A second issue I noted is that, on line 1292, userDeltaT is determined using the function `timeToUserTime`. This is only correct if the user time is a linear function of the physical time. It would be better to calculate this as:
```c
const scalar userDeltaT = timeToUserTime(value()) - timeToUserTime(value() - deltaT_);
```Kutalmış BerçinKutalmış Berçinhttps://develop.openfoam.com/Development/openfoam/-/issues/2287mismatch in autoMap function?2021-12-10T13:05:39ZMark OLESENmismatch in autoMap function?Compiler warnings for newly added code:
```
filmPyrolysisRadiativeCoupledMixedFvPatchScalarField.H:222:26: warning: 'Foam::filmPyrolysisRadiativeCoupledMixedFvPatchScalarField::autoMap' hides overloaded virtual function [-Woverloaded-vi...Compiler warnings for newly added code:
```
filmPyrolysisRadiativeCoupledMixedFvPatchScalarField.H:222:26: warning: 'Foam::filmPyrolysisRadiativeCoupledMixedFvPatchScalarField::autoMap' hides overloaded virtual function [-Woverloaded-virtual]
virtual void autoMap
^
temperatureCoupledBase.H:205:22: note: hidden overloaded virtual function 'Foam::temperatureCoupledBase::autoMap' declared here: type mismatch at 1st parameter ('const Foam::FieldMapper &' vs 'const Foam::fvPatchFieldMapper &')
virtual void autoMap
^
filmPyrolysisRadiativeCoupledMixedFvPatchScalarField.H:228:26: warning: 'Foam::filmPyrolysisRadiativeCoupledMixedFvPatchScalarField::rmap' hides overloaded virtual function [-Woverloaded-virtual]
virtual void rmap
^
temperatureCoupledBase.H:211:22: note: hidden overloaded virtual function 'Foam::temperatureCoupledBase::rmap' declared here: type mismatch at 1st parameter ('const Foam::temperatureCoupledBase &' vs 'const fvPatchField<Foam::scalar> &' (aka 'const fvPatchField<double> &'))
virtual void rmap
^
```
There are a few more, but this is the gist of it. Warnings raised by clang-13v2112Mattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comhttps://develop.openfoam.com/Development/openfoam/-/issues/564mismatch in send/receive sizes of int32/int642021-07-06T12:05:23ZMark OLESENmismatch in send/receive sizes of int32/int64I think the root cause for #505 could be how ints are being sent/received.
For example, an int32_t is sent with a LABEL tag and is 4 bytes. But a LABEL is received in UIPstream as a `label` and could be 32 or 64-bits (depending on WM_LAB...I think the root cause for #505 could be how ints are being sent/received.
For example, an int32_t is sent with a LABEL tag and is 4 bytes. But a LABEL is received in UIPstream as a `label` and could be 32 or 64-bits (depending on WM_LABEL_SIZE). It would seem to be the same for int64, but we probably haven't been sending those about too much in that form.
@andy @MattijsMark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/217Missing bracket closure in "doc/Doxygen/css/doxyMod.css" leads to broken code...2019-12-09T22:04:10ZAdminMissing bracket closure in "doc/Doxygen/css/doxyMod.css" leads to broken code flow in DoxygenThe missing bracket closure in , for which a fix is provided in the patch below, will fix the current issue that occurs in the included source code files that are rendered with Doxygen.
For example, [this page for `temperatureCoupledB...The missing bracket closure in , for which a fix is provided in the patch below, will fix the current issue that occurs in the included source code files that are rendered with Doxygen.
For example, [this page for `temperatureCoupledBase.C`](http://openfoam.com/documentation/cpp-guide/html/a11262_source.html), as we can also see in the image below (left is the current result for the unfixed file, on the right when the fix is implemented), is not using the correct format for ensuring the verbatim render for the source code lines:
![Before_vs_after](/uploads/c951efe7dfc4406cf086283784f4fb72/Before_vs_after.png)
The patch for fixing this is as follows:
```
diff --git a/doc/Doxygen/css/doxyMod.css b/doc/Doxygen/css/doxyMod.css
index 46ac2df..fbb968f 100644
--- a/doc/Doxygen/css/doxyMod.css
+++ b/doc/Doxygen/css/doxyMod.css
@@ -118,6 +118,8 @@ tr.memlist
.OFPlainTable tr td {
height: 20px;
padding-left: 5px;
+}
+
div.line,
span.comment,
span.keyword,
```
In addition, this can easily be used to fix the current file that is located at http://openfoam.com/documentation/cpp-guide/css/doxyMod.cssAdminAdminhttps://develop.openfoam.com/Development/openfoam/-/issues/1449Missing cmptMagSqr2023-12-07T19:05:04ZMark OLESENMissing cmptMagSqrNoted by @sbna - would be useful when calculating matrix norms.Noted by @sbna - would be useful when calculating matrix norms.Mark OLESENMark OLESEN