Development issueshttps://develop.openfoam.com/groups/Development/-/issues2019-12-09T22:18:10Zhttps://develop.openfoam.com/Development/openfoam/-/issues/742simpleCoalParcelFoam - incorrect dimensions for Qdot2019-12-09T22:18:10ZAdminsimpleCoalParcelFoam - incorrect dimensions for QdotAdding on behalf of M. Richter:
I get a dimension error while running the simpleCoalParcelFoam solver. I think all my dimensions in the 0-folder are correct so I had a look at the source code. I found the line dimEnergy/dimTime for Q...Adding on behalf of M. Richter:
I get a dimension error while running the simpleCoalParcelFoam solver. I think all my dimensions in the 0-folder are correct so I had a look at the source code. I found the line dimEnergy/dimTime for Qdot in the createFields.H file. The other lagrangian solvers use instead dimEnergy/dimVolume/dimTime . When I correct this line and compile the code the solver ist running. Is this an error in the source code or do I have a wrong setup?v1806AdminAdminhttps://develop.openfoam.com/Development/openfoam/-/issues/743Turbulence models for DPMFoam (Realizable K-epsilon model does not work)2023-12-07T19:03:27ZAdminTurbulence models for DPMFoam (Realizable K-epsilon model does not work)When running DPMFoam cases, there is not much choice in turbulence models. I have added some myself to the 'DPMTurbulenceModels'. However, an inexperienced user would think that there is only 1 turbulence model compatible with DPMFoam. C...When running DPMFoam cases, there is not much choice in turbulence models. I have added some myself to the 'DPMTurbulenceModels'. However, an inexperienced user would think that there is only 1 turbulence model compatible with DPMFoam. Can you consider adding some more common turblence models for DPMFoam? I get that this would take more compiling time, so it might not be the best solution. Another option would be to mention if you try a non-existing turbulence model that you can compile some more yourself.
My second question is regarding the use of the realizable k-epsilon model. After adding this one to 'DPMTurbulenceModels' this does not work. The solver asks for the 'k' file instead of the 'k.water' file (where 'water' is my fluid phase name). To make this compatible with DPMFoam (and other sediment solvers) the line 'IOobject::groupName("epsilon", U.group()),' should be used in the IOobject instead of '"epsilon"'. The same holds for the k-IOobject. Could you make this change so it can be used in multiphase solvers?https://develop.openfoam.com/Development/openfoam/-/issues/744Building error on KAHIP2019-12-09T22:18:10ZAdminBuilding error on KAHIPI am trying to build KAHIP with makeKAHIP and got the following error:
```
/opt/HPC/Compilers/gcc/7.1.0/include/c++/7.1.0/utility:147:12: error: partial specialization of 'struct std::__is_tuple_like_impl<std::pair<_T1, _T2> >' after in...I am trying to build KAHIP with makeKAHIP and got the following error:
```
/opt/HPC/Compilers/gcc/7.1.0/include/c++/7.1.0/utility:147:12: error: partial specialization of 'struct std::__is_tuple_like_impl<std::pair<_T1, _T2> >' after instantiation of 'struct std::__is_tuple_like_impl<std::pair<unsigned int, unsigned int> >' [-fpermissive]
struct __is_tuple_like_impl<std::pair<_T1, _T2>> : true_type
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
In file included from /opt/HPC/Compilers/gcc/7.1.0/include/c++/7.1.0/algorithm:60:0,
from interface/../lib/partition/uncoarsening/separator/area_bfs.h:8,
from interface/kaHIP_interface.cpp:32:
/opt/HPC/Compilers/gcc/7.1.0/include/c++/7.1.0/utility:147:12: error: partial specialization of 'struct std::__is_tuple_like_impl<std::pair<_T1, _T2> >' after instantiation of 'struct std::__is_tuple_like_impl<std::pair<unsigned int, unsigned int> >' [-fpermissive]
struct __is_tuple_like_impl<std::pair<_T1, _T2>> : true_type
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
cpptoo: vertex_separator_flow_solver.cpp
```
KAHIP is pulled so latest version (commit: 10de804a5df585fe166b549c1a4f8f0e9574cb2b)
and compiled with gcc 7.1.0Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/745Sampling does not stop at 'end'2019-12-09T22:18:10ZAdminSampling does not stop at 'end'Hi,
I stumbled over a bug, namely that running with the function object 'sets', then sampling continues beyond the point 'end' in the set definition. This bug is reproducible with the damBreak case. Simply test with this function object...Hi,
I stumbled over a bug, namely that running with the function object 'sets', then sampling continues beyond the point 'end' in the set definition. This bug is reproducible with the damBreak case. Simply test with this function object (sorry for the formatting):
functions
{
testSet
{
type sets;
functionObjectLibs ("libsampling.so");
writeControl timeStep; //adjustableRunTime;
writeInterval 1;
setFormat raw;
interpolationScheme cellPointFace;
fields ( alpha.water );
sets
(
gauge_1
{
type face;
axis y;
start (0.02 0.20 0.005);
end (0.02 0.25 0.005);
nPoints 100;
}
gauge_2
{
type face;
axis y;
start (0.2 0.03 0.005);
end (0.2 0.55 0.005);
nPoints 100;
}
);
}
}
The problem is fixed by changing line 78 in faceOnlySet.C from
OLD>> if (mag(trackPt - end_) < smallDist)
to
NEW>> if (smallDist < ((trackPt - end_) & (end_ - start_)))
The old formulation only ends, if the absolute distance is less than smallDist, which will hardly ever happen. The new formulation makes a projection along the search direction and the search stops as soon as the value become larger than smallDist.
A quick check showed the same error in foam-extend-3.1, so the bug seems to have been around for a long time.
Kind regards
NielsMark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/746Possible Redundancy in Comments of the Tutorial: channel395DFSEM2019-12-09T22:18:10ZKutalmış BerçinPossible Redundancy in Comments of the Tutorial: channel395DFSEMHi,
Please consider: `tutorials/incompressible/pimpleFoam/LES/channel395DFSEM`
Therein, `0/U` has the following comment for `nu`:
```
// Re = 395, L = pi, utau = 1, nu = pi/395 = 7.9534e-3
```
Yet in `constant/transportProperties` ...Hi,
Please consider: `tutorials/incompressible/pimpleFoam/LES/channel395DFSEM`
Therein, `0/U` has the following comment for `nu`:
```
// Re = 395, L = pi, utau = 1, nu = pi/395 = 7.9534e-3
```
Yet in `constant/transportProperties` another comment for `nu` states:
```
// Re_tau = u_tau L / nu
// Re_tau = 395
// L = half channel height = 1
// Ubulk/u_tau = 17.55
// U_bulk = 17.55 -> u_tau = 1
// -> nu = 1*1/395 = 2.532e-3
```
AFAIK, the second comment reflects the generally accepted value of the half channel height for this particular plane channel flow although its value can be anything. Considering the computation uses the value of `nu = 2.532e-3`, I believe that discarding the first comment may be useful.
Kind regardshttps://develop.openfoam.com/Development/openfoam/-/issues/747Additional time control to functionObjects2021-07-06T11:50:37ZAdminAdditional time control to functionObjectsHi,
I am missing a flavour of time control in the function objects, namely an approximate output interval. For some of the applications that I am running, it is restrictive to use adjustableRunTime, because it affects the execution too ...Hi,
I am missing a flavour of time control in the function objects, namely an approximate output interval. For some of the applications that I am running, it is restrictive to use adjustableRunTime, because it affects the execution too much and the time steps become integer ratios of the output interval, however, the timeStep output provides too much data. Often, I do not care that the output time axis is non-equidistant.
I have added a new flavour which I call "approximateFixedInterval" and it simply outputs the sampling, if the time is greater than or equal to an integer times the output interval (the integer being larger than the one at the previous output time). Could the addition be adopted (perhaps with a nicer name) in the next release? The required modifications to functionObjects/timeControl/timeControl.[C,H] is attached to this report.
Thank you
Niels
P.S. I know that it is not really an issue, but it seemed to be the only way of making a request.
[timeControl.H](/uploads/c49e31d1d8fda3eb9662f68ed05132b3/timeControl.H)
[timeControl.C](/uploads/f28679a18ddd72a438b6b5c6615dfd63/timeControl.C)
\## Reattaching the author to the issue ticket: @ngj ##https://develop.openfoam.com/Development/openfoam/-/issues/748mapToSurface template substitution problem2018-03-06T10:49:12ZAdminmapToSurface template substitution problemThe finiteArea mapToSurface function won't accept boundaryField() input complaining of 'template argument deduction/substitution failed'.
`Us.internalField() = vsm.mapToSurface(U.boundaryField());`
`no matching function for call to ‘Fo...The finiteArea mapToSurface function won't accept boundaryField() input complaining of 'template argument deduction/substitution failed'.
`Us.internalField() = vsm.mapToSurface(U.boundaryField());`
`no matching function for call to ‘Foam::volSurfaceMapping::mapToSurface(const Foam::GeometricField<Foam::Vector<double>, Foam::fvPatchField, Foam::volMesh>::Boundary&)’`
`note: candidate: template<class Type> Foam::tmp<Foam::Field<Type> > Foam::volSurfaceMapping::mapToSurface(const typename Foam::GeometricField<Type, Foam::fvPatchField, Foam::volMesh>::Boundary&) const
tmp<Field<Type>> mapToSurface`https://develop.openfoam.com/Development/openfoam/-/issues/749potential memory leak with HashPtrTable2018-07-03T05:52:29ZMark OLESENpotential memory leak with HashPtrTableSince the `insert()` method is directly inherited from the underlying HashTable, there is no special treatment for any failure. Eg,
T* ptr = new ...;
table.insert(existingKey, ptr);
Since the insert failed, the ptr becomes unma...Since the `insert()` method is directly inherited from the underlying HashTable, there is no special treatment for any failure. Eg,
T* ptr = new ...;
table.insert(existingKey, ptr);
Since the insert failed, the ptr becomes unmanaged.v1806Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/750overRhoPimpleDyMFoam only with psi thermo2018-06-08T23:43:43ZMatej FormanoverRhoPimpleDyMFoam only with psi thermoThe overRhoPimpleDyMFoam solver is set only with psi thermo.
Is there any particular reason for that?
Would be great to construct fluid thermo type.The overRhoPimpleDyMFoam solver is set only with psi thermo.
Is there any particular reason for that?
Would be great to construct fluid thermo type.Sergio FerrarisSergio Ferrarishttps://develop.openfoam.com/Development/openfoam/-/issues/751cleanup packed lists2018-05-30T09:53:40ZMark OLESENcleanup packed listsVarious things affecting PackedList and PackedBoolList
- PackedBoolList is a class built on PackedList with additional features, but could be streamlined/reduces with some refactoring.
- iterator access in general is/was a questionable d...Various things affecting PackedList and PackedBoolList
- PackedBoolList is a class built on PackedList with additional features, but could be streamlined/reduces with some refactoring.
- iterator access in general is/was a questionable design feature. It is normally needed, and adds a layer of complexity. However, being able to quickly find and access the indices of bits set (for PackedBoolList) would be more useful - we otherwise spend loads of times indexing through zeroes and have numerous bit-ops on the way (losing the inherent parallelism for Bool).
- propagate into reduction operations.v1806Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/752Feature: Writing mesh quality fields under a separate directory2021-10-20T12:59:50ZKutalmış BerçinFeature: Writing mesh quality fields under a separate directoryHi,
Please consider the following command within a case directory:
`checkMesh -writeAllFields`
If `0` directory exists, `8(cellDeterminant nonOrthoAngle cellVolumeRatio skewness faceWeight aspectRatio cellVolume cellShapes)` field fil...Hi,
Please consider the following command within a case directory:
`checkMesh -writeAllFields`
If `0` directory exists, `8(cellDeterminant nonOrthoAngle cellVolumeRatio skewness faceWeight aspectRatio cellVolume cellShapes)` field files are written under `0` directory, otherwise under `constant` directory.
There might be times for a user who may find this conceptually and practically messy.
IMHO, collecting these fields under a directory may be useful in terms of tidiness.
Kind regardshttps://develop.openfoam.com/Development/openfoam/-/issues/753Possibly Incorrect Cs used in the Tutorial: channel395DFSEM2023-12-07T19:03:27ZKutalmış BerçinPossibly Incorrect Cs used in the Tutorial: channel395DFSEMHi,
Please consider `tutorials/incompressible/pimpleFoam/LES/channel395DFSEM`
In the tutorial's `README` file, it is stated that:
> Channel test case for ReTau=395,based on the reference:
>
> Poletto, R., Craft, T., and Revel...Hi,
Please consider `tutorials/incompressible/pimpleFoam/LES/channel395DFSEM`
In the tutorial's `README` file, it is stated that:
> Channel test case for ReTau=395,based on the reference:
>
> Poletto, R., Craft, T., and Revell, A.,
> "A New Divergence Free Synthetic Eddy Method for the
> Reproduction of Inlet Flow Conditions for LES",
> Flow Turbulence Combust (2013) 91:519-539
In the page 531 of the above reference, it was reported that the `Cs=0.065` was used for the case.
In `constant/turbulenceProperties`, the model coefficients that determine `Cs` are given as:
```
kEqnCoeffs
{
Ce 1.048;
Ck 0.07; // 0.094;
}
```
Considering the `Cs = f(Ce, Ck)` relation (also assumed by the community) is as follows:
`Cs^2 = Ck * sqrt(Ck/Ce)`
Computing `Cs` according to this relation yields `Cs~0.1345` rather than `Cs=0.065`. Assuming `Ce=1.048` constant, `Ck~0.02654` produces `Cs=0.065` according to this definition. In practice, this means, the tutorial is more diffusive than the benchmark. (Admittedly, `Cs~0.1345` is approximately twice the `Cs=0.065`. May explain this.)
If all aforementioned premises are correct, the tutorial in OpenFOAM currently does not exactly replicate the channel test case, as was mentioned, that the tutorial was based on.
Kind regardshttps://develop.openfoam.com/Development/openfoam/-/issues/754contiguous testing in UList output2020-03-13T14:30:13ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comcontiguous testing in UList outputA list of enum does not get folded into a single uniform entry when printing (since it tests for contiguous)
[Test-io.C](/uploads/eaae82693eb6ae1fb441787ae8c6da4c/Test-io.C)A list of enum does not get folded into a single uniform entry when printing (since it tests for contiguous)
[Test-io.C](/uploads/eaae82693eb6ae1fb441787ae8c6da4c/Test-io.C)Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/755faceSet and cellSet also in topoSet, setSet2020-06-18T21:27:38ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comfaceSet and cellSet also in topoSet, setSetIntegrate the checkMesh -writeSets functionality into topoSet, setSet. Especially the parallel reconstruction is very useful. (or have parallel set handling inside paraFoam)Integrate the checkMesh -writeSets functionality into topoSet, setSet. Especially the parallel reconstruction is very useful. (or have parallel set handling inside paraFoam)https://develop.openfoam.com/Development/openfoam/-/issues/756snappyHexMesh does not refine surface when geometry is small relative to doma...2021-07-06T11:51:35ZAdminsnappyHexMesh does not refine surface when geometry is small relative to domain sizeThis is occurring in 2.4.0 (2.4.0-dcea1e13ff76) as well as 1712.
This never occurs on our automotive cases, but only when we are building very coarse test cases to upload here. We have a volume refinement region of 16mm (refine level 6)...This is occurring in 2.4.0 (2.4.0-dcea1e13ff76) as well as 1712.
This never occurs on our automotive cases, but only when we are building very coarse test cases to upload here. We have a volume refinement region of 16mm (refine level 6) around a simple box and wheel geometry (image below from ANSA), on which we specify surface refinements of 8 and 4mm (levels 7 and 8). For some reason, these surface refinements never occur, with all surfaces only reaching 16mm (level 6) mesh size.
Only after adding more complex/larger geometry does the refinement occur. Not a huge problem as our standard cases are very large and complex, but for sending cases for bug reports, it would be nice to figure out the cause so that our test cases can be smaller :-) Not sure if the geometry being refined is considered "too small" relative to the domain size to be refined?
The case on which this is occurring is attached, all you would need to do is run snappyHexMesh.[test_case_refinement_issue_A_00020.zip](/uploads/39953de0d58b345eb357c6037d2192ab/test_case_refinement_issue_A_00020.zip)
![geom_image](/uploads/8562ebd0c151be532e2566dd424dd337/geom_image.png)
\## Reattaching the author to the issue ticket: @aerogt3 ##https://develop.openfoam.com/Development/openfoam/-/issues/757checkMesh consistently fails with IOerrors when using -writeSets stl option2023-12-07T19:03:27ZAdmincheckMesh consistently fails with IOerrors when using -writeSets stl optionI am running checkMesh in v1712 (mesh generated in same version). When using the option "-writeSets stl", I consistently get an IOstream error. checkMesh works fine with every other combination. This happens on dozens of cases; none succ...I am running checkMesh in v1712 (mesh generated in same version). When using the option "-writeSets stl", I consistently get an IOstream error. checkMesh works fine with every other combination. This happens on dozens of cases; none successfully execute.
Attached is a test case, simply run run_snappy.sh to generate the failure.
I can also submit this case with the run_snappy.sh already executed, the file is 104MB.
[checkMesh_writeSets_issue_A_00021_UNMESHED.zip](/uploads/e3ed29bb27a273e94ee11e8204011705/checkMesh_writeSets_issue_A_00021_UNMESHED.zip)Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/758Error in recompiling solver in OpenFOAM-v1712 on Windows 102019-01-08T17:33:43ZAdminError in recompiling solver in OpenFOAM-v1712 on Windows 10I have installed OpenFOAM-v1712 on Windows 10 according to the instructions on the following page
https://www.openfoam.com/download/install-windows-10.php
Everything went well, but it is not possible to recompile any solver. When I tri...I have installed OpenFOAM-v1712 on Windows 10 according to the instructions on the following page
https://www.openfoam.com/download/install-windows-10.php
Everything went well, but it is not possible to recompile any solver. When I tried to recompile e.g. icoFoam, I got the following error message
*$FOAM_INST_DIR/OpenFOAM-v1706/wmake/wmake: line 407: make: command not found*
Could you please figure out the problem?
Kind regards
Chenhttps://develop.openfoam.com/Development/openfoam/-/issues/759snappyHexMesh : layer extrusion in parallel2018-07-02T16:14:00ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comsnappyHexMesh : layer extrusion in parallelshm avoids trying to extrude if:
1) locally two patch faces only connect via a point
`
+--+
| |
+--+--+
| |
+--+
`
It does this even though neighbouring processors might have the missing patch faces.
2) if a mesh point is not on...shm avoids trying to extrude if:
1) locally two patch faces only connect via a point
`
+--+
| |
+--+--+
| |
+--+
`
It does this even though neighbouring processors might have the missing patch faces.
2) if a mesh point is not on the patch on some processors. This state 'wins'.Mattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comhttps://develop.openfoam.com/Development/openfoam/-/issues/760A redundant setting (or a possible typo) in the tutorial: snappyMultiRegionHe...2018-03-13T13:24:20ZKutalmış BerçinA redundant setting (or a possible typo) in the tutorial: snappyMultiRegionHeaterHi,
In `decomposeParDict` of https://develop.openfoam.com/Development/OpenFOAM-plus/blob/c7969911bc736af70c14faa74496b8b7801baa91/tutorials/heatTransfer/chtMultiRegionFoam/snappyMultiRegionHeater/system/decomposeParDict
The following ...Hi,
In `decomposeParDict` of https://develop.openfoam.com/Development/OpenFOAM-plus/blob/c7969911bc736af70c14faa74496b8b7801baa91/tutorials/heatTransfer/chtMultiRegionFoam/snappyMultiRegionHeater/system/decomposeParDict
The following is written:
```
coeffs
{
n (2 2 1);
}
```
IMHO, it was forgotten to be deleted in one of the commits while changing the method from `hierarchial` to `scotch`.https://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 regards