Development issueshttps://develop.openfoam.com/groups/Development/-/issues2016-10-24T21:19:11Zhttps://develop.openfoam.com/Development/openfoam/-/issues/183ENH: extend coverage for wmUNSET2016-10-24T21:19:11ZPrashant SonakarENH: extend coverage for wmUNSETCertain variables could be added for further clearing of environment:
- FOAM_ETC
- WM_COMPILER_TYPE
- WM_LABEL_SIZE
- WM_LABEL_OPTION
@Roger @Pawan Certain variables could be added for further clearing of environment:
- FOAM_ETC
- WM_COMPILER_TYPE
- WM_LABEL_SIZE
- WM_LABEL_OPTION
@Roger @Pawan Version v1612Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/184Reduce code duplication for coded boundary conditions2016-12-23T12:44:52ZMark OLESENReduce code duplication for coded boundary conditionsVersion v1612Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/186BUG: runTimePostProcessing - glyphs on cutPlanes2016-12-23T12:44:52ZPrashant SonakarBUG: runTimePostProcessing - glyphs on cutPlanesAttached example replicating the issue.[pitzDaily-glyphOnCutPlane.tgz](/uploads/7ea764c6e64c8b122243c6f6e642f0d3/pitzDaily-glyphOnCutPlane.tgz)
Probably similar issue of handling PointData/CellData.Attached example replicating the issue.[pitzDaily-glyphOnCutPlane.tgz](/uploads/7ea764c6e64c8b122243c6f6e642f0d3/pitzDaily-glyphOnCutPlane.tgz)
Probably similar issue of handling PointData/CellData.Version v1612AdminAdminhttps://develop.openfoam.com/Development/openfoam/-/issues/188Generic patches are missing access to their actual underlying patch types2016-12-23T12:44:51ZMark OLESENGeneric patches are missing access to their actual underlying patch typesTrivial change.Trivial change.Version v1612Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/190BUG: icorrect mapping for processor patch2016-12-23T12:44:52ZPrashant SonakarBUG: icorrect mapping for processor patchAttached case replicating the issue [cavityMappingTest.tgz](/uploads/178c05d27197c3a247e02bce402c6943/cavityMappingTest.tgz)
```
procBoundary0to1
{
type processor;
value nonuniform List<s...Attached case replicating the issue [cavityMappingTest.tgz](/uploads/178c05d27197c3a247e02bce402c6943/cavityMappingTest.tgz)
```
procBoundary0to1
{
type processor;
value nonuniform List<scalar> 5(9.95865e-317 -nan -nan -nan -nan);
}
```
Issue was not observed for vector field mapping in tutorial.
Version v1612AdminAdminhttps://develop.openfoam.com/Development/openfoam/-/issues/192regIOobjectRead should use reverse scatter order2016-12-23T12:44:52ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comregIOobjectRead should use reverse scatter orderVersion v1612https://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/199BUG: decomposition failure (due to folder name/ ??)2019-12-09T22:04:11ZPrashant SonakarBUG: decomposition failure (due to folder name/ ??)An interesting bug in decomposition from @Koushik
[issue_with_decomposition_processor1.tgz](/uploads/a828281324e633cd39e875c2d2a400a9/issue_with_decomposition_processor1.tgz)
deomposePar seems to fails with error [log.decomposePar...An interesting bug in decomposition from @Koushik
[issue_with_decomposition_processor1.tgz](/uploads/a828281324e633cd39e875c2d2a400a9/issue_with_decomposition_processor1.tgz)
deomposePar seems to fails with error [log.decomposePar](/uploads/ce7be4460579a49a854c57fea8c51296/log.decomposePar)
@Mattijs Version v1612Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/201Bug: residuals function in openfoam42016-08-03T04:52:50ZAdminBug: residuals function in openfoam4Dear developer, I have installed openfoam4 and I tried to use the residuals function, implemented in order to plot the residuals of the variables p, Ux, Uy and Uz. I tried this function with some solvers and with the interDyMFoam this fu...Dear developer, I have installed openfoam4 and I tried to use the residuals function, implemented in order to plot the residuals of the variables p, Ux, Uy and Uz. I tried this function with some solvers and with the interDyMFoam this function does not work. I tried three case study the testTubeMixer, damBreakWithObstacle and the DTCHull; for every case the result is the same. For example in the testTubeMixer case I got:
user:~/OpenFOAM/user-4.0/run/testTubeMixer$ foamMonitor -l postProcessing/residuals/0/residuals.dat
plot
^
"/tmp/tmp.mZHUoAmF0R", line 7: function to plot expected
Best regards,
Vincenzo
https://develop.openfoam.com/Development/openfoam/-/issues/202decomposePar -cellDist misses patches2019-12-09T22:04:11ZMark OLESENdecomposePar -cellDist misses patchesIt would be easier to visualize if patches were included in `cellDist` as well.It would be easier to visualize if patches were included in `cellDist` as well.Version v1612Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/203runParallel ignores presence of log file2019-12-09T22:04:11ZMark OLESENrunParallel ignores presence of log fileSame bug also exists in the upstream version.Same bug also exists in the upstream version.Version v1612Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/205blendingFactor function object cannot be applied to bounded schemes2019-12-09T22:04:11ZAdminblendingFactor function object cannot be applied to bounded schemesIf the blendingFactor function object is applied to a bounded scheme the code crashes with an invalid cast.If the blendingFactor function object is applied to a bounded scheme the code crashes with an invalid cast.Version v1612AdminAdminhttps://develop.openfoam.com/Development/openfoam/-/issues/206sampledSets do not warn for empty field list (and do not write geometry either)2019-12-09T22:04:11ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comsampledSets do not warn for empty field list (and do not write geometry either)This happened when there was a 0/p which happened to be of type dictionary instead of volScalarField. Would be nice if there was a warning. This does not need to be done for sampledSurfaces since these can be used without fields.
This happened when there was a 0/p which happened to be of type dictionary instead of volScalarField. Would be nice if there was a warning. This does not need to be done for sampledSurfaces since these can be used without fields.
https://develop.openfoam.com/Development/openfoam/-/issues/207Field mapping using the tetOverlapVolume class an be fragile when using the c...2019-12-09T22:04:10ZAdminField mapping using the tetOverlapVolume class an be fragile when using the cellVolumeWeight optionThe cellVolumeWeight option calculates volume conservative weights when mapping between meshes. However, the use of tolerances e.g. comparing against the decomposed tet volume is not sufficient in some cases, and not consistent with the...The cellVolumeWeight option calculates volume conservative weights when mapping between meshes. However, the use of tolerances e.g. comparing against the decomposed tet volume is not sufficient in some cases, and not consistent with the failure mode reported by the plane class. Typical error suggests that a plane normal direction cannot be defined due to collapsed tet points:
```
[3] --> FOAM FATAL ERROR:
[3] Plane normal defined with zero length
Bad points:(0.176595 0.0984721 0.39584) (0.176595 0.0993738 0.39584) (0.176595 0.098964 0.39584)
[3]
[3] From function void Foam::plane::calcPntAndVec(const Foam::point&, const Foam::point&, const Foam::point&)
[3] in file meshes/primitiveShapes/plane/plane.C at line 101.
```Version v1612AdminAdminhttps://develop.openfoam.com/Development/openfoam/-/issues/209Environment variables in libs not handled2016-12-20T17:10:25ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comEnvironment variables in libs not handledlibs entries are not expanded.
libs ("$FOAM_USER_LIBSRC/libbla.so");
libs entries are not expanded.
libs ("$FOAM_USER_LIBSRC/libbla.so");
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/214Typo in 'SunDirTraking'2016-09-28T17:27:10ZAdminTypo in 'SunDirTraking'This is by no means critical, but `SunDirTraking` has a typo, since it's missing the `c` in `Tracking`, i.e. it should be `SunDirTracking`.
The files that have these typos can be found with the following commands:
```
grep -r 'Sun...This is by no means critical, but `SunDirTraking` has a typo, since it's missing the `c` in `Tracking`, i.e. it should be `SunDirTracking`.
The files that have these typos can be found with the following commands:
```
grep -r 'SunDirTraking' applications src tutorials
grep -r 'sunDirTraking' applications src tutorials
```
Sergio FerrarisSergio Ferrarishttps://develop.openfoam.com/Development/openfoam/-/issues/216runTimePostProcessing FO scalarBar label and picture numbering2017-03-16T05:40:18ZMatej FormanrunTimePostProcessing FO scalarBar label and picture numberingIn FO runTimePostProcessing the title for scalarBar in vertical position in not justified nicely to the scalar bar. There is a big gap between the title and the scalar bar.
Testing on $FOAM_TUTORIALS/multiphase/interFOAM/laminar/damBre...In FO runTimePostProcessing the title for scalarBar in vertical position in not justified nicely to the scalar bar. There is a big gap between the title and the scalar bar.
Testing on $FOAM_TUTORIALS/multiphase/interFOAM/laminar/damBreak, added FO to controlDict (attached) creates not nice description. Might be nice to allow user to control the justification of the text and other parameters of the label. Maybe possibility to allow vertical orientation (for longer names) of the text via vtk functions.
Other issue is, that all pictures has the same name in different directories which makes it difficult to create the movie or doing other post-processing unless the user is skilled with shell commands.
Attached the [controlDict](/uploads/1b327ef9625fcb38449a7148b10ddf09/controlDict) with the FO definition and produced picture ![image.0000](/uploads/be69a074a2fdd83a83253807bf12d543/image.0000.png). AdminAdminhttps://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/218sHM crash with Intel-MPI-5.12017-03-16T05:35:22ZvilfayeausHM crash with Intel-MPI-5.1With Intel-MPI 5.1 compiler, most of jobs crash with OF-1606+. It is worth to mention it's working fine with Intel-MPI 4.1. I have attached a motorbike test case that fails.
FYI,
You can set the debug flag for fvMeshDistribute :
in ...With Intel-MPI 5.1 compiler, most of jobs crash with OF-1606+. It is worth to mention it's working fine with Intel-MPI 4.1. I have attached a motorbike test case that fails.
FYI,
You can set the debug flag for fvMeshDistribute :
in system/controlDict add:
DebugSwitches
{
fvMeshDistribute 1;
}
and it should give you more debug output.
Additional comment, by setting Intel-MPI environment variable I_MPI_DAPL_TRANSLATION_CACHE to 0, the case runs successfully. But this is just a work around and not a long term solution.
Please let me know, if you need more information.
[motorBikeLES_INTEL.tgz](/uploads/b41af7dbde7f7499ad980cf611803e05/motorBikeLES_INTEL.tgz)