Development issueshttps://develop.openfoam.com/groups/Development/-/issues2023-03-01T15:00:46Zhttps://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/1514solid body motion solver does not work with rigid body solver2021-07-06T16:37:25ZAdminsolid body motion solver does not work with rigid body solverHi,
I am trying to use solid body motion as a mesh motion solver for rigid body motion. Although it lists the solid body motion as a valid motion solver, it fails to cast solver type and crash at the beginning. I have attached dynamicMe...Hi,
I am trying to use solid body motion as a mesh motion solver for rigid body motion. Although it lists the solid body motion as a valid motion solver, it fails to cast solver type and crash at the beginning. I have attached dynamicMeshDict file which can be placed in floatingBody overset tutorial to reproduce the error. The error line
--> FOAM FATAL ERROR:
Attempt to cast type solidBody to type displacementMotionSolver
Regards,
Ali
[6DoF.dat](/uploads/b4482b95045d89f392cbb664abc39412/6DoF.dat)
[dynamicMeshDict](/uploads/090b4e4130601b0d00883af3c85c20dc/dynamicMeshDict)
\## Reattaching the author to the issue ticket: @ashim ##https://develop.openfoam.com/Development/openfoam/-/issues/1513applyBoundaryLayer : fails when cell is disconnected2021-10-05T10:49:50ZPrashant SonakarapplyBoundaryLayer : fails when cell is disconnected<!--
*** 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
For disconnected cells wallDistance can have -1e15 (i.e. -GREAT) value, which can cause issue with ::pow
cross ref : EP#1158
<!-- Summarize the bug encountered concisely -->
### What is the current *bug* behaviour?
Fails with error (discriminator 1)
<!-- What actually happens -->
### Possible fixes
Warn user for non-visited cells. And protection in ::pow function?
<!--
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
-->
@Mattijsv2112Kutalmış BerçinKutalmış Berçinhttps://develop.openfoam.com/Development/openfoam/-/issues/1512Porting OpenFOAM to Windows2021-07-06T16:36:42ZAdminPorting OpenFOAM to WindowsHello,
Yesterday I have opened an [issue about OpenFOAM filenames in Windows](https://github.com/blueCFD/Core/issues/136) in BlueCFD project. Bruno, told me to open an issue here as well. This might be a potential solution to the probl...Hello,
Yesterday I have opened an [issue about OpenFOAM filenames in Windows](https://github.com/blueCFD/Core/issues/136) in BlueCFD project. Bruno, told me to open an issue here as well. This might be a potential solution to the problem of file naming in Windows (case insensitive).
In summary:
* Windows 10 now offers an optional case-sensitive file system, just like Linux and other UNIX-like operating systems. But this could be enabled on per-directory basis.
* Newer C++ compilers that support C++17, have `__has_include` feature for conditional including.
\## Reattaching the author to the issue ticket: @samir1291 ##https://develop.openfoam.com/Development/openfoam/-/issues/1511ensightReadFile ignores string limits2019-12-09T22:37:29ZMark OLESENensightReadFile ignores string limitsMark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/1510support specified time for transformPoints2019-12-15T21:09:38ZPrashant Sonakarsupport specified time for transformPoints### Functionality to add/problem to solve
transformPoints reads time from points instance. But it might be nice to operate on given time.
### Proposal
As discussed with @mark Use given time or default to constant### Functionality to add/problem to solve
transformPoints reads time from points instance. But it might be nice to operate on given time.
### Proposal
As discussed with @mark Use given time or default to constantMark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/1508isoSurfaceTopo not passing through ACMI2020-01-13T14:10:41ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comisoSurfaceTopo not passing through ACMIRun oscillatingInletACMI2D tutorial with
```
isoSurfaceTopo
{
type surfaces;
libs ("libsampling.so");
enabled true;
writeControl timeStep;
writeInterval 1;
interpolationScheme cellPoint;
surfaceFo...Run oscillatingInletACMI2D tutorial with
```
isoSurfaceTopo
{
type surfaces;
libs ("libsampling.so");
enabled true;
writeControl timeStep;
writeInterval 1;
interpolationScheme cellPoint;
surfaceFormat vtk;
// Fields to be sampled
fields
(
p
U
);
surfaces
(
isoSurface1
{
type isoSurfaceTopo;
patches ( ".*");
isoField p;
isoValue 0.1;
interpolate true;
triangulate false;
regularise cell; //diagcell;
}
);
}
```
and the isosurface does not pass through the acmi. This is due to the duplicate faces (ACMI+wall) on either side of the ACMI.Mattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comhttps://develop.openfoam.com/Development/openfoam/-/issues/1507Modify the static regIOobject::store method, possibly remove the member version?2024-02-20T15:58:37ZMark OLESENModify the static regIOobject::store method, possibly remove the member version?Just discussed with @Mattijs, following up on discussions with @andy
Given the scenario of having a local (unregistered) field
```
volScalarField* ptr = volScalarField:New(...).ptr(); // An unregistered pointer
```
I would later like...Just discussed with @Mattijs, following up on discussions with @andy
Given the scenario of having a local (unregistered) field
```
volScalarField* ptr = volScalarField:New(...).ptr(); // An unregistered pointer
```
I would later like to register this on its objectRegistry and have the registry take ownership.
- Using `ptr->store()` merely changes the ownership flag, but doesn't register.
- Using `ptr->checkIn()` will register it, but not take ownership.
The static `store()` version is just the same as the member one, with a nullptr check, but does not actually give ownership to the registry.
The static regIOobject::store() should probably attempt to check-in the object if not already marked as registered_.
If the object cannot be checked in, Fatal, Warn, or package as autoPtr for deletion?
Minor (style) - the objectRegistry debug diagnostics will warn about attempting to insert an object with identical name. Should probably check if existing object is actually different.Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/1506wrong sampling in arraySet.C line 722019-12-09T22:37:29ZAdminwrong sampling in arraySet.C line 72please change
`point pt(i*dx*i , j*dy, k*dz);`
to
`point pt(i*dx , j*dy, k*dz);`
- i am not allowed...please change
`point pt(i*dx*i , j*dy, k*dz);`
to
`point pt(i*dx , j*dy, k*dz);`
- i am not allowed...Mattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comhttps://develop.openfoam.com/Development/openfoam/-/issues/1505Failed start of simulation due to non-zero "defaultFaces" in a case converted...2019-12-19T08:53:00ZAdminFailed start of simulation due to non-zero "defaultFaces" in a case converted by gmshToFoam<!--
*** 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 -->
(I think this issue can be closed. I gave my analysis in the first comment.)
I intended to generate 2D mesh by `Gmsh` (latest version v4.4.1), and then convert it to `OpenFOAM` (latest version v1906) polyMesh by `gmshToFoam`.
But I found the utility "gmshToFoam" is unreliable. Two example cases are provided here. They have nearly the same configuration but produce different states of mesh conversion. After minor adjustment of the spatial coordinate of a control point in the geometry definition ("bridgeFlow.geo"), "gmshToFoam" might find some faces that belongs to none of any defined physical groups and label them as "`defaultFaces`" in "constant/polyMesh/boundary". By visualizing the patches, the internal wall, which is expected to be in the same patch, is found to be divided into two patches by `gmshToFoam`.
The non-zero "nFaces" of "defaultFaces" in "boundary" will make the following commands unable to proceed.
For example, errors will be met in the operation "`decomposePar`".
### Steps to reproduce
<!-- How one can reproduce the issue - this is very important -->
1. Have Gmsh v4.4.1 and OpenFOAM v1906 in the environment.
2. Extract zipped files in the example cases.
3. `cd example_failed` or `cd example_successful`
4. `gmsh -3 bridgeFlow.geo`
5. `gmshToFoam bridgeFlow.msh`
6. Open `constant/polyMesh/boundary` and check whether it has non-zero "defaultFaces".
### 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've uploaded two cases here. The only differences in their setup are Line 14 and Line 17 in `bridgeFlow.geo` in these two cases.
The "failed" one will produce non-zero "defaultFaces".
[example_failed.zip](/uploads/d69ae6d7064727938b0a894a74630d55/example_failed.zip)
[example_successful.zip](/uploads/fd7a016b47cf46d6785c815681c5fb3c/example_successful.zip)
### What is the current *bug* behaviour?
<!-- What actually happens -->
The utility `gmshToFoam` is unreliable. Sometime it works well (as in 'example_successful'), but after a minor modification of geometry setup of mesh (as in 'example_failed'),
it will generate non-zero `defaultFaces` in `constant/polyMesh/boundary` and make the workflow unable to proceed.
### What is the expected *correct* behavior?
<!-- What you should see instead -->
No `defaultFaces` appears in `constant/polyMesh/boundary`, as in 'example_successful'.
### 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.
-->
```
/*---------------------------------------------------------------------------*\
| ========= | |
| \\ / F ield | OpenFOAM: The Open Source CFD Toolbox |
| \\ / O peration | Version: v1906 |
| \\ / A nd | Web: www.OpenFOAM.com |
| \\/ M anipulation | |
\*---------------------------------------------------------------------------*/
Build : v1906 OPENFOAM=1906
Arch : "LSB;label=32;scalar=64"
Exec : gmshToFoam bridgeFlow.msh
Date : Nov 20 2019
Time : 01:08:37
PID : 5532
I/O : uncollated
Case : /mnt/c/python/Chamorro_thermal/DRL_girder_optimization/example_failed
nProcs : 1
trapFpe: Floating point exception trapping enabled (FOAM_SIGFPE).
fileModificationChecking : Monitoring run-time modified files using timeStampMaster (fileModificationSkew 10)
allowSystemOperations : Allowing user-supplied system call operations
// * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * //
Create time
Starting to read mesh format at line 2
Read format version 4.1 ascii 0
Starting to read physical names at line 5
Physical names:7
Surface 1 outlet
Surface 2 top
Surface 3 inlet
Surface 4 bottom
Surface 5 backAndFront
Surface 6 bridgeWall
Volume 7 bridgeFlow
Starting to read points at line 174
Vertices to be read: 14844
Vertices read: 14844
Starting to read cells at line 29989
Cells to be read:43860
Mapping region 5 to Foam patch 0
Mapping region 6 to Foam patch 1
Mapping region 1 to Foam patch 2
Mapping region 2 to Foam patch 3
Mapping region 3 to Foam patch 4
Mapping region 4 to Foam patch 5
Mapping region 7 to Foam cellZone 0
Cells:
total: 14513
hex : 0
prism: 14513
pyr : 0
tet : 0
CellZones:
Zone Size
0 14513
Skipping tag $Periodic at line 73888
Patch 0 gets name backAndFront
Patch 1 gets name bridgeWall
Patch 2 gets name outlet
Patch 3 gets name top
Patch 4 gets name inlet
Patch 5 gets name bottom
--> FOAM Warning :
From function Foam::polyMesh::polyMesh(const Foam::IOobject&, Foam::pointField&&, const cellShapeList&, const faceListList&, const wordList&, const wordList&, const Foam::word&, const Foam::word&, const wordList&, bool)
in file meshes/polyMesh/polyMeshFromShapeMesh.C at line 592
Found 29357 undefined faces in mesh; adding to default patch.
Finding faces of patch 0
Finding faces of patch 1
Finding faces of patch 2
Finding faces of patch 3
Finding faces of patch 4
Finding faces of patch 5
FaceZones:
Zone Size
1 24
Writing zone 0 to cellZone bridgeFlow and cellSet
Writing zone 1 to faceZone bridgeWall and faceSet
End
```
For the failed case, the block in `boundary` says:
```
defaultFaces
{
type patch;
nFaces 34;
startFace 50927;
}
```
I visualized the location of the 'defaultFaces' by Tecplot.
The 2D mesh layout looks like:
![location_of_defaultFaces](/uploads/9134ccea3d7116d1a838c4c7f39c49db/location_of_defaultFaces.png)
The internal wall is dyed with colors for each patch.
![location_of_defaultFaces_2](/uploads/9e66b9e5cbbbab84249a6444b6a2f69f/location_of_defaultFaces_2.png)
The whole internal wall should be in the same patch `bridgeWall`.
However, after the mesh conversion by `gmshToFoam`, the internal wall is divided into two patches: `bridgeWall` in the blue color and `defaultFaces` in the green color, as shown in the picture above.
### Environment information
<!--
Providing details of your set-up can help us identify any issues, e.g.
OpenFOAM version : v1906
Operating system : ubuntu
Compiler : pre-compiled binary for WSL of Win10
-->
- OpenFOAM version : v1906
- Operating system : ubuntu
- Compiler : pre-compiled binary for WSL of Win10
- Gmsh version : 4.4.1
\## Reattaching the author to the issue ticket: @lyupin ##https://develop.openfoam.com/Development/openfoam/-/issues/1504maintenance-v1812 does not compile: getOrDefault is not defined2019-12-09T22:37:29ZAdminmaintenance-v1812 does not compile: getOrDefault is not definedCommit d11cfca introduced use of getOrDefault, but this in not present in version 1812.Commit d11cfca introduced use of getOrDefault, but this in not present in version 1812.Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/1502adjointSolverName not set correctly in adjointWallVelocityLowRe2019-11-19T11:08:58ZVaggelis PapoutsisadjointSolverName not set correctly in adjointWallVelocityLowRe## Description
"Ua" is passed as the solverName argument in the adjointBoundaryCondition constructors of adjointWallVelocityLowRe. As a result, adjointWallVelocityLowRe cannot be used if useSolverNameForFields has been set to `true` in ...## Description
"Ua" is passed as the solverName argument in the adjointBoundaryCondition constructors of adjointWallVelocityLowRe. As a result, adjointWallVelocityLowRe cannot be used if useSolverNameForFields has been set to `true` in `optimisationDict`.
## Possible fixes
Replace
```c++
adjointBoundaryCondition(p, iF, "Ua")
```
with
```c++
adjointBoundaryCondition(p, iF, ptf.adjointSolverName_)
```
and
```c++
adjointBoundaryCondition(p, iF, dict.get<word>("solverName"))
```
in the second and third constructors of adjointWallVelocityLowRe.v1912AdminAdminhttps://develop.openfoam.com/Development/openfoam/-/issues/1501RASModelVariables::SpalartAllmaras cannot be combined with an fvMotionSolver ...2019-11-19T13:33:06ZVaggelis PapoutsisRASModelVariables::SpalartAllmaras cannot be combined with an fvMotionSolver diffusivity which depends on wall distances### Summary
When an fvMotionSolver using a distance-dependent diffusivity is used, wallDist names the distance field as "yPatch". However, RASModelVariables::SpalartAllmaras expects to find a field named "yWall" in the database. Since g...### Summary
When an fvMotionSolver using a distance-dependent diffusivity is used, wallDist names the distance field as "yPatch". However, RASModelVariables::SpalartAllmaras expects to find a field named "yWall" in the database. Since getObjectPtr returns a nullptr if the field is not found in the database, this bug is silenced but manifests later on when the pointer is dereferenced in adjointSpalartAllmaras.
### Possible fixes
Replace
```c++
dPtr_ = mesh_.getObjectPtr<volScalarField>("yWall");
```
with
```c++
dPtr_ = &(const_cast<volScalarField&>(wallDist::New(mesh_).y()));
```
so that wallDist.y() is retrieved, no matter what the actual name of the variable is.v1912AdminAdminhttps://develop.openfoam.com/Development/openfoam/-/issues/1500surfaceRedistributePar needs a dictionary2019-11-14T22:16:02ZAdminsurfaceRedistributePar needs a dictionary### Functionality to add/problem to solve
surfaceRedistributePar could benefit from having its own dictionary similar to decomposeParDict or surfaceFeatureExtractDict. That way we won't have to run the command line multiple times for mu...### Functionality to add/problem to solve
surfaceRedistributePar could benefit from having its own dictionary similar to decomposeParDict or surfaceFeatureExtractDict. That way we won't have to run the command line multiple times for multiple surfaces.
### Target audience
Anyone decomposing multiple surfaces
### Proposal
Have surfaceRedistributePar read a surfaceRedistributeParDict which has a list of surfaces and requires the distributionType to be listed for each surface (or use a global distributionType specified in this file).
### What does success look like, and how can we measure that?
When surfaceRedistributePar reads from a dictionary, I'll be happy.
### Funding
Nonehttps://develop.openfoam.com/Development/openfoam/-/issues/1498BUG: reading a labelList preceded by its size in a binary-format dictionary t...2020-01-23T12:35:17ZKutalmış BerçinBUG: reading a labelList preceded by its size in a binary-format dictionary throws FatalError<!--
*** 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 -->
When `FoamFile.format` is `binary` in a dictionary, a labelList keyword preceded by its size, e.g. `labelList 1(1);` is not read, and `FatalError` is thrown due to [operator>>](https://develop.openfoam.com/Development/OpenFOAM-plus/blob/OpenFOAM-v1906/src/OpenFOAM/containers/Lists/UList/UListIO.C#L201). The problem in practice is that [CSV.C](https://develop.openfoam.com/Development/OpenFOAM-plus/blame/master/src/OpenFOAM/primitives/functions/Function1/CSV/CSV.C#L281) writes out a labelList entry with its size at writeTime. When a restart is needed, the simulation fails.
### Steps to reproduce
<!-- How one can reproduce the issue - this is very important -->
`tutorials/combustion/reactingFoam/RAS/chokedNozzle`
Make the following changes thereat:
```
format binary;
```
```
componentColumns 1( 2 );
```
`./Allrun`
### 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 : dev-13Nov
- Operating system : osuse 15.1
- Compiler : gcc
cross-ref EP[#1176](https://exchange.openfoam.com/node/1176)
@markMark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/1497Error decomposing with redistributePar and codedFixedValue BC2021-07-07T07:54:39ZAdminError decomposing with redistributePar and codedFixedValue BC<!--
*** 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
Decomposing a case with `redistributePar` fails when `codedFixedValue` boundary condition is used.
<!-- Summarize the bug encountered concisely -->
### Steps to reproduce
A minimal example with `pitzDaily` has been attached. The error appears when executing the following commands:
```
blockMesh
mpirun -np 16 redistributePar -parallel -decompose
```
<!-- How one can reproduce the issue - this is very important -->
### Example case
`pitzDaily` tutorial. `0/U` file modified for reproducing the error.
[pitzDailyTest.zip](/uploads/a516c651c6e06aef2e2a8027c9156628/pitzDailyTest.zip)
<!--
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?
Trying to decompose with `redistributePar` any case that includes `codedFixedValue` fails.
Decomposition works with `decomposePar`, or `fixedValue` and `redistributePar` but fails including a basic `codedFixedValue` BC.
<!-- What actually happens -->
### Relevant logs and/or images
```
[10] --> FOAM FATAL IO ERROR:
[10] Attempt to put back onto bad stream
[10]
[10] file: IOstream at line 0
[11]
[11] file: IOstream.
[9]
[9] From function [5]
FOAM parallel run exiting
```
<!--
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 : centos
- Compiler : gcc
<!--
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
-->
## Reattaching the author to the issue ticket: @carpemonf ##Mattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.com