Development issueshttps://develop.openfoam.com/groups/Development/-/issues2019-03-22T08:02:06Zhttps://develop.openfoam.com/Development/openfoam/-/issues/1230optionally suppress cell, proc, patch ids for foamToVTK2019-03-22T08:02:06ZMark OLESENoptionally suppress cell, proc, patch ids for foamToVTKcross-reference EP718
@SonESIcross-reference EP718
@SonESIMark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/333provide log option to top-level build2018-05-29T05:39:49ZMark OLESENprovide log option to top-level buildCapture stdout/stderr for later diagnostics.Capture stdout/stderr for later diagnostics.Version v1612Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/469DTCHull fails on various number of domains in parallel2018-07-03T10:43:06ZMatej FormanDTCHull fails on various number of domains in parallel$FOAM_TUTORIALS/multiphase/interDyMFoam/ras/DTCHull run on centOS (vanilla 1612+ compiled with all default options).
runs fine on 16 and 32 CPUs
fails on 4 and 8 CPUs.
case on 4CPUs on k growing out of bounds:
[log_interDyMFoam_4](/u...$FOAM_TUTORIALS/multiphase/interDyMFoam/ras/DTCHull run on centOS (vanilla 1612+ compiled with all default options).
runs fine on 16 and 32 CPUs
fails on 4 and 8 CPUs.
case on 4CPUs on k growing out of bounds:
[log_interDyMFoam_4](/uploads/f6e2af364a76f0f11ab862f95e658e77/log_interDyMFoam_4)
case on 8 CPUs suddenly with SigSev on pressure equation.
[log_interDyMFoam_8](/uploads/49d6b19325216b4a30686d11081d8952/log_interDyMFoam_8)
See logs attached.Prashant SonakarPrashant Sonakarhttps://develop.openfoam.com/Development/openfoam/-/issues/119BUG: inconsistent configuation files in develop branch2016-11-24T07:34:55ZPrashant SonakarBUG: inconsistent configuation files in develop branchSome setup configuration files are missing in etc/config.csh
e.g. scotch
@Mattijs Some setup configuration files are missing in etc/config.csh
e.g. scotch
@Mattijs AdminAdminhttps://develop.openfoam.com/Development/openfoam/-/issues/1034searchableSurfacesQueries does not handle multiple separate surfaces2021-07-06T13:28:14ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comsearchableSurfacesQueries does not handle multiple separate surfacesMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comhttps://develop.openfoam.com/Development/openfoam/-/issues/759snappyHexMesh : layer extrusion in parallel2018-07-02T16:14:00ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comsnappyHexMesh : layer extrusion in parallelshm avoids trying to extrude if:
1) locally two patch faces only connect via a point
`
+--+
| |
+--+--+
| |
+--+
`
It does this even though neighbouring processors might have the missing patch faces.
2) if a mesh point is not on...shm avoids trying to extrude if:
1) locally two patch faces only connect via a point
`
+--+
| |
+--+--+
| |
+--+
`
It does this even though neighbouring processors might have the missing patch faces.
2) if a mesh point is not on the patch on some processors. This state 'wins'.Mattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comhttps://develop.openfoam.com/Development/openfoam/-/issues/933mpirun on less than decomposed number of processors does not give error message2020-01-03T14:21:29ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.commpirun on less than decomposed number of processors does not give error messageE.g. decompose into 8 with a non-standard decomposeParDict but run checkMesh on 6 (as set by system/decomposeParDict). This bypasses the argList check on incorrect number of processors so now gives sigsegv from processorPolyPatch trying ...E.g. decompose into 8 with a non-standard decomposeParDict but run checkMesh on 6 (as set by system/decomposeParDict). This bypasses the argList check on incorrect number of processors so now gives sigsegv from processorPolyPatch trying to send to non-existing neighbouring processors.https://develop.openfoam.com/Development/openfoam/-/issues/260implicit plane constructors cause weirdness2016-12-23T12:39:40ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comimplicit plane constructors cause weirdnessin shm was using
p.boundaryField()[patchi] == scalarField(..)
which causes implicit plane-construct-from-scalarList to be invoked.in shm was using
p.boundaryField()[patchi] == scalarField(..)
which causes implicit plane-construct-from-scalarList to be invoked.https://develop.openfoam.com/Development/openfoam/-/issues/808checkMesh crash on zero volume cell2018-07-02T16:12:22ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comcheckMesh crash on zero volume cellMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comhttps://develop.openfoam.com/Development/openfoam/-/issues/881dictionary deprecation mechanism quite verbose2018-06-21T09:20:13ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comdictionary deprecation mechanism quite verboseI am getting (e.g. smallPoolFire2D tutorial)
```
keyword is deemed to be 5 months old
```
on all processors. One should be enough.I am getting (e.g. smallPoolFire2D tutorial)
```
keyword is deemed to be 5 months old
```
on all processors. One should be enough.Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/449"timeVaryingMappedFixedValue" cannot read files when I use mpirun2019-12-09T21:29:29ZAdmin"timeVaryingMappedFixedValue" cannot read files when I use mpirunHi,
The boundary condition "timeVaryingMappedFixedValue" refuses to read inlet files in boundaryData/inlet at each time steps when I use mpirun.
**1. I post what I saw from the screen: **
```
Starting time loop
streamLine stream...Hi,
The boundary condition "timeVaryingMappedFixedValue" refuses to read inlet files in boundaryData/inlet at each time steps when I use mpirun.
**1. I post what I saw from the screen: **
```
Starting time loop
streamLine streamLines:
Employing velocity field U
automatic track length specified through number of sub cycles : 5
Time = 1
timeVaryingFixedValueFvPatchField : Read 70 sample points from "/home/ofuser/wor
kingDir/run/pitzDailyExptInlet/processor0/../constant/boundaryData/inlet/points"
timeVaryingFixedValueFvPatchField : In directory "/home/ofuser/workingDir/run/pi
tzDailyExptInlet/processor0/../constant/boundaryData/inlet" found times
4
(
0
0.7
2
4
)
[0] checkTable : Reading startValues from "boundaryData/inlet/0.7"
[3] checkTable : Reading startValues from "boundaryData/inlet/0.7"
[2] checkTable : Reading startValues from "boundaryData/inlet/0.7"
[1] checkTable : Reading startValues from "boundaryData/inlet/0.7"
[3] checkTable : Reading endValues from "boundaryData/inlet/2"
[0] checkTable : Reading endValues from "boundaryData/inlet/2"
[2] checkTable : Reading endValues from "boundaryData/inlet/2"
[0]
[0]
[0] --> FOAM FATAL IO ERROR:
[0] file "../constant/boundaryData/inlet/2/U" does not exist
[0]
[0] file: ../constant/boundaryData/inlet/2/U at line 1.
[0]
[0] From function Foam::IFstream& Foam::IFstream::operator()() const
[0] in file db/IOstreams/Fstreams/IFstream.C at line 176.
[0]
FOAM parallel run exiting
[0]
--------------------------------------------------------------------------
MPI_ABORT was invoked on rank 0 in communicator MPI_COMM_WORLD
with errorcode 1.
NOTE: invoking MPI_ABORT causes Open MPI to kill all MPI processes.
You may or may not see output from other processes, depending on
exactly when Open MPI kills them.
--------------------------------------------------------------------------
[1] checkTable : Reading endValues from "boundaryData/inlet/2"
[3]
[3]
[3] --> FOAM FATAL IO ERROR:
[3] file "../constant/boundaryData/inlet/2/U" does not exist
[3]
[3] file: ../constant/boundaryData/inlet/2/U at line 1.
[3]
[3] From function Foam::IFstream& Foam::IFstream::operator()() const
[3] in file db/IOstreams/Fstreams/IFstream.C at line 176.
[3]
FOAM parallel run exiting
[3]
[2]
[2]
[2] --> FOAM FATAL IO ERROR:
[2] file "../constant/boundaryData/inlet/2/U" does not exist
[2]
[2] file: ../constant/boundaryData/inlet/2/U at line 1.
[2]
[2] From function Foam::IFstream& Foam::IFstream::operator()() const
[2] in file db/IOstreams/Fstreams/IFstream.C at line 176.
[2]
FOAM parallel run exiting
[2]
[1]
[1]
[1] --> FOAM FATAL IO ERROR:
[1] file "../constant/boundaryData/inlet/2/U" does not exist
[1]
[1] file: ../constant/boundaryData/inlet/2/U at line 1.
[1] [default:26184] 1 more process has sent help message help-mpi-api.txt / mpi-
abort
[default:26184] Set MCA parameter "orte_base_help_aggregate" to 0 to see all hel
p / error messages[pitzDailyExptInlet.7z](/uploads/eb58a7f8a25df1966091c72985e38262/pitzDailyExptInlet.7z)
```
[pitzDailyExptInlet.7z](/uploads/9df573a34ff06fbb460b03bd7e9f71b4/pitzDailyExptInlet.7z)
**2. To reproduce the error, the steps are: **
*step 1*: clone pitzDailyExptInlet;
*step 2*: creat new files of others time steps by copying constant/boundaryData/inlet/0. So I have new directories and files like:
constant/boundaryData/inlet/0.7/U
constant/boundaryData/inlet/0.7/k
constant/boundaryData/inlet/0.7/epsilon
constant/boundaryData/inlet/2/U
constant/boundaryData/inlet/2/k
constant/boundaryData/inlet/2/epsilon
constant/boundaryData/inlet/4/U
constant/boundaryData/inlet/4/k
constant/boundaryData/inlet/4/epsilon
*step 3*: I run "blockMesh" "decomposePar" then "mpirun -np 4 simpleFoam -parallel"
**3. The version OpenFoam 3.0.x is used and the case is run in windows system (windows server 2012). **
* No errors are producted during "blockMesh", "decomposePar" in mpirun
* No errors are producted in sequential calculation.
* I have attached my test case.
Best Regards,AdminAdminhttps://develop.openfoam.com/Development/openfoam/-/issues/580contiguous flag2018-07-02T09:38:59ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comcontiguous flagIn lagrangian there are various occurrences of making a specialisation of contiguous(), returning false:
coalCombustion/coalParcel/coalParcel.H
intermediate/parcels/derived/basicReactingMultiphaseParcel/basicReactingMultiphaseParcel.H
i...In lagrangian there are various occurrences of making a specialisation of contiguous(), returning false:
coalCombustion/coalParcel/coalParcel.H
intermediate/parcels/derived/basicReactingMultiphaseParcel/basicReactingMultiphaseParcel.H
intermediate/parcels/derived/basicReactingParcel/basicReactingParcel.H
spray/parcels/derived/basicSprayParcel/basicSprayParcel.H
The default template function returns false so they're not needed.AdminAdminhttps://develop.openfoam.com/Development/openfoam/-/issues/552managing fatal exceptions is awkward2017-07-29T11:22:50ZMark OLESENmanaging fatal exceptions is awkwardMark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/1225update compilation flags for ARM2019-12-09T22:37:28ZMark OLESENupdate compilation flags for ARMAs advised by Nathan, use consistent compilation and linkage flagsAs advised by Nathan, use consistent compilation and linkage flagsv1906Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/1237add support for writing finiteArea fields2019-04-26T08:09:45ZMark OLESENadd support for writing finiteArea fields- currently no easy mean of writing into other formats (ensight, vtk, etc).
- implement as a function object, reusing the newly revised surface writers
cross-ref: EP945- currently no easy mean of writing into other formats (ensight, vtk, etc).
- implement as a function object, reusing the newly revised surface writers
cross-ref: EP945Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/501COMP: 64 bit label compilation - further updates2017-07-12T04:46:26ZPrashant SonakarCOMP: 64 bit label compilation - further updatesFurther compilation failure at
foamVtkLagrangianWriter.C:103:25: error: call of overloaded 'write(int)' is ambiguous
@markFurther compilation failure at
foamVtkLagrangianWriter.C:103:25: error: call of overloaded 'write(int)' is ambiguous
@markVersion v1706Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/1117foamToVTK cannot write faceZones only2018-12-12T15:29:45ZMark OLESENfoamToVTK cannot write faceZones onlyAs noted by @Prashant - used to be able to hack foamToVTK with -noInternal and -excludePatches to get faceZones only, but now these are linked to the internal mesh (so that -no-internal really doesn't generate internal data fields).
Agr...As noted by @Prashant - used to be able to hack foamToVTK with -noInternal and -excludePatches to get faceZones only, but now these are linked to the internal mesh (so that -no-internal really doesn't generate internal data fields).
Agreed that it probably makes more sense to explicitly request faceZones by name or regex as per foamToEnsight. This makes it more flexible and more consistent with foamToEnsight.Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/414Number of time steps for adjustableRunTime calculated not robust2018-05-29T05:39:48ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comNumber of time steps for adjustableRunTime calculated not robustThe current logic to calculate the remaining number of time steps goes
scalar nSteps = timeToNextWrite/deltaT_ - SMALL;
label nStepsToNextWrite = label(nSteps) + 1;
which for e.g. deltaT=0.005, writeInterval 0.1 should ...The current logic to calculate the remaining number of time steps goes
scalar nSteps = timeToNextWrite/deltaT_ - SMALL;
label nStepsToNextWrite = label(nSteps) + 1;
which for e.g. deltaT=0.005, writeInterval 0.1 should go
nSteps = 19.99999999;
nStepsToNextWrite = 19+1
however the SMALL can fall in the truncation error and instead
nSteps = 20.000000001;
nStepsToNextWrite = 20+1
so replace logic with
scalar nSteps = timeToNextWrite/deltaT_;
// nSteps can be < 1 so make sure at least 1
label nStepsToNextWrite = max(1, round(nSteps));Mattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comhttps://develop.openfoam.com/Development/openfoam/-/issues/68OPenFoam3.0+ on windows 7: blockMesh killed when using more than ~1M cells2016-02-11T12:13:13ZAdminOPenFoam3.0+ on windows 7: blockMesh killed when using more than ~1M cellsHello,
I have a problem with large meshes more than 1M cells.
I'm using OpenFoam on Windows 7. I copied the cavity tutorial to my working directory and gradually increased the number of nodes. When the resulting mesh is larger than a...Hello,
I have a problem with large meshes more than 1M cells.
I'm using OpenFoam on Windows 7. I copied the cavity tutorial to my working directory and gradually increased the number of nodes. When the resulting mesh is larger than about 1M cells, the process is killed without an error message. I checked that ulimit is unlimited and checked through task manager that there is enough memory available.
Does anyone have a clue?
Alexander Pawan GhildiyalPawan Ghildiyalhttps://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`.