Development issueshttps://develop.openfoam.com/groups/Development/-/issues2016-04-25T10:52:55Zhttps://develop.openfoam.com/Development/openfoam/-/issues/21BUG: syntax correction in fieldCoordinateSystemTransform2016-04-25T10:52:55ZPrashant SonakarBUG: syntax correction in fieldCoordinateSystemTransformPlease correct the syntax in header as well as postProcessingDict file as per attached example
[functionObjects.fieldCoordinateSystemTransform](/uploads/a74c5adc2a66862259257dafbce04ed2/functionObjects.fieldCoordinateSystemTransform)
...Please correct the syntax in header as well as postProcessingDict file as per attached example
[functionObjects.fieldCoordinateSystemTransform](/uploads/a74c5adc2a66862259257dafbce04ed2/functionObjects.fieldCoordinateSystemTransform)
@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/17BUG: Missing correction from of-dev.master2023-08-19T21:13:19ZPrashant SonakarBUG: Missing correction from of-dev.masterCase reporting failure: /home/alex2/prashant/QA/UNIT_TESTS/OpenFOAM-test.dev-OpenCFD.develop/testCases/turbulenceModels/compressible/LES/pitzDaily/log.rhoPimpleFoam.dynamicLagrangian
Possible fix: https://develop.openfoam.com/OpenCFD/...Case reporting failure: /home/alex2/prashant/QA/UNIT_TESTS/OpenFOAM-test.dev-OpenCFD.develop/testCases/turbulenceModels/compressible/LES/pitzDaily/log.rhoPimpleFoam.dynamicLagrangian
Possible fix: https://develop.openfoam.com/OpenCFD/OpenFOAM-dev/commit/b93eca5221c05c17e6eafc47bd98dd36f693b5bf
@Mattijs @Sergio Functionality migration from internal development lineSergio FerrarisSergio Ferrarishttps://develop.openfoam.com/Development/openfoam/-/issues/33BUG: Missing boundaryRadiationProperties file2015-12-15T09:22:38ZPrashant SonakarBUG: Missing boundaryRadiationProperties filecombustion/fireFoam/les/flameSpreadWaterSuppressionPanel case failed for unitTest.
/home/alex2/prashant/OpenFOAM/OpenFOAM-dev-OpenCFD.develop/tutorialsTest.14Dec
@Mattijs combustion/fireFoam/les/flameSpreadWaterSuppressionPanel case failed for unitTest.
/home/alex2/prashant/OpenFOAM/OpenFOAM-dev-OpenCFD.develop/tutorialsTest.14Dec
@Mattijs Functionality migration from internal development lineSergio FerrarisSergio Ferrarishttps://develop.openfoam.com/Development/openfoam/-/issues/49BUG: inconsistent result for Third-party test case (DEShybrid)2016-01-08T12:41:03ZPrashant SonakarBUG: inconsistent result for Third-party test case (DEShybrid)- blending factor seems to behave differently for processor boundries
![img1](/uploads/73230aaf7101ae18a2291cafa7b8d7c8/img1.jpg)
- reconfirm the blending factor calculation (seem to show some differences)
![img2](/uploads/69bb743...- blending factor seems to behave differently for processor boundries
![img1](/uploads/73230aaf7101ae18a2291cafa7b8d7c8/img1.jpg)
- reconfirm the blending factor calculation (seem to show some differences)
![img2](/uploads/69bb7432c31f58403412bc62e931c545/img2.jpg)
@Sergio @Mattijs @Koushik Functionality migration from internal development lineAdminAdminhttps://develop.openfoam.com/Development/openfoam/-/issues/18BUG: Failure of tutorial cases2023-08-19T21:13:19ZPrashant SonakarBUG: Failure of tutorial casesStandard tutorials supplied with $FOAM_TUTORIALS fail at few points as listed under:
/home/alex2/prashant/OpenFOAM/OpenFOAM-dev-OpenCFD.develop/tutorialsTest/testLoopReport
@andy @Mattijs Standard tutorials supplied with $FOAM_TUTORIALS fail at few points as listed under:
/home/alex2/prashant/OpenFOAM/OpenFOAM-dev-OpenCFD.develop/tutorialsTest/testLoopReport
@andy @Mattijs Functionality migration from internal development lineAdminAdminhttps://develop.openfoam.com/Development/openfoam/-/issues/43BUG: Correct the setup2019-01-09T05:30:15ZPrashant SonakarBUG: Correct the setup/home/alex2/prashant/OpenFOAM/OpenFOAM-dev-OpenCFD.develop-16Dec/tutorials/multiphase/interDyMFoam/ras/damBreakWithObstacle/log.interDyMFoam
gives warning:
```
--> FOAM Warning :
From function Foam::autoPtr<Foam::mapPolyMesh> F.../home/alex2/prashant/OpenFOAM/OpenFOAM-dev-OpenCFD.develop-16Dec/tutorials/multiphase/interDyMFoam/ras/damBreakWithObstacle/log.interDyMFoam
gives warning:
```
--> FOAM Warning :
From function Foam::autoPtr<Foam::mapPolyMesh> Foam::dynamicRefineFvMesh::unrefine(const labelList&)
in file dynamicRefineFvMesh/dynamicRefineFvMesh.C at line 550
Cannot find surfaceScalarField alphaPhi in user-provided flux mapping table
4
(
phi none
rhoPhi none
nHatf none
ghf none
)
```
@Mattijs
Functionality migration from internal development lineSergio FerrarisSergio Ferrarishttps://develop.openfoam.com/Development/openfoam/-/issues/1Lagrangian standard patch interaction model errors2023-08-19T21:13:18ZAdminLagrangian standard patch interaction model errorsReported statistics are incorrect
* Counters of number and mass of particles continuously reset on output
* Mass escape/stick not calculatedReported statistics are incorrect
* Counters of number and mass of particles continuously reset on output
* Mass escape/stick not calculatedFunctionality migration from internal development lineAdminAdminhttps://develop.openfoam.com/Development/openfoam/-/issues/40BUG: execFlowFunctionObjects with -noRead2015-12-18T09:09:33ZPrashant SonakarBUG: execFlowFunctionObjects with -noReadMissing argument -noRead
@Mattijs @Sergio Missing argument -noRead
@Mattijs @Sergio 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/27BUG: fvOptions - velocityDamping2015-12-15T11:23:03ZPrashant SonakarBUG: fvOptions - velocityDampingThe damping is not applied on cells.
Also, selectionMode is not taken into account!
[pitzDaily.tgz](/uploads/281e79b4bf1f31cdbadc838ec18dcaec/pitzDaily.tgz)
run simpleFoam in dev and dev-OpenCFD version to see the difference.
@...The damping is not applied on cells.
Also, selectionMode is not taken into account!
[pitzDaily.tgz](/uploads/281e79b4bf1f31cdbadc838ec18dcaec/pitzDaily.tgz)
run simpleFoam in dev and dev-OpenCFD version to see the difference.
@Mattijs @Koushik 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/5redistributePar fails2023-08-19T21:13:19ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comredistributePar failsmpirun -np 4 redistributePar -parallel -reconstruct -time 7
- undecomposed mesh is starting blockMesh
- mesh generated in parallel
- time 7 is the mesh at some step in snappyHexMesh
```
Time = 7
Reading undecomposed mesh (on ...mpirun -np 4 redistributePar -parallel -reconstruct -time 7
- undecomposed mesh is starting blockMesh
- mesh generated in parallel
- time 7 is the mesh at some step in snappyHexMesh
```
Time = 7
Reading undecomposed mesh (on master)
Reading local, decomposed mesh
Boundary definition OK.
Reading addressing from procXXXAddressing at "7"
[1] #0 Foam::error::printStack(Foam::Ostream&)[2] #0 Foam::error::printStack(Foam::Ostream&)[3] #0 Foam::error::printStack(Foam::Ostream&) at ??:?
[1] #1 Foam::sigSegv::sigHandler(int, siginfo_t*, void*) at ??:?
[3] #1 Foam::sigSegv::sigHandler(int, siginfo_t*, void*) at ??:?
[2] #1 Foam::sigSegv::sigHandler(int, siginfo_t*, void*) at ??:?
```Functionality migration from internal development linehttps://develop.openfoam.com/Development/openfoam/-/issues/232metisDecomp compile error2019-12-09T22:04:12ZAdminmetisDecomp compile errorWhen compiling OpenFOAM v1606, the following compilation error appears:
`metisDecomp.C:211:9: error: cannot convert ‘Foam::UList<float>::iterator {aka float*}’ to ‘real_t* {aka double*}’ for argument ‘9’ to ‘int METIS_PartGraphRecursi...When compiling OpenFOAM v1606, the following compilation error appears:
`metisDecomp.C:211:9: error: cannot convert ‘Foam::UList<float>::iterator {aka float*}’ to ‘real_t* {aka double*}’ for argument ‘9’ to ‘int METIS_PartGraphRecursive(idx_t*, idx_t*, idx_t*, idx_t*, idx_t*, idx_t*, idx_t*, idx_t*, real_t*, real_t*, idx_t*, idx_t*, idx_t*)’`
`metisDecomp.C:230:9: error: cannot convert ‘Foam::UList<float>::iterator {aka float*}’ to ‘real_t* {aka double*}’ for argument ‘9’ to ‘int METIS_PartGraphKway(idx_t*, idx_t*, idx_t*, idx_t*, idx_t*, idx_t*, idx_t*, idx_t*, real_t*, real_t*, idx_t*, idx_t*, idx_t*)’`
It seems that `REALTYPEWIDTH 64` in metis.h should correspond to `Field<scalar> processorWeights` in metisDecomp.C, while `REALTYPEWIDTH 32` corresponds to `Field<floatScalar> processorWeights`. So, in order to compile metisDecomp, I changed metisDecomp.C to have `Field<scalar>` instead of `Field<floatScalar>`(see below).
`$WM_THIRD_PARTY_DIR/platforms/linux64Gcc/metis-5.1.0/include/metis.h`
`#define REALTYPEWIDTH 64`
`$WM_PROJECT_DIR/src/parallel/decompose/metisDecomp/metisDecomp.C`
`Field<scalar> processorWeights`
For reference: this problem appears to be related to the bug report on the OpenFOAM fork's website: http://bugs.openfoam.org/view.php?id=2085.Version v1612Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/290inconsistency in scotch, metis library locations2017-01-02T12:24:10ZMark OLESENinconsistency in scotch, metis library locationsScotch and metis libraries are being installed under FOAM_EXT_LIBBIN, not under their respective XX_ARCH_PATH/lib.
If there are copies in the XX_ARCH_PATH/lib, they will not be available in the LD_LIBRARY_PATH anyhow and thus is confusi...Scotch and metis libraries are being installed under FOAM_EXT_LIBBIN, not under their respective XX_ARCH_PATH/lib.
If there are copies in the XX_ARCH_PATH/lib, they will not be available in the LD_LIBRARY_PATH anyhow and thus is confusing (wrong) to have them as LIB_LIB.Version v1612Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/167Ensight surface writer does not write fields2016-08-09T09:07:09ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comEnsight surface writer does not write fields[controlDict](/uploads/e630334b702cd7862e986783a5cc2f2e/controlDict)
I'm running cavity with attached controlDict. It writes Ensight files to postProcessing/ but these are not referenced in the .case file so never loaded. (I think)
[controlDict](/uploads/e630334b702cd7862e986783a5cc2f2e/controlDict)
I'm running cavity with attached controlDict. It writes Ensight files to postProcessing/ but these are not referenced in the .case file so never loaded. (I think)
Version v1612Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/272Need base64 encoding layer for vtk xml formats.2017-01-02T12:24:52ZMark OLESENNeed base64 encoding layer for vtk xml formats.Need to move to XML-based formats in order to properly support 64-bit labels (see issue #270).Need to move to XML-based formats in order to properly support 64-bit labels (see issue #270).Version v1612Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/234CGAL wmake sets incorrect paths to MPFR and GMP2019-12-09T22:04:12ZMark OLESENCGAL wmake sets incorrect paths to MPFR and GMPFiled by @sergiykhan - re-located from ThirdParty (https://develop.openfoam.com/Development/ThirdParty-plus/issues/4)
When compiling OpenFOAM v1606, the ./makeGcc script gets the MPFR and GMP libraries placed in the lib64 sub-directory,...Filed by @sergiykhan - re-located from ThirdParty (https://develop.openfoam.com/Development/ThirdParty-plus/issues/4)
When compiling OpenFOAM v1606, the ./makeGcc script gets the MPFR and GMP libraries placed in the lib64 sub-directory, while `$WM_PROJECT_DIR/wmake/rules/CGAL` sets paths explicitly to lib.Version v1612Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/240Improvements to foamToEnsight*2021-01-27T10:52:08ZMark OLESENImprovements to foamToEnsight*During testing of issue #231 noticed that startup/conversion time (per step) to be dependent on the number of times-steps converted (foamToEnsight).
The per step conversion time for foamToEnsightParts is constant.
In serial, the writing ...During testing of issue #231 noticed that startup/conversion time (per step) to be dependent on the number of times-steps converted (foamToEnsight).
The per step conversion time for foamToEnsightParts is constant.
In serial, the writing times for foamToEnsight are generally much slower than foamToEnsightParts.
No comparison in parallel, since foamToEnsightParts is not yet parallelized.Version v1612Mark OLESENMark OLESEN2016-10-14https://develop.openfoam.com/Development/openfoam/-/issues/189polyMesh::findCell uses tree only for nearest; should use findInside directly2020-01-06T09:39:08ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.compolyMesh::findCell uses tree only for nearest; should use findInside directlyThe underlying treeDataCell does:
return mesh_.pointInCell(sample, cellLabels_[index], decompMode_);
which is exactly the test that polyMesh::findCell does on the nearest and its neighbours.The underlying treeDataCell does:
return mesh_.pointInCell(sample, cellLabels_[index], decompMode_);
which is exactly the test that polyMesh::findCell does on the nearest and its neighbours.Version v1612https://develop.openfoam.com/Development/openfoam/-/issues/282Allow specific restart time for field averaging.2017-01-02T12:24:43ZMark OLESENAllow specific restart time for field averaging.Can currently have a periodic restart, but for simulations with a known run-up, it can be useful to have a specific time to restart the averaging.Can currently have a periodic restart, but for simulations with a known run-up, it can be useful to have a specific time to restart the averaging.Version v1612Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/266Unify surface area/normal calculations2017-01-02T12:22:12ZMark OLESENUnify surface area/normal calculationsNeed face areas and normals for meshed surfaces in several places. It makes sense to relocate this frequently needed functionality to PrimitivePatch. PolyPatch continues to use a slice field for efficiency on poly meshes.Need face areas and normals for meshed surfaces in several places. It makes sense to relocate this frequently needed functionality to PrimitivePatch. PolyPatch continues to use a slice field for efficiency on poly meshes.Version v1612Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/309Avoid constant/polyMesh/blockMeshDict2018-06-22T12:28:54ZMark OLESENAvoid constant/polyMesh/blockMeshDictFinally possible to use `system/blockMeshDict`. Avoid using `constant/polyMesh/blockMeshDict` since it may now get cleaned out accidentally.Finally possible to use `system/blockMeshDict`. Avoid using `constant/polyMesh/blockMeshDict` since it may now get cleaned out accidentally.Version v1612Mark OLESENMark OLESEN