Development issueshttps://develop.openfoam.com/groups/Development/-/issues2023-08-19T21:13:19Zhttps://develop.openfoam.com/Development/openfoam/-/issues/9BUG: surface collate option dumps empty time folders2023-08-19T21:13:19ZPrashant SonakarBUG: surface collate option dumps empty time folderscase dumps additional time directories in postProcessing folder. (these are empty folders)
[09star_write_transient.tgz](https://develop.openfoam.com/Development/OpenFOAM-dev-OpenCFD/uploads/c8a33d1b292382fb33f0e8edfb089772/09star_writ...case dumps additional time directories in postProcessing folder. (these are empty folders)
[09star_write_transient.tgz](https://develop.openfoam.com/Development/OpenFOAM-dev-OpenCFD/uploads/c8a33d1b292382fb33f0e8edfb089772/09star_write_transient.tgz)
@Mattijs Functionality migration from internal development lineAdminAdminhttps://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/1245ENH: add function1 support for rpm in swirl fan velocity2019-03-26T05:50:05ZPrashant SonakarENH: add function1 support for rpm in swirl fan velocity### Functionality to add/problem to solve
Function1 type for rpm (e.g. table) in swirl fan velocity
### Target audience
General capability
### Links / references
Cross ref: EP#949### Functionality to add/problem to solve
Function1 type for rpm (e.g. table) in swirl fan velocity
### Target audience
General capability
### Links / references
Cross ref: EP#949v1906Prashant SonakarPrashant Sonakarhttps://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/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/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/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/227Non-const dereferencing of tmp in fvc:dt2dt22019-12-09T22:04:11ZMark OLESENNon-const dereferencing of tmp in fvc:dt2dt2Reported as http://exchange.openfoam.com/node/252
@andyReported as http://exchange.openfoam.com/node/252
@andyVersion v1612Mark OLESENMark OLESEN2016-09-08https://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 OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/457compressible dynamicLagrangian SGS2017-07-20T08:46:57ZAdmincompressible dynamicLagrangian SGSIt seems that there is a bug in dynamicLagrangian SGS model implemented for “compressible” solver. Since the rho value already implemented into the equations for fmm and flm then flm and fmm files in zero directory should have the same d...It seems that there is a bug in dynamicLagrangian SGS model implemented for “compressible” solver. Since the rho value already implemented into the equations for fmm and flm then flm and fmm files in zero directory should have the same dimension as incompressible version which is [0 4 -4 0 0 0 0] for both fmm and flm. However, with this set of dimension and with many other combinations, OpenFOAM is giving the “incompatible dimensions for operation” error.Sergio FerrarisSergio Ferrarishttps://develop.openfoam.com/Development/openfoam/-/issues/563markup for pstream token types is fragile2017-08-10T12:57:02ZMark OLESENmarkup for pstream token types is fragileThis seems to be the root of the issue I encountered while adding in dictionary macros. The additional `MACRO` enumeration value (placed immediately after `WORD`) means that the indices of the subsequent `tokenType` enumerations increase...This seems to be the root of the issue I encountered while adding in dictionary macros. The additional `MACRO` enumeration value (placed immediately after `WORD`) means that the indices of the subsequent `tokenType` enumerations increase by one. This made `DOUBLE_SCALAR` receive a value of 9.
In `UOPstream::write(double)` this enumeration value is written as a character, which unfortunately corresponds to Tab and thus gets swallowed as a whitespace character. After this, the receiving end hasn't much chance.
I think that we should be invoking `writeToBuffer(char)` directly instead of using things like `write(char(token::DOUBLE_SCALAR))` - should be more reliable.
@Mattijsv1712Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/407BUG: volume sampling output location2020-01-03T11:15:54ZPrashant SonakarBUG: volume sampling output location[pitzDaily_sample_surfaceAndVol.tgz](/uploads/9b26e07b30ae20acd358fa402c72fb31/pitzDaily_sample_surfaceAndVol.tgz)
Case attached replicating issue.
- contains sampling for surface and volume type with writeFields=true
surface-> outputs...[pitzDaily_sample_surfaceAndVol.tgz](/uploads/9b26e07b30ae20acd358fa402c72fb31/pitzDaily_sample_surfaceAndVol.tgz)
Case attached replicating issue.
- contains sampling for surface and volume type with writeFields=true
surface-> outputs field in postProcessing directory
volume-> outputs field (!) in processor0 (for parallel) or case directory (serial)
@andy @MattijsVersion v1706Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/942velocity damping description not up-to-date2019-12-18T16:20:17Zvilfayeauvelocity damping description not up-to-dateHi,
I'd just realized that the velocity damping header file description is not up-to-date
https://develop.openfoam.com/Development/OpenFOAM-plus/blob/master/src/fvOptions/constraints/derived/velocityDampingConstraint/velocityDampingCon...Hi,
I'd just realized that the velocity damping header file description is not up-to-date
https://develop.openfoam.com/Development/OpenFOAM-plus/blob/master/src/fvOptions/constraints/derived/velocityDampingConstraint/velocityDampingConstraint.H
It should be:
`
damp
{
type velocityDampingConstraint;
active true;
velocityDampingConstraintCoeffs
{
UMax 25;
selectionMode all;
// Optional: name of velocity field (default: U)
//UName U;
}
}
`
Best,
SebastienKutalmış BerçinKutalmış Berçin