Development issueshttps://develop.openfoam.com/groups/Development/-/issues2020-01-23T16:24:40Zhttps://develop.openfoam.com/Development/openfoam/-/issues/1541paraview 5.6.3 in 1912 compilation fail2020-01-23T16:24:40ZMatej Formanparaview 5.6.3 in 1912 compilation failOn VirtualBox, new latest Ubuntu installation following all prerequisites, having OpenFOAM-v1912 compiled,
in ThirdParty-v1912 running:
```
./makeParaView
```
returns:
```
./makeParaView: 64: local: -DWM_DP: bad variable name
./makePar...On VirtualBox, new latest Ubuntu installation following all prerequisites, having OpenFOAM-v1912 compiled,
in ThirdParty-v1912 running:
```
./makeParaView
```
returns:
```
./makeParaView: 64: local: -DWM_DP: bad variable name
./makeParaView: 64: -DOPENFOAM: bad variable name
```https://develop.openfoam.com/Development/openfoam/-/issues/1540BUG: continuation of updateMethods with empty activeDesignVariables2020-01-03T09:43:15ZVaggelis PapoutsisBUG: continuation of updateMethods with empty activeDesignVariables<!--
*** 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 activeDesignVariables are not set explicitly, all design variables
are treated as active. These are allocated properly when starting from
0 but not when starting from an intermediate optimisation cycle
(e.g. running 5 optimisation cycles, stopping and restarting).
The bug affects the BFGS, DBFGS, LBFGS, SR1, SQP and conjugateGradient updateMethods.
### Steps to reproduce
1. Copy an optimisation case using BFGS, say $FOAM_TUTORIALS/incompressible/adjointOptimisationFoam/shapeOptimisation/sbend/turbulent/opt/BFGS/op1
2. Comment out the *activeDesignVariables* in *optimisationDict*.
3. Run for a number of optimisation cycles using *adjointOptimisationFoam*, say 5.
4. Change the *endTime* to 10, to run another 5 optimisation cycles and re-run *adjointOptimisationFoam*. The solver will crash upon trying to compute the update of the design variables since the *activeDesignVariables* list will be empty.Andrew HeatherAndrew Heatherhttps://develop.openfoam.com/Development/openfoam/-/issues/1538BUG: writeMorpherCPs expects a controlBoxes entry2020-01-03T09:43:42ZVaggelis PapoutsisBUG: writeMorpherCPs expects a controlBoxes entry<!--
*** 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 *writeMorpherCPs* preProcessing utility expects a *controlBoxes* entry in volumetricBSplinesMotionSolverCoeffs, within dynamicMeshDict. NURBS3DVolume no longer expects this entry (defeatured before release) but *writeMorpherCPs* was not updated accordingly.Andrew HeatherAndrew Heatherhttps://develop.openfoam.com/Development/openfoam/-/issues/1537BUG: Wrong FatalIOError message in displacementMethod and optMeshMovement2020-01-03T09:44:02ZVaggelis PapoutsisBUG: Wrong FatalIOError message in displacementMethod and optMeshMovement<!--
*** 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 core of the FatalIOError message, including the table of contents of the base class, is not printed by displacementMethod::New and optMeshMovement::New due to exiting the FatalIOError call with exit(FatalError) instead of exit(FatalIOError).
### Steps to reproduce
Enter a non-valid displacementMethod (in dynamicMeshDict) or meshMovement type (in optimisationDict) in any of the tutorials under $FOAM_TUTORIALS/incompressible/adjointOptimisationFoam/shapeOptimisation.
### What is the current *bug* behaviour?
No error message content is printed, only the Fatal Error line.
### What is the expected *correct* behavior?
The full FatalError message, including the toc of the base class should be printed.Andrew HeatherAndrew Heatherhttps://develop.openfoam.com/Development/openfoam/-/issues/1535Thermal resistance in turbulentTemperatureRadCoupledMixed boundary conditions...2021-10-18T18:22:52ZLieven VerveckenThermal resistance in turbulentTemperatureRadCoupledMixed boundary conditions not working properly### Summary
When defining thicknessLayers and kappaLayers in the turbulentTemperatureRadCoupledMixed boundary conditions, energy conservation over the interface is broken, resulting in wrong temperatures at the interface and inside the ...### Summary
When defining thicknessLayers and kappaLayers in the turbulentTemperatureRadCoupledMixed boundary conditions, energy conservation over the interface is broken, resulting in wrong temperatures at the interface and inside the domain. Exactly the same settings in combination with turbulentTemperatureCoupledBaffleMixed produce the correct results.
### Steps to reproduce
Run a multi-region heat transfer case using chtMultiRegion(Simple)Foam with turbulentTemperatureRadCoupledMixed in combination with one or more thermal resistance layers at the interface. Radiation is switched off.
### Example case
Attached, a simple 2-region conduction case is added. The regions are 'leftSolid' and 'rightSolid'. Both have a length of 1m. A 1kW heat flux is imposed at heatFluxWall in leftSolid, a fixed temperature of 300K is imposed at fixedTWall in rightSolid. At the interface (leftSolid_to_rightSolid and rightSolid_to_leftSolid) a thermal resistance with kappa 0.1 and thickness 0.001 is added. Four different 0-folders are added for comparison, switch between turbulentTemperatureRadCoupledMixed and turbulentTemperatureCoupledBaffleMixed and switching the resistance on and off.
Analytically, the temperatures including thermal resistance are:
fixedTWall = 300
rightSolid_to_leftSolid = 312.5
leftSolid_to_rightSolid = 322.5
heatFluxWall = 335
turbulentTemperatureCoupledBaffleMixed reproduces these values, turbulentTemperatureRadCoupledMixed does not.
[resistance.tar.gz](/uploads/b6f1798442502445cfdea4bbd698c43b/resistance.tar.gz)
### What is the current *bug* behaviour?
See example case. turbulentTemperatureCoupledBaffleMixed reproduces the correct temperatures, turbulentTemperatureRadCoupledMixed does not.
### Relevant logs and/or images
Output of the last iteration when running the test case.
*Output with turbulentTemperatureCoupledBaffleMixed:*
Solving for solid region leftSolid
DICPCG: Solving for h, Initial residual = 9.282926e-10, Final residual = 9.282926e-10, No Iterations 0
Min/max T:**322.5 335**
Solving for solid region rightSolid
DICPCG: Solving for h, Initial residual = 8.370484e-10, Final residual = 8.370484e-10, No Iterations 0
Min/max T:300 312.5
ExecutionTime = 0.99 s ClockTime = 2 s
*Output with turbulentTemperatureRadCoupledMixed:"
Solving for solid region leftSolid
DICPCG: Solving for h, Initial residual = 2.955242e-10, Final residual = 2.955242e-10, No Iterations 0
Min/max T:**322.375 334.875**
Solving for solid region rightSolid
DICPCG: Solving for h, Initial residual = 9.524563e-10, Final residual = 9.524563e-10, No Iterations 0
Min/max T:300 312.5
ExecutionTime = 1.03 s ClockTime = 1 s
### 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 7
- Hardware info :
- Compiler :
### Possible fixes
I suspect the bug is related to the definition of TcNbr at line 206 in turbulentTemperatureRadCoupledMixedFvPatchScalarField.C, which is independent of contactRes_. In turbulentTemperatureCoupledBaffleMixed, there is a dependency on constantRes_.https://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/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/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/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/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/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