Development issueshttps://develop.openfoam.com/groups/Development/-/issues2018-05-01T08:50:52Zhttps://develop.openfoam.com/Development/openfoam/-/issues/496Lagrangian case injector bug2018-05-01T08:50:52ZAdminLagrangian case injector bugI am performing a lagrangian simulation with sprayFoam solver on OpenFOAM-v1612+. I am writting you down to report a bug that I have noticed when initializing a buzzard with coneNozzleInjection option. If the injection method is a disc a...I am performing a lagrangian simulation with sprayFoam solver on OpenFOAM-v1612+. I am writting you down to report a bug that I have noticed when initializing a buzzard with coneNozzleInjection option. If the injection method is a disc and particles size is constant, particles injection is no longer done on a surface but a line from the innerDiameter to the outerDiameter.
I have work around with it and the bug only appears when running the simulation in parallel with metis decomposition. I tried a simple and hierarchical decomposition but the case can't run with such methods. A simple solution to avoid the problem is to use a normal distribution with a small variance.https://develop.openfoam.com/Development/openfoam/-/issues/60BUG: surfaceRedistributePar with alternate decomposeparDict argument2019-12-09T22:04:14ZPrashant SonakarBUG: surfaceRedistributePar with alternate decomposeparDict argumentFrom @Roger
It seems the application surfaceRedistributePar ignores any
decomposeParDict other than the standard system/decomposeParDict.
@andy From @Roger
It seems the application surfaceRedistributePar ignores any
decomposeParDict other than the standard system/decomposeParDict.
@andy Mattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comhttps://develop.openfoam.com/Development/openfoam/-/issues/51BUG: Failure in SHM2016-01-08T12:41:03ZPrashant SonakarBUG: Failure in SHMTutorial case $FOAM_TUTORIALS/mesh/snappyHexMesh/gap_detection fails with
[snappyHexMeshDict](/uploads/ce12b703b0f1e681378c6aaa2f3d16e7/snappyHexMeshDict)
Also, is it compulsory to use atleast one volume refinement with (gapLevel+ ...Tutorial case $FOAM_TUTORIALS/mesh/snappyHexMesh/gap_detection fails with
[snappyHexMeshDict](/uploads/ce12b703b0f1e681378c6aaa2f3d16e7/snappyHexMeshDict)
Also, is it compulsory to use atleast one volume refinement with (gapLevel+ gapMode) to activate such refinement for surfaces section?
[case1.tgz](/uploads/856b472ce41a8ec69c8d6162b654d537/case1.tgz)
- Switching on/off lines 73-80 illustrates different behaviour.
@andy
Mattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comhttps://develop.openfoam.com/Development/openfoam/-/issues/761(Possible) BUG: foamToVTK - FOAM FATAL ERROR - in channel395DFSEM of OpenFOAM...2019-12-09T22:18:10ZKutalmış Berçin(Possible) BUG: foamToVTK - FOAM FATAL ERROR - in channel395DFSEM of OpenFOAM v1712Hi,
Please consider the following MWE:
* The case is mostly based on the tutorial: `pimpleFoam/LES/channel395DFSEM`
* The minimum case set-up and complete error message can be found in the attachment: [bug.tar.gz](/uploads/c555d176a57...Hi,
Please consider the following MWE:
* The case is mostly based on the tutorial: `pimpleFoam/LES/channel395DFSEM`
* The minimum case set-up and complete error message can be found in the attachment: [bug.tar.gz](/uploads/c555d176a573193065d4e56b38e57cce/bug.tar.gz)
* Operating system: Red Hat Enterprise Linux Server release 6.3 (Santiago)
* OpenFOAM version: 1712
* nProcs: 16
Subsequent to the job completion, I successfully executed `reconstructPar -latestTime`. Then executing `foamToVTK -latestTime` returned the error below (the complete error message file is in the attachment):
> --> FOAM FATAL ERROR:
> Not implemented
>
> From function virtual Foam::label Foam::cyclicPolyPatch::neighbPatchID() const
> in file faMesh/faPatches/constraint/cyclic/cyclicFaPatch.C at line 286.
>
> FOAM aborting
>
> #0 Foam::error::printStack(Foam::Ostream&) in "/scratch/kb8e10/OpenFOAM/OpenFOAM-v1712/platforms/linux64GccDPInt32Opt/lib/libOpenFOAM.so"
> #1 Foam::error::abort() in "/scratch/kb8e10/OpenFOAM/OpenFOAM-v1712/platforms/linux64GccDPInt32Opt/lib/libOpenFOAM.so"
> #2 Foam::cyclicPolyPatch::neighbPatchID() const in "/scratch/kb8e10/OpenFOAM/OpenFOAM-v1712/platforms/linux64GccDPInt32Opt/lib/libfiniteArea.so"
> #3 Foam::cyclicPolyPatch::neighbPatch() const in "/scratch/kb8e10/OpenFOAM/OpenFOAM-v1712/platforms/linux64GccDPInt32Opt/lib/libOpenFOAM.so"
> #4 Foam::cyclicPolyPatch::calcGeometry(Foam::PstreamBuffers&) in "/scratch/kb8e10/OpenFOAM/OpenFOAM-v1712/platforms/linux64GccDPInt32Opt/lib/libOpenFOAM.so"
> #5 Foam::polyBoundaryMesh::calcGeometry() in "/scratch/kb8e10/OpenFOAM/OpenFOAM-v1712/platforms/linux64GccDPInt32Opt/lib/libOpenFOAM.so"
> #6 Foam::polyMesh::polyMesh(Foam::IOobject const&) in "/scratch/kb8e10/OpenFOAM/OpenFOAM-v1712/platforms/linux64GccDPInt32Opt/lib/libOpenFOAM.so"
> #7 Foam::fvMesh::fvMesh(Foam::IOobject const&) in "/scratch/kb8e10/OpenFOAM/OpenFOAM-v1712/platforms/linux64GccDPInt32Opt/lib/libfiniteVolume.so"
> #8 ? in "/scratch/kb8e10/OpenFOAM/OpenFOAM-v1712/platforms/linux64GccDPInt32Opt/bin/foamToVTK"
> #9 __libc_start_main in "/lib64/libc.so.6"
> #10 ? in "/scratch/kb8e10/OpenFOAM/OpenFOAM-v1712/platforms/linux64GccDPInt32Opt/bin/foamToVTK"
> Aborted (core dumped)
When I executed the same command `foamToVTK -latestTime` with **OF1706** onto the same case, the error disappeared (I attached its response into the tar.gz as well).
I can also provide further information that you think necessary.
Kind regardshttps://develop.openfoam.com/Development/openfoam/-/issues/1058uniformFixedValue bc cannot be used in second order cases (restart)2018-12-24T09:00:22ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comuniformFixedValue bc cannot be used in second order cases (restart)@Development
uniformFixedValue bc
- never reads the 'value' field
- never maps the value
and instead re-evaluates the Function1. This is wrong for old-time fields ('_0'). Try e.g. compressible/rhoPimpleFoam/laminar/sineWaveDamping with...@Development
uniformFixedValue bc
- never reads the 'value' field
- never maps the value
and instead re-evaluates the Function1. This is wrong for old-time fields ('_0'). Try e.g. compressible/rhoPimpleFoam/laminar/sineWaveDamping with for 0/p
```
type uniformFixedValue; // oscillatingFixedValue;
uniformValue table ((0 100000)(1 200000));
```
run for a bit and then decompose a time with p_0.https://develop.openfoam.com/Development/openfoam/-/issues/882static initialisation order in simplifiedDynamicFvMeshes2018-06-20T07:24:03ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comstatic initialisation order in simplifiedDynamicFvMeshesOn some older linkers the debug symbol was referring to a not-yet initialised typeName (is a word):
```
const word simplified##Type::typeName = Type::typeName;
```
Instead access the const char* access function:
```
const word simplifie...On some older linkers the debug symbol was referring to a not-yet initialised typeName (is a word):
```
const word simplified##Type::typeName = Type::typeName;
```
Instead access the const char* access function:
```
const word simplified##Type::typeName(Type::typeName_());
```Mattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comhttps://develop.openfoam.com/Development/openfoam/-/issues/233Surface snapping problem in snappyHexMesh2019-01-08T16:51:36ZAdminSurface snapping problem in snappyHexMeshI've experienced a peculiar snapping problem when meshing a 2D airfoil profile with SHM v1606+.
The attached pictures show the surface mesh, on which some vertices have been distorted for no reason apparent to me. The detected features ...I've experienced a peculiar snapping problem when meshing a 2D airfoil profile with SHM v1606+.
The attached pictures show the surface mesh, on which some vertices have been distorted for no reason apparent to me. The detected features edges are far away (shown in white) and the underlying STL has no irregularities.
After the castellation stage, the mesh looks good - no irregularities in this region - checking the mesh at each stage confirm the problem occurs during the snapping phase, not castellation or layer addition.
In the problematic run, explicit feature edge capturing was set to on, implicit off. Switching all feature edge snapping off, the problem no longer occurs. Using implicit feature capturing, the problem also does not occur.
I tried changing the number of parallel processes and the problem went away again.
So this would seem to indicate that the problem is related to explicit feature edge snapping and is sensitive to the domain decomposition.
I hope this helps to localise the problem. I have a workaround (change number of parallel processes), so the urgency for this particular case is now relaxed.
Thanks and best regards,
Charlie.
![surfGridProblem_STL](/uploads/d4080079a52f8b59fe93bc80af61a1a6/surfGridProblem_STL.png)![surfGridProblem_surfaceMeshAndFeatureEdges](/uploads/4bd988a4a07c02efaebf0937ae6cc3da/surfGridProblem_surfaceMeshAndFeatureEdges.png)https://develop.openfoam.com/Development/openfoam/-/issues/934Wrong sign in documentation of p_rgh2018-07-13T10:22:40ZAdminWrong sign in documentation of p_rghIn the documentation of the "p_rgh" the sign is wrong in some of the equations. All terms in the equations below the sentence "After the following substititions" should be negative in https://www.openfoam.com/documentation/cpp-guide/html...In the documentation of the "p_rgh" the sign is wrong in some of the equations. All terms in the equations below the sentence "After the following substititions" should be negative in https://www.openfoam.com/documentation/cpp-guide/html/guide-applications-solvers-variable-transform-p-rgh.html
In the second to last equation, the last term g*h*grad(rho) should be negative too. Compare for example with this:
https://develop.openfoam.com/Development/OpenFOAM-plus/blob/master/applications/solvers/heatTransfer/buoyantSimpleFoam/UEqn.H#L28https://develop.openfoam.com/Development/openfoam/-/issues/980feature request: more descriptive error message instead of "FATAL ERROR: face...2021-07-06T13:14:58ZAdminfeature request: more descriptive error message instead of "FATAL ERROR: face ... in patch ... does not have neighbour cell face ..."I was trying to follow [this tutorial](https://openfoamwiki.net/index.php/Main_ContribExamples/AxiSymmetric) implementing an axisymmetric cylinder and piston when I got the infamous error (FYI [my blockMeshDict](https://gist.github.com/F...I was trying to follow [this tutorial](https://openfoamwiki.net/index.php/Main_ContribExamples/AxiSymmetric) implementing an axisymmetric cylinder and piston when I got the infamous error (FYI [my blockMeshDict](https://gist.github.com/Foadsf/56eed7c3b5a24aa0665909aad1576813)).
Googling the error message above returns tens, if not hundreds, of different forum posts. Although some of them can be grouped in similar categories:
* wrong order of verticies
* wrong face/patch/block definition
* patch isn't defined in the boundary file
* ...
in the end they are different and there is no way to systematically debug the problem. Usually it is suggested to use some form of visualization tool like `paraFoam -block` to check the defined geometry. however paraFoam requires Linux and for people like me who are running OpenFOAM on a headless cluster it is not available. besides it needs the generated mesh from `blockMesh` to work! Other visualization tools also have similar issues as far as a I know. Either they are not available for macOS/Windows.
It would be a great help if the error message could be more descriptive. What could be done:
1. searching the internet for all the cases who ended up with this error message
2. categorizing them in specific groups with similar solutions
3. finding a way to diagnose those mistakes programmatically
4. offering a more descriptive error message which can be used to resolve the issue.
\#\# Reattaching the author to the issue ticket: @foadsf \#\#https://develop.openfoam.com/Development/openfoam/-/issues/886compiler warnings: unused variables2018-07-02T09:34:07ZPrashant Sonakarcompiler warnings: unused variablesCan we do anything about compiler warnings of unused variables?
1) applications/solvers/DNS/dnsFoam
- readTurbulenceProperties.H:28:18: warning: unused variable 'recRootN'
2) applications/solvers/combustion/fireFoam
- createFields.H:11...Can we do anything about compiler warnings of unused variables?
1) applications/solvers/DNS/dnsFoam
- readTurbulenceProperties.H:28:18: warning: unused variable 'recRootN'
2) applications/solvers/combustion/fireFoam
- createFields.H:117:6: warning: unused variable 'solvePrimaryRegion'
- createFields.H:122:6: warning: unused variable 'solvePyrolysisRegion'
3) src/finiteVolume/cfdTools/general/include/alphaControls.H:24:8:
- warning: unused variable 'scAlpha'
4) applications/solvers/incompressible/simpleFoam/overSimpleFoam
- createOversetFields.H:27:6: warning: unused variable 'adjustFringe'
- createOversetFields.H:31:6: warning: unused variable 'massFluxInterpolation'
5) applications/solvers/incompressible/simpleFoam/porousSimpleFoam
- createPorousZones.H:2:10: warning: variable 'pressureImplicitPorosity' set but not used
6) applications/solvers/lagrangian/reactingParcelFoam
- createFields.H:106:6: warning: unused variable 'solvePrimaryRegion'
@andy @Mattijs @mark @Sergiohttps://develop.openfoam.com/Development/openfoam/-/issues/1110parallelized vtk writers running in serial block or crash2018-12-07T17:55:11ZMark OLESENparallelized vtk writers running in serial block or crashunguarded use of globalIndex - tripped by issue #1104unguarded use of globalIndex - tripped by issue #1104Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/587mirrorMesh seems to fail in parallel2017-12-19T06:29:50ZAdminmirrorMesh seems to fail in parallelThe below dummy case seems to work fine in serial (./Allrun) but when using mirrorMesh in parallel (./Allrun.parallel) on a decomposed case mirrorMesh gives a warning:
> Mirroring faces on coupled patches destroys the ordering. This mi...The below dummy case seems to work fine in serial (./Allrun) but when using mirrorMesh in parallel (./Allrun.parallel) on a decomposed case mirrorMesh gives a warning:
> Mirroring faces on coupled patches destroys the ordering. This might be fixed by running a dummy createPatch afterwards.
However, running createPatch yields
> ***Inconsistent patches across processors, processor 0 has patch names:
and then it runs forever.
If the parallel option is given I would think it should work in principal, but I have not been able to get it to work in any parallel case, so I would consider it a bug... Or is there a work around?
Thanks,
Pal
[case.tgz](/uploads/3943f1c356bef25aca1c341cdf6abb55/case.tgz)https://develop.openfoam.com/Development/openfoam/-/issues/1020is nut wall function in SRFSimpleFoam mixer tutorial actually using Urel?2019-12-09T22:22:47ZAdminis nut wall function in SRFSimpleFoam mixer tutorial actually using Urel?All,
I'm looking at SRFSimpleFoam mixer tutorial and I have o doubt about nut boundary condition.
It specifies the entry "U Urel;".
Changing it to something stupid like "U blablabla;" it still runs fine. I then changed to nutUSpaldingW...All,
I'm looking at SRFSimpleFoam mixer tutorial and I have o doubt about nut boundary condition.
It specifies the entry "U Urel;".
Changing it to something stupid like "U blablabla;" it still runs fine. I then changed to nutUSpaldingWallFunction that for sure uses the velocity field and still got the same behaviour.
I'm not a programmer expert so i'm not sure what velocity field is the nut wall function actually using.
Anyone can help please?
Best Regards
Marcohttps://develop.openfoam.com/Development/openfoam/-/issues/799Current develop branch does not compile in SP2023-12-07T19:03:31ZAdminCurrent develop branch does not compile in SPThrowing the following error:
turbulentFluidThermoModels/derivedFvPatchFields/outletMachNumberPressure/outletMachNumberPressureFvPatchScalarField.C: In member function ‘virtual void Foam::outletMachNumberPressureFvPatchScalarField::writ...Throwing the following error:
turbulentFluidThermoModels/derivedFvPatchFields/outletMachNumberPressure/outletMachNumberPressureFvPatchScalarField.C: In member function ‘virtual void Foam::outletMachNumberPressureFvPatchScalarField::write(Foam::Ostream&) const’:
turbulentFluidThermoModels/derivedFvPatchFields/outletMachNumberPressure/outletMachNumberPressureFvPatchScalarField.C:252:44: error: no matching function for call to ‘Foam::Ostream::writeEntryIfDifferent(const char [3], double, const scalar&)’
os.writeEntryIfDifferent("c1", 0.0, c1_);
^
turbulentFluidThermoModels/derivedFvPatchFields/outletMachNumberPressure/outletMachNumberPressureFvPatchScalarField.C:252:44: note: candidate is:
In file included from /scratch/OpenFOAM/OpenFOAM-plus-develop/src/OpenFOAM/lnInclude/OSstream.H:39:0,
from /scratch/OpenFOAM/OpenFOAM-plus-develop/src/OpenFOAM/lnInclude/messageStream.H:216,
from /scratch/OpenFOAM/OpenFOAM-plus-develop/src/OpenFOAM/lnInclude/error.H:51,
from /scratch/OpenFOAM/OpenFOAM-plus-develop/src/OpenFOAM/lnInclude/UListI.H:26,
from /scratch/OpenFOAM/OpenFOAM-plus-develop/src/OpenFOAM/lnInclude/UList.H:532,
from /scratch/OpenFOAM/OpenFOAM-plus-develop/src/OpenFOAM/lnInclude/List.H:43,
from /scratch/OpenFOAM/OpenFOAM-plus-develop/src/OpenFOAM/lnInclude/wordList.H:48,
from /scratch/OpenFOAM/OpenFOAM-plus-develop/src/OpenFOAM/lnInclude/patchIdentifier.H:38,
from /scratch/OpenFOAM/OpenFOAM-plus-develop/src/OpenFOAM/lnInclude/polyPatch.H:42,
from /scratch/OpenFOAM/OpenFOAM-plus-develop/src/finiteVolume/lnInclude/fvPatch.H:39,
from /scratch/OpenFOAM/OpenFOAM-plus-develop/src/finiteVolume/lnInclude/fvPatchField.H:47,
from /scratch/OpenFOAM/OpenFOAM-plus-develop/src/finiteVolume/lnInclude/fixedValueFvPatchField.H:57,
from /scratch/OpenFOAM/OpenFOAM-plus-develop/src/finiteVolume/lnInclude/fixedValueFvPatchFields.H:29,
from turbulentFluidThermoModels/derivedFvPatchFields/outletMachNumberPressure/outletMachNumberPressureFvPatchScalarField.H:133,
from turbulentFluidThermoModels/derivedFvPatchFields/outletMachNumberPressure/outletMachNumberPressureFvPatchScalarField.C:26:
/scratch/OpenFOAM/OpenFOAM-plus-develop/src/OpenFOAM/lnInclude/Ostream.H:219:22: note: template<class T> Foam::Ostream& Foam::Ostream::writeEntryIfDifferent(const Foam::word&, const T&, const T&)
Ostream& writeEntryIfDifferent
^
/scratch/OpenFOAM/OpenFOAM-plus-develop/src/OpenFOAM/lnInclude/Ostream.H:219:22: note: template argument deduction/substitution failed:
turbulentFluidThermoModels/derivedFvPatchFields/outletMachNumberPressure/outletMachNumberPressureFvPatchScalarField.C:252:44: note: deduced conflicting types for parameter ‘const T’ (‘double’ and ‘Foam::scalar {aka float}’)
os.writeEntryIfDifferent("c1", 0.0, c1_);Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/592kOmegaSSTLMCoeffs model incorrect syntax.2019-12-09T22:11:26ZvilfayeaukOmegaSSTLMCoeffs model incorrect syntax.kOmegaSSTCoeffs written instead of kOmegaSSTLMCoeffs.
extract form log file:
```
Selecting incompressible transport model Newtonian
Selecting turbulence model type RAS
Selecting RAS turbulence model kOmegaSSTLM
Selecting patchDi...kOmegaSSTCoeffs written instead of kOmegaSSTLMCoeffs.
extract form log file:
```
Selecting incompressible transport model Newtonian
Selecting turbulence model type RAS
Selecting RAS turbulence model kOmegaSSTLM
Selecting patchDistMethod meshWave
**kOmegaSSTCoeffs**
{
alphaK1 0.85;
alphaK2 1;
alphaOmega1 0.5;
alphaOmega2 0.856;
gamma1 0.55555556;
gamma2 0.44;
beta1 0.075;
beta2 0.0828;
betaStar 0.09;
a1 0.31;
b1 1;
c1 10;
F3 false;
}
https://develop.openfoam.com/Development/OpenFOAM-plus/blob/master/src/TurbulenceModels/turbulenceModels/RAS/kOmegaSSTLM/kOmegaSSTLM.H
```https://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/1009kOmegaSSTDES model converges to unphysical result2018-11-29T23:15:00ZAdminkOmegaSSTDES model converges to unphysical resultI was using kOmegaSSTDES turbulence model to run a simulation at deltaT = 0.000002. The max Courant number is less than 0.01, but the result is clearly unphysical. I then decreased deltaT to 0.000001. The result is much better but the ti...I was using kOmegaSSTDES turbulence model to run a simulation at deltaT = 0.000002. The max Courant number is less than 0.01, but the result is clearly unphysical. I then decreased deltaT to 0.000001. The result is much better but the time cost is increased. I was looking for the reason so I changed the turbulence model to dynamicKEqn with deltaT = 0.000002. the converged result is also physical. It seems that there is a problem with the kOmegaSSTDES turbulence model, which will result in unphysical result unless we limit the deltaT less than 0.000001. I am wondering if there is something wrong with my case. My case files have been attached.[SST_2D3.zip](/uploads/12dc2abc0e69c974020bc937b967a5e9/SST_2D3.zip)
There are three sets of result figures in my file. Result 1 corresponds to kOmegaSSTDES with deltaT = 0.000002, which is the unphysical result.
![result1_p](/uploads/ff4d35a491a2d9c0bec036dd3cc9bab7/result1_p.png)![result1_U](/uploads/f3f956ab0ea04268493885e6433bc6f7/result1_U.png)
Result 2 is kOmegaSSTDES with deltaT = 0.000001.
![result2_p](/uploads/06c36308d4889f291a15cad4c10b26a1/result2_p.png)![result2_U](/uploads/80ef9366e987e5bed3d1e00322d62d98/result2_U.png)
Result 3 is dynamicKEqn with deltaT = 0.000002.
![result3_p](/uploads/bed5b8837a3c4363e89bcf669dff47c6/result3_p.png)![result3_U](/uploads/07ce6fdfcc88fd582585331387cdea79/result3_U.png)
To reproduce result 1, you can use the following command
`decomposePar`
`mpirun -np 8 pimpleFoam -parallel`
`paraFoam -builtin`
To reproduce result 2, please change the deltaT in controlDict to 0.000001, then
`decomposePar -force`
`mpirun -np 8 pimpleFoam -parallel`
`paraFoam -builtin`
To reproduce result 3, please change the deltaT in controlDict to 0.000002, and change the turbulenceProperties to dynamicKEqn, then
`decomposePar -force`
`mpirun -np 8 pimpleFoam -parallel`
`paraFoam -builtin`https://develop.openfoam.com/Development/openfoam/-/issues/403kOmegaSST results change from of version 1606 to 16122018-05-29T05:39:49ZAdminkOmegaSST results change from of version 1606 to 1612[graphs.pdf](/uploads/b98ef29431b86535723730fdaf2448e4/graphs.pdf)[FlatPlateCases.zip](/uploads/c4be5fc3e08147d782fd3cb276e820de/FlatPlateCases.zip)
In the friction results is differences if it run openFOAM 1606 or 1612 when kOmegaSST m...[graphs.pdf](/uploads/b98ef29431b86535723730fdaf2448e4/graphs.pdf)[FlatPlateCases.zip](/uploads/c4be5fc3e08147d782fd3cb276e820de/FlatPlateCases.zip)
In the friction results is differences if it run openFOAM 1606 or 1612 when kOmegaSST model is used. It seems that difference related to models where y^+ in on the buffer layer i.e. at the level of 20. Difference occur when nutkWallFunction is in use. In attachment is test case. By using this case is possible repeat problem and investigate friction behaviour.AdminAdminhttps://develop.openfoam.com/Development/openfoam/-/issues/617label overflow in checkMesh2020-01-03T11:18:24ZMark OLESENlabel overflow in checkMeshIn checkMesh:
https://develop.openfoam.com/Development/OpenFOAM-plus/blob/develop/applications/utilities/mesh/manipulation/checkMesh/checkTools.C#L107
I don't see why we have `scalar(nFaces + nIntFaces)` instead of just `scalar(nFaces)...In checkMesh:
https://develop.openfoam.com/Development/OpenFOAM-plus/blob/develop/applications/utilities/mesh/manipulation/checkMesh/checkTools.C#L107
I don't see why we have `scalar(nFaces + nIntFaces)` instead of just `scalar(nFaces)`. However, it this is intended, it should probably be formulated as `(scalar(nFaces) + scalar(nIntFaces))` to avoid label overflow.
partial reference from EP#482
@PrashantMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comhttps://develop.openfoam.com/Development/openfoam/-/issues/269BUG: createExternalCoupledPatchGeometry don't find meshes in parallel run2019-12-09T22:04:14ZAdminBUG: createExternalCoupledPatchGeometry don't find meshes in parallel runThe Utility createExternalCoupledPatchGeometry is not able to run in parallel.
If one try to run it in parallel, it leads to the error: object of type N4Foam8OFstreamE is not allocated.
So the Utility is unable to load the splitted mesh.The Utility createExternalCoupledPatchGeometry is not able to run in parallel.
If one try to run it in parallel, it leads to the error: object of type N4Foam8OFstreamE is not allocated.
So the Utility is unable to load the splitted mesh.Mark OLESENMark OLESEN