Development issueshttps://develop.openfoam.com/groups/Development/-/issues2019-12-27T10:02:17Zhttps://develop.openfoam.com/Development/openfoam/-/issues/1534Wiki home: broken link to page "Submitting issues"2019-12-27T10:02:17ZGerasimos ChourdakisWiki home: broken link to page "Submitting issues"In the [wiki home](https://develop.openfoam.com/Development/openfoam/wikis/home), in the sentence:
```
Users can provide feedback by submitting *issues* or *feature requests*; please see [Submitting Issues](/Development/openfoam/wikis/p...In the [wiki home](https://develop.openfoam.com/Development/openfoam/wikis/home), in the sentence:
```
Users can provide feedback by submitting *issues* or *feature requests*; please see [Submitting Issues](/Development/openfoam/wikis/page-submitting-issues)
```
the [Submitting Issues](https://develop.openfoam.com/Development/openfoam/wikis/Submitting-issues) link is broken. Replace with:
```
Users can provide feedback by submitting *issues* or *feature requests*; please see [Submitting Issues](/Development/openfoam/wikis/Submitting-issues)
```https://develop.openfoam.com/Development/openfoam/-/issues/1533ENH: LambVector FO is expensive to compute2021-12-21T18:46:13ZKutalmış BerçinENH: LambVector FO is expensive to compute**Problem statement:**
`LambVector` expression is $`(\nabla \times \mathbf{u}) \times \mathbf{u}`$, which revealed to be expensive to compute.
**Problem solution:**
Equivalent expressions, and potential simplifications, e.g. for incompr...**Problem statement:**
`LambVector` expression is $`(\nabla \times \mathbf{u}) \times \mathbf{u}`$, which revealed to be expensive to compute.
**Problem solution:**
Equivalent expressions, and potential simplifications, e.g. for incompressible flow computations, may reduce the computational cost of `LambVector`.
Most of the time the divergence of `LambVector` is the actual field of interest rather than the `LambVector` itself.
Nevertheless, the divergence of `lambVector` is computed by an external `div` FO. Instead, $`\nabla \cdot ((\nabla \times \mathbf{u})\times \mathbf{u})`$ may be further reduced to a simpler form.v2112Kutalmış BerçinKutalmış Berçinhttps://develop.openfoam.com/Development/ThirdParty-common/-/issues/48Compilation of paraview5.6.3 does not start.2020-07-22T11:05:07Zsariew8Compilation of paraview5.6.3 does not start.$ ~/OpenFOAM/ThirdParty-common$ ./makeParaView \
./makeParaView: 64: local: -DWM_DP: bad variable name \
./makeParaView: 64: ./makeParaView: -DOPENFOAM: bad variable name
did i make another mistakes?$ ~/OpenFOAM/ThirdParty-common$ ./makeParaView \
./makeParaView: 64: local: -DWM_DP: bad variable name \
./makeParaView: 64: ./makeParaView: -DOPENFOAM: bad variable name
did i make another mistakes?Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/1532Local Time Stepping for High Aspect Ratio Cells2022-04-26T16:10:39ZLiamLocal Time Stepping for High Aspect Ratio CellsLocal Time stepping an extremely effective method to obtain steady state solutions to a variety of cases. However, in cases with high aspect ratio cells, the local time-step becomes extremely small. This occurs in a number of situations,...Local Time stepping an extremely effective method to obtain steady state solutions to a variety of cases. However, in cases with high aspect ratio cells, the local time-step becomes extremely small. This occurs in a number of situations, specifically in cases where a wall resolved simulation is required. As the mesh must be refined to Y+ < 1, the aspect ratio becomes very high and the simulation begins to converge very slowly.
It has been shown in literature, and in other CFD codes, that taking into account the aspect ratio of the cell can speed up the convergence of the computation significantly (by an order of magnitude). In my own experience, certain cases (airfoils/de Lave nozzles) with high Reynolds number and thus very small Y+ = 1 distance, had an acceleration of over 100 times making these simulations optimum for parametric studies or optimization.
Implementing this feature which takes into account the aspect ratio of the cell in computing the local time-step would alleviate the number of iterations required to converge the solution in these cases. Literature on this can be found:
https://arc.aiaa.org/doi/pdf/10.2514/6.2001-2557
Additionally, this has been implemented into ANSYS Fluent under the name of "Convergence Acceleration for Stretched Meshes (CASM)".
http://www.pmt.usp.br/ACADEMIC/martoran/NotasModelosGrad/ANSYS%20Fluent%20Theory%20Guide%2015.pdf (PDF Pg. 699)
https://support.ansys.com/staticassets/ANSYS/Conference/Dallas/downloads/fluid-dynamics-14.0-update.pdf (PDF Pg. 14)
http://www.pmt.usp.br/academic/martoran/notasmodelosgrad/ANSYS%20Fluent%20Users%20Guide.pdf (PDF Pg. 1499)
An appropriate test case, for example, would be: NACA0012 with a wall-resolved mesh and the appropriate turbulence model for a wall-resolved RAS simulation. Running this at a high Re number would help high-light the effectiveness. Run the simulation with and without this new feature. The results should be effectively identical however using this feature the simulation should required significantly fewer iterations.v2206https://develop.openfoam.com/Development/openfoam/-/issues/1530chtMultiRegionTwoPhaseEulerFoam: missing L parameters for restart2020-01-21T20:24:12ZPawan GhildiyalchtMultiRegionTwoPhaseEulerFoam: missing L parameters for restartI) Restarting the case from solution , ask for missing parameters L from Bromley model .
2)Switching the DebugSwitches i.e below one to 2 , lead solver failing with error. Please check with tutorial for
chtMultiRegionTwoPhaseEulerFo...I) Restarting the case from solution , ask for missing parameters L from Bromley model .
2)Switching the DebugSwitches i.e below one to 2 , lead solver failing with error. Please check with tutorial for
chtMultiRegionTwoPhaseEulerFoam
DebugSwitches
{
compressible::alphatWallBoilingWallFunction 2;
} Sergio FerrarisSergio Ferrarishttps://develop.openfoam.com/Development/openfoam/-/issues/1529foamFormatConvert in parallel does miss converting faces file2019-12-23T14:48:52ZPrashant SonakarfoamFormatConvert in parallel does miss converting faces file### Summary
foamFormatConvert to convert between uncollated and collated format fails
### Steps to reproduce
- any case
- set writeFormat binary
- decomposePar -fileHandler uncollated
- mpirun -np XXX foamFormatConvert -parallel -file...### Summary
foamFormatConvert to convert between uncollated and collated format fails
### Steps to reproduce
- any case
- set writeFormat binary
- decomposePar -fileHandler uncollated
- mpirun -np XXX foamFormatConvert -parallel -fileHandler collated
This misses out converting the faces file!Mattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comhttps://develop.openfoam.com/Development/openfoam/-/issues/1528snappyHexMesh castellation step creates gaps between curved triangulated surf...2024-01-02T13:17:31ZDries AllaertssnappyHexMesh castellation step creates gaps between curved triangulated surfaces### Summary
In multiRegion cases, the castellation step of snappyHexMesh creates small gaps between curved triangulated surfaces (specified by stl files exported from CAD software AutoDesk Invecntor) when they are not exactly equal, eve...### Summary
In multiRegion cases, the castellation step of snappyHexMesh creates small gaps between curved triangulated surfaces (specified by stl files exported from CAD software AutoDesk Invecntor) when they are not exactly equal, even when stl files are exported at very high resolution (highest resolution available in the CAD software).
### Steps to reproduce
The issue can be reproduced by applying snappyHexMesh on a multiregion case with a curved interface between two regions, and with the different regions specified by different stl files exported from CAD software.
### Example case
Attached is a minimal working example consisting of two concentric cylinders corresponding to a fluid and a solid region. Only the castellation step of snappyHexMesh is run. [MWE.tar.gz](/uploads/21ca31e1c36f1f0e4a2673ec786c5fd9/MWE.tar.gz)
### What is the current *bug* behaviour?
The castellation step of snappyHexMesh creates small gaps between two triangulated surfaces, i.e., on the interface between two regions. As a result, some faces on the interface are identified as walls instead of mappedWalls between the two surfaces. In the snapping step, the gaps are closed but the patch type of some faces remains wall instead of mappedWall.
### What is the expected *correct* behavior?
snappyHexMesh should not remove cells located between two triangulated surface when the two triangulated surfaces coincide within a certain tolerance. The tolerance should be such that coinciding surfaces exported by CAD software can be meshed without creating small gaps. Possibly, this tolerance could be a user input.
### Relevant logs and/or images
Attached is a log file ([log.txt](/uploads/d20cb17863dbfce7ae643e6f8d23c929/log.txt)) of the provided minimal working example (logs of surfaceFeatureExtract - blockMesh - snappyHexMesh - splitMeshRegions) as well as some figures showing the case setup and the gaps on the interface.
Overview of the multiRegion geometry.
![MWE_fig1](/uploads/46a8588961f77c7616bdefac7eede9f1/MWE_fig1.png)
Detailed view of the interface.
![MWE_fig2](/uploads/a691486b653b0a97414885d0052784e1/MWE_fig2.png)
View of the interface, showing some faces that are identified as type wall (white) instead of mappedWall (red)
![MWE_fig3](/uploads/d6a1e6157024dad044c6cc8306f2dd6c/MWE_fig3.png)
### 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
- Operating system : CentOS Linux release 7.6.1810
- Hardware info :
- Compiler : intel
### Possible fixeshttps://develop.openfoam.com/Development/openfoam/-/issues/1526no fvMesh::solve forwarding for sphericalTensor2019-12-23T14:48:52ZMark OLESENno fvMesh::solve forwarding for sphericalTensor- seen on https://www.cfd-online.com/Forums/openfoam-programming-development/222893-port-of60-of1812-problem.html#post752642- seen on https://www.cfd-online.com/Forums/openfoam-programming-development/222893-port-of60-of1812-problem.html#post752642https://develop.openfoam.com/Development/openfoam/-/issues/1524Support Loader/Unloader function for libraries2021-07-07T07:23:37ZMark OLESENSupport Loader/Unloader function for librariesIn discussion with @Lars (and others), to forcibly trigger an unload function prior to closing a library. Uses a framework similar to codedBase
[dlLibraryTable.patch](/uploads/6f378c49daf335fae78122e93212c957/dlLibraryTable.patch)
Cross...In discussion with @Lars (and others), to forcibly trigger an unload function prior to closing a library. Uses a framework similar to codedBase
[dlLibraryTable.patch](/uploads/6f378c49daf335fae78122e93212c957/dlLibraryTable.patch)
Cross-ref EP1197.
Patch from Bram.Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/1523Generate distance to surface for checking correspondence of generated mesh to...2019-12-23T14:48:52ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comGenerate distance to surface for checking correspondence of generated mesh to original surface### Functionality to add/problem to solve
Would be nice to show the distance from face centres to the geometry that the mesh was generated for.
### Target audience
E.g. snappyHexMesh users### Functionality to add/problem to solve
Would be nice to show the distance from face centres to the geometry that the mesh was generated for.
### Target audience
E.g. snappyHexMesh usersMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comhttps://develop.openfoam.com/Development/openfoam/-/issues/1522Add OpenQBMM2020-02-10T15:21:01ZMark OLESENAdd OpenQBMMAs per discussions with @andy and @albertop - aim to add OpenQBMM in as a submodule for 1912.
Alberto has rejiged some bits to compile will 1906 (only some deprecation warnings for dimensionedType that can be safely ignored). I've recom...As per discussions with @andy and @albertop - aim to add OpenQBMM in as a submodule for 1912.
Alberto has rejiged some bits to compile will 1906 (only some deprecation warnings for dimensionedType that can be safely ignored). I've recompiled his branch with the 1912 develop and nothing came up with gcc-7.4.
May need to recheck with gcc-4.8.5, but probably not too bad.
As soon as we get a _mostly_ finalized branch (even better, tagged) can add the submodule.
Q: The subdirectory name as under modules/OpenQBMM, modules/open-qbmm ...? We are flexible.v2006Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/1521IListStream scope issue with Foam::List2023-03-01T15:00:46ZOliver PerksIListStream scope issue with Foam::List<!--
*** 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 -->
Scope issue with List in `IListStream.H`.
Whilst testing a new compiler release we encountered a build issue with `IListStream.H`, line 161.
The use of `List<char>&& buffer,` tries to inherit `List<char>` from `Detail::IListStreamAllocator`. However, this is a private member, and so can not be used. I believe the correct usage should be of `Foam::list`.
I have raised this with our internal compiler team, and they believe this to be a code issue rather than a compiler issue.
I believe this relates the the issue shown https://stackoverflow.com/questions/41595208/accessing-the-name-of-a-private-inherited-class-from-a-subclass
### Steps to reproduce
<!-- How one can reproduce the issue - this is very important -->
This issue was encountered when building OpenFOAM 1906 with the Arm Compiler for Linux 20.0 (LLVM 9 based). So I believe this to be an issue for Clang 9.
Simply building with the new compiler 20.0 encountered this issue - as LLVM 9 is being stricter. This was not an issue with the previous version 19.3 (LLVM 7 based) - nor GCC.
### 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
-->
I have reduced the relevant files to the included MWE.
[List_20.0.tar.gz](/uploads/56f54641ce09b4bc4ac35c82c715acf5/List_20.0.tar.gz)
```
> clang++ -std=c++11 -mcpu=native -Wall -Wextra -Wold-style-cast -Wnon-virtual-dtor -Wno-unused-parameter -Wno-invalid-offsetof -Wno-undefined-var-template -Wno-unknown-warning-option -O3 -I. -fPIC -c reproducer.C
In file included from reproducer.C:1:
./IListStream.H:103:10: error: 'List' is a private member of 'Foam::List<char>'
List<char>&& buffer
^
./IListStream.H:61:5: note: constrained by private inheritance here
private List<char>
^~~~~~~~~~~~~~~~~~
./List.H:65:7: note: member is declared here
class List
^
1 error generated.
```
### What is the current *bug* behaviour?
<!-- What actually happens -->
As shown above, the attempt is made to scope `List<char>` from the wrong source - `IListStreamAllocator`.
### What is the expected *correct* behavior?
<!-- What you should see instead -->
`List<char>` should be sourced from `List.H`.
### 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
- Operating system : RHEL 7 + 8
- Hardware info : Arm (aarch64)
- Compiler : clang 9 (armclang from Arm Compiler for Linux 20.0)
### 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/blob/master/src/OpenFOAM/db/IOstreams/memory/IListStream.H#L161
Before:
`List<char>&& buffer,`
After:
`Foam::List<char>&& buffer,`Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/1519cell derminant in checkMesh too limiting2021-07-06T16:39:04ZPrashant Sonakarcell derminant in checkMesh too limiting### Functionality to add/problem to solve
For low-Re meshes, the high aspect ratio might trigger the cell determinant warning.
The cell determinant
- is a measure for how close the cell is to an ideal 'cube' shape.
- it does a principa...### Functionality to add/problem to solve
For low-Re meshes, the high aspect ratio might trigger the cell determinant warning.
The cell determinant
- is a measure for how close the cell is to an ideal 'cube' shape.
- it does a principal axis determination based on amount of face-area (to internal faces)
- the determinant is then the product of the face-areas in all three principal directions
For high-aspect ratio cells or indeed 1D pipes the cell determinant is very small or zero. It probably should not look at the determinant but instead make sure there is at least one 'valid' direction (enough connectivity to neighbouring cells).
This is more a problem of what we want to output than problems with the mesh or checkMesh.
The problem is that in the default `meshQualityDict` in etc/caseDicts specifies a minimum cellDeterminant of 0.001. Maybe this needs reviewing.https://develop.openfoam.com/Development/openfoam/-/issues/1518BUG: no regression in tutorials using potentialFoam due to the lack of -writephi2019-12-12T11:33:12ZKutalmış BerçinBUG: no regression in tutorials using potentialFoam due to the lack of -writephi[New `writephi` option](https://develop.openfoam.com/Development/openfoam/blob/develop/applications/solvers/basic/potentialFoam/potentialFoam.C#L200) of `potentialFoam` was default in previous versions (<= 1906).
The lack of new option ...[New `writephi` option](https://develop.openfoam.com/Development/openfoam/blob/develop/applications/solvers/basic/potentialFoam/potentialFoam.C#L200) of `potentialFoam` was default in previous versions (<= 1906).
The lack of new option throughout tutorials will lead to different results from tutorials.
Adding `-writephi` option into the `Allrun` scripts where `potentialFoam` is present could be the solution.Kutalmış BerçinKutalmış Berçinhttps://develop.openfoam.com/Development/openfoam/-/issues/1516blockMesh be able to generate duplicate patches (e.g. cyclicACMI + wall)2021-07-06T16:37:59ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comblockMesh be able to generate duplicate patches (e.g. cyclicACMI + wall)### Functionality to add/problem to solve
Currently ACMI cases have to have additional patches added (to get the duplicate cyclicACMI + wall patches). Be nice if this could be done inside blockMesh.
### Target audience
blockMesh meshe...### Functionality to add/problem to solve
Currently ACMI cases have to have additional patches added (to get the duplicate cyclicACMI + wall patches). Be nice if this could be done inside blockMesh.
### Target audience
blockMesh meshes with cyclicACMI. Be much harder to add to any topo changing (e.g. snappyHexMesh). This would need to add the concept of duplicate baffles to polyMesh.
The blockMesh route uses the 'construct-from-cellShape' route. Attached a hack to get hold of the patch when doing the blockMesh. This could check for cyclicACMI and allow duplicate block faces (or just give a warning instead of falling over)
[polyMeshFromShapeMesh.C](/uploads/991ad5e38fccf5b3949b44335a879ac0/polyMeshFromShapeMesh.C)https://develop.openfoam.com/Development/openfoam/-/issues/1515compilation failure of libs POSIX (latest version Dec 2019, PLUS)2019-12-26T08:48:56Zsariew8compilation failure of libs POSIX (latest version Dec 2019, PLUS)i failed to install the latest version (openfoam-plus) in POSIX library. Where should i fix them?
---
[log.make.tar.gz](/uploads/e044e9a16a178ec32a70dce26771523d/log.make.tar.gz)i failed to install the latest version (openfoam-plus) in POSIX library. Where should i fix them?
---
[log.make.tar.gz](/uploads/e044e9a16a178ec32a70dce26771523d/log.make.tar.gz)Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/1302interIsoFoam with morphing meshes2019-07-02T09:26:33ZJohan RoenbyinterIsoFoam with morphing meshesSo far isoAdvector has not worked with morphing meshes.
A version of isoAdvection/interIsoFoam that works with morphing meshes has now been committed in the new branch feature-isoAdvectorWithMorphingMeshes
A test case demonstrating th...So far isoAdvector has not worked with morphing meshes.
A version of isoAdvection/interIsoFoam that works with morphing meshes has now been committed in the new branch feature-isoAdvectorWithMorphingMeshes
A test case demonstrating that it works can be found here:
[sphereInSqueezedMesh.tar.gz](/uploads/68d31fde5a917760b7a0a0bc852b97bd/sphereInSqueezedMesh.tar.gz)
Will someone with merge privilege look at this (@andy ,@mark )?v1906Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/1291In the same case, magneticFoam in this version does not return any results.2019-07-09T18:06:00ZAdminIn the same case, magneticFoam in this version does not return any results.<!--
*** 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
-->
<!--
All text between these marker...<!--
*** 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
-->
<!--
All text between these markers are comments and will not be present in the
report
-->
### Summary
<!-- Summarize the bug encountered concisely -->
'magneticFoam' in this version does not return any results but ofv6 seems to work properly for it.
### Steps to reproduce
<!-- How one can reproduce the issue - this is very important -->
we execute 'Allrun' script in the case.
### 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
-->
for v1812[magSandboxFailure.zip](/uploads/a40f6c4e3576f97e1f4c4da61c935038/magSandboxFailure.zip)
---
for ofv6[magSandboxSuccess.zip](/uploads/7f2544852e5e54e233f4f2e41f6d0f7d/magSandboxSuccess.zip)
### What is the current *bug* behaviour?
<!-- What actually happens -->
--> FOAM FATAL ERROR:
cannot find file "/home/xxxx/OpenFOAM/xxxx-v1812/run/magSandbox/0/murf"
### 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.
-->
[log.zip](/uploads/6f108923bcfe39f2bf404b48bc96b2ae/log.zip)
### Environment information
<!--
Providing details of your set-up can help us identify any issues, e.g.
OpenFOAM version : v1812
Operating system : ubuntu
Hardware info : intel
Compiler : gcc-7.3.0
-->
OpenFOAM version :v1812
Operating system :ubuntu18.04
Compiler :gcc-7.3.0
### Possible fixes
<!--
If you can, link to the line of code that might be responsible for the
problem
-->Mattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comhttps://develop.openfoam.com/Development/openfoam/-/issues/1282dynamicCode does not work with the Intel compiler2023-12-07T19:00:15ZAdmindynamicCode does not work with the Intel compilerIf "blockMesh" is executed in the tutorial $FOAM_TUTORIALS/basic/potentialFoam/cylinder using an OpenFOAM version compiled with the Intel compiler, the following error message will appear:
codeStreamTemplate.C(35): error: invalid line n...If "blockMesh" is executed in the tutorial $FOAM_TUTORIALS/basic/potentialFoam/cylinder using an OpenFOAM version compiled with the Intel compiler, the following error message will appear:
codeStreamTemplate.C(35): error: invalid line number
#line 0 "/path/to/system/blockMeshDict.#codeStream"
I tested this with Intel2018 and 2019 and OpenFOAM v1712 and v1812 on two different systems and the error happens with all instances where dynamicCode is used.
The generated code in cylinder/dynamicCode/_1c19e29ae18c779aa836a14631d6419f303e3d9d/codeStreamTemplate.C in line 35 reads:
#line 0 "/path/to/cylinder/system/blockMeshDict.#codeStream"
The Intel compiler complains about the "0". If instead "blockMesh" is run with an OpenFOAM version compiled with clang or gcc, the same code is generated but the compiler does not complain. A quick fix would be to remove the following line:
https://develop.openfoam.com/Development/OpenFOAM-plus/blob/master/src/OpenFOAM/db/dynamicLibrary/dynamicCode/dynamicCodeContext.C#L129Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/1284dry-run-write overwrites mesh2019-04-15T09:58:33ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comdry-run-write overwrites mesh<!--
*** 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
-->
<!--
All text between these marker...<!--
*** 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
-->
<!--
All text between these markers are comments and will not be present in the
report
-->
### Summary
<!-- Summarize the bug encountered concisely -->
dry-run-write overwrites mesh with the dry-run write.Mattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.com