Development issueshttps://develop.openfoam.com/groups/Development/-/issues2023-12-13T17:03:48Zhttps://develop.openfoam.com/Development/openfoam/-/issues/2036cyclicACMI checkMesh2023-12-13T17:03:48ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comcyclicACMI checkMesh<!--
*** 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 re...<!--
*** 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 -->
checkMesh reports open cells if it detects different topology (i.e. presence of polyMesh/owner,boundary etc)
### Steps to reproduce
<!-- How one can reproduce the issue - this is very important -->
- run `tutorials/incompressible/pimpleFoam/RAS/oscillatingInletACMI2D`
- `cp constant/polyMesh/ 1/polyMesh/`
- `checkMesh` now reports open cells at time 1
### What is the current *bug* behaviour?
<!-- What actually happens -->
```
Checking geometry...
Overall domain bounding box (0 0 0) (3 1 0.1)
Mesh has 2 geometric (non-empty/wedge) directions (1 1 0)
Mesh has 2 solution (non-empty) directions (1 1 0)
All edges aligned with or perpendicular to non-empty directions.
***Boundary openness (-0.01030927835 3.144558878e-17 -4.584107381e-16) possible hole in boundary description.
***Open cells found, max cell openness: 0.3333333333, number of open cells 136
<<Writing 136 non closed cells to set nonClosedCells
```
### Environment information
- OpenFOAM version :v2012
### Possible fixes
It reports the AMI weights correctly. Maybe ordering of polyBoundaryMesh in polyMesh::readUpdate?
@Pawanhttps://develop.openfoam.com/Development/openfoam/-/issues/965cyclicACMIFvPatchField with non-overlap field constructed afterwards2018-11-09T05:25:16ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comcyclicACMIFvPatchField with non-overlap field constructed afterwardsIn case with ACMI: change e.g. 0/U to have the non-overlap bc (usually a wall) after the ACMI bc. If there is no initial value it will trigger 'evaluate' which will try to access the non-overlap patch field value - which has not been ini...In case with ACMI: change e.g. 0/U to have the non-overlap bc (usually a wall) after the ACMI bc. If there is no initial value it will trigger 'evaluate' which will try to access the non-overlap patch field value - which has not been initialised yet.Mattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comhttps://develop.openfoam.com/Development/openfoam/-/issues/2980cyclicAMI ignores patchNeighbourField in component-coupled linear solver2023-12-21T17:28:44ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comcyclicAMI ignores patchNeighbourField in component-coupled linear solver<!--
*** 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 re...<!--
*** Please read this first! ***
Before opening a new issue, make sure to search for keywords in the issues
filtered by the "bug" label and check to see if it has already been reported
You can see how your report will be rendered on the platform by using the
"preview" tab above
-->
<!--
All text between these markers are comments and will not be present in the
report
-->
### Summary
<!-- Summarize the bug encountered concisely -->
The non-blocking cyclicAMI (!623) ignores patchNeighbourField in component-coupled linear solver
2) clone-with-new internalfield also copies patchNeighbourfield. Generally a new internalfield also introduces new values (?) so the patch-neighbour field should be updated
### Steps to reproduce
<!-- How one can reproduce the issue - this is very important -->
Visual inspection of the code.
### 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
-->
any cyclicAMI with distributed AMI, e.g. mixerVesselAMI2D tutorial
### Environment information
<!--
Providing details of your set-up can help us identify any issues, e.g.
OpenFOAM version : v2306|v2212|v2206|v2112|v2106 etc
Operating system : ubuntu|openSUSE|centos etc
Hardware info : any info that may help?
Compiler : gcc|intel|clang etc
-->
- OpenFOAM version : >v2306
- Operating system :
- Hardware info :
- Compiler :
### Possible fixes
<!--
If you can, link to the line of code that might be responsible for the
problem
The "/label ~bug" text is a gitlab flag that will add the "bug" label to this
issue
-->
@markMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comhttps://develop.openfoam.com/Development/openfoam/-/issues/930cyclicAMI not robust for perpendicular triangles; plane normal2019-12-09T22:22:46ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comcyclicAMI not robust for perpendicular triangles; plane normalOn badly matching AMI patches the individual triangles can be perpendicular to the projection normal. If they are exactly perpendicular this can cause division by zero.
See ep 704.
```
--> FOAM Warning :
From function Foam::plane:...On badly matching AMI patches the individual triangles can be perpendicular to the projection normal. If they are exactly perpendicular this can cause division by zero.
See ep 704.
```
--> FOAM Warning :
From function Foam::plane::plane(const point&, const vector&, bool)
in file meshes/primitiveShapes/plane/plane.C at line 145
plane normal has zero length. base point:(2.492624677978299 0.7945491940387345 -0.06079065865800785)
```Mattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comhttps://develop.openfoam.com/Development/openfoam/-/issues/2983cyclicAMI requires up-to-date neighbourPatch field2023-12-21T15:49:11ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comcyclicAMI requires up-to-date neighbourPatch field<!--
*** 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 re...<!--
*** 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 -->
cyclicAMI in non-blocking mode (#2963) produces different results
### Steps to reproduce
<!-- How one can reproduce the issue - this is very important -->
Run `incompressible/pimpleFoam/laminar/mixerVesselAMI2D/mixerVesselAMI2D` tutorial even for one time step. Initial residuals on U of 2nd pimple are different from v2306.
### Example case
See above
<!--
If possible, please create a SMALL example and attach it to your report
If you are using an older version of OpenFOAM this will also determine
whether the bug has been fixed in a more recent version
-->
### What is the current *bug* behaviour?
<!-- What actually happens -->
The stress term (nuEff*dev2(T(grad(U))))) is not consistent across the cyclicAMI. In the old formulation it would be calculated - in the new one it is stored/cached and updated during the evaluation. However this intermediate calculation is not evaluated.
### What is the expected *correct* behavior?
<!-- What you should see instead -->
Same as v2306.
### 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 : v2306|v2212|v2206|v2112|v2106 etc
Operating system : ubuntu|openSUSE|centos etc
Hardware info : any info that may help?
Compiler : gcc|intel|clang etc
-->
- OpenFOAM version : v2307
- Operating system :
- Hardware info :
- Compiler :
### Possible fixes
This is can be solved by
- disabling caching of neighbourValue in cyclicAMI. Note that linear-solver behaviour is ok.
- or tag neighbourValue with timestamp of internal field (using regIOobject::upToDate)
- or going to fully consistent cyclicAMI values (https://develop.openfoam.com/Development/openfoam/-/tree/feature-evaluation-check?ref_type=heads)
<!--
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
-->
@markv2312https://develop.openfoam.com/Development/openfoam/-/issues/3119cyclicAMI startup without 'value'2024-03-27T10:02:05ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comcyclicAMI startup without 'value'<!--
*** 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 re...<!--
*** 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 -->
cyclicAMI parallel start without 'value' entry can fail
### Steps to reproduce
<!-- How one can reproduce the issue - this is very important -->
E.g. `tutorials/incompressible/pimpleFoam/laminar/mixerVesselAMI2D/mixerVesselAMI2D`
- decompose into 4
- remove the 'value' entry from the processor*/0/U field for the cyclicAMI
- this will force the call to evaluate which will give e.g.
```
[3] --> FOAM FATAL ERROR: (openfoam-2401 patch=240220)
[3] From processor 0 : unallocated receive field. Expected size 36 on comm 0 with procs 4
[3]
[3]
[3] From static void Foam::mapDistributeBase::receive(Foam::label, const labelListList&, bool, const Foam::labelRange&, const Foam::UPtrList<Foam::List<T> >&, Foam::List<T>&, const CombineOp&, const negateO
p&, int, Foam::label) [with T = Foam::Vector<double>; CombineOp = Foam::eqOp<Foam::Vector<double> >; negateOp = Foam::flipOp; Foam::label = int; Foam::labelListList = Foam::List<Foam::List<int> >]
[3] in file /home/bigbuzz2/mattijs/OpenFOAM/OpenFOAM-plus/work/develop/src/OpenFOAM/lnInclude/mapDistributeBaseTemplates.C at line 350.
```
### Environment information
<!--
Providing details of your set-up can help us identify any issues, e.g.
OpenFOAM version : v2312|v2306|v2212|v2206|v2112 etc
Operating system : ubuntu|openSUSE|centos etc
Hardware info : any info that may help?
Compiler : gcc|intel|clang etc
-->
- OpenFOAM version : v2312
### 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
-->
- switch off local-consistency so it takes the old path.Mattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comhttps://develop.openfoam.com/Development/openfoam/-/issues/2175cyclicAMI with implicit solution2021-11-02T16:03:55ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comcyclicAMI with implicit solution<!--
*** 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 re...<!--
*** 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 -->
cyclicAMIFvPatchField seems to be using the patch faceCells instead of the assembly faceCells for low-weight correction.
### What is the current *bug* behaviour?
<!-- What actually happens -->
Visual inspection:
```
cyclicAMIFvPatchField<Type>::updateInterfaceMatrix
```
uses lduAddr.patchAddr to go from patch face to cell but also patch.faceCells() to get default values.
### What is the expected *correct* behavior?
<!-- What you should see instead -->
### Relevant logs and/or images
<!--
Paste any relevant logs - please use code blocks (```) to format console
output, logs, and code as it's very hard to read otherwise.
-->
### Environment information
<!--
Providing details of your set-up can help us identify any issues, e.g.
OpenFOAM version : v1806|v1812|v1906|v1912|v2006|v2012|v2106 etc
Operating system : ubuntu|openSUSE|centos etc
Hardware info : any info that may help?
Compiler : gcc|intel|clang etc
-->
- OpenFOAM version : v2112Sergio FerrarisSergio Ferrarishttps://develop.openfoam.com/Development/openfoam/-/issues/2693cyclicAMI with transformations not supported for wall distance2023-06-26T10:33:39ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comcyclicAMI with transformations not supported for wall distance<!--
*** 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 re...<!--
*** 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 -->
Wall distance uses internally the FaceCellWave class. This operates on cyclicAMI on a slice of the face-based data, i.e. it modifies in-place the face-based data. This means that when the neighbour patch gets evaluated it operates on the modified data and this gives problems.
- only with cyclicAMI, cyclic is ok
- only if transformations are applied
### Steps to reproduce
<!-- How one can reproduce the issue - this is very important -->
Below case is a hack of the pipeCyclic tutorial. It puts additional walls inside the domain (see ./Allrun script). Run `checkMesh -writeFields '(wallDistance)'` to trigger wall distance evaluation. It will give an error about same transformation applied with different signs.
### Example case
[pipeCyclic_with_baffles.tgz](/uploads/e0ec13f06a6ea24bb889bce4f9e0540c/pipeCyclic_with_baffles.tgz)
<!--
If possible, please create a SMALL example and attach it to your report
If you are using an older version of OpenFOAM this will also determine
whether the bug has been fixed in a more recent version
-->
### What is the current *bug* behaviour?
<!-- What actually happens -->
Error inside globalIndexAndTransform.
### What is the expected *correct* behavior?
<!-- What you should see instead -->
### Relevant logs and/or images
<!--
Paste any relevant logs - please use code blocks (```) to format console
output, logs, and code as it's very hard to read otherwise.
-->
### Environment information
<!--
Providing details of your set-up can help us identify any issues, e.g.
OpenFOAM version : v2212|v2206|v2112|v2106|v2012 etc
Operating system : ubuntu|openSUSE|centos etc
Hardware info : any info that may help?
Compiler : gcc|intel|clang etc
-->
- OpenFOAM version :v2212
### 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
-->Mattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comhttps://develop.openfoam.com/Development/openfoam/-/issues/1784cyclic BC in blockMeshDict -> snappyHexMesh not in parallel mode2021-07-07T09:03:18ZAlexander Kospachcyclic BC in blockMeshDict -> snappyHexMesh not in parallel modeHi,
I have noticed that when I added my cyclic BC in my blockMeshDict directly I can't perform snappyHexMesh in parallel mode.
Then I always get the error message:
face area does not match to neighbour by 22.222% possible face orderin...Hi,
I have noticed that when I added my cyclic BC in my blockMeshDict directly I can't perform snappyHexMesh in parallel mode.
Then I always get the error message:
face area does not match to neighbour by 22.222% possible face ordering problem
When I don't add the cyclic BC in my blockMeshDict I don't get the error messagehttps://develop.openfoam.com/Development/openfoam/-/issues/2305cyclic not consistent2021-12-21T12:33:42ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comcyclic not consistent<!--
*** 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 re...<!--
*** 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 -->
cyclic behaviour visible
### Example case
tutorial : incompressible/pimpleFoam/LES/periodicHill/steadyState
Run for e.g. 10 time steps. Look at velocity on top. There are oscillations on the cyclic inlet/outlet. Same happens in parallel.
### 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.
-->
![processorCyclic_U](/uploads/eeaf860293933f2fdfa6ebe576ac1227/processorCyclic_U.png)
### Environment information
<!--
Providing details of your set-up can help us identify any issues, e.g.
OpenFOAM version : v1806|v1812|v1906|v1912|v2006|v2012|v2106 etc
Operating system : ubuntu|openSUSE|centos etc
Hardware info : any info that may help?
Compiler : gcc|intel|clang etc
-->
- OpenFOAM version :v2112
- Operating system :
- Hardware info :
- Compiler :
### Possible fixes
<!--
If you can, link to the line of code that might be responsible for the
problem
The "/label ~bug" text is a gitlab flag that will add the "bug" label to this
issue
-->https://develop.openfoam.com/Development/openfoam/-/issues/2145cyclicPeriodicAMI does not transform contributions2021-09-16T17:49:21ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comcyclicPeriodicAMI does not transform contributions<!--
*** 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 re...<!--
*** 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 -->
cyclicPeriodicAMI uses underlying cyclicAMI to do area weighted interpolation. It uses an underlying patch to provide a transform for the geometry to obtain full coverage. It however does not use this transform to do interpolation so non-scalar properties are interpolated incorrectly (if using a rotational periodicity, not for planar periodicity)
### Steps to reproduce
<!-- How one can reproduce the issue - this is very important -->
tutorial combustion/XiDyMFoam/annularCombustorTurbine
Check any of the tangential components of the velocity.
### What is the current *bug* behaviour?
<!-- What actually happens -->
Discontinuity (in the tangential component) where the target is partially overlapped so it requires another transform to do full coverage.
### What is the expected *correct* behavior?
<!-- What you should see instead -->
No discontinuity.
### 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 : v2106
### 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
-->
Ideas:
- have multiple AMI, each with their own transformation
- tag AMI addressing with their transformation
- interpolate in cylindrical coordinate system (produces slight inconsistency between weights (since from overlap areas calculated in global coordinate system) and values)
@andy @PrashantMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comhttps://develop.openfoam.com/Development/openfoam/-/issues/2226cyclicPeriodicAMI uses wrong lowWeightCorrection2021-10-13T15:59:20ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comcyclicPeriodicAMI uses wrong lowWeightCorrection<!--
*** 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 re...<!--
*** 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 -->
cyclicPeriodicAMI transforms 'lowWeightCorrection' supplied values using the nbr transformation instead of the local.
### Steps to reproduce
<!-- How one can reproduce the issue - this is very important -->
Take any cyclicPeriodicAMI case with differing number of faces on source and target. Set lowWeightCorrection to 1. Should trigger memory error.
### Environment information
<!--
Providing details of your set-up can help us identify any issues, e.g.
OpenFOAM version : v1806|v1812|v1906|v1912|v2006|v2012|v2106 etc
Operating system : ubuntu|openSUSE|centos etc
Hardware info : any info that may help?
Compiler : gcc|intel|clang etc
-->
- OpenFOAM version : develop at Sept 2021https://develop.openfoam.com/Development/openfoam/-/issues/2606CylicAMI incompatible with scaling of mesh2024-01-10T11:09:06Zfranco otaolaCylicAMI incompatible with scaling of 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
You can see how your report will be re...<!--
*** 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 -->
Hello,
there is a bug regarding the cyclicAMI patches to be more precise regarding the separationVector (at least I think it commes from that).
if we create a mesh that we assign a pair of cyclicAMI patches source and target, and we check the mesh, where we obtain correct AMI weights, if the we scale the mesh with transformPoints(I would guess that this behavior is the same one for the other transformations) the cyclicAMI breakes completly, even in the checkMesh output we can see that the weights are 0.
### Steps to reproduce
<!-- How one can reproduce the issue - this is very important -->
create a mesh with snappyHexMesh
use createPatch to create two cyclicAMI patches that are linked by "transform translational;"
checkMesh to be sure that the AMI weights are correct
scale the mesh using transformPoints -scale 1000
checkMesh again, the AMI weights will explode completly
### Example case
<!--
If possible, please create a SMALL example and attach it to your report
If you are using an older version of OpenFOAM this will also determine
whether the bug has been fixed in a more recent version
-->
### What is the current *bug* behaviour?
<!-- What actually happens -->
the source cyclicAMI patch unlinks from its cyclicAMI target patch after scaling the mesh
### What is the expected *correct* behavior?
<!-- What you should see instead -->
the source and target cyclicAMI patches should stay linked even after doing a transformation of points
### 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 : v2206|v2112|v2106|v2012|v2006 etc
Operating system : ubuntu|openSUSE|centos etc
Hardware info : any info that may help?
Compiler : gcc|intel|clang etc
-->
- OpenFOAM version :2206
- Operating system :ubuntu
- Hardware info :
- Compiler :
### Possible fixes
<!--
If you can, link to the line of code that might be responsible for the
problem
The "/label ~bug" text is a gitlab flag that will add the "bug" label to this
issue
-->https://develop.openfoam.com/Development/openfoam/-/issues/392Dahl case in driftFluxFoan fails - Reappearance of a previous bug2018-05-29T05:39:48ZAdminDahl case in driftFluxFoan fails - Reappearance of a previous bugThe bug reported for driftFluxFoam (ID 0002317) and fixed in November 2016 is still in a fresh install of openFoam 4.1 I downloaded last week. Same symptoms: run the Dahl case for 300 simulation-seconds. No settling (contrast to a run I'...The bug reported for driftFluxFoam (ID 0002317) and fixed in November 2016 is still in a fresh install of openFoam 4.1 I downloaded last week. Same symptoms: run the Dahl case for 300 simulation-seconds. No settling (contrast to a run I'd stored from openFoam 2.1) and paraFoam shows just some minor distortion in the alpha.sludge field by one edge. Behaviour reproduces in a 3D case with my own mesh.https://develop.openfoam.com/Development/openfoam/-/issues/2664Darwin-specific wmake rule prevents compilation with CGAL 52023-02-21T13:32:14ZGabriel GerleroDarwin-specific wmake rule prevents compilation with CGAL 5<!--
*** 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 re...<!--
*** 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 -->
Darwin/macOS-specific wmake rule at `wmake/rules/darwin64Clang/cgal` causes macOS builds to fail with a linker error with CGAL versions >= 5
### Steps to reproduce
Compile OpenFOAM on macOS with CGAL version >= 5
Note: CGAL versions >= 5.5 are also affected by #2665
### 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
-->
N/A
### What is the current *bug* behaviour?
<!-- What actually happens -->
Linker error `ld: library not found for -lCGAL` (note: CGAL >= 5 is header-only)
### What is the expected *correct* behavior?
<!-- What you should see instead -->
Build succeeds
### 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.
-->
```
wmake PolyhedronReader
link: /Volumes/OpenFOAM-v2206/platforms/darwin64ClangDPInt32Opt/lib/libPolyhedronReader.dylib
ld: library not found for -lCGAL
clang: error: linker command failed with exit code 1 (use -v to see invocation)
make[3]: *** [/Volumes/OpenFOAM-v2206/platforms/darwin64ClangDPInt32Opt/lib/libPolyhedronReader.dylib] Error 1
make[2]: *** [surfaceBooleanFeatures] Error 2
make[1]: *** [surface] Error 2
```
### Environment information
<!--
Providing details of your set-up can help us identify any issues, e.g.
OpenFOAM version : v2206|v2112|v2106|v2012|v2006 etc
Operating system : ubuntu|openSUSE|centos etc
Hardware info : any info that may help?
Compiler : gcc|intel|clang etc
-->
- OpenFOAM version : v2206|v2112|master|develop
- Operating system : macOS
- Hardware info : arm64|x86_64
- Compiler : clang
### 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
-->
Delete the [`wmake/rules/darwin64Clang/cgal` file](https://develop.openfoam.com/Development/openfoam/-/blob/8993af73ac6e58fd9741a3accc8e52eeb37e40ee/wmake/rules/darwin64Clang/cgal). I have tried this and can report that OpenFOAM will build with CGAL 5 on macOS if this specific file is deleted.
Additional note: the `wmake/rules/darwin64Clang/cgal` rule seems to be written for CGAL 4 (i.e., before CGAL went header-only). ~~I'm aware that, as of the current `develop` branch, OpenFOAM won't build with CGAL 4.x anymore (at least on macOS), so this fix becomes more important for macOS users.~~ EDIT: this last part doesn't seem to be true as of v2212, but CGAL 4 is now an old version anywayMark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/1757dash bug with string expansion and assignment of default values2020-11-26T13:55:23ZMark OLESENdash bug with string expansion and assignment of default valuesNoticed when compiling OpenFOAM-v2006 modules with ubuntu _bionic_ (18.04) that the module prefix is not being correctly set. Seems to be a weird bug in the `dash` shell expansions.
Starting from any non-root directory
```
echo "$PWD"
-...Noticed when compiling OpenFOAM-v2006 modules with ubuntu _bionic_ (18.04) that the module prefix is not being correctly set. Seems to be a weird bug in the `dash` shell expansions.
Starting from any non-root directory
```
echo "$PWD"
-> /home/user/openfoam/BuildEnv/scratch
```
dash 0.5.8-2.10 (bionic) shows this
```
unset test1
echo "${test1:=${PWD%/*}}"
-> /home/user/openfoam/BuildEnv/scratch <-- WHAT?? Not what we expected
```
The additional quotes cause incorrect expansion. Whereas
```
unset test1
echo ${test1:=${PWD%/*}}
-> /home/user/openfoam/BuildEnv <-- Expected
```
- bash and dash 0.5.10.2-6 (focal) work as expected, with/without quotes
- quoted expansion with `:-` works as expected.
Possible fixes?
- https://git.kernel.org/pub/scm/utils/dash/dash.git/commit/?id=48ca00863af909461d1372998bb90549f27abaaf
- https://git.kernel.org/pub/scm/utils/dash/dash.git/commit/?id=a29e9a1738a4e7040211842f3f3d90e172fa58ce
- https://git.kernel.org/pub/scm/utils/dash/dash.git/commit/?id=878514712c5d21f675c45d99d2f8a04098ea4a19
Possible workarounds
- use unqoted version, but risk fixing it on the next shellcheck
- explicit `if [ -z VAR ]; then ...; fi` construct
- with dirname as `: "${VAR:=$(dirname xxx)}`Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/111data alignment cause gap in particle binary representation2016-06-30T22:09:37ZMark OLESENdata alignment cause gap in particle binary representationReplacing the bool 'active' with an int value uses the same space and provides a more predictable layout in memory, which is useful when working directly with the binary chunks.
Changing to int also permits future uses to mark different...Replacing the bool 'active' with an int value uses the same space and provides a more predictable layout in memory, which is useful when working directly with the binary chunks.
Changing to int also permits future uses to mark different states.Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/2797"data" from faMesh same registration as fvMesh2023-12-21T16:00:42ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.com"data" from faMesh same registration as fvMesh### Functionality to add/problem to solve
faSolution constructs 'data' database. This is the same name as that from fvSolution.
Run e.g. `liquidFilmFoam/cylinder` with
```
DebugSwitches
{
regIOobject 2;
objectRegistry 1;
...### Functionality to add/problem to solve
faSolution constructs 'data' database. This is the same name as that from fvSolution.
Run e.g. `liquidFilmFoam/cylinder` with
```
DebugSwitches
{
regIOobject 2;
objectRegistry 1;
}
```
and you'll see
```
--> FOAM FATAL ERROR: (openfoam-2302 patch=230110)
failed to register object ".../tutorials/finiteArea/liquidFilmFoam/cylinder/system/data" the name already exists in the objectRegistry
```
### Proposal
Not sure if it is a problem. Does mean that items registered on data need to have different names.
@kutiv2406Kutalmış BerçinKutalmış Berçinhttps://develop.openfoam.com/Development/openfoam/-/issues/1994Dead code, Unused files2024-01-11T18:18:23ZVolker WeißmannDead code, Unused filesI wanted to report that the following files seem to be dead code (grep $FILENAME did not find anything).
You might want to delete them.
```
dead code: graphTest2.C
dead code: Test-ExtendedStencil2.C
dead code: basicSymmetryFaPatchFields...I wanted to report that the following files seem to be dead code (grep $FILENAME did not find anything).
You might want to delete them.
```
dead code: graphTest2.C
dead code: Test-ExtendedStencil2.C
dead code: basicSymmetryFaPatchFields.C
dead code: extendedFeatureEdgeMeshTemplates.C
dead code: PolynomialIO.C
dead code: curveTools.C
dead code: findRefCells.C
dead code: unweightedLeastSquaresVectors.C
dead code: invDistLeastSquaresVectors.C
dead code: fvcSimpleReconstruct.C
dead code: adjointZeroInletFvPatchFieldsFwd.C
dead code: adjointBoundaryConditionTemplates.C
dead code: fluent3DMeshToFoam.L.C
dead code: fluentMeshToFoam.L.C
dead code: ansysToFoam.L.C
dead code: gambitToFoam.L.C
dead code: STLAsciiParseFlex.L.C
dead code: chemkinLexer.L.C
```
grep $FILENAME also fails for the following files, but you propabley don't want to delete them
```
dead code: _TemplateTemplate.C
dead code: _TemplateTemplateIO.C
dead code: _TemplateApp.C
dead code: _TemplateIO.C
dead code: _Template.C
```https://develop.openfoam.com/Development/openfoam/-/issues/2074Dead link on homepage2021-04-27T17:10:20ZJohan RoenbyDead link on homepageThe link to https://www.develop.openfoam.com in the 2nd bullet point here is wrong:
[https://www.openfoam.com/governance/how-to-get-involved](https://www.openfoam.com/governance/how-to-get-involved)
It should be https://develop.openfoa...The link to https://www.develop.openfoam.com in the 2nd bullet point here is wrong:
[https://www.openfoam.com/governance/how-to-get-involved](https://www.openfoam.com/governance/how-to-get-involved)
It should be https://develop.openfoam.com