Development issueshttps://develop.openfoam.com/groups/Development/-/issues2016-11-28T05:07:21Zhttps://develop.openfoam.com/Development/openfoam/-/issues/285Noise utility and models - unable to use environment variables for input files2016-11-28T05:07:21ZAdminNoise utility and models - unable to use environment variables for input filesCurrently the file names are not expanded for the control dictionary and surface noise model, so we cannot use `"$FOAM_CASE/..."` etcCurrently the file names are not expanded for the control dictionary and surface noise model, so we cannot use `"$FOAM_CASE/..."` etcVersion v1612https://develop.openfoam.com/Development/openfoam/-/issues/284Lagrangian Particle Tracking hangs in parallel - #2315@OpenFOAM-Foundation2018-09-19T16:59:31ZAdminLagrangian Particle Tracking hangs in parallel - #2315@OpenFOAM-FoundationFor full details, proposed bug fix and description of the reason why the bug happens, please check the original bug report and comments: http://bugs.openfoam.org/view.php?id=2315
Not only this is useful for OpenFOAM+, but the other re...For full details, proposed bug fix and description of the reason why the bug happens, please check the original bug report and comments: http://bugs.openfoam.org/view.php?id=2315
Not only this is useful for OpenFOAM+, but the other reason that I'm posting this here is because I could use a second/third opinion on this fix.
I'm not fully familiar with particle tracking within OpenFOAM and even though I debugged the this bug a few weeks ago for another similar type of simulation, the fix that I found, tested and proposed, seems to work as intended... but I have the nagging feeling in the back of my head that this particular fix was not used already in OpenFOAM in the past due to some other reason that I haven't seen yet.https://develop.openfoam.com/Development/openfoam/-/issues/283Provide method to write boundary field entries as dictionary entries2017-01-02T12:24:26ZMark OLESENProvide method to write boundary field entries as dictionary entriesSimilar to what dictionary::writeEntries() offers - just the contents, without a surrounding 'boundaryField' block.Similar to what dictionary::writeEntries() offers - just the contents, without a surrounding 'boundaryField' block.Version v1612Mark OLESENMark OLESEN2016-10-31https://develop.openfoam.com/Development/openfoam/-/issues/282Allow specific restart time for field averaging.2017-01-02T12:24:43ZMark OLESENAllow specific restart time for field averaging.Can currently have a periodic restart, but for simulations with a known run-up, it can be useful to have a specific time to restart the averaging.Can currently have a periodic restart, but for simulations with a known run-up, it can be useful to have a specific time to restart the averaging.Version v1612Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/281Some csh versions/forks seem to have problems with line breaks inside inline ...2017-01-24T17:01:30ZAdminSome csh versions/forks seem to have problems with line breaks inside inline subshells - #2309@OpenFOAM-FoundationQuoting myself from http://bugs.openfoam.org/view.php?id=2309
>>>
The issue I've stumbled upon with the "csh" package "20110502-2.1ubuntu1" in Ubuntu 16.04 (dpkg -l csh) is that a single backslash within the sub-shells using `` require d...Quoting myself from http://bugs.openfoam.org/view.php?id=2309
>>>
The issue I've stumbled upon with the "csh" package "20110502-2.1ubuntu1" in Ubuntu 16.04 (dpkg -l csh) is that a single backslash within the sub-shells using `` require double backslash and not a single backslash.
The problem is that I have not seen any similar report by anyone else, including on the OpenFOAM-plus issue tracker, and since Henry must have tested the script with success with a particular version or two, I'm really intrigued as to which csh versions/forks the current implementation in OpenFOAM 4.0 and newer works on.
Anyway, attached are two possible patches for extending compatibility, for easier inspection, on possible solutions:
- patch.v1 - uses double backslash inside `` sub-shells
- patch.v2 - uses removes backslash from inside `` sub-shells and makes the command a single line
The affected files are only these two:
- etc/config.csh/paraview
- etc/cshrc
>>>
Steps to reproduce:
```
# While on bash:
$ cd ~/OpenFOAM/OpenFOAM-dev
$ csh
% source etc/cshrc
Invalid null command.
/OpenFOAM-dev/bin/foamEtcFile: Command not found.
/OpenFOAM-dev/bin/foamCleanPath: Command not found.
/OpenFOAM-dev/bin/foamCleanPath: Command not found.
/OpenFOAM-dev/bin/foamCleanPath: Command not found.
/OpenFOAM-dev/etc/config.csh/settings: No such file or directory.
```
----
Already tagged @Mattijs on that report. I don't know if anyone else here at OpenCFD uses `csh`.https://develop.openfoam.com/Development/openfoam/-/issues/280sourcing etc/bashrc breaks with aliases2016-12-23T12:39:42ZMark OLESENsourcing etc/bashrc breaks with aliasesIf `cd` is an alias, the new sourcing mechanism breaks.If `cd` is an alias, the new sourcing mechanism breaks.AdminAdminhttps://develop.openfoam.com/Development/openfoam/-/issues/279tutorial RunFunctions ignore non-standard locations of decomposeParDict2017-07-12T07:20:28ZMark OLESENtutorial RunFunctions ignore non-standard locations of decomposeParDictSeems to have broken with last foundation merge.Seems to have broken with last foundation merge.Version v1612Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/278provide separate geometry description per region/patch in createExternalCoupl...2020-05-01T11:41:34ZMark OLESENprovide separate geometry description per region/patch in createExternalCoupledPatchGeometryCurrent implementation has all faces together, which makes it difficult for external applications to handle
- Redirect from exchange ticket.Current implementation has all faces together, which makes it difficult for external applications to handle
- Redirect from exchange ticket.Version v1612Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/277sed: -e expression #1, char 72: unknown option to `s' ( And some funky PATH e...2016-10-29T08:39:43ZAdminsed: -e expression #1, char 72: unknown option to `s' ( And some funky PATH errors )```
[ steven.walton ] [~] > lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description: Ubuntu 16.04.1 LTS
Release: 16.04
Codename: xenial
```
I am also on a domain controlled computer.
When sourcing `/opt/openfoa...```
[ steven.walton ] [~] > lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description: Ubuntu 16.04.1 LTS
Release: 16.04
Codename: xenial
```
I am also on a domain controlled computer.
When sourcing `/opt/openfoam4/etc/bashrc` and opening a new bash terminal I get the following error
```
sed: -e expression #1, char 72: unknown option to `s'
sed: -e expression #1, char 111: unknown option to `s'
sed: -e expression #1, char 111: unknown option to `s'
/opt/openfoam4/bin/foamCleanPath: 110: /opt/openfoam4/bin/foamCleanPath: sed: not found
/opt/openfoam4/bin/foamCleanPath: 110: /opt/openfoam4/bin/foamCleanPath: sed: not found
/opt/openfoam4/bin/foamCleanPath: 110: /opt/openfoam4/bin/foamCleanPath: sed: not found
/opt/openfoam4/bin/foamCleanPath: 110: /opt/openfoam4/bin/foamCleanPath: sed: not found
/opt/openfoam4/bin/foamCleanPath: 110: /opt/openfoam4/bin/foamCleanPath: sed: not found
/opt/openfoam4/bin/foamCleanPath: 110: /opt/openfoam4/bin/foamCleanPath: sed: not found
/opt/openfoam4/bin/foamCleanPath: 110: /opt/openfoam4/bin/foamCleanPath: sed: not found
bash: uname: No such file or directory
Your "" operating system is not supported by this release
of OpenFOAM. For further assistance, please contact www.OpenFOAM.org
Command 'sed' is available in '/bin/sed'
Command 'mpicc' is available in '/usr/bin/mpicc'
The command could not be located because '/usr/bin' is not included in the PATH environment variable.
The command could not be located because '/bin' is not included in the PATH environment variable.
mpicc: command not found
sed: command not found
/opt/openfoam4/bin/foamCleanPath: 110: /opt/openfoam4/bin/foamCleanPath: sed: not found
/opt/openfoam4/bin/foamCleanPath: 110: /opt/openfoam4/bin/foamCleanPath: sed: not found
/opt/openfoam4/bin/foamCleanPath: 110: /opt/openfoam4/bin/foamCleanPath: sed: not found
bash: sed: No such file or directory
/opt/openfoam4/bin/foamCleanPath: 129: /opt/openfoam4/bin/foamCleanPath: sed: not found
```
The worse part of this is that `PATH` gets completely overwritten!
I can fix some of this by getting rid of line 154 in `/opt/openfoam4/etc/bashrc`. That reduces to the following error
```
sed: -e expression #1, char 72: unknown option to `s'
sed: -e expression #1, char 111: unknown option to `s'
sed: -e expression #1, char 111: unknown option to `s'
```
If I am running in zsh (yes, I know it says bashrc) I get
```
sed: -e expression #1, char 72: unknown option to `s'
/opt/openfoam4/etc/config.sh/aliases:73: bad option: -t
```
If I enter bash and type `wmRefresh` it overwrites `PATH` and I now have no access to simple commands like `ls`. ( Removing the `-t` in that line reduces the last error in zsh but adds the line `bash: type: wmRefresh: not found` into the list of errors for bash.) Which is strange because the comment above line 73 in `/opt/openfoam4/etc/config.sh/aliases` says `For backward-compatibility unalias wmRefresh if it is defined as an alias`.
Working through this one I see that `which wmRefresh` and `alias wmRefresh` return nothing. So getting the same behaviour in both shells ( and a lack of care for backwards compatibility at this point ) I found that I could just remove lines 74-80 in `/opt/openfoam4/etc/config.sh/aliases`. Note that if I just removed line 73 bash would have `PATH` overwritten again ( **why ever modify `PATH` when we have other environment variables?** ).
So at this point I am only left with the sed errors ( 1 in zsh and 3 in bash ). I cannot tell that I am getting any errors* in using OpenFoam, but as you might imagine it is quite annoying seeing multiple errors every time I open a new shell. I have been attempting to resolve these issues by looking at where `sed` has been used, but I'm not seeing a problem. It doesn't appear to be a `sed` command within `/opt/openfoam4/etc`, and grepping a directory back results is quite a log of commands.
So I am wondering if anyone else has had this error and solved it.
*To check validity through modifications I am just run the cavity icoFoam case, checking for the known solution.https://develop.openfoam.com/Development/openfoam/-/issues/275BUG: multiRegionFeatureSnap does not work in v16062019-09-20T13:24:55ZAdminBUG: multiRegionFeatureSnap does not work in v1606Setting multiRegionFeatureSnap to true (or false) in snappyHexMeshDict for v1606 gives the same mesh as setting it to false in foundation code version 3.0.x. Version 1606 fails to detect multi-region features.
Model...
![zones_model](...Setting multiRegionFeatureSnap to true (or false) in snappyHexMeshDict for v1606 gives the same mesh as setting it to false in foundation code version 3.0.x. Version 1606 fails to detect multi-region features.
Model...
![zones_model](/uploads/6402ead313821dd169463ad0db1da5b0/zones_model.PNG)
Foundation code 3.0.x multiRegionFeatureSnap=true (zoom to faceZone edges)...
![3.0.x_faceZone_Edges](/uploads/720b19cad3a7e2cc5a0c6cfa60e0fb6e/3.0.x_faceZone_Edges.PNG)
Foundation code 3.0.x multiRegionFeatureSnap=false (zoom to faceZone edges)...
![3.0.x_faceZone_Edges_false](/uploads/0597b0b9435083b2eddb4b8bf2db5f96/3.0.x_faceZone_Edges_false.PNG)
v1606 multiRegionFeatureSnap=true/false (zoom to faceZone edges)...
![1606_faceZone_Edges](/uploads/f387810ed2e2bbb1969a3aed072d5650/1606_faceZone_Edges.PNG)
I've attached the model for your review.
[multiregion_snap_bug.tar.gz](/uploads/262d49ae8e9bce20899e12bd985eb3e9/multiregion_snap_bug.tar.gz)Mattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comhttps://develop.openfoam.com/Development/openfoam/-/issues/274BUG: single locationInMesh behavior now broken when compared with the foundat...2016-10-18T05:05:13ZAdminBUG: single locationInMesh behavior now broken when compared with the foundation codeThe single locationInMesh behavior is now broken when there is a geometry based cellZone defined when compared to the foundation code.
I've attached 3 pics and the model. The geometry pic is a pipe with a cellZone geometry defined in t...The single locationInMesh behavior is now broken when there is a geometry based cellZone defined when compared to the foundation code.
I've attached 3 pics and the model. The geometry pic is a pipe with a cellZone geometry defined in the middle.
![geometry](/uploads/80450e9dd316c13340de821bbaf3fd13/geometry.PNG)
The "3.0.x_mesh_with_cellZone.png" pic is what foundation version 3.0.x produces when a single locationInMesh is defined to one side of the cellZone. 3.0.x correctly sets the middle to one cellZone and the rest of the pipe to defaultFaces.
![3.0.x_mesh_with_cellZone](/uploads/91dace921e83fe4d3c8fc443c9663e92/3.0.x_mesh_with_cellZone.PNG)
The "v1606_mesh_with_cellZone_broken.PNG" shows what v1606 produces using the same model. It cuts off half the pipe and then leaks out into the background mesh. Not cool.
![v1606_mesh_with_cellZone_broken](/uploads/2e937dd4d15eebf0371ec383085e0347/v1606_mesh_with_cellZone_broken.PNG)
I know there has been a lot of changes so if I'm missing something let me know. I have tested the locationsInMesh functionality and that works OK for this model, but the single locationInMesh fails. I've attached the model.
[mesh_issue.tar.gz](/uploads/3f1f0af8bf58b7d1b42746861e3892d9/mesh_issue.tar.gz)https://develop.openfoam.com/Development/openfoam/-/issues/273compile issue with gcc-5.22019-12-09T22:04:13ZMark OLESENcompile issue with gcc-5.2Superfluous `#include "FieldFunctions.H"` provokes warnings/errors.Superfluous `#include "FieldFunctions.H"` provokes warnings/errors.Version v1612Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/272Need base64 encoding layer for vtk xml formats.2017-01-02T12:24:52ZMark OLESENNeed base64 encoding layer for vtk xml formats.Need to move to XML-based formats in order to properly support 64-bit labels (see issue #270).Need to move to XML-based formats in order to properly support 64-bit labels (see issue #270).Version v1612Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/271cleanup endian handling2016-12-23T12:39:41ZMark OLESENcleanup endian handlingSimilar code spread in several placesSimilar code spread in several placesVersion v1612Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/270VTK legacy formats will fail with label-size 642020-03-13T14:22:41ZMark OLESENVTK legacy formats will fail with label-size 64The VTK legacy binary output performs byte-swapping on labels, but since legacy VTK only handles 32-bit ints, the code also only swaps endian content for 32-bits. For 64-bit labels the swapping and output are wrong. The newer VTK formats...The VTK legacy binary output performs byte-swapping on labels, but since legacy VTK only handles 32-bit ints, the code also only swaps endian content for 32-bits. For 64-bit labels the swapping and output are wrong. The newer VTK formats are needed for this.
Code affected:
* setSet/writeFuncs.C
* foamToVTK/writeFuncs.C
* CloudToVTK/vtkTools.CVersion v1706Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/269BUG: createExternalCoupledPatchGeometry don't find meshes in parallel run2019-12-09T22:04:14ZAdminBUG: createExternalCoupledPatchGeometry don't find meshes in parallel runThe Utility createExternalCoupledPatchGeometry is not able to run in parallel.
If one try to run it in parallel, it leads to the error: object of type N4Foam8OFstreamE is not allocated.
So the Utility is unable to load the splitted mesh.The Utility createExternalCoupledPatchGeometry is not able to run in parallel.
If one try to run it in parallel, it leads to the error: object of type N4Foam8OFstreamE is not allocated.
So the Utility is unable to load the splitted mesh.Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/268BUG: distributedTriSurfaceMesh is always seen as an open geometry in snappyHe...2019-12-09T22:04:13ZAdminBUG: distributedTriSurfaceMesh is always seen as an open geometry in snappyHexMeshA distributedTriSurfaceMesh in snappyHexMesh cannot be used to define a cellZone using the cellZoneInside inside designation because snappyHexMesh sees the geometry as an open geometry. It works if you change it to triSurfaceMesh.A distributedTriSurfaceMesh in snappyHexMesh cannot be used to define a cellZone using the cellZoneInside inside designation because snappyHexMesh sees the geometry as an open geometry. It works if you change it to triSurfaceMesh.Mattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comhttps://develop.openfoam.com/Development/openfoam/-/issues/267ENH : create an option in surfaceRedistributePar to redistribute all surface ...2020-01-03T20:32:56ZAdminENH : create an option in surfaceRedistributePar to redistribute all surface filessurfaceRedistributePar requires you to re-run the command to distribute multiple surfaces. Create an option to distribute all surfaces or allow wildcards in the surface specification.
\#\# Reattaching the author to the issue ticket: @...surfaceRedistributePar requires you to re-run the command to distribute multiple surfaces. Create an option to distribute all surfaces or allow wildcards in the surface specification.
\#\# Reattaching the author to the issue ticket: @graups \#\# https://develop.openfoam.com/Development/ThirdParty-common/-/issues/7Allclean script in ThirdParty (v1606+) wrongly deletes all installed ThirdPar...2019-07-21T22:56:27ZPhilippose RajanAllclean script in ThirdParty (v1606+) wrongly deletes all installed ThirdParty packages instead of the out-of-source temporary build filesHello,
The following part of the **Allclean** script in the **ThirdParty** folder of v1606+ wrongly deletes all the *installed* ThirdParty packages instead of deleting only the *out-of-source build* files:
```bash
# clean out-of-source...Hello,
The following part of the **Allclean** script in the **ThirdParty** folder of v1606+ wrongly deletes all the *installed* ThirdParty packages instead of deleting only the *out-of-source build* files:
```bash
# clean out-of-source build directories
[ -d platforms ] && ( set -x; rm -rf platforms/* )
```
Solution:
Change to:
```bash
# clean out-of-source build directories
[ -d build ] && ( set -x; rm -rf build/* )
```
in order to clean only the out-of -source build files, but leave the installed packages intact.
Thank you.
Philippose RajanMark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/266Unify surface area/normal calculations2017-01-02T12:22:12ZMark OLESENUnify surface area/normal calculationsNeed face areas and normals for meshed surfaces in several places. It makes sense to relocate this frequently needed functionality to PrimitivePatch. PolyPatch continues to use a slice field for efficiency on poly meshes.Need face areas and normals for meshed surfaces in several places. It makes sense to relocate this frequently needed functionality to PrimitivePatch. PolyPatch continues to use a slice field for efficiency on poly meshes.Version v1612Mark OLESENMark OLESEN