Development issueshttps://develop.openfoam.com/groups/Development/-/issues2016-01-13T17:18:14Zhttps://develop.openfoam.com/Development/openfoam/-/issues/55hopperInitialState tutorial fails2016-01-13T17:18:14ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comhopperInitialState tutorial failsRunning hopper tutorial in tutorialsTest gives failure on hopperInitialState[log.icoUncoupledKinematicParcelFoam](/uploads/8122f605379f02253f131f5a64e3d8c5/log.icoUncoupledKinematicParcelFoam)
Running hopper tutorial in tutorialsTest gives failure on hopperInitialState[log.icoUncoupledKinematicParcelFoam](/uploads/8122f605379f02253f131f5a64e3d8c5/log.icoUncoupledKinematicParcelFoam)
https://develop.openfoam.com/Development/openfoam/-/issues/905solid thermo (heSolidThermo) initialisation of psi, mu2020-01-08T14:41:37ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comsolid thermo (heSolidThermo) initialisation of psi, muheSolidThermo does not initialise or update the psi,mu of the base class (rhoThermo). This shows up when calculating turbulence for multi-phase systems (e.g. icoReactingMultiPhaseInterFoam) when accessing divDevRhoReff.
The underlying p...heSolidThermo does not initialise or update the psi,mu of the base class (rhoThermo). This shows up when calculating turbulence for multi-phase systems (e.g. icoReactingMultiPhaseInterFoam) when accessing divDevRhoReff.
The underlying problem is that the solid transportModels do not implement mu(), psi() functionality. See #856. The current solution is to explicitly set the mu, psi to 0 in the multi-phase system constructor.Andrew HeatherAndrew Heatherhttps://develop.openfoam.com/Development/openfoam/-/issues/704sampledTriSurfaceMesh reading surfaces from region directory2019-12-09T22:18:09ZMark OLESENsampledTriSurfaceMesh reading surfaces from region directory IOobject
(
dict.lookup("surface"),
mesh.time().constant(), // instance
"triSurface", // local
mesh, // registry
IOobject::MUST_READ,
... IOobject
(
dict.lookup("surface"),
mesh.time().constant(), // instance
"triSurface", // local
mesh, // registry
IOobject::MUST_READ,
IOobject::NO_WRITE,
false
),
So surfaces are taken from the mesh registry, which means `regionName/constant/triSurface` for etc.
Could, however, have them taken from `mesh.time()` so that they use the main `constant/triSurface`
@Mattijs @Prashant
cross-reference EP#598Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/52BUG: Unit test failed for kOmegaSSTDES2016-01-07T09:31:26ZPrashant SonakarBUG: Unit test failed for kOmegaSSTDESCould you please test
turbulenceModels/compressible/LES/pitzDaily from unit tests repository?
It seems to report unconfirmed completion
@andy @Mattijs Could you please test
turbulenceModels/compressible/LES/pitzDaily from unit tests repository?
It seems to report unconfirmed completion
@andy @Mattijs Sergio FerrarisSergio Ferrarishttps://develop.openfoam.com/Development/openfoam/-/issues/916aerofoilNACA0012_directionalRefinement : not visited by Allrun2018-07-03T04:19:19ZPrashant SonakaraerofoilNACA0012_directionalRefinement : not visited by AllrunPlease add the tutorial aerofoilNACA0012_directionalRefinement for execution in
mesh/snappyHexMesh/Allrun
@Mattijs @andyPlease add the tutorial aerofoilNACA0012_directionalRefinement for execution in
mesh/snappyHexMesh/Allrun
@Mattijs @andyv1812Mattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comhttps://develop.openfoam.com/Development/openfoam/-/issues/66BUG: SHM can't resolve wall boundary near faceZone2019-12-09T22:04:12ZPrashant SonakarBUG: SHM can't resolve wall boundary near faceZone[case1.tgz](/uploads/883bebc867dfbd68bfa9008e3597cc46/case1.tgz)
When used with new mutli-location method:
- Attached case illustrates the wall frame (top and bottom) is not resolved.
![image1](/uploads/e254cd4d7d3e208b1b888f9cc11...[case1.tgz](/uploads/883bebc867dfbd68bfa9008e3597cc46/case1.tgz)
When used with new mutli-location method:
- Attached case illustrates the wall frame (top and bottom) is not resolved.
![image1](/uploads/e254cd4d7d3e208b1b888f9cc117e865/image1.jpg)
When old style is used (defining single locationInMesh, and using faceZone+cellZone combination for HX)
- The mesh leaks inside these frames
![image2](/uploads/1289093aa087ba09a72fe4ac7d19aadb/image2.jpg)
# The single wall thick (baffles) are never resolved as walls (HX_CAC_FRAME.stl)
![image3](/uploads/16ab3483c66ffcdcec821724f97e9ba3/image3.jpg)
This might be cirtical to block the flow for inclided HX, unless there is any other family blocking the flow from sides.
@andy @Sergio
Mattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comhttps://develop.openfoam.com/Development/openfoam/-/issues/146ENH: Installation notes - csh/sh files2016-11-16T05:29:15ZPrashant SonakarENH: Installation notes - csh/sh filesAs the compilation is done with sh scripts (and also some of the scripts now use internal sourcing to sh files
e.g.
- src/renumber/Allwmake
- src/fvAgglomerationMethods/Allwmake
- src/parallel/decompose/Allwmake ...)
users MUST ...As the compilation is done with sh scripts (and also some of the scripts now use internal sourcing to sh files
e.g.
- src/renumber/Allwmake
- src/fvAgglomerationMethods/Allwmake
- src/parallel/decompose/Allwmake ...)
users MUST edit the *.sh files or configuration settings to ensure nothing is conflicting.
Installation guide should state this clearly.
I might have missed some points, please share your views.
@andy @Mattijs @mark @Sergio @matej @Roger Pawan GhildiyalPawan Ghildiyalhttps://develop.openfoam.com/Development/openfoam/-/issues/647ENH: turbulentMixingLengthDissipationRateInlet Cmu lookup for realizableKE2020-06-12T17:35:58ZAdminENH: turbulentMixingLengthDissipationRateInlet Cmu lookup for realizableKEIn turbulentMixingLengthDissipationRateInletFvPatchScalarField.C Cmu appears to be looked up or defaulted to a constant of 0.09...
```c
// Lookup Cmu corresponding to the turbulence model selected
const turbulenceModel& turbModel = ...In turbulentMixingLengthDissipationRateInletFvPatchScalarField.C Cmu appears to be looked up or defaulted to a constant of 0.09...
```c
// Lookup Cmu corresponding to the turbulence model selected
const turbulenceModel& turbModel = db().lookupObject<turbulenceModel>
(
IOobject::groupName
(
turbulenceModel::propertiesName,
internalField().group()
)
);
const scalar Cmu =
turbModel.coeffDict().lookupOrDefault<scalar>("Cmu", 0.09);
```
It looks like Cmu is being looked up from the turbulence dictionary in turbulenceProperties. However, for turbulence models like realizableKE where Cmu is not constant, I think Cmu should be looked up from the turbulence model itself. Am I reading this correctly? Thoughts?
\## Reattaching the author to the issue ticket: @graups ##v2006Kutalmış BerçinKutalmış Berçinhttps://develop.openfoam.com/Development/openfoam/-/issues/680decomposition fails with faMesh2017-12-22T11:54:11ZMark OLESENdecomposition fails with faMeshRunning the wolfsgrube avalanche tutorial. Decomposing with 4 proc OK.
Decomposing with hierarchical (4 4 1)
--> FOAM FATAL ERROR:
Impossible processor label 757738797for face 8
From function Finite area mesh decompositio...Running the wolfsgrube avalanche tutorial. Decomposing with 4 proc OK.
Decomposing with hierarchical (4 4 1)
--> FOAM FATAL ERROR:
Impossible processor label 757738797for face 8
From function Finite area mesh decomposition
in file faMeshDecomposition.C at line 223.v1806Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/4vector field required in documentation section2023-08-19T21:13:18ZPrashant Sonakarvector field required in documentation sectionmovingWallVelocityFvPatchVectorField.H should have velocity "vector" initialization value.movingWallVelocityFvPatchVectorField.H should have velocity "vector" initialization value.Mattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comhttps://develop.openfoam.com/Development/openfoam/-/issues/950Not reflecting emissivity... (v1806)2020-03-13T13:44:25ZAdminNot reflecting emissivity... (v1806)hi Maintainer!
I think the emissivity in the submodel called multiBandSolidAbsorptionEmission is invalidated.
i understand the emissivity effects an inclease of temperature in objects.
Is that a specification or bug for this model?
[...hi Maintainer!
I think the emissivity in the submodel called multiBandSolidAbsorptionEmission is invalidated.
i understand the emissivity effects an inclease of temperature in objects.
Is that a specification or bug for this model?
[myTest.tar.gz](/uploads/520b735eb5153ad1751340dd6f16d6ee/myTest.tar.gz)https://develop.openfoam.com/Development/openfoam/-/issues/695COMP: incorrect executable path2019-12-09T22:18:10ZPrashant SonakarCOMP: incorrect executable pathhttps://develop.openfoam.com/Development/OpenFOAM-plus/blob/develop/applications/solvers/finiteArea/sphereSurfactantFoam/Make/files points to USER area and not standard APPBIN
@andy @markhttps://develop.openfoam.com/Development/OpenFOAM-plus/blob/develop/applications/solvers/finiteArea/sphereSurfactantFoam/Make/files points to USER area and not standard APPBIN
@andy @markMark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/561writeInterval not respected when starting from T != 02017-08-11T11:42:54ZAdminwriteInterval not respected when starting from T != 0Some context: I am running DES simulations which start from a steady RANS result. This means, I'll run thousands of RANS iterations, and then run a few physical seconds.
In this case I am testing setup scripts, so I'm running 6 RANS ite...Some context: I am running DES simulations which start from a steady RANS result. This means, I'll run thousands of RANS iterations, and then run a few physical seconds.
In this case I am testing setup scripts, so I'm running 6 RANS iterations, and 0.051 seconds of DES time. So my DES case starts at t=6, does 85 iterations of deltaT=0.0006, ending at t=6.051. I have calculated those values out so that, using a writeInterval of 17, the case writes out exactly 5 times and the last write is exactly at t=6.051.
However, the first write occurs at t=6.0066, which is only 11 iterations in, rather than 17. I think should be writing out at 6.0102, as per deltaT and the writeInterval. It seems to me the writeInterval of 17 is including the t=6 startTime as 6 iterations, which means it writes after 11 DES iterations (0.0006*11 = 0.0066). This shifts the writing to undesired interval, and I think this is a bug. I would assume the correct behaviour would be to always count the writeInterval from the startTime?
I confirmed this by starting from a RANS run with 10 iterations, so startTime = 10. In this case, the first write is at 6.0042, or 7 iterations after the startTime.
Is this a bug? I am able to provide a case, it's a very simple geometry.https://develop.openfoam.com/Development/openfoam/-/issues/12Documentation/BUG: Volume point smoothing2023-08-19T21:13:19ZPrashant SonakarDocumentation/BUG: Volume point smoothingIs it possible to have nSmoothInternal > nSmoothPatch?
Documentation says it can't. But present version can allow this.
Please fix either of these! :)
@andy Is it possible to have nSmoothInternal > nSmoothPatch?
Documentation says it can't. But present version can allow this.
Please fix either of these! :)
@andy Functionality migration from internal development lineMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comhttps://develop.openfoam.com/Development/openfoam/-/issues/15BUG: Failure of case for humidity BC2023-08-19T21:13:19ZPrashant SonakarBUG: Failure of case for humidity BCCase $FOAM_TUTORIALS/heatTransfer/chtMultiRegionFoam/windshieldCondensation fails.
@andy @Mattijs Case $FOAM_TUTORIALS/heatTransfer/chtMultiRegionFoam/windshieldCondensation fails.
@andy @Mattijs Functionality migration from internal development lineAdminAdminhttps://develop.openfoam.com/Development/openfoam/-/issues/955surfaceFeatureExtract accesses zero-sized bitSet2020-01-03T14:23:08ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comsurfaceFeatureExtract accesses zero-sized bitSetMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comhttps://develop.openfoam.com/Development/openfoam/-/issues/3Reposition fvMotionSolver in Allwmake2023-08-19T21:13:18ZPrashant SonakarReposition fvMotionSolver in AllwmakePlaceholder for resolution of mesh compilation, depending on fvMotionSolver
wmake $targetType fvMotionSolverPlaceholder for resolution of mesh compilation, depending on fvMotionSolver
wmake $targetType fvMotionSolverMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comhttps://develop.openfoam.com/Development/openfoam/-/issues/551Feature: improve TAB functionality2017-10-06T07:54:11ZPrashant SonakarFeature: improve TAB functionalityRefer EP#456
@andy @markRefer EP#456
@andy @markv1712Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/23Discussion: FO output : blendingFactor2015-12-15T07:07:16ZPrashant SonakarDiscussion: FO output : blendingFactorIs it OK to have two output statements per iteration?
blendingFactor blendingFactor1 output:
scheme 1 cells : 106634
scheme 2 cells : 0
blended cells : 0
blendingFactor blendingFactor1 output:
writing fi...Is it OK to have two output statements per iteration?
blendingFactor blendingFactor1 output:
scheme 1 cells : 106634
scheme 2 cells : 0
blended cells : 0
blendingFactor blendingFactor1 output:
writing field blendingFactor1:U
/home/alex2/prashant/QA/UNIT_TESTS/FO-tests/compressible/motorBike/log.rhoPimpleFoam.blendingFactor
@Mattijs Functionality migration from internal development lineMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comhttps://develop.openfoam.com/Development/openfoam/-/issues/98Error while trying to compile the SP version of openFoam v3.0+2016-06-10T15:06:03ZAdminError while trying to compile the SP version of openFoam v3.0+The DP version of the code compiles fine.
When the SP flag is used the compiler throws the following :
In file included from ../turbulenceModels/lnInclude/SpalartAllmarasDES.H:241:0,
from turbulentTransportModels/...The DP version of the code compiles fine.
When the SP flag is used the compiler throws the following :
In file included from ../turbulenceModels/lnInclude/SpalartAllmarasDES.H:241:0,
from turbulentTransportModels/turbulentTransportModels.C:112:
../turbulenceModels/lnInclude/SpalartAllmarasDES.C: In member function 'Foam::tmp<Foam::GeometricField<float, Foam::fvPatchField, Foam::volMesh> > Foam::LESModels::SpalartAllmarasDES<BasicTurbulenceModel>::psi(const volScalarField&, const volScalarField&) const':
../turbulenceModels/lnInclude/SpalartAllmarasDES.C:189:55: error: no matching function for call to 'max(double, Foam::tmp<Foam::GeometricField<float, Foam::fvPatchField, Foam::volMesh> >&)'
../turbulenceModels/lnInclude/SpalartAllmarasDES.C:189:55: note: candidates are:
/scratch/Apps/OF/OpenFOAM-v3.0+/src/OpenFOAM/lnInclude/int.H:59:1: note: int8_t Foam::max(int8_t, int8_t)
/scratch/Apps/OF/OpenFOAM-v3.0+/src/OpenFOAM/lnInclude/int.H:59:1: note: no known conversion for argument 2 from 'Foam::tmp<Foam::GeometricField<float, Foam::fvPatchField, Foam::volMesh> >' to 'int8_t {aka signed char}'
/scratch/Apps/OF/OpenFOAM-v3.0+/src/OpenFOAM/lnInclude/int.H:60:1: note: int16_t Foam::max(int16_t, int16_t)
/scratch/Apps/OF/OpenFOAM-v3.0+/src/OpenFOAM/lnInclude/int.H:60:1: note: no known conversion for argument 2 from 'Foam::tmp<Foam::GeometricField<float, Foam::fvPatchField, Foam::volMesh> >' to 'int16_t {aka short int}'
/scratch/Apps/OF/OpenFOAM-v3.0+/src/OpenFOAM/lnInclude/int.H:62:1: note: int32_t Foam::max(int32_t, int32_t)
/scratch/Apps/OF/OpenFOAM-v3.0+/src/OpenFOAM/lnInclude/int.H:62:1: note: no known conversion for argument 2 from 'Foam::tmp<Foam::GeometricField<float, Foam::fvPatchField, Foam::volMesh> >' to 'int32_t {aka int}'
/scratch/Apps/OF/OpenFOAM-v3.0+/src/OpenFOAM/lnInclude/int.H:63:1: note: int64_t Foam::max(int64_t, int32_t)
/scratch/Apps/OF/OpenFOAM-v3.0+/src/OpenFOAM/lnInclude/int.H:63:1: note: no known conversion for argument 2 from 'Foam::tmp<Foam::GeometricField<float, Foam::fvPatchField, Foam::volMesh> >' to 'int32_t {aka int}'
/scratch/Apps/OF/OpenFOAM-v3.0+/src/OpenFOAM/lnInclude/int.H:64:1: note: int64_t Foam::max(int32_t, int64_t)
/scratch/Apps/OF/OpenFOAM-v3.0+/src/OpenFOAM/lnInclude/int.H:64:1: note: no known conversion for argument 2 from 'Foam::tmp<Foam::GeometricField<float, Foam::fvPatchField, Foam::volMesh> >' to 'int64_t {aka long int}'
It has also been tried to compile it with a single cpu but the error is the same.
Thank you
Pawan GhildiyalPawan Ghildiyal