Development issueshttps://develop.openfoam.com/groups/Development/-/issues2017-04-18T13:40:34Zhttps://develop.openfoam.com/Development/openfoam/-/issues/443BUG: FOAM_INST_DIR setting?2017-04-18T13:40:34ZPrashant SonakarBUG: FOAM_INST_DIR setting?Latest develop branch throws error while sourcing.
Invalid (blank) entry for FOAM_INST_DIR
Linux version: CentOS-7Latest develop branch throws error while sourcing.
Invalid (blank) entry for FOAM_INST_DIR
Linux version: CentOS-7Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/1872BUG: foamMeshToFluent writes empty brackets in msh file2023-01-11T10:54:09ZDaveBUG: foamMeshToFluent writes empty brackets in msh file### Summary
foamMeshToFluent writes empty brackets in the msh file in the "caption" of the very last section when the names ans types of the domains and the boundaries are declared, p.e.
`(12 (1 1 a94fc 1 0)(`
` 4 4 ... 4 4)`**_`()`_...### Summary
foamMeshToFluent writes empty brackets in the msh file in the "caption" of the very last section when the names ans types of the domains and the boundaries are declared, p.e.
`(12 (1 1 a94fc 1 0)(`
` 4 4 ... 4 4)`**_`()`_**`)`
`(39 (1 fluid fluid-1)())`
`(39 (2 interior interior-1)())`
`...`
Those empty brackets **_`()`_** cause ICEM to throw the following error when importing the mesh file:
`icem read_rampant_file() expecting '(' and got 41`
Although, the mesh is imported, the boundary and domain names aren't.
### Steps to reproduce
Export a mesh from any OpenFoam test case to Fluent msh via `foamMeshToFluent`
### Environment information
- OpenFOAM version : v2006
- Operating system : ubuntu1804@WSL@Win10
### Possible fixes
Removing the empty brackets in the mentioned header enables ICEM to properly read in all mesh informations.https://develop.openfoam.com/Development/openfoam/-/issues/317BUG : foamToEnsight -faceZones sometimes fails in the develop branch2018-05-29T05:39:49ZAdminBUG : foamToEnsight -faceZones sometimes fails in the develop branchfoamToEnsight -faceZones '(".*")' sometimes fails in the most recent commit (7582334f). The attached case worked in commit 57a1e6d2, but fails in 7582334f. This failure only occurs in parallel and only occurs when using the -faceZones fl...foamToEnsight -faceZones '(".*")' sometimes fails in the most recent commit (7582334f). The attached case worked in commit 57a1e6d2, but fails in 7582334f. This failure only occurs in parallel and only occurs when using the -faceZones flag.
The error I receive appears to be an infinite loop of...
```
[adpn029:214314] *** Process received signal ***
[adpn029:214314] Signal: Segmentation fault (11)
[adpn029:214314] Signal code: (2102221680)
[adpn029:214314] Failing at address: (nil)
[adpn029:214314] [ 0] /lib64/libc.so.6[0x3d83c326a0]
[adpn029:214314] [ 1] /apps/OpenFOAM/.builds/OFPlus/dev/OpenFOAM-plus/platforms/linux64Gcc61DPInt32Opt/lib/libconversion.so(_ZNK4Foam11ensightMesh5writeERNS_14ensightGeoFileE+0xb4e)[0x7fc64ebc91fe]
[adpn029:214314] [ 2] foamToEnsight[0x4ecb4a]
[adpn029:214314] [ 3] /lib64/libc.so.6[0x3d83c326a0]
[adpn029:214317] [ 1] /apps/OpenFOAM/.builds/OFPlus/dev/OpenFOAM-plus/platforms/linux64Gcc61DPInt32Opt/lib/libconversion.so(_ZNK4Foam11ensightMesh5writeERNS_14ensightGeoFileE+0xb4e)[0x7fc374cae1fe]
[adpn029:214317] [ 2] foamToEnsight[0x4ecb4a]
[adpn029:214317] [ 3] /lib64/libc.so.6(__libc_start_main+0xfd)[0x3d83c1ed5d]
[adpn029:214317] [ 4] foamToEnsight[0x44d19d]
[adpn029:214317] *** End of error message ***
```
[dam_break.tar.gz](/uploads/bbdc6050da02940a8dab6b0ce5e3fdfa/dam_break.tar.gz)Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/334BUG : foamToEnsight -faceZones still crashes sometimes in develop2018-05-29T05:39:49ZAdminBUG : foamToEnsight -faceZones still crashes sometimes in developPossibly related to #317, foamToEnsight -faceZones still crashes sometimes. I tested with the latest develop commit.
The example model is attached and is a simple pipe with a few faceZones and a cellZone created during meshing. When...Possibly related to #317, foamToEnsight -faceZones still crashes sometimes. I tested with the latest develop commit.
The example model is attached and is a simple pipe with a few faceZones and a cellZone created during meshing. When foamToEnsight -faceZones is run at the end, it crashes and goes into a large loop of errors.
![Capture](/uploads/bdfad5480880eef1f3f574a6e027b74e/Capture.PNG)
[tube_test_inter.tar.gz](/uploads/8fb9d819bf61cf3d317df22fa09ccd0c/tube_test_inter.tar.gz)Version v1612Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/430BUG: foamToEnsight failed when first patch type is empty?2019-12-09T21:29:27ZPrashant SonakarBUG: foamToEnsight failed when first patch type is empty?Attached modified tutorial with change only in
- blockMeshDict -> order of patch definition
- controlDict -> reduced run time
- Allrun -> Added foamToEnsight
[sineWaveDamping_modified.tgz](/uploads/a7dbed1ecb0e223edd8b39f2facd5ffc...Attached modified tutorial with change only in
- blockMeshDict -> order of patch definition
- controlDict -> reduced run time
- Allrun -> Added foamToEnsight
[sineWaveDamping_modified.tgz](/uploads/a7dbed1ecb0e223edd8b39f2facd5ffc/sineWaveDamping_modified.tgz)Version v1706Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/92BUG: foamToEnsight failed with epsilon field from applyBL2016-05-30T06:01:01ZPrashant SonakarBUG: foamToEnsight failed with epsilon field from applyBLAttached case replicating the behavior with new applyBoundaryLayer code from 92ae4fbe
Should the fields be written only corresponding to turbulence model being used?
[case_ofplus_foamToEnsight_failure.tgz](/uploads/dccead1228870cbd...Attached case replicating the behavior with new applyBoundaryLayer code from 92ae4fbe
Should the fields be written only corresponding to turbulence model being used?
[case_ofplus_foamToEnsight_failure.tgz](/uploads/dccead1228870cbdb91a557de5c6fe9f/case_ofplus_foamToEnsight_failure.tgz)
@Sergio AdminAdminhttps://develop.openfoam.com/Development/openfoam/-/issues/304BUG : foamToEnsight -nodeValues places an extra space in the .case file2016-11-28T23:37:04ZAdminBUG : foamToEnsight -nodeValues places an extra space in the .case fileWhen the -nodeValues option is used in foamToEnsight, it places an extra space in the .case file for each variable (see attached pic).
![ensight_error](/uploads/b1a128b351eb5ab7bdc4f528ea11145e/ensight_error.PNG)
This causes ensi...When the -nodeValues option is used in foamToEnsight, it places an extra space in the .case file for each variable (see attached pic).
![ensight_error](/uploads/b1a128b351eb5ab7bdc4f528ea11145e/ensight_error.PNG)
This causes ensight to fail when trying to open the case. There is no issue when -nodeValues isn't used.https://develop.openfoam.com/Development/openfoam/-/issues/902BUG: foamToEnsight replaces ":" with "_" for Lagrangian file names but retain...2020-06-22T15:13:04ZAdminBUG: foamToEnsight replaces ":" with "_" for Lagrangian file names but retains ":" in .case filefoamToEnsight replaces ":" with "_" when writing out Lagrangian file names. However, the .case file retains the ":" when listing the filenames for ensight to read. This results in a file read error when reading into EnSight.
[simple_spr...foamToEnsight replaces ":" with "_" when writing out Lagrangian file names. However, the .case file retains the ":" when listing the filenames for ensight to read. This results in a file read error when reading into EnSight.
[simple_spray_steady_good.case](/uploads/e5f3eb73f8b14dff94bcb333b019e50b/simple_spray_steady_good.case)
\#\# Reattaching the author to the issue ticket: @graups \#\#Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/2185Bug: foamToEnsight skips mesh2021-09-09T16:14:41ZPrashant SonakarBug: foamToEnsight skips meshFollowing illustrator creates valid EnSight in v1912 but later versions seem to skip the time without uniform folder and hence invalid EnSight export.
[pitzDaily.tgz](/uploads/9b6a5226d64515b801940207310b4538/pitzDaily.tgz)
@markFollowing illustrator creates valid EnSight in v1912 but later versions seem to skip the time without uniform folder and hence invalid EnSight export.
[pitzDaily.tgz](/uploads/9b6a5226d64515b801940207310b4538/pitzDaily.tgz)
@markhttps://develop.openfoam.com/Development/openfoam/-/issues/459BUG: forceCoeff not working in sonicFoam -> nacaAirfoil2017-05-02T08:54:30ZPrashant SonakarBUG: forceCoeff not working in sonicFoam -> nacaAirfoilcarried forward from https://develop.openfoam.com/Community/OpenFOAM-addOns/issues/4carried forward from https://develop.openfoam.com/Community/OpenFOAM-addOns/issues/4https://develop.openfoam.com/Development/openfoam/-/issues/436BUG: forceCoeffs function object not operating correctly for compressible cases2019-12-09T21:29:27ZAdminBUG: forceCoeffs function object not operating correctly for compressible casesThe rhoRef_ value is used when calculating the freestream dynamic pressure. This is only set in forces.C for incompressible cases, leaving the value uninitialised for compressible cases.The rhoRef_ value is used when calculating the freestream dynamic pressure. This is only set in forces.C for incompressible cases, leaving the value uninitialised for compressible cases.Version v1706https://develop.openfoam.com/Development/openfoam/-/issues/2552BUG: forceCoeffs: Log entries of pressure and viscous components are swapped2022-08-18T10:37:11ZKutalmış BerçinBUG: forceCoeffs: Log entries of pressure and viscous components are swapped### Summary
Reported by: @THO
Here an example:
**OLD Behavior**
```
forceCoeffs forceCoeffs write:
Cd : 0.8975191254 pressure: 0.8568458762 viscous: 0.04067324918
writing force and moment coefficient files.
```
*...### Summary
Reported by: @THO
Here an example:
**OLD Behavior**
```
forceCoeffs forceCoeffs write:
Cd : 0.8975191254 pressure: 0.8568458762 viscous: 0.04067324918
writing force and moment coefficient files.
```
**NEW Behavior**
```
forceCoeffs forceCoeffs write:
Coefficient Total Pressure Viscous Internal
Cd: 0.8975191254 0.04067324918 0.8568458762 0
```
As you can see, `pressure` and `viscous` are vice versa compared to the **old** behavior and for external aerodynamics, the main part is the `pressure` contribution. Hence, there is some mistake either in `.y()` and `.x()` or the output should be changed from:
```
Coefficient Total Pressure Viscous Internal
```
to
```
Coefficient Total Viscous Pressure Internal
```
### Example case
`$FOAM_TUTORIALS/incompressible/simpleFoam/simpleCar`
### Environment information
a72d4a1708Kutalmış BerçinKutalmış Berçinhttps://develop.openfoam.com/Development/openfoam/-/issues/2490BUG: forces/forceCoeffs: multiple FOs with writeFields=true is not possible2022-05-25T17:49:51ZKutalmış BerçinBUG: forces/forceCoeffs: multiple FOs with writeFields=true is not possibleOtherwise, throws `Failed to store pointer: force. Risk of memory leakage` error, simply because of name clashes for `force` and `moment` volFields:
[forces.C#L914](https://develop.openfoam.com/Development/openfoam/-/blob/develop/src/fu...Otherwise, throws `Failed to store pointer: force. Risk of memory leakage` error, simply because of name clashes for `force` and `moment` volFields:
[forces.C#L914](https://develop.openfoam.com/Development/openfoam/-/blob/develop/src/functionObjects/forces/forces/forces.C#L914)
[forces.C#L1115](https://develop.openfoam.com/Development/openfoam/-/blob/develop/src/functionObjects/forces/forces/forces.C#L1115)Kutalmış BerçinKutalmış Berçinhttps://develop.openfoam.com/Development/openfoam/-/issues/24BUG: forces FO with execFlowFunctionObject (including porosity)2015-12-17T12:53:52ZPrashant SonakarBUG: forces FO with execFlowFunctionObject (including porosity)When porosity is requested:
--> FOAM Warning :
From function virtual void Foam::forces::calcForcesMoment()
in file forces/forces.C at line 1174
Porosity effects requested, but no porosity models found in the database
...When porosity is requested:
--> FOAM Warning :
From function virtual void Foam::forces::calcForcesMoment()
in file forces/forces.C at line 1174
Porosity effects requested, but no porosity models found in the database
/home/alex2/prashant/QA/MD2014/AUTOMATED_TEST_LOOP/MD2014-09Dec/16_localForce_execFlowFunctionObjects/motorBike
@Mattijs Functionality migration from internal development lineSergio FerrarisSergio Ferrarishttps://develop.openfoam.com/Development/openfoam/-/issues/2093BUG: forces: UName entry is not used2021-08-05T12:56:59ZKutalmış BerçinBUG: forces: UName entry is not used### Summary
<!-- Summarize the bug encountered concisely -->
For basic incompressible and compressible simulations, the `force` function object has not been using a given `UName` for the `devRhoReff` computation (affecting the tangenti...### Summary
<!-- Summarize the bug encountered concisely -->
For basic incompressible and compressible simulations, the `force` function object has not been using a given `UName` for the `devRhoReff` computation (affecting the tangential component), but using the `U` of the latest available step.
In contrast, the `pName` has always been being used correctly.
### Steps to reproduce
<!-- How one can reproduce the issue - this is very important -->
Consider any tutorial using the `force` function object.
Compute the following, and compare the output of integrated forces or force fields:
- `fieldAverage` of `force` function object using instantaneous `U` field.
- `force` function object using a given `UMean` at the end of the simulation; obtain `UMean` by using `fieldAverage`.
The results consistently differ within a certain range of decimal points irrespective of initialisation/sampling duration.
### 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
-->
api = 2102
patch = 210414
HEAD = 5eb48c443a
version = com
compiler = Clang (system)
= clang version 9.0.1
mpi = SYSTEMOPENMPI
= mpirun (Open MPI) 1.10.7.0.5e373bf1fd
OS = Description: openSUSE Leap 15.1
opts = linux64ClangDPInt32Opt
### 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
-->
(EP#1224)Kutalmış BerçinKutalmış Berçinhttps://develop.openfoam.com/Development/openfoam/-/issues/2618BUG: functionObjectProperties: baseDict.findDict(objectName); interrupts func...2022-10-26T14:14:58ZKutalmış BerçinBUG: functionObjectProperties: baseDict.findDict(objectName); interrupts function object restarts### Summary
`./Allrun` the test case [GL2616-test-case.zip](/uploads/9875eb5b1df41f0da5bb35133dd6fbe8/GL2616-test-case.zip) with 0c3a938810. The restart with `pisoFoam` will throw the error below:
```
--> FOAM FATAL IO ERROR: (openfoa...### Summary
`./Allrun` the test case [GL2616-test-case.zip](/uploads/9875eb5b1df41f0da5bb35133dd6fbe8/GL2616-test-case.zip) with 0c3a938810. The restart with `pisoFoam` will throw the error below:
```
--> FOAM FATAL IO ERROR: (openfoam-2206 patch=220907)
Entry 'totalIter' not found in dictionary "
```
### Possible fixes
Change `objectName` in [functionObjectProperties.C#L140](https://develop.openfoam.com/Development/openfoam/-/blob/develop/src/OpenFOAM/db/functionObjects/functionObjectProperties/functionObjectProperties.C#L140) to `entryName`.Kutalmış BerçinKutalmış Berçinhttps://develop.openfoam.com/Development/openfoam/-/issues/26BUG: Function Objects2016-01-08T12:41:02ZPrashant SonakarBUG: Function ObjectsFailed: cloudInfo
case: /home/alex2/prashant/QA/UNIT_TESTS/FO-tests/lagrangian/verticalChannel
--------------
output log missing:
abort, cellSource, faceSource, partialWrite, patchProbes, probes, readFields, removeRegisteredObj...Failed: cloudInfo
case: /home/alex2/prashant/QA/UNIT_TESTS/FO-tests/lagrangian/verticalChannel
--------------
output log missing:
abort, cellSource, faceSource, partialWrite, patchProbes, probes, readFields, removeRegisteredObject, setTimeStep, sets, surfaces, timeActivatedFileUpdate, turbulenceFields, wallBoundedStreamLines, writeDictionary
case: /home/alex2/prashant/QA/UNIT_TESTS/FO-tests/compressible/motorBike
Is the output to log controlled by outputControl keyword?
--------------
Not working as expected: abort
@Mattijs
Functionality migration from internal development lineMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comhttps://develop.openfoam.com/Development/openfoam/-/issues/437BUG: function object time usage does not respect user time2019-12-09T21:29:28ZAdminBUG: function object time usage does not respect user timeIf cases are set up using, e.g. engineTime, the reported times are in 's' and not 'CA'. This relates to file output via the `writeFile` class, and all time-related inputsIf cases are set up using, e.g. engineTime, the reported times are in 's' and not 'CA'. This relates to file output via the `writeFile` class, and all time-related inputsVersion v1706https://develop.openfoam.com/Development/openfoam/-/issues/27BUG: fvOptions - velocityDamping2015-12-15T11:23:03ZPrashant SonakarBUG: fvOptions - velocityDampingThe damping is not applied on cells.
Also, selectionMode is not taken into account!
[pitzDaily.tgz](/uploads/281e79b4bf1f31cdbadc838ec18dcaec/pitzDaily.tgz)
run simpleFoam in dev and dev-OpenCFD version to see the difference.
@...The damping is not applied on cells.
Also, selectionMode is not taken into account!
[pitzDaily.tgz](/uploads/281e79b4bf1f31cdbadc838ec18dcaec/pitzDaily.tgz)
run simpleFoam in dev and dev-OpenCFD version to see the difference.
@Mattijs @Koushik Functionality migration from internal development lineMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comhttps://develop.openfoam.com/Development/openfoam/-/issues/1928BUG: geometricVoF included twice in interIsoFoam/Make/options2020-11-18T21:44:09ZJohan RoenbyBUG: geometricVoF included twice in interIsoFoam/Make/options`-I$(LIB_SRC)/transportModels/geometricVoF/lnInclude`
appears twice under EXE_INC in:
[https://develop.openfoam.com/Development/openfoam/-/blob/master/applications/solvers/multiphase/interIsoFoam/Make/options](https://develop.openfoam....`-I$(LIB_SRC)/transportModels/geometricVoF/lnInclude`
appears twice under EXE_INC in:
[https://develop.openfoam.com/Development/openfoam/-/blob/master/applications/solvers/multiphase/interIsoFoam/Make/options](https://develop.openfoam.com/Development/openfoam/-/blob/master/applications/solvers/multiphase/interIsoFoam/Make/options)Mark OLESENMark OLESEN