Development issueshttps://develop.openfoam.com/groups/Development/-/issues2020-01-08T14:47:22Zhttps://develop.openfoam.com/Development/openfoam/-/issues/974fileHandler in combination with threading2020-01-08T14:47:22ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comfileHandler in combination with threadingWhen using a threaded fileHandler (e.g. collated) the code does not know to wait for a file being written before trying to read it. This happens e.g. in topoSet (reading a set that has just been written), decomposePar (reading the decomp...When using a threaded fileHandler (e.g. collated) the code does not know to wait for a file being written before trying to read it. This happens e.g. in topoSet (reading a set that has just been written), decomposePar (reading the decomposed mesh to decompose the fields)
Solutions:
- switch off threading altogether. This is what is currently done.
- have IFstream know about currently written files. This would require all IFstream to go through the fileHandler, so use fileHandler().NewIFstream instead of IFstream everywhere.
- since it is only a few applications that have this make sure to reset the fileHandler.
This last solution has been implemented by a new 'flush()' method on all fileHandlers which clears out any cached data (e.g. time directories) and waits for all file operations to finish.Mattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comhttps://develop.openfoam.com/Development/openfoam/-/issues/730blockMesh with multi-surface edges unstable2020-01-03T12:05:03ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comblockMesh with multi-surface edges unstableThe underlying algorithm for the iterative surface-intersection in blockMesh does not handle two co-planar surfaces. The intersection line is at infinite which crashes the code.The underlying algorithm for the iterative surface-intersection in blockMesh does not handle two co-planar surfaces. The intersection line is at infinite which crashes the code.Mattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comhttps://develop.openfoam.com/Development/openfoam/-/issues/409Old changeDictionaryDict format in externalSolarLoad tutorial2020-08-31T13:08:28ZAdminOld changeDictionaryDict format in externalSolarLoad tutorialIn tutorial heatTransfer/chtMultiRegionFoam/externalSolarLoad, changeDictionaryDicts are written in the old format. No need of dictionaryReplacement sub-dict after commit 685afaafbf8ce9fe0d43bb7b6d40eb712531b617 "changeDictionary: Simpl...In tutorial heatTransfer/chtMultiRegionFoam/externalSolarLoad, changeDictionaryDicts are written in the old format. No need of dictionaryReplacement sub-dict after commit 685afaafbf8ce9fe0d43bb7b6d40eb712531b617 "changeDictionary: Simplified by removing the need for the superfluous dictionaryReplacement sub-dictionary."https://develop.openfoam.com/Development/openfoam/-/issues/1268avoid use of gatherList (e.g. fvMeshDistribute)2019-11-08T07:11:42ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comavoid use of gatherList (e.g. fvMeshDistribute)### Functionality to add/problem to solve
Currently in the code it sometimes uses a gatherList to collect data from other processors. This becomes expensive for large numbers of processors.
### Proposal
Replace with an allToAll type ...### Functionality to add/problem to solve
Currently in the code it sometimes uses a gatherList to collect data from other processors. This becomes expensive for large numbers of processors.
### Proposal
Replace with an allToAll type wrapper.https://develop.openfoam.com/Development/openfoam/-/issues/645-decomposeParDict invokes MPI2017-12-18T23:12:32ZMark OLESEN-decomposeParDict invokes MPIIt looks like "decomposeParDict" should not really be part of [validParOptions](https://develop.openfoam.com/Development/OpenFOAM-plus/blob/develop/src/OpenFOAM/global/argList/argList.C#L84) since this triggers detection as a [parallel r...It looks like "decomposeParDict" should not really be part of [validParOptions](https://develop.openfoam.com/Development/OpenFOAM-plus/blob/develop/src/OpenFOAM/global/argList/argList.C#L84) since this triggers detection as a [parallel run](https://develop.openfoam.com/Development/OpenFOAM-plus/blob/develop/src/OpenFOAM/global/argList/argList.C#L610)
@andyv1712Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/764addProfiling has overhead even if not active2023-12-07T19:03:28ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comaddProfiling has overhead even if not activeaddProfiling calls clockTime even if not active. The profilingTrigger does two thing:
- construct clockTime. This calls the low-level time function.
- optionally return/construct a profilingInformation. This is protected from doing anyth...addProfiling calls clockTime even if not active. The profilingTrigger does two thing:
- construct clockTime. This calls the low-level time function.
- optionally return/construct a profilingInformation. This is protected from doing anything expensive unless it is active().
The addProfiling macro should really check for profiling::active().Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/732meshStructure returns indices into local addressing2018-07-02T09:37:46ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.commeshStructure returns indices into local addressingmeshStructure returns a cellToPatchFaceAddressing() which are indices into local addressing so will not be correct.meshStructure returns a cellToPatchFaceAddressing() which are indices into local addressing so will not be correct.https://develop.openfoam.com/Development/openfoam/-/issues/265BUG: snappyHexMesh doesn't fully respect the -decomposeParDict option2019-12-09T22:04:15ZAdminBUG: snappyHexMesh doesn't fully respect the -decomposeParDict optionsnappyHexMesh doesn't fully respect the -decomposeParDict option. Crashes half way through when it starts looking for system/decomposeParDict. Looks like it occurs right after the castellation phase. In addition, the -decomposeParDict op...snappyHexMesh doesn't fully respect the -decomposeParDict option. Crashes half way through when it starts looking for system/decomposeParDict. Looks like it occurs right after the castellation phase. In addition, the -decomposeParDict option on snappyHexMesh doesn't appear to like relative paths (this works with other utilities though).
This is the command I used to run...
mpirun -np 4 snappyHexMesh -overwrite -decomposeParDict /home/graupjj/OpenFOAM/graupjj-plus/run/of/system/decomposeParDict1 -profiling -parallel
This is the error I got...
Doing final balancing
Found 0 zoned faces to keep together.
Found 0 separated coupled faces to keep together.
[0]
[0]
[0] --> FOAM FATAL IO ERROR:
[0] cannot find file
[0]
[0] file: /home/graupjj/OpenFOAM/graupjj-plus/run/of/processor0/system/decomposeParDict at line 0.
[0]
[0] From function regIOobject::readStream()
[0] in file db/regIOobject/regIOobjectRead.C at line 237.
[0]
FOAM parallel run exiting
Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/344renumberMesh twice in the same workflow2018-05-29T05:39:49ZvilfayeaurenumberMesh twice in the same workflowHi,
In some situation, you have to run renumberMesh twice in the same workflow. For example, if you run a coarse case, map to a fine mesh and run it.
This leads to a error message:
Reading volScalarField cellID
[3]
[3]
[3] --> FOAM ...Hi,
In some situation, you have to run renumberMesh twice in the same workflow. For example, if you run a coarse case, map to a fine mesh and run it.
This leads to a error message:
Reading volScalarField cellID
[3]
[3]
[3] --> FOAM FATAL IO ERROR:
[3] size 58624 is not equal to the given value of 58185
[3]
[3] file: /home/a45bwpq/OpenFOAM/1606+/a45bwpq-16.06plus/tutorials/incompressible/simpleFoam/motorBike/processor3/constant/cellID from line 18 to line 58953.
[3]
[3] From function Foam::Field<Type>::Field(const Foam::word&, const Foam::dictionary&, Foam::label) [with Type = double; Foam::label = int]
[3] in file /appl/openfoam/16.06plus/OpenFOAM-16.06plus/src/OpenFOAM/lnInclude/Field.C at line 295.
[3]
FOAM parallel run exiting
motorBike test case is attached to reproduce the error.
Best,
Sebastien
[motorBike.tgz](/uploads/67b76ae6ecde6bb5fb8a3fa1179fdc9d/motorBike.tgz)https://develop.openfoam.com/Development/openfoam/-/issues/369Incomplete cleanup of paraview environment2019-12-09T21:29:26ZMark OLESENIncomplete cleanup of paraview environment* LD_LIBRARY_PATH is not being cleaned at all when switching between paraview versions.
* PATH is being cleaned against the third-party `paraview-*`, although 3rd party paraview is installed as `ParaView-*`. The additional cleanup for Pa...* LD_LIBRARY_PATH is not being cleaned at all when switching between paraview versions.
* PATH is being cleaned against the third-party `paraview-*`, although 3rd party paraview is installed as `ParaView-*`. The additional cleanup for ParaView_DIR may not catch this (if it was unset elsewhere).Mark OLESENMark OLESEN2017-01-06https://develop.openfoam.com/Development/openfoam/-/issues/126oscillatingACMI tutorial reports open cells2016-06-16T13:17:44ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comoscillatingACMI tutorial reports open cellsThis is solved by commit 90ba6113b597880dd3200bd37284627302bf9cc7 from OpenFOAM-dev
This is solved by commit 90ba6113b597880dd3200bd37284627302bf9cc7 from OpenFOAM-dev
https://develop.openfoam.com/Development/openfoam/-/issues/359BUG: incorrect documentation2018-05-29T05:39:49ZPrashant SonakarBUG: incorrect documentationblendingFactor.H specifes
```
fieldName U;
```
but expects
```
field U;
```blendingFactor.H specifes
```
fieldName U;
```
but expects
```
field U;
```Version v1612AdminAdminhttps://develop.openfoam.com/Development/openfoam/-/issues/706Fix regressions introduced by #6862018-04-06T10:41:16ZMark OLESENFix regressions introduced by #686v1806Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/797subTriSurfaceMesh does not work with distributedTriSurfaceMesh2018-06-08T22:52:16ZAdminsubTriSurfaceMesh does not work with distributedTriSurfaceMeshI'm testing out the feature "subTriSurfaceMesh" as described at: https://www.openfoam.com/releases/openfoam-v3.0+/meshing.php
The issue is that it does not work for distirbutedTriSurfaceMesh. I am not sure if it was intended to work wit...I'm testing out the feature "subTriSurfaceMesh" as described at: https://www.openfoam.com/releases/openfoam-v3.0+/meshing.php
The issue is that it does not work for distirbutedTriSurfaceMesh. I am not sure if it was intended to work with all triSurfaceMesh types; if the behavior is as intended I would suggest it as a feature request.https://develop.openfoam.com/Development/openfoam/-/issues/1274decomposePar -allRegions produces different results than decomposePar -region...2019-07-04T11:47:18ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comdecomposePar -allRegions produces different results than decomposePar -region XXX<!--
*** 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
-->
<!--
All text between these marker...<!--
*** 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
-->
<!--
All text between these markers are comments and will not be present in the
report
-->
### Steps to reproduce
<!-- How one can reproduce the issue - this is very important -->
heatTransfer/chtMultiRegionFoam/windshieldDefrost
Set system/decomposeParDict to scotch
```decomposePar -allRegions```
vs
```
decomposePar -region exterior
decomposePar -region ice
decomposePar -region cabin
```
- eg `simple` method produces exactly the same decompositions
- we compile scotch with `SCOTCH_DETERMINISTIC`
bug or feature of scotch?https://develop.openfoam.com/Development/openfoam/-/issues/1030Syntax error near unexpected token2018-10-16T05:59:30ZAdminSyntax error near unexpected token![issue](/uploads/25b3de515657517c15dc079eed035083/issue.PNG)
I installed OpenFOAM about a month ago, it worked very well. But from last week, these errors keep showing up when I just open the Ubuntu without doing any things.
Is there...![issue](/uploads/25b3de515657517c15dc079eed035083/issue.PNG)
I installed OpenFOAM about a month ago, it worked very well. But from last week, these errors keep showing up when I just open the Ubuntu without doing any things.
Is there anyone having the same problem? What should I do?
Thank you!Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/383Error sourcing etc/bashrc with relative path2018-05-29T05:39:49ZJohan RoenbyError sourcing etc/bashrc with relative pathIf I try to source the etc/bashrc file without specifying its full path I get "-bash: cd: etc/bashrc: Not a directory".
To reproduce do:
dhi@argos3:~$ cd /home/dhi/OpenFOAM/OpenFOAM-plus
dhi@argos3:~/OpenFOAM/OpenFOAM-plus$ source etc/...If I try to source the etc/bashrc file without specifying its full path I get "-bash: cd: etc/bashrc: Not a directory".
To reproduce do:
dhi@argos3:~$ cd /home/dhi/OpenFOAM/OpenFOAM-plus
dhi@argos3:~/OpenFOAM/OpenFOAM-plus$ source etc/bashrc
-bash: cd: etc/bashrc: Not a directory
dhi@argos3:~/OpenFOAM/OpenFOAM-plus$ source ~/OpenFOAM/OpenFOAM-plus/etc/bashrc
dhi@argos3:~/OpenFOAM/OpenFOAM-plus$
Same problem in v1612+Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/41BUG: Combustion: Case hungup2015-12-18T05:11:41ZPrashant SonakarBUG: Combustion: Case hungup/home/alex2/prashant/OpenFOAM/OpenFOAM-dev-OpenCFD.develop-16Dec/tutorials/combustion/XiDyMFoam/annularCombustorTurbine
@Mattijs /home/alex2/prashant/OpenFOAM/OpenFOAM-dev-OpenCFD.develop-16Dec/tutorials/combustion/XiDyMFoam/annularCombustorTurbine
@Mattijs Sergio FerrarisSergio Ferrarishttps://develop.openfoam.com/Development/openfoam/-/issues/222ENH: Warn if input geometry contains invalid data2019-12-09T22:04:11ZPrashant SonakarENH: Warn if input geometry contains invalid datasurfaceCheck failed with crash for attached case. [GitLab_Test.stl](/uploads/9bc0a53fa67c43645e27c0b980398b64/GitLab_Test.stl)
It would be desirable if the code gives warning like
- invalid normal (0 0 0) or
- degenerated triangles etcsurfaceCheck failed with crash for attached case. [GitLab_Test.stl](/uploads/9bc0a53fa67c43645e27c0b980398b64/GitLab_Test.stl)
It would be desirable if the code gives warning like
- invalid normal (0 0 0) or
- degenerated triangles etcVersion v1612Mattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comhttps://develop.openfoam.com/Development/openfoam/-/issues/711sixDoFRigidBodyState function object not built2019-12-09T22:18:10ZAdminsixDoFRigidBodyState function object not builtAs title - code also requires further integration updates re: `writeFile` class usage and would benefit from using enums for angle typesAs title - code also requires further integration updates re: `writeFile` class usage and would benefit from using enums for angle typesv1806