Development issueshttps://develop.openfoam.com/groups/Development/-/issues2020-01-08T10:41:47Zhttps://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.comhttps://develop.openfoam.com/Development/openfoam/-/issues/1542checkMesh aspect ratio2024-01-10T16:47:46ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comcheckMesh aspect ratio### Functionality to add/problem to solve
checkMesh calculates an aspect ratio in the global coordinate system. More relevant would probably using a cell-local coordinate system.
### Proposal
Use the cell-local coordinate system calc...### Functionality to add/problem to solve
checkMesh calculates an aspect ratio in the global coordinate system. More relevant would probably using a cell-local coordinate system.
### Proposal
Use the cell-local coordinate system calculation from e.g. the cellDeterminant check and determine the aspect ratio in that.
### What does success look like, and how can we measure that?
Make e.g. cavity with a lot of grading. See if the reported aspect ratio changes if the case is rotated (e.g. using `transformPoints -rotate`)https://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/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 OLESEN