Development issueshttps://develop.openfoam.com/groups/Development/-/issues2016-12-23T12:39:42Zhttps://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/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/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/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/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/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/286STYLE: Duplicate information in SHM reference dict2016-11-09T11:52:36ZPrashant SonakarSTYLE: Duplicate information in SHM reference dict```
// Optional: keep zero-sized patches. By default snappyHexMesh filters
// these out.
//keepPatches true; // default false
//Optional: preserve all generated patches. Default is to remove
// zero-sized patches....```
// Optional: keep zero-sized patches. By default snappyHexMesh filters
// these out.
//keepPatches true; // default false
//Optional: preserve all generated patches. Default is to remove
// zero-sized patches.
//keepPatches true;
```
in applications/utilities/mesh/generation/snappyHexMesh/snappyHexMeshDictVersion v1612AdminAdminhttps://develop.openfoam.com/Development/openfoam/-/issues/287mesh reader does not preserve physicalType2016-12-23T12:39:43ZMark OLESENmesh reader does not preserve physicalTypeThis is a very long-standing bug (Oct 2010), but obviously rarely noticed.This is a very long-standing bug (Oct 2010), but obviously rarely noticed.Version v1612Mark OLESENMark OLESEN2016-11-04https://develop.openfoam.com/Development/openfoam/-/issues/288Newer CGAL versions build into lib64, breaking current CGAL make rules.2017-01-02T12:24:17ZMark OLESENNewer CGAL versions build into lib64, breaking current CGAL make rules.On 64-bit systems, the system installations of boost, cgal are under `lib64/`.
The behaviour for a ThirdParty build is *mostly* `lib/` but this can also be changing.
- Boost 1_62_0 and older build into 'lib/'.
- CGAL-4.9 builds into ...On 64-bit systems, the system installations of boost, cgal are under `lib64/`.
The behaviour for a ThirdParty build is *mostly* `lib/` but this can also be changing.
- Boost 1_62_0 and older build into 'lib/'.
- CGAL-4.9 builds into 'lib64/', older versions into 'lib/'.
Future-proof things by using `lib$WM_COMPILER_LIB_ARCH` for boost and cgal build rules, and forcing these as build targets in the ThirdParty makeCGAL as well.
Cross-referenced as ThirdParty issue https://develop.openfoam.com/Development/ThirdParty-plus/issues/8Version v1612Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/ThirdParty-common/-/issues/8Build boost/cgal into lib64 on 64-bit systems2019-07-21T22:56:27ZMark OLESENBuild boost/cgal into lib64 on 64-bit systemsNoted as OpenFOAM issue https://develop.openfoam.com/Development/OpenFOAM-plus/issues/288Noted as OpenFOAM issue https://develop.openfoam.com/Development/OpenFOAM-plus/issues/288Version v1612Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/289BUG: invalid type while accessing fields2016-11-11T12:55:22ZPrashant SonakarBUG: invalid type while accessing fieldsAttached case which replicates issue while accessing pressure field (develop branch).
[pitzDaily-develop.tgz](/uploads/c2213bc9d7442d4e1e0d0b37974279c5/pitzDaily-develop.tgz)
fails with error
```
Reading p
--> FOAM Warning :
--> FO...Attached case which replicates issue while accessing pressure field (develop branch).
[pitzDaily-develop.tgz](/uploads/c2213bc9d7442d4e1e0d0b37974279c5/pitzDaily-develop.tgz)
fails with error
```
Reading p
--> FOAM Warning :
--> FOAM FATAL IO ERROR:
unexpected class name volScalarField expected volVectorField
while reading object p
file: /hosts/pnq073/home/sonakar/share/pitzDaily-develop/5/p at line 15.
From function Foam::Istream& Foam::regIOobject::readStream(const Foam::word&)
in file db/regIOobject/regIOobjectRead.C at line 295.
End
```Version v1612AdminAdminhttps://develop.openfoam.com/Development/openfoam/-/issues/290inconsistency in scotch, metis library locations2017-01-02T12:24:10ZMark OLESENinconsistency in scotch, metis library locationsScotch and metis libraries are being installed under FOAM_EXT_LIBBIN, not under their respective XX_ARCH_PATH/lib.
If there are copies in the XX_ARCH_PATH/lib, they will not be available in the LD_LIBRARY_PATH anyhow and thus is confusi...Scotch and metis libraries are being installed under FOAM_EXT_LIBBIN, not under their respective XX_ARCH_PATH/lib.
If there are copies in the XX_ARCH_PATH/lib, they will not be available in the LD_LIBRARY_PATH anyhow and thus is confusing (wrong) to have them as LIB_LIB.Version v1612Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/291BUG: decaying isotropic turbulence case2016-11-07T06:27:32ZPrashant SonakarBUG: decaying isotropic turbulence casePlaceholder to revisit boxTurb for decaying isotropic turbulence case, which doesn't seem to give correct results.
(From EP#262)Placeholder to revisit boxTurb for decaying isotropic turbulence case, which doesn't seem to give correct results.
(From EP#262)Sergio FerrarisSergio Ferrarishttps://develop.openfoam.com/Development/openfoam/-/issues/292DriftfluxFoam does not produce a settling alpha field2016-12-23T16:24:51ZAdminDriftfluxFoam does not produce a settling alpha fieldSince the code update to 4.x, DriftfluxFoam does not settle. Now, this has been solved in OpenFOAM 4.x. I made a bugreport there: http://bugs.openfoam.org/view.php?id=2317 and it was solved by commit OpenFOAM-4.x commit 8e01ae0462c90f06a...Since the code update to 4.x, DriftfluxFoam does not settle. Now, this has been solved in OpenFOAM 4.x. I made a bugreport there: http://bugs.openfoam.org/view.php?id=2317 and it was solved by commit OpenFOAM-4.x commit 8e01ae0462c90f06af7fba33dca9fef5cb63f26e
Is it possible to merge this solution to the future release of OpenFOAM1612+?https://develop.openfoam.com/Development/openfoam/-/issues/293STYLE: checkMesh header lists writeSets twice. Also use of both \par and \param2020-01-08T14:28:45ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comSTYLE: checkMesh header lists writeSets twice. Also use of both \par and \paramThere are more utilities:
(util; git grep '\\par')
(util ; git grep '\\param' )There are more utilities:
(util; git grep '\\par')
(util ; git grep '\\param' )AdminAdminhttps://develop.openfoam.com/Development/openfoam/-/issues/294simplify, cleanup surface handling infrastructure2017-12-18T23:17:41ZMark OLESENsimplify, cleanup surface handling infrastructureVersion v1706Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/ThirdParty-common/-/issues/9Cannot compile paraview32019-07-21T22:56:27ZMark OLESENCannot compile paraview3With paraview 3.14 (Feb 2012) and paraview 3.98 (Dec 2012) experience unresolvable build issues. Can no longer compile (was also the case at the time of the 1606 release).With paraview 3.14 (Feb 2012) and paraview 3.98 (Dec 2012) experience unresolvable build issues. Can no longer compile (was also the case at the time of the 1606 release).Version v1612Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/295Update paraview versions2017-02-01T10:22:20ZMark OLESENUpdate paraview versions- Drop support for paraview 3.x (released in 2012). Cannot test if these older reader modules actually build (see
https://develop.openfoam.com/Development/ThirdParty-plus/issues/9).
- Ensure build works with paraview 5.1.2 (bug fix versi...- Drop support for paraview 3.x (released in 2012). Cannot test if these older reader modules actually build (see
https://develop.openfoam.com/Development/ThirdParty-plus/issues/9).
- Ensure build works with paraview 5.1.2 (bug fix version of 5.1.0) from July 2016.Version v1612Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/ThirdParty-common/-/issues/10Ensure third-party compile of current and upcoming paraview work.2019-07-21T22:56:27ZMark OLESENEnsure third-party compile of current and upcoming paraview work.Adjust patching for 5.1.2 and 5.2.0 (using current release candidate).Adjust patching for 5.1.2 and 5.2.0 (using current release candidate).Version v1612Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/296Native ofs format appears to be broken.2017-01-02T12:22:58ZMark OLESENNative ofs format appears to be broken.This format is little-used, but relying on raw stream operators for the native format breaks down when different face types (face vs. triFace vs. labelledFace) are being used. It is still reasonable to have stream operators for pass arou...This format is little-used, but relying on raw stream operators for the native format breaks down when different face types (face vs. triFace vs. labelledFace) are being used. It is still reasonable to have stream operators for pass around data (eg, between processors), but they shouldn't be used for files. Otherwise we can easily create a binary file using triFace or labelledFace and not be able to read it back with normal face.
Additionally, the static OFSsurfaceFormat::read functions are too fragile (broken).
Suggest removing entirely. @andyVersion v1612Mark OLESENMark OLESEN