Development issueshttps://develop.openfoam.com/groups/Development/-/issues2019-12-09T21:29:28Zhttps://develop.openfoam.com/Development/openfoam/-/issues/455an inconsistence of gamma in nacaAirfoil tutorial of sonicFoam2019-12-09T21:29:28ZAdminan inconsistence of gamma in nacaAirfoil tutorial of sonicFoam`// caseDir/0/p
// gamma = 1.3
...
"outlet.*"
{
type waveTransmissive;
field p;
psi thermo:psi;
gamma 1.3;
fieldInf $pressure;
lIn...`// caseDir/0/p
// gamma = 1.3
...
"outlet.*"
{
type waveTransmissive;
field p;
psi thermo:psi;
gamma 1.3;
fieldInf $pressure;
lInf 1;
value $internalField;
}
...
`
However, in the thermophysical file, gamma = 1.4 which can be calculated by molecular weight and Cp.https://develop.openfoam.com/Development/openfoam/-/issues/456BUG: clipBox when active resets the scene in runTimePostProcessing2019-12-09T21:29:29ZPrashant SonakarBUG: clipBox when active resets the scene in runTimePostProcessingTested on pisoFoam/motorBike/motorBike case with file [runtimePostProcessing2](/uploads/fe66021e8760a7e2ee012ed00eb2be8c/runtimePostProcessing2)
The image with clipBox appear to capture entire view instead of specific clipBox (also atta...Tested on pisoFoam/motorBike/motorBike case with file [runtimePostProcessing2](/uploads/fe66021e8760a7e2ee012ed00eb2be8c/runtimePostProcessing2)
The image with clipBox appear to capture entire view instead of specific clipBox (also attached for quick reference in paraview)[clipBox.stl](/uploads/ce26c86eda81134304eb45c0cd097c43/clipBox.stl)Version v1706AdminAdminhttps://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/458FixedList '<' operator using a template parameter2017-06-29T20:38:04ZMark OLESENFixedList '<' operator using a template parameterCannot use comparison of list sizes. Okay for UList, but not here.
- noticing the `operator==` method immediately above, should probably also short-circuit the first time `equal` becomes false.
This won't matter much for fixed lists t...Cannot use comparison of list sizes. Okay for UList, but not here.
- noticing the `operator==` method immediately above, should probably also short-circuit the first time `equal` becomes false.
This won't matter much for fixed lists that would generally have small sizes, but same issue in UILList.C and UList.CVersion v1706Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/459BUG: forceCoeff not working in sonicFoam -> nacaAirfoil2017-05-02T08:54:30ZPrashant SonakarBUG: forceCoeff not working in sonicFoam -> nacaAirfoilcarried forward from https://develop.openfoam.com/Community/OpenFOAM-addOns/issues/4carried forward from https://develop.openfoam.com/Community/OpenFOAM-addOns/issues/4https://develop.openfoam.com/Development/openfoam/-/issues/460odd sizing for hash tables.2017-06-29T20:38:04ZMark OLESENodd sizing for hash tables.Came across a few odd things, especially when copy/copy-constructing from other hash tables.
* HashPtrTable copy from HashPtrTable: uses default size, not related to what it is copying
* HashTable from initializer_list uses list size, n...Came across a few odd things, especially when copy/copy-constructing from other hash tables.
* HashPtrTable copy from HashPtrTable: uses default size, not related to what it is copying
* HashTable from initializer_list uses list size, not 2*list size for its table
* HashSet from HashTable uses number of keys, not the table size.Version v1706Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/462BUG: Several tutorial failures after commit 2d036ca002017-06-29T20:38:04ZAdminBUG: Several tutorial failures after commit 2d036ca00With the change in behaviour of the inverseDistanceDiffusivity (commit 2d036ca00) to use a run-time selectable wall distance, users are now required to add wall dist construction info into the fvSchemes dictionary. Also, the computed dif...With the change in behaviour of the inverseDistanceDiffusivity (commit 2d036ca00) to use a run-time selectable wall distance, users are now required to add wall dist construction info into the fvSchemes dictionary. Also, the computed diffusivity has dimensions of 1/m as opposed to dimensionless.
Tutorials:
```
heatTransfer/buoyantBoussinesqSimpleFoam/iglooWithFridges:
log.snappyHexMesh: keyword patchDist is undefined in dictionary "system/fvSchemes": fvSchemes
mesh/moveDynamicMesh/SnakeRiverCanyon:
log.moveDynamicMesh: keyword patchDist is undefined in dictionary "system/fvSchemes": fvSchemes
mesh/moveDynamicMesh/relativeMotion/box2D_moveDynamicMesh:
log.moveDynamicMesh: keyword patchDist is undefined in dictionary "system/fvSchemes": fvSchemes
multiphase/potentialFreeSurfaceDyMFoam/oscillatingBox:
log.potentialFreeSurfaceDyMFoam: keyword patchDist is undefined in dictionary "system/fvSchemes": fvSchemes
```Version v1706https://develop.openfoam.com/Development/openfoam/-/issues/463BUG: sampling with optional entry zones - issue in parallel running2017-06-29T20:38:04ZPrashant SonakarBUG: sampling with optional entry zones - issue in parallel runningAttached case (modified tutorial) where sampling plane is restricted to cell zone. [angledDuct_parallel.tgz](/uploads/e24eee115a31244cd392d2111f7f49d5/angledDuct_parallel.tgz)
- works OK if serial
- produces invalid results (vtk) in p...Attached case (modified tutorial) where sampling plane is restricted to cell zone. [angledDuct_parallel.tgz](/uploads/e24eee115a31244cd392d2111f7f49d5/angledDuct_parallel.tgz)
- works OK if serial
- produces invalid results (vtk) in parallel
@Mattijs @markVersion v1706https://develop.openfoam.com/Development/openfoam/-/issues/464failure to paraview plugin without qt support2019-12-09T21:29:29ZMark OLESENfailure to paraview plugin without qt supportIf it has paraview, it attempts to build a plugin, but fails if it cannot find the needed pq* headers.
This flags as error, but shouldn't halt compilation of OpenFOAM, since the readers are an optional component.
Nonetheless, we should a...If it has paraview, it attempts to build a plugin, but fails if it cannot find the needed pq* headers.
This flags as error, but shouldn't halt compilation of OpenFOAM, since the readers are an optional component.
Nonetheless, we should avoid this from the start.Version v1706Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/465interCondensatingEvaporatingFoam for closed domain2017-05-09T15:41:27ZAdmininterCondensatingEvaporatingFoam for closed domainHello,
The solver shows a very strange behaviour for `alpha` field for closed domain cases. Simply after running the simulation for a while the entire domain reach `alpha = 1`. Indeed closed domains pose numerical challenges but usually...Hello,
The solver shows a very strange behaviour for `alpha` field for closed domain cases. Simply after running the simulation for a while the entire domain reach `alpha = 1`. Indeed closed domains pose numerical challenges but usually the problem appears due to `p` underspecification not `alpha`. I never had a similar experience with `interFoam` in closed domain cases.
To reproduce the issue:
* use the existing tutorial for this solver, `condensatingVessel`.
* set the `top` patch to wall.
* use the same boundary conditions for all fields as the `bottom` patch.
* add reference value for pressure in `pimple` subDict.
Note: I am using OpenFOAM-plus updated to commit e6cbe0b11923b2fe3ef24068af8da282db1c0978 to make sure I didn't miss any bug fix.
Thanks for your support, please let me know if further testes are required.
Best wishes,
Hassanhttps://develop.openfoam.com/Development/openfoam/-/issues/466mesh quality visualisation2017-06-29T20:38:04ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.commesh quality visualisationTicket to output mesh quality parameters using checkMesh.Ticket to output mesh quality parameters using checkMesh.Version v1706Mattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comhttps://develop.openfoam.com/Development/openfoam/-/issues/467Feature: histogram FO2017-06-29T20:38:04ZPrashant SonakarFeature: histogram FOenhancements ref : EP#384enhancements ref : EP#384Version v1706Prashant SonakarPrashant Sonakarhttps://develop.openfoam.com/Development/openfoam/-/issues/469DTCHull fails on various number of domains in parallel2018-07-03T10:43:06ZMatej FormanDTCHull fails on various number of domains in parallel$FOAM_TUTORIALS/multiphase/interDyMFoam/ras/DTCHull run on centOS (vanilla 1612+ compiled with all default options).
runs fine on 16 and 32 CPUs
fails on 4 and 8 CPUs.
case on 4CPUs on k growing out of bounds:
[log_interDyMFoam_4](/u...$FOAM_TUTORIALS/multiphase/interDyMFoam/ras/DTCHull run on centOS (vanilla 1612+ compiled with all default options).
runs fine on 16 and 32 CPUs
fails on 4 and 8 CPUs.
case on 4CPUs on k growing out of bounds:
[log_interDyMFoam_4](/uploads/f6e2af364a76f0f11ab862f95e658e77/log_interDyMFoam_4)
case on 8 CPUs suddenly with SigSev on pressure equation.
[log_interDyMFoam_8](/uploads/49d6b19325216b4a30686d11081d8952/log_interDyMFoam_8)
See logs attached.Prashant SonakarPrashant Sonakarhttps://develop.openfoam.com/Development/openfoam/-/issues/470surfaceMeshTriangulate does not handle - time selection - moving meshes2017-06-29T20:38:04ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comsurfaceMeshTriangulate does not handle - time selection - moving meshesVersion v1706Mattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comhttps://develop.openfoam.com/Development/openfoam/-/issues/471Dynamic (Adaptive) Mesh Refinement after using extrudeMesh2017-12-07T09:09:47ZAdminDynamic (Adaptive) Mesh Refinement after using extrudeMeshDear Foamers and esi-team,
adaptive/ dynamic meshing presented e.g. here
http://www.openfoam.com/version-v1606+/meshing.php
is a fantastic utility - thanks a lot!
The problem is that it does not work after 'extrudeMesh' was used: All ...Dear Foamers and esi-team,
adaptive/ dynamic meshing presented e.g. here
http://www.openfoam.com/version-v1606+/meshing.php
is a fantastic utility - thanks a lot!
The problem is that it does not work after 'extrudeMesh' was used: All cells containing hanging nodes (cells between two different cell levels) will become protected ('protectedCells') from refinement.
Here
https://www.cfd-online.com/Forums/openfoam-meshing/115246-extrudemesh.html#post647491
you can find more detailed information on the problem and a minimal-working-example which illustrates the problem.
The minimal-working-example is based on the motorBike tutorial case for the 'interDyMFoam' solver.
**Question: Is it possible to change the 'extrudeMesh' utility so that the characteristics of the mesh which guarantee dynamic refinement can be preserved?**
Therefore, the cell/pointLevel fields need to be kept in some way and maybe the switch 'mergePatchFaces' from the snappyHexMeshDict file needs to be adapted for the use in extrudeMeshDict.
Best Regards,
Dag Federhttps://develop.openfoam.com/Development/openfoam/-/issues/472about the implementations of mass transfer induced momentum transfer in react...2019-01-08T14:43:16ZAdminabout the implementations of mass transfer induced momentum transfer in reactingEulerFoamHello,
I am trying to understand the Openfoam 3.0.1 implementations of momentum transfer caused by the mass transfer. The source file is:
HeatAndMassTransferPhaseSystem.C and HeatAndMassTransferPhaseSystem.H.
There are following lines...Hello,
I am trying to understand the Openfoam 3.0.1 implementations of momentum transfer caused by the mass transfer. The source file is:
HeatAndMassTransferPhaseSystem.C and HeatAndMassTransferPhaseSystem.H.
There are following lines in the function Foam::HeatAndMassTransferPhaseSystem<BasePhaseSystem>::momentumTransfer() const:
` const volScalarField dmdt(this->dmdt(pair));
const volScalarField dmdt21(posPart(dmdt));
const volScalarField dmdt12(negPart(dmdt));
*eqns[pair.phase1().name()] += dmdt21*U2 - fvm::Sp(dmdt21, U1); // gas
*eqns[pair.phase2().name()] -= dmdt12*U1 - fvm::Sp(dmdt12, U2); // coal
`
In my case, it is pulverized coal combustion. So coal particle (phase 2 here, dispersed phase) is dispersed in the flow (phase 1 here, continuous phase). I have the questions about the source terms for the momentum equations for phases 1 and 2.
I think mathematically, the source term for phase 1 (gas phase) can be written as: dmdt21*U21 - dmdt12*U12. For phase 2(coal phase ), it is dmdt12*U12 - dmdt21*U21. The sum of them is zero.
So now let us look at the the implementation in OpenFOAM 3.0.1 and the codes are given above. So dmdt21 is positive, while dmdt 12 is always negative. Here I think dmdt21 means that the mass is from phase 2 (coal particle) to phase 1 (gas phase). dmdt12 means that the mass is from phase 1 (gas phase) to phase 2 (coal particle phase). Why not write the 4th and 5th lines of the above codes in the following way?
`
*eqns[pair.phase1().name()] += dmdt21*U2 - fvm::Sp(dmdt12, U1); // gas
*eqns[pair.phase2().name()] -= dmdt12*U1 - fvm::Sp(dmdt21, U2); // coal
`
I am confused about this issue. Can you give me some explanations about it? Please help to point out if I am making some mistakes about the above understanding. Thanks.
NB: physically, the net mass transfer is always from coal particle to gas phase, through devolatilization and char combustion processes.
best regards,
huangweihttps://develop.openfoam.com/Development/openfoam/-/issues/473foamToEnsight fails with missing field at time 02019-12-09T22:04:15ZMark OLESENfoamToEnsight fails with missing field at time 0Version v1706Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/474STYLE: Fix indent in boundary files after createBafflesDict execution2017-05-24T11:51:15ZPrashant SonakarSTYLE: Fix indent in boundary files after createBafflesDict executionRefer tutorial: $FOAM_TUTORIALS/incompressible/pimpleDyMFoam/oscillatingInletACMI2D
The boundary file looks like
```
ACMI1_couple
{
type cyclicACMI;
inGroups
2
(
cyclicACMI
ACMI1
)
;
nFaces ...Refer tutorial: $FOAM_TUTORIALS/incompressible/pimpleDyMFoam/oscillatingInletACMI2D
The boundary file looks like
```
ACMI1_couple
{
type cyclicACMI;
inGroups
2
(
cyclicACMI
ACMI1
)
;
nFaces 40;
startFace 43680;
matchTolerance 0.0001;
transform noOrdering;
neighbourPatch ACMI2_couple;
nonOverlapPatch ACMI1_blockage;
}
```
inGroups have incorrect indentation.
@markVersion v1706Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/475Where are the mass transfer source terms in phase fraction equation in reacti...2019-01-08T14:44:40ZAdminWhere are the mass transfer source terms in phase fraction equation in reactingEulerFoam solver?In reactingEulerFoam from OF3.0.1, there are mass transfer between different phases. The phase fraction is estentially the continuity equations, and so there must be some source terms accounting for mass change of individual phases. In f...In reactingEulerFoam from OF3.0.1, there are mass transfer between different phases. The phase fraction is estentially the continuity equations, and so there must be some source terms accounting for mass change of individual phases. In fluid.solve(), actually I did not see these terms appearring in the RHS of the phase fraction equations. Is this a bug? or I dismiss something in the code?
BTW, the fluid.solve(); is from:
> twoPhaseSystem/twoPhaseSystem.C
Thank you.https://develop.openfoam.com/Development/openfoam/-/issues/476Absorptivity in constant/boundaryRadiationProperties (e.g. hotRadiationRoom)2017-05-18T16:12:16ZAdminAbsorptivity in constant/boundaryRadiationProperties (e.g. hotRadiationRoom)I guess the absorptivity in constant/boundaryRadiationProperties not to be used in this case.
I invalidated it and then executed this case, but no problems occurred.
Is this parameter really necessary to execute this case?
--
...I guess the absorptivity in constant/boundaryRadiationProperties not to be used in this case.
I invalidated it and then executed this case, but no problems occurred.
Is this parameter really necessary to execute this case?
--
Build: plus- e 6 c b e 0 b 1 1 9 2 3, v1606+