Development issueshttps://develop.openfoam.com/groups/Development/-/issues2020-04-15T08:53:57Zhttps://develop.openfoam.com/Development/openfoam/-/issues/1574native reduce for solveScalar2020-04-15T08:53:57ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comnative reduce for solveScalar### Functionality to add/problem to solve
Foam::reduce is specialised for summation of scalar but not solveScalar. Hence in SPDP mode it will fall back to non-native reduce (might be slower)
### Target audience
Parallel running### Functionality to add/problem to solve
Foam::reduce is specialised for summation of scalar but not solveScalar. Hence in SPDP mode it will fall back to non-native reduce (might be slower)
### Target audience
Parallel runninghttps://develop.openfoam.com/Development/openfoam/-/issues/1571Incorrect Nastran surface value export2020-05-14T16:02:42ZPrashant SonakarIncorrect Nastran surface value exportCross Ref : EP#1210
Indexing error in writing as discussed with @markCross Ref : EP#1210
Indexing error in writing as discussed with @markMark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/1567searchableExtrudedCircle / extrudedCircle uses wrong search sphere2024-01-05T17:05:08ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comsearchableExtrudedCircle / extrudedCircle uses wrong search sphere<!--
*** Please read this first! ***
Before opening a new issue, make sure to search for keywords in the issues
filtered by the "bug" label and check to see if it has already been reported
You can see how your report will be ...<!--
*** Please read this first! ***
Before opening a new issue, make sure to search for keywords in the issues
filtered by the "bug" label and check to see if it has already been reported
You can see how your report will be rendered on the platform by using the
"preview" tab above
-->
<!--
All text between these markers are comments and will not be present in the
report
-->
### Summary
<!-- Summarize the bug encountered concisely -->
The analytical shape 'extrudedCircle' does not interpret the search distance correctly. It is taken as the distance to the centre line instead of the distance to the cylinder itself.
### Steps to reproduce
<!-- How one can reproduce the issue - this is very important -->
Use in e.g. a snappyHexMeshDict. Set the snapping distance (`snapTol`) to e.g. 1. Make sure that the centre line is more than 1 edge distance away from the geometry. Now it will not be attracted to the extrusion, even when the extrusion itself might intersect the geometry.
### Example case
<!--
If possible, please create a SMALL example and attach it to your report
If you are using an older version of OpenFOAM this will also determine
whether the bug has been fixed in a more recent version
-->
### What is the current *bug* behaviour?
<!-- What actually happens -->
### What is the expected *correct* behavior?
<!-- What you should see instead -->
Re-work the search distance into distance-to-extrusion
@PrashantMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comhttps://develop.openfoam.com/Development/openfoam/-/issues/1566foamConfigurePath : update gcc removes entries till end of line2020-05-14T16:02:42ZPrashant SonakarfoamConfigurePath : update gcc removes entries till end of line<!--
*** Please read this first! ***
Before opening a new issue, make sure to search for keywords in the issues
filtered by the "bug" label and check to see if it has already been reported
You can see how your report will be ...<!--
*** Please read this first! ***
Before opening a new issue, make sure to search for keywords in the issues
filtered by the "bug" label and check to see if it has already been reported
You can see how your report will be rendered on the platform by using the
"preview" tab above
-->
<!--
All text between these markers are comments and will not be present in the
report
-->
### Summary
foamConfigurePath seems to setup gcc, but removes ;; at the end.
### Environment information
<!--
Providing details of your set-up can help us identify any issues, e.g.
OpenFOAM version : v1806|v1812|v1906 etc
Operating system : ubuntu|openSUSE|centos etc
Hardware info : any info that may help?
Compiler : gcc|intel|clang etc
-->
- OpenFOAM version : 1912
- Compiler : gcc-4.8.5Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/1565How to control foamyQuadMesh bounding box?2020-01-21T08:52:56ZkilaHow to control foamyQuadMesh bounding box?Recently I'm playing with foamyQuadMesh. And I have a problem that my stl file contains a simple closed circle and their coordinates are **below 0.003**. However after using foamyQuadMesh, it automatically insert some points outside circ...Recently I'm playing with foamyQuadMesh. And I have a problem that my stl file contains a simple closed circle and their coordinates are **below 0.003**. However after using foamyQuadMesh, it automatically insert some points outside circle region. And it give a bounding box:
boundingBox : (-1.06e-01 -1.05e-01 0.00e+00) (1.10e-01 1.15e-01 0.00e+00)
The maximum x coordinate is **about 0.01** which is triple of maximum x coordinate of my circle so that the final MeshedSurface.obj looks very strange.
My foamyQuadMeshDict looks like:
-----------------------------
geometry
{
OutletPartSurface.stl
{
name outlet;
type closedTriSurfaceMesh;
}
}
surfaceConformation
{
// The z-coordinate of the plane is taken from here.
locationInMesh (0 0 0);
pointPairDistanceCoeff 0.1;
minEdgeLenCoeff 0.1;
maxNotchLenCoeff 1.0;
minNearPointDistCoeff 0.1;
maxQuadAngle 120;
// Insert near-boundary point mirror or point-pairs
insertSurfaceNearestPointPairs yes;
// Mirror near-boundary points rather than insert point-pairs
mirrorPoints no;
// Insert point-pairs vor dual-cell vertices very near the surface
insertSurfaceNearPointPairs yes;
// Maximum number of iterations used in boundaryConform.
maxBoundaryConformingIter 5;
geometryToConformTo
{
outlet
{
featureMethod extendedFeatureEdgeMesh;
extendedFeatureEdgeMesh "OutletPartSurface.extendedFeatureEdgeMesh";
}
}
additionalFeatures
{}
// Choose if to randomise the initial grid created by insertGrid.
randomiseInitialGrid no;
// Perturbation fraction, 1 = cell-size.
randomPerturbation 0.1;
}
motionControl
{
// This is a tolerance for determining whether to deal with surface
// protrusions or not.
minCellSize 0.0001;
// Assign a priority to all requests for cell sizes, the highest overrules.
defaultPriority 0;
shapeControlFunctions
{
}
relaxationModel adaptiveLinear;
adaptiveLinearCoeffs
{
relaxationStart 0.5;
relaxationEnd 0.0;
}
objOutput no;
meshedSurfaceOutput yes;
// Near-wall region where cells are aligned with the wall specified as a
// number of cell layers
nearWallAlignedDist 3;
}
shortEdgeFilter
{
// Factor to multiply the average of a face's edge lengths by.
// If an edge of that face is smaller than that value then delete it.
shortEdgeFilterFactor 0.2;
// Weighting for the lengths of edges that are attached to the boundaries.
// Used when calculating the length of an edge. Default 2.0.
edgeAttachedToBoundaryFactor 2.0;
}
extrusion
{
extrude off;
#include "extrude2DMeshDict"
}
---------------------------
OutletPartSurface is my stl file that contains a circle. First I use surfaceFeatureExtract to create "OutletPartSurface.extendedFeatureEdgeMesh". As my circle is very small, I set **minCellSize 0.0001;** which is about 0.1 mm.
I have attach a minimum sample to reproduce this problem.
I'm using v1912.
[foamycircle.rar](/uploads/33546ec93da9f4a16d3c934a2c82c570/foamycircle.rar)https://develop.openfoam.com/Development/openfoam/-/issues/1564limitTemperature functionObject does not work with compressibleInterFoam2020-06-19T07:07:20ZPawan GhildiyallimitTemperature functionObject does not work with compressibleInterFoam<!--
*** Please read this first! ***
-->
<!--
All text between these markers are comments and will not be present in the
report
-->
### Summary
limitTemperature functionObject does not work with compressibleInterFoam
### S...<!--
*** Please read this first! ***
-->
<!--
All text between these markers are comments and will not be present in the
report
-->
### Summary
limitTemperature functionObject does not work with compressibleInterFoam
### Steps to reproduce
<!-- How one can reproduce the issue - this is very important -->
### Example case
<!--
If possible, please create a SMALL example and attach it to your report
If you are using an older version of OpenFOAM this will also determine
whether the bug has been fixed in a more recent version
-->
### What is the current *bug* behaviour?
<!-- What actually happens -->
### What is the expected *correct* behavior?
<!-- What you should see instead -->
### Relevant logs and/or images
<!--
Paste any relevant logs - please use code blocks (```) to format console
output, logs, and code as it's very hard to read otherwise.
-->
### Environment information
<!--
Providing details of your set-up can help us identify any issues, e.g.
OpenFOAM version : v1806|v1812|v1906 etc
Operating system : ubuntu|openSUSE|centos etc
Hardware info : any info that may help?
Compiler : gcc|intel|clang etc
-->
- OpenFOAM version :v1906 and dev
- Operating system :
- Hardware info :
- Compiler :
### Possible fixes
<!--
If you can, link to the line of code that might be responsible for the
problem
The "/label ~bug" text is a gitlab flag that will add the "bug" label to this
issue
-->https://develop.openfoam.com/Development/openfoam/-/issues/1562Centos docker version of v1912 doesn't has foamyQuadMesh and foamyHexMesh tool.2021-07-06T17:03:07ZkilaCentos docker version of v1912 doesn't has foamyQuadMesh and foamyHexMesh tool.By check the folder /opt/OpenFOAM/OpenFOAM-v1912/platforms/linux64GccDPInt32Opt/bin/, I find that this folder doesn't contain foamyHexMesh and foamyQuadMesh so that if one using these commands, he would encounter "command not found".
Ho...By check the folder /opt/OpenFOAM/OpenFOAM-v1912/platforms/linux64GccDPInt32Opt/bin/, I find that this folder doesn't contain foamyHexMesh and foamyQuadMesh so that if one using these commands, he would encounter "command not found".
However in windows 10 ubuntu version, one wouldn't have this problem.https://develop.openfoam.com/Development/openfoam/-/issues/1558BUG: cyclicACMI & redistributePar Error2022-02-10T13:47:10ZJustin GraupmanBUG: cyclicACMI & redistributePar Error### Summary
Running redistributePar after decomposing a model with cyclicACMI patches will result in this error...
`[0] --> FOAM FATAL ERROR:
[0] Inconsistent ACMI patches ACMI2_couple and ACMI2_blockage. Patches should have identical...### Summary
Running redistributePar after decomposing a model with cyclicACMI patches will result in this error...
`[0] --> FOAM FATAL ERROR:
[0] Inconsistent ACMI patches ACMI2_couple and ACMI2_blockage. Patches should have identical topology
[0]
[0] From function virtual Foam::label Foam::cyclicACMIPolyPatch::nonOverlapPatchID() const
[0] in file AMIInterpolation/patches/cyclicACMI/cyclicACMIPolyPatch/cyclicACMIPolyPatch.C at line 538.
[0]
FOAM parallel run exiting`
### Steps to reproduce
Modify the Allrun-parallel file in the oscillatingInletACMI2D tutorial, add a **runParallel redistributePar** line after the decomposePar line. Optionally comment out the solver and reconstruct lines since they aren't needed to reproduce the error. Should look like this...
* runApplication decomposePar
* runParallel redistributePar
* #runParallel $(getApplication)
* #runApplication reconstructPar
Run the Allrun-parallel file, you'll find the error in log.redistributePar
### Example case
oscillatingInletACMI2D tutorial
### What is the current *bug* behaviour?
`[0] --> FOAM FATAL ERROR:
[0] Inconsistent ACMI patches ACMI2_couple and ACMI2_blockage. Patches should have identical topology
[0]
[0] From function virtual Foam::label Foam::cyclicACMIPolyPatch::nonOverlapPatchID() const
[0] in file AMIInterpolation/patches/cyclicACMI/cyclicACMIPolyPatch/cyclicACMIPolyPatch.C at line 538.
[0]
FOAM parallel run exiting`
### What is the expected *correct* behavior?
I expect it to redistribute the already decomposed mesh.
### Environment information
- OpenFOAM version : v1906
- Operating system : RHEL/Windows 10
- Hardware info : Intel
- Compiler : GCC/minGW
~bugMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comhttps://develop.openfoam.com/Development/openfoam/-/issues/1556issue with surfaceFieldValue in v19122022-02-28T09:38:35ZJozsef Nagyissue with surfaceFieldValue in v1912I noticed an issue with surfaceFieldValue combination with dynamicMotionSolverFvMesh in v1912. The function writes out the header for all time steps into the dat file.
I upload the case as a zip file. [case.zip](/uploads/41bf0f56d1470d7...I noticed an issue with surfaceFieldValue combination with dynamicMotionSolverFvMesh in v1912. The function writes out the header for all time steps into the dat file.
I upload the case as a zip file. [case.zip](/uploads/41bf0f56d1470d7e32d6695b6d80ef2a/case.zip)
If you run it in v1812 the dat file in postProcessing is fine. If you run it in v1912 it writes out the header in each time step, however if you change in dynamicMeshDict "dynamicMotionSolverFvMesh" to "staticFvMesh", the output is fine again.
Please consider, that the case is a constructed one for this problem, so it has no real physical meaning.https://develop.openfoam.com/Development/openfoam/-/issues/1555questionable surfZoneIOList read construction2020-01-15T10:54:33ZMark OLESENquestionable surfZoneIOList read constructionAfter the PtrList resize, requires `set()` and not `operator[]` - potential nullptr accessAfter the PtrList resize, requires `set()` and not `operator[]` - potential nullptr accessMark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/1554Deprecated Use2020-01-14T17:36:10ZCole MuellerDeprecated UseHi. Using v1912 now. Everything seems to work well on install. I am trying to use solvers and BC's built on old versions specifically 1806. In CHTmultiregionfoam a function in createsolidfields.h uses the member "transformVector" when i...Hi. Using v1912 now. Everything seems to work well on install. I am trying to use solvers and BC's built on old versions specifically 1806. In CHTmultiregionfoam a function in createsolidfields.h uses the member "transformVector" when in 1912 it uses "transformPrinciple." This is the same in setRegionSolidFields.h. I was unable to find a way to use older version standards without installing the older version. I have a lot of solvers from the old version and it would be quite tedious to go through and update all my solvers. Could you guide me to a forum or solved issue that is the same as this. Or potentially guide me through a solution. If none exists I will bite the bullet but I'm unsure of how many potential deprecated uses I will run into beyond this one.
Colehttps://develop.openfoam.com/Development/openfoam/-/issues/1553rRb definition in SchnerrSauer phase change model2020-01-13T14:27:25ZRiccardo RossirRb definition in SchnerrSauer phase change modelI'm dealing with a cavitation problem and started digging in the source code of phase change models available with the interPhaseChangeFoam solver.
While checking the rRb definition in the Schnerr and Sauer model:
return pow
(
...I'm dealing with a cavitation problem and started digging in the source code of phase change models available with the interPhaseChangeFoam solver.
While checking the rRb definition in the Schnerr and Sauer model:
return pow
(
((4*constant::mathematical::pi*n_)/3)
*limitedAlpha1/(1.0 + alphaNuc() - limitedAlpha1),
1.0/3.0
);
I've noticed the volume fraction of the liquid is used instead of the vapor one as in the definition of bubble radius from theory.
I feel like this would be too obvious to be an error/bug, so I was wondering what am I missing.https://develop.openfoam.com/Development/openfoam/-/issues/1551yplus accommodetion for pisoFoam in LES wall model2020-01-13T10:31:50ZHaijing Panyplus accommodetion for pisoFoam in LES wall modelI'm doing LES model, but don't want to cost too much time on the first calculating, so I select the wall function, now it works normally, but I don't know how to choose a suitable wallfunction for my case and how to see whether the calcu...I'm doing LES model, but don't want to cost too much time on the first calculating, so I select the wall function, now it works normally, but I don't know how to choose a suitable wallfunction for my case and how to see whether the calculation is correct according to the yplus from each interaction.
I choose kqRwallFunction for k, nutUspaldingWallFunction and nutkWallFunction for nut, kEqn and Smagorinsky for LES model, so there are four cases now, and all of them are calculating now.
would any suggestion about my cases is welcome, thank youhttps://develop.openfoam.com/Development/openfoam/-/issues/1549BUG: wrong bounding of sensitivity contituents in case of many control boxes2020-01-09T21:04:43ZVaggelis PapoutsisBUG: wrong bounding of sensitivity contituents in case of many control boxes<!--
*** Please read this first! ***
Before opening a new issue, make sure to search for keywords in the issues
filtered by the "bug" label and check to see if it has already been reported
You can see how your report will be ...<!--
*** Please read this first! ***
Before opening a new issue, make sure to search for keywords in the issues
filtered by the "bug" label and check to see if it has already been reported
You can see how your report will be rendered on the platform by using the
"preview" tab above
-->
<!--
All text between these markers are comments and will not be present in the
report
-->
### Summary
When more than one volumetric B-Splines control boxes are present, the sensitivity constituents corresponding to the non-active design variables are not bounded(zeroed) correctly. The resultant sensitivities, used in the optimization, are bounded correctly, so this is more a bug pertaining to the output file of the sensitivities rather than a functional one.
Things work as intended in the presence of a single volumetric B-Splines control box.Vaggelis PapoutsisVaggelis Papoutsishttps://develop.openfoam.com/Development/openfoam/-/issues/1548Not a valid INTELMPI installation directory2020-01-09T08:03:32ZHaijing PanNot a valid INTELMPI installation directoryI'm using paralleling computing in the HPC, but now I found I can't login normally and there is an error hint about it. However, I don't do any modification and it can work normally before this unexpected problem coming. Could anyone giv...I'm using paralleling computing in the HPC, but now I found I can't login normally and there is an error hint about it. However, I don't do any modification and it can work normally before this unexpected problem coming. Could anyone give me some suggestions about how to deal with it, thank you.![image](/uploads/29fbf0aa68dbec0e38bc6ea30463b8b9/image.png)https://develop.openfoam.com/Development/openfoam/-/issues/1546OpenFOAM v1912 mpirun killed due to memory shortage2020-01-16T17:56:48ZpanagiotisOpenFOAM v1912 mpirun killed due to memory shortageWhen I run an external aero case (70M cells) with porosity in OF v1906 **it runs normally**.
When I switch to OF v1912 it crashes in the beginning and gives the following error:
"Starting time loop
Time = 1
--------------------------...When I run an external aero case (70M cells) with porosity in OF v1906 **it runs normally**.
When I switch to OF v1912 it crashes in the beginning and gives the following error:
"Starting time loop
Time = 1
--------------------------------------------------------------------------
mpirun noticed that process rank 111 with PID 21978 on node node001 exited on signal 9 (Killed).
--------------------------------------------------------------------------
Some error occured in calculation.(error code=137)"
Info from cluster:
"Out of memory: Kill process 21978 (porousSimpleFoa) score 8 or sacrifice child
[4825555.767487] Killed process 21978 (porousSimpleFoa) total-vm:1900080kB, anon-rss:537616kB, file-rss:8280kB"https://develop.openfoam.com/Development/ThirdParty-common/-/issues/49issues with ptscotch and mingw2020-06-26T08:12:25ZMark OLESENissues with ptscotch and mingwAppears that we might need the following in the Makefile:
```
CCD = gcc -I$(MPI_ARCH_PATH)/include
```
@PawanAppears that we might need the following in the Makefile:
```
CCD = gcc -I$(MPI_ARCH_PATH)/include
```
@PawanMark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/1545Binary file compatibility not working with collated file format2021-07-06T16:47:55ZMortesinsBinary file compatibility not working with collated file format<!--
*** Please read this first! ***
Before opening a new issue, make sure to search for keywords in the issues
filtered by the "bug" label and check to see if it has already been reported
You can see how your report will be ...<!--
*** Please read this first! ***
Before opening a new issue, make sure to search for keywords in the issues
filtered by the "bug" label and check to see if it has already been reported
You can see how your report will be rendered on the platform by using the
"preview" tab above
-->
<!--
All text between these markers are comments and will not be present in the
report
-->
### Summary
The binary file compatibility that handles the reading of different precision or label sizes does not work when using the collated file format.
### Steps to reproduce
-Create a mesh in DP with the collated file format.
-Run a solver in SP.
### What is the current *bug* behaviour?
A ```FOAM FATAL IO ERROR``` occurs when trying to read the mesh and the binary crashes. Note that the same case with the uncollated file format works.
### What is the expected *correct* behavior?
The binary in SP should be able to read the DP mesh.
### Relevant logs and/or images
```
Create mesh for time = 0
[9]
[9]
[9] --> FOAM FATAL IO ERROR:
[9] Expected a ')' while reading binaryBlock, found on line 2: word '�ʩ���
[9]
[9] file: /path_to_case/processors128/constant/polyMesh/points at line 2.
[9]
[9] From function bool Foam::Istream::readEnd(const char*)
[9] in file db/IOstreams/IOstreams/Istream.C at line 134.
[9]
FOAM parallel run exiting
[9]
```
### Environment information
<!--
Providing details of your set-up can help us identify any issues, e.g.
OpenFOAM version : v1806|v1812|v1906 etc
Operating system : ubuntu|openSUSE|centos etc
Hardware info : any info that may help?
Compiler : gcc|intel|clang etc
-->
- OpenFOAM version : v1912
- Operating system : CentOS Linux 7
- Hardware info :
- Compiler : Gcc 4.8.5Mattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comhttps://develop.openfoam.com/Development/openfoam/-/issues/1544pressure function object v19122020-01-08T10:41:47ZPacific ESIpressure function object v1912<!--
*** Please read this first! ***
Before opening a new issue, make sure to search for keywords in the issues
filtered by the "bug" label and check to see if it has already been reported
You can see how your report will be ...<!--
*** Please read this first! ***
Before opening a new issue, make sure to search for keywords in the issues
filtered by the "bug" label and check to see if it has already been reported
You can see how your report will be rendered on the platform by using the
"preview" tab above
-->
<!--
All text between these markers are comments and will not be present in the
report
-->
### Summary
The v1912 pressure function object fails if hydrostatic pressures are applied for incompressible cases. The reason is that the pressure field created in calcPressure and that is the only parameter to function addHydrostaticContribution always has dimensions dimPressure and can never be kinematic pressure. Function rhoScale is called from addHydrostaticContribution and checks the dimensions of the pressure field to decide whether to multiply a second field by the volScalarField rho (if dimPressure) or the by the scalar rhoInf. It can never multiply by rhoInf as the pressure always has dimensions dimPressure. It tries to retrieve a volScalarField called rhoInf and crashes as the field does not exist.
It would also help to list g and hRef in the documentation as optional parameters for the function object when hydrostaticMode applies.
<!-- Summarize the bug encountered concisely -->
### Steps to reproduce
<!-- How one can reproduce the issue - this is very important -->
### Example case
<!--
If possible, please create a SMALL example and attach it to your report
If you are using an older version of OpenFOAM this will also determine
whether the bug has been fixed in a more recent version
-->
### What is the current *bug* behaviour?
The software crashes when a volScalarField called rhoInf is not found.
<!-- What actually happens -->
### What is the expected *correct* behavior?
<!-- What you should see instead -->
It should not crash!
### Relevant logs and/or images
<!--
Paste any relevant logs - please use code blocks (```) to format console
output, logs, and code as it's very hard to read otherwise.
-->
### Environment information
<!--
Providing details of your set-up can help us identify any issues, e.g.
OpenFOAM version : v1806|v1812|v1906 etc
Operating system : ubuntu|openSUSE|centos etc
Hardware info : any info that may help?
Compiler : gcc|intel|clang etc
-->
- OpenFOAM version : v1912
- Operating system : Centos 7
- Hardware info :
- Compiler : gcc 8.3
### Possible fixes
1. In the 2-parameter rhoScale function check whether rhoInfInitialised_ is true. If so, use rhoInf, otherwise use rho.
Or, more in keeping with the current code:
2. Have 2 input parameters to addHydrostaticContribution(p,result) where p is the unmodified input pressure field and result is the pressure field created in calcPressure. In addHydrostaticContribution use p as the first parameter to rhoScale while rgh is added or subtracted from result and returned.
<!--
If you can, link to the line of code that might be responsible for the
problem
The "/label ~bug" text is a gitlab flag that will add the "bug" label to this
issue
-->https://develop.openfoam.com/Development/openfoam/-/issues/1543checkMesh pyramid volume2021-07-06T16:47:06ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comcheckMesh pyramid volume### Functionality to add/problem to solve
checkMesh -writeAllFields does not output pyramid volume
### Target audience
This would be useful for debugging snappyHexMesh behaviour### Functionality to add/problem to solve
checkMesh -writeAllFields does not output pyramid volume
### Target audience
This would be useful for debugging snappyHexMesh behaviourMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.com