Development issueshttps://develop.openfoam.com/groups/Development/-/issues2018-05-29T05:39:48Zhttps://develop.openfoam.com/Development/openfoam/-/issues/324Parallel compilation on Ubuntu2018-05-29T05:39:48ZAdminParallel compilation on UbuntuSeems like parallel compilation needs lockfile utility that is not installed on Ubuntu by default
Please add package including lockfile (e.g. procmail) to the instructions pageSeems like parallel compilation needs lockfile utility that is not installed on Ubuntu by default
Please add package including lockfile (e.g. procmail) to the instructions pagehttps://develop.openfoam.com/Development/openfoam/-/issues/1086single precision issues2021-07-06T13:58:44ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comsingle precision issuesGeneric issue for single precision issuesGeneric issue for single precision issueshttps://develop.openfoam.com/Development/openfoam/-/issues/546Cannot print application help from non-case directory2017-07-22T21:58:37ZAdminCannot print application help from non-case directoryBehavior at c2db86f:
```bash
~ $ blockMesh -help
debug::switchSet(const char*, dictionary*&):
Cannot find DebugSwitches in dictionary
```Behavior at c2db86f:
```bash
~ $ blockMesh -help
debug::switchSet(const char*, dictionary*&):
Cannot find DebugSwitches in dictionary
```Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/1119ENH: abort functionObject2018-12-13T07:18:09ZPrashant SonakarENH: abort functionObjectinstead of action specified in FO details, can abort FO be updated to read the "action=" specified inside the trigger file?
cross ref : EP#865
@markinstead of action specified in FO details, can abort FO be updated to read the "action=" specified inside the trigger file?
cross ref : EP#865
@markMark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/570Velocity fluctuation in porousSimpleFoam2017-08-16T05:19:51ZAdminVelocity fluctuation in porousSimpleFoamWhile using 'porousSimpleFoam' solver its expected to show constant superficial velocity along the flow.
But its showing some variation or oscillation at the entrance, at higher velocities the its showing at more regions.
Tried with a ve...While using 'porousSimpleFoam' solver its expected to show constant superficial velocity along the flow.
But its showing some variation or oscillation at the entrance, at higher velocities the its showing at more regions.
Tried with a very low relaxation factor also, it doesn't works.
But the pressure drop is showing convincing values.https://develop.openfoam.com/Development/openfoam/-/issues/123BUG: inconsistent specification for -dict2016-07-27T12:16:16ZPrashant SonakarBUG: inconsistent specification for -dictargument specification should be consistent. Present syntax
```
noise -dict noiseDict
execFlowFunctionObjects -dict system/postProcessingDict
```
expected
```
noise -dict system/noiseDict
```
@Mattijs argument specification should be consistent. Present syntax
```
noise -dict noiseDict
execFlowFunctionObjects -dict system/postProcessingDict
```
expected
```
noise -dict system/noiseDict
```
@Mattijs AdminAdminhttps://develop.openfoam.com/Development/openfoam/-/issues/1028Poisson: KHI case failing with develop branch in walldistance calcualtion using2020-01-08T14:42:09ZPawan GhildiyalPoisson: KHI case failing with develop branch in walldistance calcualtion usingHello @Mattijs @Sergio
KHI case work fine with 1806 but with latest develop version,
it is failing while doing wallDistance calculation using poisson
but work fine with meshWave. Is there any changes applied to poisson metho...Hello @Mattijs @Sergio
KHI case work fine with 1806 but with latest develop version,
it is failing while doing wallDistance calculation using poisson
but work fine with meshWave. Is there any changes applied to poisson method. ?
Thanks
Pawanhttps://develop.openfoam.com/Development/openfoam/-/issues/1036wmkdepend sometimes throws2023-12-07T18:58:57ZMark OLESENwmkdepend sometimes throwsEvidenced by this:
```
terminate called after throwing an instance of 'std::length_error'
what(): basic_string::_M_create
```
The root cause is incorrect token shifting when getting the next file chunk.
@MattijsEvidenced by this:
```
terminate called after throwing an instance of 'std::length_error'
what(): basic_string::_M_create
```
The root cause is incorrect token shifting when getting the next file chunk.
@MattijsMark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/251foamCalc not reading arguments when executed through runParallel2016-11-11T07:38:37ZRoger AlmenarfoamCalc not reading arguments when executed through runParallelWhen I try to exectute foamCalc through runParallel, I get following errors (command runParallel foamCalc mag U):
[ram@pc-ram xyz]$ more log.foamCalc
...When I try to exectute foamCalc through runParallel, I get following errors (command runParallel foamCalc mag U):
[ram@pc-ram xyz]$ more log.foamCalc
--> FOAM FATAL ERROR:
Unknown calcType type -parallel
Valid calcType selections are:
8
(
addSubtract
components
div
interpolate
mag
magGrad
magSqr
randomise
)
From function static Foam::autoPtr<Foam::calcType> Foam::calcType::New(const Foam::word&)
in file calcType/calcTypeNew.C at line 53.
FOAM aborting
Selecting calcType -parallel
Selecting calcType -parallel
--> FOAM FATAL ERROR:
Unknown calcType type -parallel
Valid calcType selections are:
However, running the full command "mpirun -np 2 foamCalc mag U -parallel" runs without issues.https://develop.openfoam.com/Development/openfoam/-/issues/259Combine wordReList and wordReListMatcher2018-10-17T16:30:03ZMark OLESENCombine wordReList and wordReListMatcherWith the newer C++11 features it is possible to re-use the parent class constructors. It would thus make sense to merge the extra `match()` functionality of wordReListMatcher into a wordReList. This would also provide a convenient place ...With the newer C++11 features it is possible to re-use the parent class constructors. It would thus make sense to merge the extra `match()` functionality of wordReListMatcher into a wordReList. This would also provide a convenient place for other additional functionality such as `uniq` (eliminate duplicates) or if desired a specialized `sort()` - eg, sorts words first and patterns after.Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/313ENH: resultName not applicable for new mag field expression2018-05-29T05:39:49ZPrashant SonakarENH: resultName not applicable for new mag field expression```
mag(U)
{
type mag;
libs ( "libfieldFunctionObjects.so" );
field U;
executeControl writeTime;
writeControl writeTime;
fields 1 ( U );...```
mag(U)
{
type mag;
libs ( "libfieldFunctionObjects.so" );
field U;
executeControl writeTime;
writeControl writeTime;
fields 1 ( U );
}
```
doesn't seem to support resultName and leads to mag(U)AdminAdminhttps://develop.openfoam.com/Development/openfoam/-/issues/538Coupled patch crash in parallel2017-07-20T10:14:25ZAdminCoupled patch crash in parallelI'm using version OF-plus from 30 September 2016 (commit a9d9107930fc1b8d39196d712de6585d50aa81d0).
I need to build a new patch that couples information from two neighbor regions. I need to couple boundary information, not internal info...I'm using version OF-plus from 30 September 2016 (commit a9d9107930fc1b8d39196d712de6585d50aa81d0).
I need to build a new patch that couples information from two neighbor regions. I need to couple boundary information, not internal information. It is currently working in serial and in parallel when the decomposition keeps the coupled patch cells in the same processor. However, if the decomposition splits the domains just at the coupling patch, the code crashes.
**I've found an easy way to reproduce the error:**
Let's imagine two cubes (left and right) with two coupled boundary conditions: left_to_right and right_to_left. Let's use the chtMultiRegionSimpleFoam solver and the compressible::turbulentTemperatureRadCoupledMixed boundary condition for temperature. Inside this boundary condition, let's add the code:
`scalarField X = (Tp + nbrField)/2.0;`
Then:
* If we run the case in serial everything is ok.
* If we decompose the case in 2 processors using simple decomposition, with the decomposition perpendicular to the coupled patches (thus processor 0 includes: left-bottom and right-bottom zones), everything is ok
* If we decompose the case in 2 processors using simple decomposition, with the decomposition parallel to the coupled patches (thus processor 0 includes: left-left and right-left zones), the error obtained is:
> --> FOAM FATAL ERROR:
> [0] Field<scalar> f1(0), Field<scalar> f2(0) and Field<scalar> f3(1600)
> for operation f1 = f2 + f3
Thus, in the case where the crash appears, the size of the patch is not the same from the owner and the neighbor regions. It seems that information between both processors is not shared at patch level. **How can I avoid it? Is it a bug or I must call the boundary values in another way?**
Thank you in advance,
Elisabethttps://develop.openfoam.com/Development/openfoam/-/issues/315cellMotion bc does not write patchType (if used on constraint types)2020-01-03T09:59:12ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comcellMotion bc does not write patchType (if used on constraint types)This was tested in v1606+, not sure if fixed already.This was tested in v1606+, not sure if fixed already.https://develop.openfoam.com/Development/openfoam/-/issues/716re-reading broken on time control function2019-12-09T22:18:10ZMark OLESENre-reading broken on time control functionIt seems that any functionObject with an executeControl or writeControl will not properly re-read for its managed functionObject when modified.
Need to change `timeControl::read(const dictionary&)` to include this. Eg,
writeControl...It seems that any functionObject with an executeControl or writeControl will not properly re-read for its managed functionObject when modified.
Need to change `timeControl::read(const dictionary&)` to include this. Eg,
writeControl_.read(dict);
executeControl_.read(dict);
readControls();
// Missing this:
foPtr_->read();
Versions affected: 1712, 1706, 1612
@andy @sbnaMark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/39BUG: SHM with multi-domain2015-12-18T12:42:35ZPrashant SonakarBUG: SHM with multi-domainCase: /home/alex2/prashant/OpenFOAM/OpenFOAM-dev-OpenCFD.develop-feature_shm_zoning/tutorials/mesh/snappyHexMesh/snappyMultiRegionHeater-usingMultiRegion-addOnTests
I'm trying to put cellZone within cellZone.
Earlier log for same s...Case: /home/alex2/prashant/OpenFOAM/OpenFOAM-dev-OpenCFD.develop-feature_shm_zoning/tutorials/mesh/snappyHexMesh/snappyMultiRegionHeater-usingMultiRegion-addOnTests
I'm trying to put cellZone within cellZone.
Earlier log for same settings: log_shmMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comhttps://develop.openfoam.com/Development/openfoam/-/issues/864refineWallLayer -useSet incorrect2018-07-04T10:45:24ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comrefineWallLayer -useSet incorrectrefineWallLayer -useSet should limit the refinement to the specified set. Instead it does the opposite.refineWallLayer -useSet should limit the refinement to the specified set. Instead it does the opposite.Mattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comhttps://develop.openfoam.com/Development/openfoam/-/issues/693incorrect implementation of jumpCyclic BC2018-03-14T17:24:39ZAdminincorrect implementation of jumpCyclic BCbegin at line 94 of jumpCyclicFvPatchField.C
```c++
template<class Type>
Foam::tmp<Foam::Field<Type>>
Foam::jumpCyclicFvPatchField<Type>::patchNeighbourField() const
{
const Field<Type>& iField = this->primitiveField();
const lab...begin at line 94 of jumpCyclicFvPatchField.C
```c++
template<class Type>
Foam::tmp<Foam::Field<Type>>
Foam::jumpCyclicFvPatchField<Type>::patchNeighbourField() const
{
const Field<Type>& iField = this->primitiveField();
const labelUList& nbrFaceCells =
this->cyclicPatch().neighbFvPatch().faceCells();
tmp<Field<Type>> tpnf(new Field<Type>(this->size()));
Field<Type>& pnf = tpnf.ref();
Field<Type> jf(this->jump());
if (!this->cyclicPatch().owner())
{
jf *= -1.0;
}
if (this->doTransform())
{
forAll(*this, facei)
{
pnf[facei] = transform
(
this->forwardT()[0], iField[nbrFaceCells[facei]]
) - jf[facei];
}
}
else
{
forAll(*this, facei)
{
pnf[facei] = iField[nbrFaceCells[facei]] - jf[facei];
}
}
return tpnf;
}
```
Mathematically, jumpCyclic BC must enforce the jump condition between patch faces. However, in the implementation, it seems that the jump condition are enforced between the inner cell and neighbour cells, which is obviously incorrect.https://develop.openfoam.com/Development/openfoam/-/issues/603muttley + openmpi-1.10.4 + openib does not support threads2019-06-28T09:56:15ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.commuttley + openmpi-1.10.4 + openib does not support threadsopenmpi-1.10.4 (compiled with thread support!) + openib fails immediately in MPI_Init_thread without even printing the message
"mpi does not seem to have thread support. There might be issues with e.g. threaded IO"
- works with self, t...openmpi-1.10.4 (compiled with thread support!) + openib fails immediately in MPI_Init_thread without even printing the message
"mpi does not seem to have thread support. There might be issues with e.g. threaded IO"
- works with self, tcp
- works when changing MPI_Init_thread to MPI_Inithttps://develop.openfoam.com/Development/openfoam/-/issues/378A way to query the current version of OpenFOAM during build?2019-12-09T21:29:27ZAdminA way to query the current version of OpenFOAM during build?Hello,
Is there a way to query the OpenFOAM System which version is currently active? For example, whether the active version is v1606+ or v1612+?
Reason for this is the fact that there are API changes between versions which are break...Hello,
Is there a way to query the OpenFOAM System which version is currently active? For example, whether the active version is v1606+ or v1612+?
Reason for this is the fact that there are API changes between versions which are breaking builds of third-party tools (in this case, cfMesh and swak4Foam). In order to maintain backward and "sideward" compatibility for external tools, queries need to be made during the build process via macros to decide which API features are valid, available, etc...
Thank you.Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/261Provide support for C++11 initializer lists in a few more places2017-02-01T10:22:34ZMark OLESENProvide support for C++11 initializer lists in a few more placesMark OLESENMark OLESEN