Development issueshttps://develop.openfoam.com/groups/Development/-/issues2020-01-03T09:59:12Zhttps://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/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/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çinhttps://develop.openfoam.com/Development/openfoam/-/issues/100Missing yyFlexLexer:yywrap()2016-06-30T09:10:10ZAdminMissing yyFlexLexer:yywrap()I am compiling on a Gentoo/Funtoo system. I had to comment out the following lines in
src/surfMesh/surfaceFormats/stl/STLsurfaceFormatASCII.L and src/triSurface/triSurface/interfaces/STL/readSTLASCII.L for dummy yywrap to get the code ...I am compiling on a Gentoo/Funtoo system. I had to comment out the following lines in
src/surfMesh/surfaceFormats/stl/STLsurfaceFormatASCII.L and src/triSurface/triSurface/interfaces/STL/readSTLASCII.L for dummy yywrap to get the code to compile:
// #if YY_FLEX_SUBMINOR_VERSION < 34
// extern "C" int yywrap()
// #else
int yyFlexLexer::yywrap()int
// #endif
This same coding is used elsewhere but a dummy yyFlexLexer::yywrap() needs to be defined and not an extern call. The code seems to assume Flex-2.5. I am running Flex-2.6.1 and get the extern call.
Pawan GhildiyalPawan Ghildiyalhttps://develop.openfoam.com/Development/openfoam/-/issues/428mass conservation problem in interCondensingEvaporatingFoam2017-04-18T13:40:34ZAdminmass conservation problem in interCondensingEvaporatingFoamDear OF Developers,
I am working with interCondensingEvaporatingFoam solver. I have encountered a possibly very important problem.
I am calculating flow with a phase change in-between heated plates. Domain has one inlet, one outlet, and...Dear OF Developers,
I am working with interCondensingEvaporatingFoam solver. I have encountered a possibly very important problem.
I am calculating flow with a phase change in-between heated plates. Domain has one inlet, one outlet, and a body limited by two heated plates.
At the inlet the liquid enters the domain, is heated, partially evaporates and leaves the domain via outlet.
The problem is that the mass is not conserved. There is approximately 6x larger mass flow of the liquid/vapor mixture at the outlet that at the inlet.
Please see the attached picture, which shows some filed values and integrated 'u_x*rho' over the inlet and outlet patch (u_x in normal to the inlet/outlet, so it gives mass flow).
![mass_conservation_problem](/uploads/392619e49f0b4f2972c607e84143be8f/mass_conservation_problem.png)
upper row of the figure shows the data for the inlet; the value "U_x_times_rho_inlet" in the table on the right corresponds to inlet mass flow
lower row of the figure shows the data for the outlet; the value "U_x_times_rho_outlet" in the table on the right corresponds to outlet mass flow
Regards
Jimhttps://develop.openfoam.com/Development/openfoam/-/issues/255ease dictionary output2017-02-01T10:22:49ZMark OLESENease dictionary outputProvide a `dictionary::write` that can also handle a leading key as its header.Provide a `dictionary::write` that can also handle a leading key as its header.Version v1612Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/631framework for cell cutting (placeholder)2021-07-06T11:23:02ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comframework for cell cutting (placeholder)Mattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comhttps://develop.openfoam.com/Development/openfoam/-/issues/1025buoyantPimpleFoam2020-01-03T20:52:53ZPawan GhildiyalbuoyantPimpleFoamhello @andy @Sergio
buoyantPimpleFoam does not read rhoMin/rhoMax or pMinFactor
(I cannot see in log whether it is being read )
Also, i can see it is not being applied while solver is running.
Any particular reason for this . ...hello @andy @Sergio
buoyantPimpleFoam does not read rhoMin/rhoMax or pMinFactor
(I cannot see in log whether it is being read )
Also, i can see it is not being applied while solver is running.
Any particular reason for this . If not, can we have same limiter
in buoyantPimpleFoam.
Regards
Pawanhttps://develop.openfoam.com/Development/openfoam/-/issues/206sampledSets do not warn for empty field list (and do not write geometry either)2019-12-09T22:04:11ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comsampledSets do not warn for empty field list (and do not write geometry either)This happened when there was a 0/p which happened to be of type dictionary instead of volScalarField. Would be nice if there was a warning. This does not need to be done for sampledSurfaces since these can be used without fields.
This happened when there was a 0/p which happened to be of type dictionary instead of volScalarField. Would be nice if there was a warning. This does not need to be done for sampledSurfaces since these can be used without fields.
https://develop.openfoam.com/Development/openfoam/-/issues/199BUG: decomposition failure (due to folder name/ ??)2019-12-09T22:04:11ZPrashant SonakarBUG: decomposition failure (due to folder name/ ??)An interesting bug in decomposition from @Koushik
[issue_with_decomposition_processor1.tgz](/uploads/a828281324e633cd39e875c2d2a400a9/issue_with_decomposition_processor1.tgz)
deomposePar seems to fails with error [log.decomposePar...An interesting bug in decomposition from @Koushik
[issue_with_decomposition_processor1.tgz](/uploads/a828281324e633cd39e875c2d2a400a9/issue_with_decomposition_processor1.tgz)
deomposePar seems to fails with error [log.decomposePar](/uploads/ce7be4460579a49a854c57fea8c51296/log.decomposePar)
@Mattijs Version v1612Mark OLESENMark OLESEN