Development issueshttps://develop.openfoam.com/groups/Development/-/issues2020-12-21T14:15:42Zhttps://develop.openfoam.com/Development/openfoam/-/issues/1965Attempt to cast type zeroGradient to type nutWallFunction2020-12-21T14:15:42ZRichard LoveAttempt to cast type zeroGradient to type nutWallFunction<!--
*** 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
When trying to simulate turbulent flow over open terrain using a k-epsilon model and RAS turbulence with inlet and outlet as type patch, the solver begins to solve for ux, uy, uz and it then fails with the warning 'FOAM FATAL ERROR:
Attempt to cast type zeroGradient to type nutWallFunction
However when the patch types in constant are changed to wall, the solution begins to run. As I am trying to simulate turbulent flow over terrain, these patch types are not suitable
![SimulationFail](/uploads/89dff3d7c72be324041e1528d3403596/SimulationFail.png)
If there is any more information you require, please get in touch at love-r3@ulster.ac.uk
### Steps to reproduce
The boundary file setup is seen at this link https://www.cfd-online.com/Forums/openfoam-solving/232526-attempt-cast-type-zerogradient-type-nutwallfunction.html.
It is being simulated through a simple cuboid blockMesh with an STL file connected via snappyHexMesh, however it does not run, even without the STL
[blockMeshDict](/uploads/c54f08fb6b054b745534c1d24765669d/blockMeshDict)
[fvSchemes](/uploads/bfb95abd1186f0eed24e22fc08c634bb/fvSchemes)
[fvSolution](/uploads/70590e40f1c178ddc7e3d73271465095/fvSolution)
[controlDict](/uploads/d187d57856b4434bc44876caba6e54b7/controlDict)[turbulenceProperties](/uploads/ace56000d2f453002e6c84d7d0060e02/turbulenceProperties)
[transportProperties](/uploads/8322db7b9ce95ed211e41a7053d4bf7d/transportProperties)
[RASProperties](/uploads/a704d4b90b9d423c13384072029988b4/RASProperties)
### 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?
It creates an error when I try and have nut type as 'zeroGradient' inside the nut file when inlet/outlet/top is type patch
### What is the expected *correct* behavior?
It should run without cancelling when the polymesh/boundary is type patch
### Relevant logs and/or images
dimensions [0 2 -1 0 0 0 0];
internalField uniform 0;
boundaryField
{
#include "include/ABLConditions"
inlet
{
type zeroGradient;
//value uniform 0.0;
}
outlet
{
type zeroGradient;
//value uniform 0;
}
top
{
type zeroGradient;
//value uniform 0;
}
DuneField
{
type nutkAtmRoughWallFunction;
z0 $z0;
value uniform 0;
}
}
### Environment information
<!--
Providing details of your set-up can help us identify any issues, e.g.
OpenFOAM version : v7
Operating system : ubuntu
Hardware info : any info that may help?
Compiler : gcc|intel|clang etc
-->
- OpenFOAM version :7
- Operating system :ubuntu
- Hardware info :
- Compiler :
### Possible fixes
<!--
'--> FOAM FATAL ERROR:
Attempt to cast type zeroGradient to type nutWallFunction
From function To& Foam::refCast(From&) [with To = const Foam::nutWallFunctionFvPatchScalarField; From = const Foam::fvPatchField<double>]
in file /home/ubuntu/OpenFOAM/OpenFOAM-7/src/OpenFOAM/lnInclude/typeInfo.H at line 114'
The "/label ~bug" text is a gitlab flag that will add the "bug" label to this
issue
-->https://develop.openfoam.com/Development/openfoam/-/issues/1966Attempt to cast type zeroGradient to type nutWallFunction2022-05-18T16:24:14ZRichard LoveAttempt to cast type zeroGradient to type nutWallFunction<!--
*** 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 r...<!--
*** 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 trying to simulate turbulent flow over open terrain using a k-epsilon model and RAS turbulence with inlet and outlet as type patch, the solver begins to solve for ux, uy, uz it then fails with the warning 'FOAM FATAL ERROR:
Attempt to cast type zeroGradient to type nutWallFunction
However when the patch types are changed to wall, the solution begins to run. As I am trying to simulate turbulent flow over terrain, these patch types are not suitable
### Steps to reproduce
The boundary file setup is seen at this link https://www.cfd-online.com/Forums/openfoam-solving/232526-attempt-cast-type-zerogradient-type-nutwallfunction.html.
It is being simulated through a simple cuboid blockMesh with an STL file connected via snappyHexMesh, however it does not run, even without the STL
[turbulenceProperties](/uploads/3b775d89696e3786c03e2a23bdbf3f90/turbulenceProperties)
[transportProperties](/uploads/39728733afb4007480a875154cc8e6de/transportProperties)
[RASProperties](/uploads/a8a00019cea3ab230150071fc26c9bf1/RASProperties)
[blockMeshDict](/uploads/9a12cca225887bd0209acc4d980f8eef/blockMeshDict)
[fvSchemes](/uploads/409738413058113cc5fdb1e19e08b6ac/fvSchemes)
[fvSolution](/uploads/5a3040145a70fd66b825e7d0054e262d/fvSolution)
[controlDict](/uploads/5914e8730c615960862e37bd68c4cd8f/controlDict)
### 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?
It creates an error when I try and have any of the patch types as 'zeroGradient' inside the nut file when inlet, outlet or top type is type patch
[boundary](/uploads/6b2336f3559c83a58af31b0cd6becb62/boundary)
### What is the expected *correct* behavior?
It should run without cancelling as type patch, and making the type be wall in order to run
### Relevant logs and/or images
dimensions [0 2 -1 0 0 0 0];
internalField uniform 0;
boundaryField
{
#include "include/ABLConditions"
inlet
{
type zeroGradient;
//value uniform 0.0;
}
outlet
{
type zeroGradient;
//value uniform 0;
}
top
{
type zeroGradient;
//value uniform 0;
}
DuneField
{
type nutkAtmRoughWallFunction;
z0 $z0;
value uniform 0;
}
}
### Environment information
<!--
Providing details of your set-up can help us identify any issues, e.g.
OpenFOAM version : v7
Operating system : ubuntu
Hardware info : any info that may help?
Compiler : gcc|intel|clang etc
-->
- OpenFOAM version :7
- Operating system :ubuntu
- Hardware info :
- Compiler :
### Possible fixes
<!--
'--> FOAM FATAL ERROR:
Attempt to cast type zeroGradient to type nutWallFunction
From function To& Foam::refCast(From&) [with To = const Foam::nutWallFunctionFvPatchScalarField; From = const Foam::fvPatchField<double>]
in file /home/ubuntu/OpenFOAM/OpenFOAM-7/src/OpenFOAM/lnInclude/typeInfo.H at line 114'
The "/label ~bug" text is a gitlab flag that will add the "bug" label to this
issue
-->v2206Kutalmış BerçinKutalmış Berçinhttps://develop.openfoam.com/Development/openfoam/-/issues/1967Tutorial forces FO has log entry twice2022-05-06T10:04:17ZRoger AlmenarTutorial forces FO has log entry twicePropeller tutorial, under incompressible/pimpleFoam/RAS/propeller/system/forces has log entry twice, once as yes, and another one as true.Propeller tutorial, under incompressible/pimpleFoam/RAS/propeller/system/forces has log entry twice, once as yes, and another one as true.https://develop.openfoam.com/Development/openfoam/-/issues/1968interfaceTrackingFvMesh does not implement two-step constructor2020-12-22T15:06:52ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.cominterfaceTrackingFvMesh does not implement two-step constructor<!--
*** 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 -->
Unallocated motionSolver in interfaceTrackingFvMesh
### Steps to reproduce
<!-- How one can reproduce the issue - this is very important -->
run
incompressible/pimpleFoam/laminar/contactAngleCavity
### What is the current *bug* behaviour?
<!-- What actually happens -->
log.pimpleFoam: unallocated autoPtr of type N4Foam12motionSolverE
### 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 : develop
@Prashant @andyMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comhttps://develop.openfoam.com/Development/openfoam/-/issues/1969windows testcase 2012: failing2024-01-09T12:15:33ZPawan Ghildiyalwindows testcase 2012: failing@mark : cases failing for windows
> **Case :** interFoam/laminar/capillaryRise
![image](/uploads/4145c1ca4a334b2f09174c9c4a0e28bb/image.png)
Adding in EXE_LIBS following lib resolve issue -ltwoPhaseProperties
> Case2: heatTransfe...@mark : cases failing for windows
> **Case :** interFoam/laminar/capillaryRise
![image](/uploads/4145c1ca4a334b2f09174c9c4a0e28bb/image.png)
Adding in EXE_LIBS following lib resolve issue -ltwoPhaseProperties
> Case2: heatTransfer/chtMultiRegionSimpleFoam/jouleHeatingSolid
failing to read variable jouleSource*:V. (looks issue with having colon in name of files
![image](/uploads/676102d50484e0516d752125c6ac277c/image.png)https://develop.openfoam.com/Development/openfoam/-/issues/1970The dummy Pstream library cannot be used in parallel mode2022-03-25T10:25:16ZNikola MajksnerThe dummy Pstream library cannot be used in parallel mode### Summary
It's not possible to run any parallel commands with mpirun. I've also tried recommendations from https://develop.openfoam.com/Development/openfoam/-/issues/1817 but it didn't help.
### Steps to reproduce
```shell
$ docker ...### Summary
It's not possible to run any parallel commands with mpirun. I've also tried recommendations from https://develop.openfoam.com/Development/openfoam/-/issues/1817 but it didn't help.
### Steps to reproduce
```shell
$ docker run -it ubuntu bash
$ apt update && apt install -y sudo curl
$ curl -s https://dl.openfoam.com/add-debian-repo.sh | sudo bash
$ apt-get install -y openfoam2012-default
$ adduser openfoam
$ source /usr/lib/openfoam/openfoam2012/etc/bashrc
$ cp -r /usr/lib/openfoam/openfoam2012/tutorials/incompressible/simpleFoam/motorBike/ .
$ cd motorBike
$ ./Allrun
```
### What is the current *bug* behaviour?
None of the parallel commands that requires mpirun are working
### What is the expected *correct* behavior?
All mpirun commands to work
### Relevant logs and/or images
The First parallel command in tutorial is snappyHexMesh. All other commands that run in parallel have the same errors.
```
--> FOAM FATAL ERROR: (openfoam-2012)
The dummy Pstream library cannot be used in parallel mode
From static bool Foam::UPstream::init(int&, char**&, bool)
in file UPstream.C at line 50.
FOAM exiting
--> FOAM FATAL ERROR: (openfoam-2012)
The dummy Pstream library cannot be used in parallel mode
From static bool Foam::UPstream::init(int&, char**&, bool)
in file UPstream.C at line 50.
FOAM exiting
--------------------------------------------------------------------------
Primary job terminated normally, but 1 process returned
a non-zero exit code. Per user-direction, the job has been aborted.
--------------------------------------------------------------------------
--> FOAM FATAL ERROR: (openfoam-2012)
The dummy Pstream library cannot be used in parallel mode
From static bool Foam::UPstream::init(int&, char**&, bool)
in file UPstream.C at line 50.
FOAM exiting
--------------------------------------------------------------------------
mpirun detected that one or more processes exited with non-zero status, thus causing
the job to be terminated. The first process to do so was:
Process name: [[32098,1],1]
Exit code: 1
--------------------------------------------------------------------------
```
- OpenFOAM version : v2012
- Operating system : ubuntu:focal (docker)
- Compiler : installed from deb openfoam repoMark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/1971Solid particle injection and mesh size issue in simpleReactingParcelFoam2021-07-07T10:50:01ZLuxmi NarasimmanSolid particle injection and mesh size issue in simpleReactingParcelFoamI tried solid particle patch injection in simple ReactingParcelFoam solver ..when particle size < mesh cell size ..its working fine ..but particle size > cell size ..results irrelevant...
My situation i m filtering solid particle size b...I tried solid particle patch injection in simple ReactingParcelFoam solver ..when particle size < mesh cell size ..its working fine ..but particle size > cell size ..results irrelevant...
My situation i m filtering solid particle size by mesh setup ...example in irrelevant case 2mm solid particle penerating 1mm flow path ...how is possible?https://develop.openfoam.com/Development/openfoam/-/issues/1973redistributePar: does not decompose cyclicACMI2021-01-26T20:22:11ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comredistributePar: does not decompose cyclicACMI<!--
*** 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 -->
`redistributePar -decompose` does not handle cyclicACMI
### Steps to reproduce
<!-- How one can reproduce the issue - this is very important -->
run `redistributePar -decompose` on e.g.
`tutorials/incompressible/pimpleFoam/RAS/oscillatingInletACMI2D`
It will give error about `turbulenceProperties` since it tries to evaluate the cyclicACMI (which evaluates the blockage bc)
### 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 : v2012Mattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comhttps://develop.openfoam.com/Development/openfoam/-/issues/1974synchronise edge data with flipping2022-12-23T15:02:18ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comsynchronise edge data with flipping### Functionality to add/problem to solve
Synchronising oriented edge data is not supported in syncTools
### Target audience
developers
### Proposal
extend syncTools with flipping operation### Functionality to add/problem to solve
Synchronising oriented edge data is not supported in syncTools
### Target audience
developers
### Proposal
extend syncTools with flipping operationMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comhttps://develop.openfoam.com/Development/openfoam/-/issues/1975apt-get update error : It seems that the xenial distribution does not exits?2021-01-14T17:25:49ZDavid Gomezapt-get update error : It seems that the xenial distribution does not exits?Hello, Im trying to install v2012 on a Ubuntu 16.04 but when I do
apt-get update I get:
`Err :11 https://dl.openfoam.com/repos/deb xenial/main amd64 Packages
404 Not Found`
`E: Impossible de récupérer https://dl.openfoam.com/repos/...Hello, Im trying to install v2012 on a Ubuntu 16.04 but when I do
apt-get update I get:
`Err :11 https://dl.openfoam.com/repos/deb xenial/main amd64 Packages
404 Not Found`
`E: Impossible de récupérer https://dl.openfoam.com/repos/deb/dists/xenial/main/binary-amd64/Packages 404 Not Found
`
then offcourse if i do sudo apt-get install openfoam2012-default i get
`Lecture des listes de paquets... Fait`
`Construction de l'arbre des dépendances`
`Lecture des informations d'état... Fait`
`E: Impossible de trouver le paquet openfoam2012-default`
Am I missing something The xenial distribution seems not to exits
Thank you in advancehttps://develop.openfoam.com/Development/openfoam/-/issues/1978bug in using function objects such as yPlus and wallShearStress with DPMFoam ...2021-10-28T12:29:08ZAtul Jaiswalbug in using function objects such as yPlus and wallShearStress with DPMFoam solver
I tried to use functions object yPlus and wallShearstress both as runtime postprocessing and postprocessing after the simulation from command line. Every time OpenFoam reported that turbulence model not found in database. I guess, few f...
I tried to use functions object yPlus and wallShearstress both as runtime postprocessing and postprocessing after the simulation from command line. Every time OpenFoam reported that turbulence model not found in database. I guess, few functions objects such as yPlus and wallShearStress do not work with multiphase solvers, as reported bu others too (https://www.cfd-online.com/Forums/openfoam-post-processing/232709-yplus-calculation-fatal-error-saying-turbulence-model-not-found.html and https://www.cfd-online.com/Forums/openfoam-post-processing/193542-yplus-twophaseeulerfoam.html#post792996).
I am using solver DPMFoam in OpenFoam-v-1912 to solve particle-laden backward faccing step but as reported by others in CFD-online discussion portal, it's not the problem only in DMPFoam, twoPhaseEulerFoam has also issue with above mentioned function objects.https://develop.openfoam.com/Development/openfoam/-/issues/1980Errors in documentation of fixedNormalSlipFvPatchField.H2021-04-15T20:24:15ZJohan RoenbyErrors in documentation of fixedNormalSlipFvPatchField.HTwo problems in the Doxygen documentation of the fixedNormalSlip boundary condition:
1. The Description is inaccurate/wrong. It says:
```
Description
This boundary condition sets the patch-normal component to a fixed value.
```
The...Two problems in the Doxygen documentation of the fixedNormalSlip boundary condition:
1. The Description is inaccurate/wrong. It says:
```
Description
This boundary condition sets the patch-normal component to a fixed value.
```
The behaviour implemented in updateCoeffs is:
```
Field<Type>::operator=
(
nHat*(nHat & fixedValue_)
+ transform(I - sqr(nHat), this->patchInternalField())
);
```
I suggest to change the description to:
```
Description
This boundary condition sets the patch-normal component to the field (vector
or tensor) to the patch-normal component of a user specified field.
The tangential component is treated as slip, i.e. copied from the internal
field.
```
2. The Usage uses a scalarField as an example but the BC is not defined for these:
So I suggest replacing:
```
Usage
\table
Property | Description | Required | Default value
fixedValue | fixed value | yes |
\endtable
Example of the boundary condition specification:
\verbatim
<patchName>
{
type fixedNormalSlip;
fixedValue uniform 0; // example entry for a scalar field
}
\endverbatim
```
with
```
Usage
\table
Property | Description | Required | Default value
fixedValue | fixed value | yes |
\endtable
Example of the boundary condition specification:
\verbatim
<patchName>
{
type fixedNormalSlip;
fixedValue uniform (1 0 0); // example entry for a vector field
}
\endverbatim
```Kutalmış BerçinKutalmış Berçinhttps://develop.openfoam.com/Development/openfoam/-/issues/1982BUG in nearestPatchFaceAMI between regions (v2012)2021-01-26T20:22:11ZRegő SimonBUG in nearestPatchFaceAMI between regions (v2012)<!--
*** 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 -->
In the 2012 version the nearestPatchfaceAMI mapping between regions is broken.
### Steps to reproduce
<!-- How one can reproduce the issue - this is very important -->
1. For example run the multiRegionHeaterRadiation case with allrun. Works fine.
2. Modify the following entry in the constant/topAir/polyMesh/boundary file as (sampleMode is modified to AMI mapping):
```
topAir_to_rightSolid
{
type mappedWall;
inGroups 2 ( wall viewFactorWall );
nFaces 130;
startFace 3760;
sampleMode nearestPatchFaceAMI;
sampleRegion rightSolid;
samplePatch rightSolid_to_topAir;
}
```
3. Modify the following entry in the constant/rightSolid/polyMesh/boundary file as (sampleMode is modified to AMI mapping):
```
rightSolid_to_topAir
{
type mappedWall;
inGroups 1 ( wall );
nFaces 130;
startFace 403;
sampleMode nearestPatchFaceAMI;
sampleRegion topAir;
samplePatch topAir_to_rightSolid;
}
```
4. Now we have a nearestPatchfaceAMI mapping between the topAir and rightSolid. Let's run the simulation again from time 0.
5. The mapping crashes with the following message even on a matching mesh:
```
--> FOAM FATAL ERROR: (openfoam-2012)
did not find sample (0.01666666 0.008 -0.045) on patch topAir_to_rightSolid on region topAir on processor 0
From void Foam::mappedPatchBase::calcMapping() const
in file mappedPatches/mappedPolyPatch/mappedPatchBase.C at line 946.
FOAM exiting
```Mattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comhttps://develop.openfoam.com/Development/openfoam/-/issues/1983v2012 new polyline extrudeMesh doesn't support spline2023-01-27T16:18:17ZGuanyang Xuev2012 new polyline extrudeMesh doesn't support spline### Functionality to add/problem to solve
In `src/mesh/extrudeModel/polyline/polyline.H` spline is mentioned as supported.
```c
Description
Extrudes by transforming points along a polyline provided as a
series of points and edge segmen...### Functionality to add/problem to solve
In `src/mesh/extrudeModel/polyline/polyline.H` spline is mentioned as supported.
```c
Description
Extrudes by transforming points along a polyline provided as a
series of points and edge segments. Supports all blockMesh edge
types, e.g. line, arc, spline. The surface points are rotated to
follow the path.
```
However when I added a spline to the path it shows
```
--> FOAM FATAL ERROR: (openfoam-2012)
Not implemented
From Foam::scalar Foam::CatmullRomSpline::length() const
in file blockEdges/splineEdge/CatmullRomSpline.C at line 136.
FOAM aborting
```
So basically in `src/mesh/blockMesh/blockEdges/splineEdge/CatmullRomSpline.C`
```c
Foam::scalar Foam::CatmullRomSpline::length() const
{
NotImplemented;
return 1;
}
```
The length of the spline is not implemented yet and makes it impossible to extrude.
### Target audience
When using lines and arcs, the discontinuity in curvature(2nd order derivative) results in sudden change on cell size.
See attached image: red<green<blue, the sudden change exceeds the ideal expansion ratio.
![mesh](/uploads/14edd53eac9716bcf22cb0d4d20eec7d/mesh.png)
Splines are ~~naturally C2 continuous~~ (not true for Catmull, see http://www.mvps.org/directx/articles/catmull/) and should guarantee a smooth transition of cell size.
### Proposal
I don't know how to evaluate the length of Catmull Rom spline and can't find it online. But if the parametric equation is known then it's doable.
Seems like only lines and arcs are implemented and all other curves are left out. Is it possible to implement cubic spline as the length is well known?
### What does success look like, and how can we measure that?
Implement the length of the spline and extrudeMesh should not show error message.
### Links / references
N/A
### Funding
N/Ahttps://develop.openfoam.com/Development/openfoam/-/issues/1986Parallel contiguous data synchronisation not scaling2022-12-23T15:02:34ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comParallel contiguous data synchronisation not scaling### Functionality to add/problem to solve
Parallel (face/edge/point) synchronisation uses the syncTools helper functions. It assumes non-contiguous data so uses streaming to extract the data, followed by an exchange of sizes before send...### Functionality to add/problem to solve
Parallel (face/edge/point) synchronisation uses the syncTools helper functions. It assumes non-contiguous data so uses streaming to extract the data, followed by an exchange of sizes before sending the actual data. It is this exchange of sizes (all-to-all) that causes scaling issues. For contiguous data and one-to-one mapping we know in advance the amount of data to receive so can skip this.
### Target audience
- parallel running on larger number of processors
### Proposal
- check for contiguous data in templated functions using PstreamBuffers
### Links / references
This work is based on the work done in
"Communication Optimization for Multiphase FlowSolver in the Library of OpenFOAM"
Zhipeng Lin1, Wenjing Yang1,*, Houcun Zhou2, Xinhai Xu3, Liaoyuan Sun1, Yongjun Zhang3and Yuhua Tang
(MDPI "Water" magazine, October 2018)
it shows two bottlenecks:
- linear solver using blocking allreduce
- MULES finding out sizes to receive every sweep
The first item was tackled in the `v2006` pipelined CG solver implementation. The current issue is a more general fix of the second item.
@mark
### Funding
(Does the functionality already exist/is sponsorship available?)Mattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comhttps://develop.openfoam.com/Development/openfoam/-/issues/1987FunctionObject from foamNewFunctionObject does not compile2021-01-26T20:22:11ZHenning ScheuflerFunctionObject from foamNewFunctionObject does not compile<!--
-->
<!--
All text between these markers are comments and will not be present in the
report
-->
### Summary
functionObject generated by the utility foamNewFunctionObject does not compile
### Environment information
- OpenF...<!--
-->
<!--
All text between these markers are comments and will not be present in the
report
-->
### Summary
functionObject generated by the utility foamNewFunctionObject does not compile
### Environment information
- OpenFOAM version : of2006,of2012,ofdev
- Operating system : ubuntu
- Hardware info :
- Compiler : gcc
### Possible fixes
error in following line:
```
boolData_(dict.getOrDefault<bool>("boolData"), true),
```
replace with
```
boolData_(dict.getOrDefault<bool>("boolData", true)),
```https://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/1998change default setting for sigFpe2021-02-10T12:33:30ZMark OLESENchange default setting for sigFpeReported as a spack issue for Fujitsu: https://github.com/spack/spack/pull/21336
It might be reasonable to have the default disabled. This does cover over possible issues, but perhaps something that we only have enabled for our test loo...Reported as a spack issue for Fujitsu: https://github.com/spack/spack/pull/21336
It might be reasonable to have the default disabled. This does cover over possible issues, but perhaps something that we only have enabled for our test loops?
@andy @Mattijs @Sergio @kuti @Prashanthttps://develop.openfoam.com/Development/openfoam/-/issues/1999surfaceFieldValue surface writer (VTK) fails with multiple fields2021-02-17T12:46:07ZMark OLESENsurfaceFieldValue surface writer (VTK) fails with multiple fieldscross-ref EP-1482 - agreed to fix in develop
It only outputs the final field.cross-ref EP-1482 - agreed to fix in develop
It only outputs the final field.Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/2001Docker container feedback2021-11-25T16:17:36ZFabian FribergDocker container feedback### Functionality to add/problem to solve
I made a thread on CFD online talking about the difference between docker containers for OF7 and OFv2006, asking if there's a way to run OFv2006 with the OF7 container. A person replied saying I...### Functionality to add/problem to solve
I made a thread on CFD online talking about the difference between docker containers for OF7 and OFv2006, asking if there's a way to run OFv2006 with the OF7 container. A person replied saying I should post my feedback regarding the containers here. [Here's a link to the thread](https://www.cfd-online.com/Forums/openfoam-installation/233285-docker-problems.html).
Here are the concerns I brought up in the thread:
> I first installed OF7 on my mac using docker, and it worked great. The script creates a contained environment where only the directory I launched the script from exists, and all alias shortcuts (like src, run etc) work.
>
>
> Then I installed OFv2006, and the docker script is different. It creates an image of my entire file system which always starts at my home directory so I have to navigate to the right folder, and the user directory shortcut aliases/variables don't work (like run or cd $FOAM_USER_APPBIN).
>
>
> For example, echo $FOAM_RUN gives //OpenFOAM/lumpor-v2006/run, which doesn't exist The two '/' characters at the start confuse me. I tried changing "home" to "pwd" in some places in the v2006 docker file, but it doesn't seem to work.
> Also, using the OF7 container I can make changes in my working directory from outside the terminal in real-time, while for the OFv2006 container I need to restart the container every time I edit any files.
### Target audience
Mac users of OFv2006/2012
### Proposal
By making changes to the docker file for v2012.
### What does success look like, and how can we measure that?
Mac users being able to use docker more easily for openfoam. An increase in use of OF for mac and/or a survey would be ways to measure it.
### Links / references
N/A
### Funding
N/A