Development issueshttps://develop.openfoam.com/groups/Development/-/issues2020-03-13T13:44:25Zhttps://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 Ghildiyalhttps://develop.openfoam.com/Development/openfoam/-/issues/974fileHandler in combination with threading2020-01-08T14:47:22ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comfileHandler in combination with threadingWhen using a threaded fileHandler (e.g. collated) the code does not know to wait for a file being written before trying to read it. This happens e.g. in topoSet (reading a set that has just been written), decomposePar (reading the decomp...When using a threaded fileHandler (e.g. collated) the code does not know to wait for a file being written before trying to read it. This happens e.g. in topoSet (reading a set that has just been written), decomposePar (reading the decomposed mesh to decompose the fields)
Solutions:
- switch off threading altogether. This is what is currently done.
- have IFstream know about currently written files. This would require all IFstream to go through the fileHandler, so use fileHandler().NewIFstream instead of IFstream everywhere.
- since it is only a few applications that have this make sure to reset the fileHandler.
This last solution has been implemented by a new 'flush()' method on all fileHandlers which clears out any cached data (e.g. time directories) and waits for all file operations to finish.Mattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comhttps://develop.openfoam.com/Development/openfoam/-/issues/730blockMesh with multi-surface edges unstable2020-01-03T12:05:03ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comblockMesh with multi-surface edges unstableThe underlying algorithm for the iterative surface-intersection in blockMesh does not handle two co-planar surfaces. The intersection line is at infinite which crashes the code.The underlying algorithm for the iterative surface-intersection in blockMesh does not handle two co-planar surfaces. The intersection line is at infinite which crashes the code.Mattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comhttps://develop.openfoam.com/Development/openfoam/-/issues/409Old changeDictionaryDict format in externalSolarLoad tutorial2020-08-31T13:08:28ZAdminOld changeDictionaryDict format in externalSolarLoad tutorialIn tutorial heatTransfer/chtMultiRegionFoam/externalSolarLoad, changeDictionaryDicts are written in the old format. No need of dictionaryReplacement sub-dict after commit 685afaafbf8ce9fe0d43bb7b6d40eb712531b617 "changeDictionary: Simpl...In tutorial heatTransfer/chtMultiRegionFoam/externalSolarLoad, changeDictionaryDicts are written in the old format. No need of dictionaryReplacement sub-dict after commit 685afaafbf8ce9fe0d43bb7b6d40eb712531b617 "changeDictionary: Simplified by removing the need for the superfluous dictionaryReplacement sub-dictionary."https://develop.openfoam.com/Development/openfoam/-/issues/1268avoid use of gatherList (e.g. fvMeshDistribute)2019-11-08T07:11:42ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comavoid use of gatherList (e.g. fvMeshDistribute)### Functionality to add/problem to solve
Currently in the code it sometimes uses a gatherList to collect data from other processors. This becomes expensive for large numbers of processors.
### Proposal
Replace with an allToAll type ...### Functionality to add/problem to solve
Currently in the code it sometimes uses a gatherList to collect data from other processors. This becomes expensive for large numbers of processors.
### Proposal
Replace with an allToAll type wrapper.https://develop.openfoam.com/Development/openfoam/-/issues/645-decomposeParDict invokes MPI2017-12-18T23:12:32ZMark OLESEN-decomposeParDict invokes MPIIt looks like "decomposeParDict" should not really be part of [validParOptions](https://develop.openfoam.com/Development/OpenFOAM-plus/blob/develop/src/OpenFOAM/global/argList/argList.C#L84) since this triggers detection as a [parallel r...It looks like "decomposeParDict" should not really be part of [validParOptions](https://develop.openfoam.com/Development/OpenFOAM-plus/blob/develop/src/OpenFOAM/global/argList/argList.C#L84) since this triggers detection as a [parallel run](https://develop.openfoam.com/Development/OpenFOAM-plus/blob/develop/src/OpenFOAM/global/argList/argList.C#L610)
@andyv1712Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/764addProfiling has overhead even if not active2023-12-07T19:03:28ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comaddProfiling has overhead even if not activeaddProfiling calls clockTime even if not active. The profilingTrigger does two thing:
- construct clockTime. This calls the low-level time function.
- optionally return/construct a profilingInformation. This is protected from doing anyth...addProfiling calls clockTime even if not active. The profilingTrigger does two thing:
- construct clockTime. This calls the low-level time function.
- optionally return/construct a profilingInformation. This is protected from doing anything expensive unless it is active().
The addProfiling macro should really check for profiling::active().Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/732meshStructure returns indices into local addressing2018-07-02T09:37:46ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.commeshStructure returns indices into local addressingmeshStructure returns a cellToPatchFaceAddressing() which are indices into local addressing so will not be correct.meshStructure returns a cellToPatchFaceAddressing() which are indices into local addressing so will not be correct.https://develop.openfoam.com/Development/openfoam/-/issues/265BUG: snappyHexMesh doesn't fully respect the -decomposeParDict option2019-12-09T22:04:15ZAdminBUG: snappyHexMesh doesn't fully respect the -decomposeParDict optionsnappyHexMesh doesn't fully respect the -decomposeParDict option. Crashes half way through when it starts looking for system/decomposeParDict. Looks like it occurs right after the castellation phase. In addition, the -decomposeParDict op...snappyHexMesh doesn't fully respect the -decomposeParDict option. Crashes half way through when it starts looking for system/decomposeParDict. Looks like it occurs right after the castellation phase. In addition, the -decomposeParDict option on snappyHexMesh doesn't appear to like relative paths (this works with other utilities though).
This is the command I used to run...
mpirun -np 4 snappyHexMesh -overwrite -decomposeParDict /home/graupjj/OpenFOAM/graupjj-plus/run/of/system/decomposeParDict1 -profiling -parallel
This is the error I got...
Doing final balancing
Found 0 zoned faces to keep together.
Found 0 separated coupled faces to keep together.
[0]
[0]
[0] --> FOAM FATAL IO ERROR:
[0] cannot find file
[0]
[0] file: /home/graupjj/OpenFOAM/graupjj-plus/run/of/processor0/system/decomposeParDict at line 0.
[0]
[0] From function regIOobject::readStream()
[0] in file db/regIOobject/regIOobjectRead.C at line 237.
[0]
FOAM parallel run exiting
Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/344renumberMesh twice in the same workflow2018-05-29T05:39:49ZvilfayeaurenumberMesh twice in the same workflowHi,
In some situation, you have to run renumberMesh twice in the same workflow. For example, if you run a coarse case, map to a fine mesh and run it.
This leads to a error message:
Reading volScalarField cellID
[3]
[3]
[3] --> FOAM ...Hi,
In some situation, you have to run renumberMesh twice in the same workflow. For example, if you run a coarse case, map to a fine mesh and run it.
This leads to a error message:
Reading volScalarField cellID
[3]
[3]
[3] --> FOAM FATAL IO ERROR:
[3] size 58624 is not equal to the given value of 58185
[3]
[3] file: /home/a45bwpq/OpenFOAM/1606+/a45bwpq-16.06plus/tutorials/incompressible/simpleFoam/motorBike/processor3/constant/cellID from line 18 to line 58953.
[3]
[3] From function Foam::Field<Type>::Field(const Foam::word&, const Foam::dictionary&, Foam::label) [with Type = double; Foam::label = int]
[3] in file /appl/openfoam/16.06plus/OpenFOAM-16.06plus/src/OpenFOAM/lnInclude/Field.C at line 295.
[3]
FOAM parallel run exiting
motorBike test case is attached to reproduce the error.
Best,
Sebastien
[motorBike.tgz](/uploads/67b76ae6ecde6bb5fb8a3fa1179fdc9d/motorBike.tgz)https://develop.openfoam.com/Development/openfoam/-/issues/126oscillatingACMI tutorial reports open cells2016-06-16T13:17:44ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comoscillatingACMI tutorial reports open cellsThis is solved by commit 90ba6113b597880dd3200bd37284627302bf9cc7 from OpenFOAM-dev
This is solved by commit 90ba6113b597880dd3200bd37284627302bf9cc7 from OpenFOAM-dev