Development issueshttps://develop.openfoam.com/groups/Development/-/issues2021-12-22T14:48:50Zhttps://develop.openfoam.com/Development/openfoam/-/issues/2220needing threaded mpi for maxThreadFileBufferSize>02021-12-22T14:48:50ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comneeding threaded mpi for maxThreadFileBufferSize>0### Functionality to add/problem to solve
Currently enabling threaded writing (using maxThreadFileBufferSize > 0) automatically triggers threaded MPI support though in most cases this not needed since the buffer is big enough to avoid a...### Functionality to add/problem to solve
Currently enabling threaded writing (using maxThreadFileBufferSize > 0) automatically triggers threaded MPI support though in most cases this not needed since the buffer is big enough to avoid additional comms. Problem is that we don't know in advance how much the user is writing.
Using threaded MPI can incur a runtime penalty.
### Target audience
Using threaded writing
### Proposal
E.g. if user specifies it explicitly (maybe through negating the buffer size specification)
maxThreadFileBufferSize < 0
assume that the buffer space is big enough to write all.
@mark @andy @Prashanthttps://develop.openfoam.com/Development/openfoam/-/issues/2221pressure functionObject, pName is not read2021-10-05T10:50:34ZHassan Kassempressure functionObject, pName is not readHello,
The [pressure functionObject](https://develop.openfoam.com/Development/openfoam/-/blob/OpenFOAM-v2012/src/functionObjects/field/pressure/pressure.H) does not read ``p`` entry which represents ``pName``, although it is mentioned i...Hello,
The [pressure functionObject](https://develop.openfoam.com/Development/openfoam/-/blob/OpenFOAM-v2012/src/functionObjects/field/pressure/pressure.H) does not read ``p`` entry which represents ``pName``, although it is mentioned in the description of the class. The pressure field name is hardcoded and passed to ``fieldExpression`` [here](https://develop.openfoam.com/Development/openfoam/-/blob/OpenFOAM-v2012/src/functionObjects/field/pressure/pressure.C#L356). In order to have the right behaviour, the user can set the ``field`` to ``pName``, then the [read function](https://develop.openfoam.com/Development/openfoam/-/blob/OpenFOAM-v2012/src/functionObjects/field/fieldExpression/fieldExpression.C#L950) of ``fieldExpression`` will overwrite the field name. I guess the easiest fix here is to update the description of the class and replace ``p`` with ``field``, but it isn't the most intuitive.Kutalmış BerçinKutalmış Berçinhttps://develop.openfoam.com/Development/openfoam/-/issues/2222opt-switch option does not parse value2024-01-10T08:58:32ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comopt-switch option does not parse value```
opt-switch maxThreadFileBufferSize=1
/*---------------------------------------------------------------------------*\
| ========= | |
| \\ / F ield | OpenFO...```
opt-switch maxThreadFileBufferSize=1
/*---------------------------------------------------------------------------*\
| ========= | |
| \\ / F ield | OpenFOAM: The Open Source CFD Toolbox |
| \\ / O peration | Version: 2107 |
| \\ / A nd | Website: www.openfoam.com |
| \\/ M anipulation | |
\*---------------------------------------------------------------------------*/
Build : ad8e5540a3-20210929 OPENFOAM=2107 version=com
Arch : "LSB;label=32;scalar=64"
Exec : simpleFoam -parallel -fileHandler collated -opt-switch maxThreadFileBufferSize=5e9
Date : Sep 29 2021
Time : 17:43:09
Host : linux-bymj
PID : 26907
I/O : collated [threaded] (maxThreadFileBufferSize = 1).
Requires buffer large enough to collect all data or thread support
enabled in MPI. If MPI thread support cannot be enabled, deactivate
threading by setting maxThreadFileBufferSize to 0 in
OpenFOAM etc/controlDict
Case : /home/mattijs/OpenFOAM/OpenFOAM-plus/work/develop/openfoam/tutorials/incompressible/simpleFoam/pitzDaily
nProcs : 2
Hosts :
```Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/2223Function1 table searches for wildcard for 'interpolationScheme'2021-12-23T17:49:11ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comFunction1 table searches for wildcard for 'interpolationScheme'<!--
*** 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 `table` version of Function1 looks for the optional `interpolationScheme` entry. It also allows wildcard matching which does not make sense.
Probably there are lots of other places where wildcard matches are allowed that shouldn't.
### Steps to reproduce
<!-- How one can reproduce the issue - this is very important -->
Maybe a `uniformFixedValue` bc with a `table` `uniformValue` and an additional ".*" entry.
### 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 : v2106https://develop.openfoam.com/Development/openfoam/-/issues/2224solverInfo - colon in field names2024-01-10T16:13:48ZPacific ESIsolverInfo - colon in field namesUsing a colon in the residual field names of function object solverInfo means that the files created for these fields have names that are indecipherable in Windows. For example, in a recent run, initialResidual:p became ICLAZW~C. Not a p...Using a colon in the residual field names of function object solverInfo means that the files created for these fields have names that are indecipherable in Windows. For example, in a recent run, initialResidual:p became ICLAZW~C. Not a problem in Linux where the computations were done, but it is when I want to examine the results in Windows.
The same comment will apply to field names containing colons that are created anywhere else in OpenFOAM.https://develop.openfoam.com/Development/openfoam/-/issues/2225chtMultiRegionSimpleFoam - frozenFlow mode results in large errors2021-12-06T20:45:03ZKumar KrishnachtMultiRegionSimpleFoam - frozenFlow mode results in large errorsRunning chtMultiRegionSimpleFoam on a converged flow by activating the frozenFlow switch to calculate the heat transport results in fairly large deviations in the final temperatures as opposed to running the case in the "normal" (fully c...Running chtMultiRegionSimpleFoam on a converged flow by activating the frozenFlow switch to calculate the heat transport results in fairly large deviations in the final temperatures as opposed to running the case in the "normal" (fully coupled) mode.
Attached is a 2D case to illustrate the problem. It is a simple case of water flowing at high velocity through a narrow channel above a copper plate which is heated from below.
To reproduce the problem, please do the following steps:
(1) Run the case as it is. The case runs in fully coupled mode for 2000 iterations.
(2) Run the case for the first 1000 iterations by turning off the (h|e) solvers in the ./system/copper/fvSolution and ./system/water/fvSolution subdirectories, i.e, please activate the 'maxIter 0' statement.
(3) Now please turn on the frozenFlow keyword in the PIMPLE subdict and run for another 1000 iterations. In this case, deactivate the 'maxIter 0' statement in the respective fvSolution dicts.
We can see that the Temp. results obtained at the end of 2000 iterations in both cases are very different.
[ConjCopperWater.tar.gz](/uploads/9bbe5fd5dedce1ef301d0f0f8c86b96a/ConjCopperWater.tar.gz)
**Environment Information**
- OpenFOAM Version: v2106
- Operating System: Windows 10 (MinGW)
- Hardware Info: PC (HP Z240)https://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/2227pimpleFoam and pisoFoam deltaT not respecting controlDict value when running ...2021-11-02T10:13:48ZAaronpimpleFoam and pisoFoam deltaT not respecting controlDict value when running SPDP (but does for DP)### Summary
deltaT is not being respected by pimpleFoam and pisoFoam when in SPDP. This is for a deltaT of 7.5e-05, so not an issue of being too small for single precision. When solving in DP, deltaT is as expected.
### Steps to reprodu...### Summary
deltaT is not being respected by pimpleFoam and pisoFoam when in SPDP. This is for a deltaT of 7.5e-05, so not an issue of being too small for single precision. When solving in DP, deltaT is as expected.
### Steps to reproduce
Simply run pimpleFoam, both in SPDP and DP to see how DP respects the deltaT prescribed in controlDict, while SPDP generates a random value. The random value is not even very close to the controlDict deltaT (it's off by ~20%), and it varies with each iteration. This prevents endTime writing on the last iteration, makes results processing difficult, etc.
### Example case
https://www.dropbox.com/s/bmfxslcx7lj3wec/issue2227_deltaT_SPDP.tar.xz?dl=0
I have a solved (steady state) 500k cell case which is about ~50Mb. I can send it through another channel if you prefer.
### What is the current *bug* behaviour?
Random deltaT - differing from controlDict value by up to 20% - being applied to each iteration when running SPDP
### What is the expected *correct* behavior?
deltaT per controlDict, as is the case when running DP
### Relevant logs and/or images
controlDict
```
startFrom startTime;
**startTime 400;**
stopAt endTime;
endTime 400.20025;
**deltaT 7.5e-05;**
writeControl timeStep;
writeInterval 267;
monStart 400.1002;
purgeWrite 100;
writeFormat ascii;
writeCompression on;
writePrecision 7;
timeFormat general;
timePrecision 11;
runTimeModifiable yes;
```
DP - expected behavior
```
Build : f4ccdec894-20210902 OPENFOAM=2012 patch=210618
Arch : "LSB;label=32;scalar=64"
Starting time loop
Courant Number mean: 0.007378641 max: 2.702994
**Time = 400.000075**
PIMPLE: iteration 1
velocityDampingConstraint damp damped 3 (0.000564893%) of cells
smoothSolver: Solving for Ux, Initial residual = 4.640301e-07, Final residual = 1.441689e-08, No Iterations 1
smoothSolver: Solving for Uy, Initial residual = 4.99919e-05, Final residual = 5.043536e-08, No Iterations 3
smoothSolver: Solving for Uz, Initial residual = 6.165809e-06, Final residual = 1.953994e-08, No Iterations 2
GAMG: Solving for p, Initial residual = 0.3755113, Final residual = 0.02669367, No Iterations 1
GAMG: Solving for p, Initial residual = 0.02671251, Final residual = 0.001826018, No Iterations 3
time step continuity errors : sum local = 1.271702e-09, global = 1.048906e-11, cumulative = 1.048906e-11
GAMG: Solving for p, Initial residual = 0.01341298, Final residual = 0.000939755, No Iterations 2
GAMG: Solving for p, Initial residual = 0.001842091, Final residual = 9.379453e-07, No Iterations 28
time step continuity errors : sum local = 6.500214e-13, global = 2.663773e-17, cumulative = 1.048909e-11
smoothSolver: Solving for omega, Initial residual = 2.509855e-07, Final residual = 1.21354e-08, No Iterations 1
bounding omega, min: -5721.012 max: 283395.7 average: 3373.21
smoothSolver: Solving for k, Initial residual = 7.494289e-06, Final residual = 1.253224e-08, No Iterations 2
bounding k, min: -36.23042 max: 384.4423 average: 11.56855
ExecutionTime = 2.98 s ClockTime = 3 s
Courant Number mean: 0.007378645 max: 2.242397
**Time = 400.00015**
```
SPDP - strange time step which is different from DP and controlDict specification
```
Build : 4245909efb-20210203 OPENFOAM=2012
Arch : "LSB;label=32;scalar=32;solveScalar=64"
Starting time loop
Courant Number mean: 0.007378641 max: 2.703078
**Time = 400.00006104**
PIMPLE: iteration 1
velocityDampingConstraint damp damped 3 (0.000564893%) of cells
smoothSolver: Solving for Ux, Initial residual = 5.07782e-07, Final residual = 1.456293e-08, No Iterations 1
smoothSolver: Solving for Uy, Initial residual = 4.999212e-05, Final residual = 5.043533e-08, No Iterations 3
smoothSolver: Solving for Uz, Initial residual = 6.165838e-06, Final residual = 1.953989e-08, No Iterations 2
GAMG: Solving for p, Initial residual = 0.3754919, Final residual = 0.02666569, No Iterations 1
GAMG: Solving for p, Initial residual = 0.02669024, Final residual = 0.00183339, No Iterations 3
time step continuity errors : sum local = 1.534634e-09, global = 7.045955e-12, cumulative = 7.045955e-12
GAMG: Solving for p, Initial residual = 0.01344812, Final residual = 0.0009438513, No Iterations 2
GAMG: Solving for p, Initial residual = 0.001842122, Final residual = 9.032984e-07, No Iterations 29
time step continuity errors : sum local = 3.146365e-10, global = 1.095093e-12, cumulative = 8.141048e-12
smoothSolver: Solving for omega, Initial residual = 2.511907e-07, Final residual = 1.21357e-08, No Iterations 1
bounding omega, min: -5721.12 max: 283415 average: 3373.219
smoothSolver: Solving for k, Initial residual = 7.494291e-06, Final residual = 1.253221e-08, No Iterations 2
bounding k, min: -36.23087 max: 384.4427 average: 11.56855
ExecutionTime = 2.36 s ClockTime = 3 s
Courant Number mean: 0.007378645 max: 2.242493
**Time = 400.00012207**
```
### Environment information
- OpenFOAM version : v2012 & v2106
- Operating system : ubuntu1804
- Hardware info : x86
- Compiler : gcchttps://develop.openfoam.com/Development/openfoam/-/issues/2228icoReactingMultiphaseInterFoam - wrong link to surfaceTensionModel2022-05-11T09:59:10ZMartin HeinrichicoReactingMultiphaseInterFoam - wrong link to surfaceTensionModel### Summary
`icoReactingMultiphaseInterFoam` links with the surfaceTensionModel from `src/transportModels/interfaceProperties/surfaceTensionModels` instead the one from the phaseSystem library located in `src/phaseSystemModels/multiphas...### Summary
`icoReactingMultiphaseInterFoam` links with the surfaceTensionModel from `src/transportModels/interfaceProperties/surfaceTensionModels` instead the one from the phaseSystem library located in `src/phaseSystemModels/multiphaseInter/phasesSystem/interfaceModels/surfaceTensionModels `.
As a result, the `type` keyword in the `phaseProperties` file for specifying the surfaceTensionModel is not read by the solver, the setting has no influence. Only the sigma value is needed. Furthermore, one cannot simply create a new surfaceTensionModel in the `phasesSystem` library as one has to use the `interfaceProperties` library from transportModels.
The developers are also aware of this issue. Looking at `Make/file` in the phasesSystem library reveals the following lines:
```
/* Ununsed? */
/*
surfaceTension = interfaceModels/surfaceTensionModels
$(surfaceTension)/surfaceTensionModel/surfaceTensionModel.C
$(surfaceTension)/constantSurfaceTensionCoefficient/constantSurfaceTensionCoefficient.C
*/
```
So the surfaceTensionModels are not even compiled. Unfortunately, simply uncommenting those lines and removing the links to the `src/transportModels/interfaceProperties` does result in other errors during compilation.
### How should it behave?
The correct surfaceTensionModels from `src/phaseSystemModels/multiphaseInter/phasesSystem/interfaceModels` should be used for `icoReactingMultiphaseInterFoam` for easier maintenance and extension of existing surfaceTensionModels.
### Environment information
- OpenFOAM version : v2106
- Operating system : Debian 10
- Compiler : Gcc 9.1.0Kutalmış BerçinKutalmış Berçinhttps://develop.openfoam.com/Development/openfoam/-/issues/2229additional info string for sampled surfaces2021-10-31T16:27:38ZMark OLESENadditional info string for sampled surfacesraised on EP1631 - could be useful to output additional information (filter types etc) for sampled surface.
Would need to add in a top-level info() method and dispatch from there.raised on EP1631 - could be useful to output additional information (filter types etc) for sampled surface.
Would need to add in a top-level info() method and dispatch from there.Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/2230Possibility to test scaling on the LUMI supercomputer2022-10-04T12:25:05ZTimofey MukhaPossibility to test scaling on the LUMI supercomputerDear all,
I am working with a group that will get pilot access to the CPU partition of the new Finnish supercomputer called LUMI, starting 18th of Oct. Some info about the machine can be found here: https://www.lumi-supercomputer.eu/may...Dear all,
I am working with a group that will get pilot access to the CPU partition of the new Finnish supercomputer called LUMI, starting 18th of Oct. Some info about the machine can be found here: https://www.lumi-supercomputer.eu/may-we-introduce-lumi/
It will be a pretty bare-bone environment, but if I manage to get OF compiled, there is a possibility to run scaling tests of OpenFOAM solvers. So, while **I can't promise anything**, I would like to open a discussion regarding what tests would be good to run. Even better would be if we already have some cases prepared. Perhaps the HPC committee has input?https://develop.openfoam.com/Development/openfoam/-/issues/2231reduce/improve library settings for paraview/vtk2021-10-07T06:51:41ZMark OLESENreduce/improve library settings for paraview/vtkMore recent paraview versions do not an explicit LD_LIBRARY_PATH to run so this setting can be removed from the config.sh/ entry.
Verified with a fresh ParaView build/install under /tmp/make-thirdparty. Used these locations when buildin...More recent paraview versions do not an explicit LD_LIBRARY_PATH to run so this setting can be removed from the config.sh/ entry.
Verified with a fresh ParaView build/install under /tmp/make-thirdparty. Used these locations when building the PV-Plugins (aka, paraFoam modules). Relocated ParaView to the usual ThirdParty/platforms locations. Plugins load correctly.
Will need an additional mechanism to specify `libpaths` for catalyst and runTimePostProcessing though.
[0001-CONFIG-newer-paraview-finds-its-own-libraries.patch](/uploads/86bae44b982821277e68fe24903f94c8/0001-CONFIG-newer-paraview-finds-its-own-libraries.patch)https://develop.openfoam.com/Development/openfoam/-/issues/2232foamGetDict topoSetDict does not return complete set2021-10-13T15:59:31ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comfoamGetDict topoSetDict does not return complete set### Functionality to add/problem to solve
Asking for topoSetDict should ideally also hit at the topoSetSourcesDict since that contains the full set.### Functionality to add/problem to solve
Asking for topoSetDict should ideally also hit at the topoSetSourcesDict since that contains the full set.Mattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comhttps://develop.openfoam.com/Development/openfoam/-/issues/2233finiteArea fails with calcPointAreaNormals2022-04-29T15:14:48ZMark OLESENfiniteArea fails with calcPointAreaNormalsThis issue has been tagged internally (EP1619) and @vaggelisp did some investigation (notes in !490).
Here are some of his notes reattached:
> [Ahmed-FaMesh-3453d169.tar.gz](/uploads/27b25f20e0acf8edef8ebe705fa79fe3/Ahmed-FaMesh-3453d1...This issue has been tagged internally (EP1619) and @vaggelisp did some investigation (notes in !490).
Here are some of his notes reattached:
> [Ahmed-FaMesh-3453d169.tar.gz](/uploads/27b25f20e0acf8edef8ebe705fa79fe3/Ahmed-FaMesh-3453d169.tar.gz)
> ... makeFaMesh still fails for hierarchical: coeffs (5 4 2), with a different error this time (floating point exception in calcPointAreaNormals)
```
[23] #1 Foam::sigFpe::sigHandler(int) at ??:?
[23] #2 ? in /lib64/libpthread.so.0
[23] #3 Foam::faMesh::calcPointAreaNormals() const at ??:?
[23] #4 Foam::faMesh::pointAreaNormals() const at ??:?
[23] #5 Foam::faBoundaryMesh::calcGeometry() at ??:?
[23] #6 Foam::faMesh::faMesh(Foam::polyMesh const&) at ??:?
[23] #7 ? at ??:?
[23] #8 __libc_start_main in /lib64/libc.so.6
[23] #9 ? at ??:?
```
Along with some discussion notes:
![20211005_notesOnFaMesh](/uploads/e0f6843e4f0de836967a50b0de196b09/20211005_notesOnFaMesh.jpg)Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/2234error: wrong implementation of solitary waves (OF-v2106)2022-08-24T09:15:14ZGabriel Barajasbarajasg@unican.eserror: wrong implementation of solitary waves (OF-v2106)In the latest release (OF-v2106) the three tutorials related to solitary waves (solitary, solitaryGrimshaw, solitaryMcCowan) do not work;
It seems that the latest implementation have defined some parameters as common for all the theories...In the latest release (OF-v2106) the three tutorials related to solitary waves (solitary, solitaryGrimshaw, solitaryMcCowan) do not work;
It seems that the latest implementation have defined some parameters as common for all the theories (maybe wavePeriod and rampingTime) that are no needed by solitary wave theories and that can possible lead to division by zero.
Gabihttps://develop.openfoam.com/Development/openfoam/-/issues/2235decomposePar -fields -copyZero - unexpected behaviour2021-11-25T15:07:49ZRobin KnowlesdecomposePar -fields -copyZero - unexpected behaviour<!--
*** 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
Unexpected behaviour when using `decomposePar -fields -copyZero` to propagate a serial zero directory to pre-existing processor directories.
If the processors also have a pre-existing zero directory (for example containing fields from `snappyHexMesh`) then the above command will copy the serial zero directory itself _into_ those directories, rather than copying the contents.
Ending up with `processor0/0/0` for example.
I appreciate there are workarounds, `restore0Dir` for example, but this seemed like incorrect behaviour in this case.
### Steps to reproduce
- mesh the `motorbike` tutorial in parallel
- copy 0.orig to 0
- run `decomposePar -fields -copyZero`
- `ls processor0/0/0`
### What is the current *bug* behaviour?
`decomposePar -fields -copyZero` copies the serial zero directory into pre-existing `processor*/0` directories
### What is the expected *correct* behavior?
`decomposePar -fields -copyZero` copies **the contents** of the serial zero directory into pre-existing `processor*/0` directories
### 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 : v2106
- Operating system : Ubuntu / Docker
- Hardware info : Mac
- Compiler : Pre-Compiled Binaries / Docker images
Related issue: #2236Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/2236Can't run decomposePar -fields after parallel snappyHexMesh due to lack of fa...2024-03-15T12:42:43ZRobin KnowlesCan't run decomposePar -fields after parallel snappyHexMesh due to lack of faceProcAddressing files<!--
*** 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
`decomposePar -fields` cannot be run _after_ parallel `snappyHexMesh` due to missing `faceProcAddressing` files.
### Steps to reproduce
- mesh the `motorbike` tutorial in parallel
- copy `0.orig` to `0`
- run `decomposePar -fields`
### What is the current *bug* behaviour?
`decomposePar -fields` fails with the error:
```
Processor 0: field transfer
--> FOAM FATAL ERROR: (openfoam-2106)
cannot find file "/home/openfoam/processor0/constant/polyMesh/faceProcAddressing"
From virtual Foam::autoPtr<Foam::ISstream> Foam::fileOperations::uncollatedFileOperation::readStream(Foam::regIOobject&, const Foam::fileName&, const Foam::word&, bool) const
in file global/fileOperations/uncollatedFileOperation/uncollatedFileOperation.C at line 542.
FOAM exiting
```
### What is the expected *correct* behavior?
`decomposePar -fields` should propagate the fields in the `0` (or any other specified time directory) to the existing processor directories, parsing any `include` directives, expressions &/or regex present in the boundary condition dictionaries.
### 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 : v2106
- Operating system : Ubuntu / Docker
- Hardware info : Mac
- Compiler : Pre-Compiled Binaries / Docker images
Related issue: #2235Mattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comhttps://develop.openfoam.com/Development/openfoam/-/issues/2237faField decomposition fails2021-11-07T18:10:48ZMark OLESENfaField decomposition failsNoticed while working on #2233 and #2152 - the faFieldDecomposer causes out-of-sync parallel communication == fails.Noticed while working on #2233 and #2152 - the faFieldDecomposer causes out-of-sync parallel communication == fails.Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/2238Feature: harmonic interpolation of zero values2022-02-20T23:38:31ZBas NieuwboerFeature: harmonic interpolation of zero values### Functionality to add/problem to solve
OpenFOAM offers an harmonic interpolation scheme which is suitable for interpolating across steep gradients. It is for instance very suitable for interpolating the concentration and (mixture) vis...### Functionality to add/problem to solve
OpenFOAM offers an harmonic interpolation scheme which is suitable for interpolating across steep gradients. It is for instance very suitable for interpolating the concentration and (mixture) viscosity in a bed transport using a sand-water mixture. Such an interpolation limits the diffusion due to the linear interpolation across the interface.
### Proposal
Currently, the interpolation scheme cannot handle zero values of the interpolated property. As can be viewed in this equation:
```math
\varphi_f = \frac{1}{\frac{\delta_1 / \delta}{\varphi_2} + \frac{\delta_2 / \delta}{\varphi_1}}
```
The dissertation of Goeree (2018) [1] describes a form in which it is possible to handle these zero values (5.22 and 5.17).
```math
\varphi_f = \frac{\varphi_1 \, \varphi_2}{\frac{\delta_1}{\delta} \,\varphi_1 + \frac{\delta_2}{ \delta} \, \varphi_2}
```
My knowledge on the interpolation schemes implementation is limited and I could not implement this scheme myself. Would it be possible to change the implementation of this scheme or add a second scheme, which uses the version described in Goeree [1]? With some pointers I could implement and test it myself.
I did found a work-around for the harmonic schemes to handle zero values by first using a linear interpolation. I’ve added the code for this scheme when implementing the different scheme is not possible.
[harmonic0.C](/uploads/b40eefb9a7787be845e65d0f3583bff9/harmonic0.C)
[harmonic0.H](/uploads/4c900e6800cfdb1afd8af42bb60d035e/harmonic0.H)
### Links / references
[1] https://repository.tudelft.nl/islandora/object/uuid%3A2d432d11-cce4-40de-b951-e89dfebbef27https://develop.openfoam.com/Development/openfoam/-/issues/2239Feature: combining surfaces in a single file2023-05-31T11:16:11ZBas NieuwboerFeature: combining surfaces in a single file### Functionality to add/problem to solve
When using CFMesh all the surface regions should be specified in a single surface file. For ascii stl files, it is relatively easy to combine the files using the linux command ‘sed’. However, for...### Functionality to add/problem to solve
When using CFMesh all the surface regions should be specified in a single surface file. For ascii stl files, it is relatively easy to combine the files using the linux command ‘sed’. However, for binary stl files this is not possible. Secondly, it is not possible to add different file types. OpenFOAM comes with the surfaceAdd utility. However, it is cumbersome to add multiple surfaces and secondly the naming of the regions (patches) in the outputfile cannot be easily used for meshing. Therefore I would like to add the included surfaceListAdd utility. This is an extension to surfaceAdd, which allows for adding multiple surfaces and use the file names instead of generic patch names, when no region name is provided
### Target audience
This is targeted at users who use CFMesh and have multiple surface files they want to use in meshing. Or SHM users who want to clean up their number of files.
### Provided code
The code provided is an extension of the surfaceAdd script. It reads a list of surface files, loops over them and combines the points and tris. It renames the regions to the file name (with an index) if no region was given in the original surface file. Some CAD packages give a generic region name to the surface file, such as 'solid' or 'OpenSCAD_model'. To exclude these names a list of ignored region names can be added as an option. A last step is checking on possible duplicate regions in the output file and renaming these to a 'fileName.regionName' format. This ensures there are no duplicate regions in the output file.
Would it be possible to include this utility in OpenFOAM?
### test case
I've included a few files for testing the script and a test.sh file for running the tests.[surfaceListAdd.zip](/uploads/6fa274cc6c5e3272ab0c22770ce0e5e0/surfaceListAdd.zip)v2206