Development issueshttps://develop.openfoam.com/groups/Development/-/issues2023-08-19T21:13:18Zhttps://develop.openfoam.com/Development/openfoam/-/issues/1Lagrangian standard patch interaction model errors2023-08-19T21:13:18ZAdminLagrangian standard patch interaction model errorsReported statistics are incorrect
* Counters of number and mass of particles continuously reset on output
* Mass escape/stick not calculatedReported statistics are incorrect
* Counters of number and mass of particles continuously reset on output
* Mass escape/stick not calculatedFunctionality migration from internal development lineAdminAdminhttps://develop.openfoam.com/Development/openfoam/-/issues/2819potential parallel issues for function objects used a patchSet2023-08-19T06:53:47ZMark OLESENpotential parallel issues for function objects used a patchSetIn function objects such as wallShearStress, the patches can be restricted using a "patches" keyword. The retrieved indices are stored as a labelHashSet (ensures that they are unique). This is generally mostly OK, except that there is no...In function objects such as wallShearStress, the patches can be restricted using a "patches" keyword. The retrieved indices are stored as a labelHashSet (ensures that they are unique). This is generally mostly OK, except that there is no ***absolute 100% guarantee ™*** that iterating across will be the same across all ranks - which means that any global operations such as gMin/gMax etc could potentially block.
This is admittedly a bit of a stretch (since the hash insertion operations will be the same on all ranks, and all ranks have the same hasher), but should be adjusted for v2312.
FYI: @kuti and @andyv2312Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/2953provision for delayed reading of compound tokens2023-08-19T06:46:01ZMark OLESENprovision for delayed reading of compound tokensIn work initiated by @serge and @gregorweiss, the files are read and the compound token is tagged as such, but allocated with zero size. This maintains the token stream elements to allow delayed reading.In work initiated by @serge and @gregorweiss, the files are read and the compound token is tagged as such, but allocated with zero size. This maintains the token stream elements to allow delayed reading.Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/2965xcrun support for darwin (MacOS)2023-08-19T06:44:26ZMark OLESENxcrun support for darwin (MacOS)Issue has been touched on before, but never handled since it would add even more complexity into the already mess wmake rules. However, since the introduction of `WM_COMPILE_CONTROL` we actually do have a fair bit more flexibility, which...Issue has been touched on before, but never handled since it would add even more complexity into the already mess wmake rules. However, since the introduction of `WM_COMPILE_CONTROL` we actually do have a fair bit more flexibility, which lets us add in `xcrun` support.
cross-ref: EP2234Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/2962icoFoam fails to install on CentOS 7.8 installation2023-08-18T07:48:03ZTom LehmannicoFoam fails to install on CentOS 7.8 installation<!--
*** 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 -->
### Steps to reproduce
<!-- How one can reproduce the issue - this is very important -->
### Example case
<!--
If possible, please create a SMALL example and attach it to your report
If you are using an older version of OpenFOAM this will also determine
whether the bug has been fixed in a more recent version
-->
### What is the current *bug* behaviour?
<!-- What actually happens -->
### 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 : 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 :
- 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/2964No base point for face... produces a valid tet decomposition.2023-08-18T07:28:42ZCesar CNo base point for face... produces a valid tet decomposition.I've been trying to run a case by using picFOAM and I'm getting this warning:
--> FOAM Warning :
From function Foam::triFace Foam::tetIndices::faceTriIs(const Foam::polyMesh&) const
in file /apps/easybuild/software/tinkercliff...I've been trying to run a case by using picFOAM and I'm getting this warning:
--> FOAM Warning :
From function Foam::triFace Foam::tetIndices::faceTriIs(const Foam::polyMesh&) const
in file /apps/easybuild/software/tinkercliffs-rome/OpenFOAM/9-foss-2021a/OpenFOAM-9/src/OpenFOAM/lnInclude/tetIndicesI.H at line 76
No base point for face 7468, 3(16 40 200), produces a valid tet decomposition.
When I run the solver it does not show me errors but it seems that it can not solve anything and no results are obtained. Any help will be appreciated. Thankshttps://develop.openfoam.com/Development/openfoam/-/issues/2957Could not load libfieldFunctionObjects.so and user created library2023-08-08T07:38:02ZNicolas CharalambousCould not load libfieldFunctionObjects.so and user created libraryHi,
I have created a user defined object using the wmake in OPENFOAM 20.06. The in Make the files contained the following:
Helicity.C
LIB = $(FOAM_USER_LIBBIN)/helicity
Therefore, the new created object was helicity.so.
I included bo...Hi,
I have created a user defined object using the wmake in OPENFOAM 20.06. The in Make the files contained the following:
Helicity.C
LIB = $(FOAM_USER_LIBBIN)/helicity
Therefore, the new created object was helicity.so.
I included both helicity.so and libfieldFunctionObjects.so in controldict. However,
when running interphaseChangeFoam I am getting the following:
```
--> FOAM Warning :
From void* Foam::dlLibraryTable::openLibrary(const Foam::fileName&, bool)
in file db/dynamicLibrary/dlLibraryTable/dlLibraryTable.C at line 65
Could not load "libfieldFunctionObjects.so"
/home/ncharala/OpenFOAMv2006/OpenFOAM-v2006/platforms/linux64GccDPInt32Opt/lib/libfieldFunctionObjects.so: undefined symbol: _ZTIN4Foam15functionObjects15fieldExpressionE
--> FOAM Warning :
From void* Foam::dlLibraryTable::openLibrary(const Foam::fileName&, bool)
in file db/dynamicLibrary/dlLibraryTable/dlLibraryTable.C at line 65
Could not load "helicity.so"
```
How can I fix this?
Thank you
Nicolashttps://develop.openfoam.com/Development/openfoam/-/issues/2947subsetMesh -patches with wildcard also selects e.g. processor patches2023-08-03T06:47:40ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comsubsetMesh -patches with wildcard also selects e.g. processor patches### Functionality to add/problem to solve
subsetMesh accepts wildcard to select patches for exposed faces. This also selects e.g. processor patches. This is generally not the expected behaviour. Can probably be worked around by using
- ...### Functionality to add/problem to solve
subsetMesh accepts wildcard to select patches for exposed faces. This also selects e.g. processor patches. This is generally not the expected behaviour. Can probably be worked around by using
- patchGroups, e.g. `wall`
- anti-patterns to deselect any "processor.*"
### Target audience
Users of subsetMesh
### Proposal
Deselect all processor patches. Guess no need to deselect all constraint patches since we might still want to select e.g. `symmetry`.
@Prashant
cross-ref: EP1904Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/2951Deb package with Ubuntu 23.042023-08-02T18:58:36ZMarkus TowaraDeb package with Ubuntu 23.04### Summary
I followed the instructions here on XUbuntu 23.04
https://develop.openfoam.com/Development/openfoam/-/wikis/precompiled/debian
After this apt-get update complains:
```
E: The repository 'https://dl.openfoam.com/repos/deb...### Summary
I followed the instructions here on XUbuntu 23.04
https://develop.openfoam.com/Development/openfoam/-/wikis/precompiled/debian
After this apt-get update complains:
```
E: The repository 'https://dl.openfoam.com/repos/deb lunar Release' does not have a Release file.
N: Updating from such a repository can't be done securely, and is therefore disabled by default.
```
### Possible fixes
This path exists, however the release codename is lunar not luna
https://dl.openfoam.com/repos/deb/dists/luna/
Workaround: change lunar to luna in /etc/apt/sources.list.d/openfoam.listhttps://develop.openfoam.com/Development/openfoam/-/issues/2937Generating uniformly sampling on a sphere for StochasticDispersionRAS2023-07-29T06:26:40ZVictor PozzobonGenerating uniformly sampling on a sphere for StochasticDispersionRAS### Functionality to add/problem to solve
The current implementation of the sampling to get a random direction for the turbulent velocity perturbation seems faulty.
Indeed, the current sampling draws number for angle from [0, 2pi] and [...### Functionality to add/problem to solve
The current implementation of the sampling to get a random direction for the turbulent velocity perturbation seems faulty.
Indeed, the current sampling draws number for angle from [0, 2pi] and [0, pi] uniform distributions. Yet, on a sphere the Jacobian makes the angle correlated and the second angle should not be chosen independently from the first angle value.
File: lagrangian/turbulence/submodels/Kinematic/DispersionModel/StochasticDispersionRAS/StochasticDispersionRAS.C
### Target audience
(Who will benefit from the changes?) -> Users
(What type of cases?) -> Lagrangian cases
### Proposal
The current sampling method could be replaced by a corrected one such as: http://corysimon.github.io/articles/uniformdistn-on-sphere/
### What does success look like, and how can we measure that?
By projecting the drawn vector on a plane. Currently, we should get a square. After the correction, we should get a disk.
### Links / references
http://corysimon.github.io/articles/uniformdistn-on-sphere/
### Funding
NAhttps://develop.openfoam.com/Development/openfoam/-/issues/2801Reimplementation of dlOpen for macOS to avoid SIP problems2023-07-25T18:28:07ZAlexey MatveichevReimplementation of dlOpen for macOS to avoid SIP problems### Functionality to add/problem to solve
SIP (System Integrity Protection) on macOS clears environment variables, which affect behaviour of dynamic linker (`DYLD_LIBRARY_PATH`). OpenFOAM keeps backup of this variable in `FOAM_LD_LIBRAR...### Functionality to add/problem to solve
SIP (System Integrity Protection) on macOS clears environment variables, which affect behaviour of dynamic linker (`DYLD_LIBRARY_PATH`). OpenFOAM keeps backup of this variable in `FOAM_LD_LIBRARY_PATH` and currently it restores `DYLD_LIBRARY_PATH` in `RunFunctions` file. This solution is not quite complete, as it (a) requires sourcing of `RunFunctions` file, (b) additional errors appear depending on a user workflow (ex. #2793, #2555).
The patch solves the problem by iterating through paths stored in backup variable, while loading dynamic library.
### Target audience
OpenFOAM users on macOS with SIP enabled.
### Proposal
Try to emulate `dlopen` behaviour: iterate over paths stored in `FOAM_LD_LIBRARY_PATH`, for each of the paths construct full path to the library, try to load a library using full path.
### What does success look like, and how can we measure that?
1. There is no need to restore `DYLD_LIBRARY_PATH` in `RunFunctions`.
2. User with SIP enabled can load additional libraries in case files and solver finds them independently of the way the case is executed (from command line, from a script using `runApplication` function, from a script using `foamJob` script, etc.)
### Funding
Patch implementing the functionality is attached to the issue.
[01-dlopen-SIP-remediation.patch](/uploads/8c8d00874f6af5c6d57bbcb0ada00113/01-dlopen-SIP-remediation.patch)
### Note
`sprintf` and `vfork` are deprecated on macOS, so I also added changes to remove deprecation warnings during compilation.Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/2941Missing Debian 12 (bookworm) release2023-07-20T09:08:25ZDiego MagelaMissing Debian 12 (bookworm) releaseThere are no precompiled packages for debian bookworm.
Is there a workaround to install precompiled OpenFOAM in Debian 12?
Error:
`The repository 'https://dl.openfoam.com/repos/deb bookworm Release' does not have a Release file.`There are no precompiled packages for debian bookworm.
Is there a workaround to install precompiled OpenFOAM in Debian 12?
Error:
`The repository 'https://dl.openfoam.com/repos/deb bookworm Release' does not have a Release file.`https://develop.openfoam.com/Development/openfoam/-/issues/2922Brownian motion force should use cubic distribution2023-07-13T15:10:38ZGuanyang XueBrownian motion force should use cubic distribution### Summary
The current code in BrownianMotionForce.C is calculating wrong Brownian motion force. The equation used to be correct (now it's commented out). However this reporter (https://develop.openfoam.com/Development/openfoam/-/commi...### Summary
The current code in BrownianMotionForce.C is calculating wrong Brownian motion force. The equation used to be correct (now it's commented out). However this reporter (https://develop.openfoam.com/Development/openfoam/-/commit/ee9e7cf0375147af1e9d57a039ad4f241bad8e4f,https://bugs.openfoam.org/view.php?id=2153) didn't know how to properly set up a particle tracking simulation and used an unrealistically large time step to generate wrong results. Unfortunately Mr. Henry Weller believed in him and adapted his wrong code. The ESI version is also affected.
### Steps to reproduce
I'm attaching an example case to reproduce. The domain is 2um x 2um x 2um box with stationary water inside. 2000 x 1um particles are injected at (0,0,0) with `BrownianMotion` and `sphereDrag` enabled. After some time, collect all coordinates and calculate the RMS of the particles (I use paraview+excel).
### Example case
This case takes 2 hours to run on my workstation. It might be OK to reduce the total time. However the time step should always be smaller than particle relaxation time (5e-8s in this case).
[Tesetcase-v2212.zip](/uploads/a35708e213aece4919013b01ac50a561/Tesetcase-v2212.zip)
```
blockMesh
decomposePar
mpirun -np 8 reactingParcelFoam -parallel
```
### What is the current *bug* behaviour?
The spherical distribution is generating a Brownian motion force that is sqrt(3) times smaller than it should be. The validation case provided by the original reporter made 2 mistakes: 1. Use 2D geometry to validate 3D Brownian motion. 2. Use super large timestep (20,000 times of particle relaxation time) to simulate Brownian motion.
### What is the expected *correct* behavior?
Literature 1: Dispersion and Deposition of Spherical Particles from Point Sources in a Turbulent Channel Flow https://www.tandfonline.com/doi/ref/10.1080/02786829208959550
Literature 2: https://dl.cfdexperts.net/cfd_resources/Ansys_Documentation/Fluent/Ansys_Fluent_Theory_Guide.pdf (page 425) Fluent is using the "cubic distribution" as well.
The RMS of the particle should match the theoretical value from diffusion coefficient (https://en.wikipedia.org/wiki/Random_walk#Relation_to_Wiener_process), where RMS^2 should equal to 6Dt.
Here T=293, mu=1e-3, d=1e-6, therefore using Stokes-Einstein equation D=4.3e-13.
### Relevant logs and/or images
![RMS](/uploads/75381e2df0676711e4e0b13618c0fc74/RMS.png)
### Environment information
- OpenFOAM version : all versions since 2016
- Operating system :
- Hardware info :
- Compiler :
### Possible fixes
Use the following code in `src/lagrangian/turbulence/submodels/Thermodynamic/ParticleForces/BrownianMotion/BrownianMotionForce.C` will generate correct results.
```
Random& rnd = this->owner().rndGen();
for (direction dir = 0; dir < vector::nComponents; dir++)
{
value.Su()[dir] = f*rnd.GaussNormal<scalar>();
}
```
This should be faster than the implementation that is commented out, as `rnd.GaussNormal<scalar>()` generates a pair of random numbers.v2312Kutalmış BerçinKutalmış Berçinhttps://develop.openfoam.com/Development/openfoam/-/issues/2940weightedFluxExample validation case does not plot anything2023-07-13T15:09:02ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comweightedFluxExample validation case does not plot anything<!--
*** 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 -->
functionObject produces line_T.xy or line_T_flux.xy. `plot` script expects `line_flux.xy`.
### 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-rc2
- Operating system :
- Hardware info :
- Compiler :Kutalmış BerçinKutalmış Berçinhttps://develop.openfoam.com/Development/openfoam/-/issues/2931Tutorial wallMountedHump uses the wrong Wall function2023-07-12T07:28:20ZDjilou MioubTutorial wallMountedHump uses the wrong Wall functionIn the tutorial `$FOAM_TUTORIALS/incompressible/pimpleFoam/LES/wallMountedHump` the `bottomWall` patch uses the `kqRWallFunction`. However, monitoring the maximum y+ value for that patch in the `wallMountedHump/results/kOmegaSSTDDES-Delt...In the tutorial `$FOAM_TUTORIALS/incompressible/pimpleFoam/LES/wallMountedHump` the `bottomWall` patch uses the `kqRWallFunction`. However, monitoring the maximum y+ value for that patch in the `wallMountedHump/results/kOmegaSSTDDES-DeltaOmegaTilde-useSigmaTrue` case (This results directory is created after running Allrun script) reveals that the maximum y+ is less than 1.
According to the documentation of [kqRWallFunction](https://www.openfoam.com/documentation/guides/latest/doc/guide-bcs-wall-turbulence-kqRWallFunction.html), this wall function works only for High-Re turbulence models. In this case, the wall function should be changed to `kLowReWallFunction`
Here is the output of yPlus functon object (the case runs from t=0 to t=0.1s):
```
# y+ ()
# Time patch min max average
0.035 bottomWall 5.069050e-01 7.116099e-01 6.489882e-01
0.036 bottomWall 5.035144e-01 7.100054e-01 6.465464e-01
0.037 bottomWall 5.001048e-01 7.086455e-01 6.441265e-01
0.038 bottomWall 4.966794e-01 7.073639e-01 6.417274e-01
0.039 bottomWall 4.932415e-01 7.060872e-01 6.393480e-01
0.04 bottomWall 4.897940e-01 7.048148e-01 6.369876e-01
0.041 bottomWall 4.863399e-01 7.035460e-01 6.346452e-01
0.042 bottomWall 4.828823e-01 7.022801e-01 6.323201e-01
0.043 bottomWall 4.794237e-01 7.010166e-01 6.300118e-01
0.044 bottomWall 4.759671e-01 6.997553e-01 6.277195e-01
0.045 bottomWall 4.725155e-01 6.984956e-01 6.254428e-01
0.046 bottomWall 4.690714e-01 6.972373e-01 6.231812e-01
0.047 bottomWall 4.656373e-01 6.959800e-01 6.209343e-01
0.048 bottomWall 4.622159e-01 6.947235e-01 6.187016e-01
0.049 bottomWall 4.588097e-01 6.934673e-01 6.164829e-01
0.05 bottomWall 4.554209e-01 6.922117e-01 6.142778e-01
0.051 bottomWall 4.520517e-01 6.909564e-01 6.120862e-01
0.052 bottomWall 4.487040e-01 6.897016e-01 6.099079e-01
0.053 bottomWall 4.452075e-01 6.884473e-01 6.077425e-01
0.054 bottomWall 4.417060e-01 6.871933e-01 6.055900e-01
0.055 bottomWall 4.382235e-01 6.859400e-01 6.034502e-01
0.056 bottomWall 4.347618e-01 6.846872e-01 6.013230e-01
0.057 bottomWall 4.313231e-01 6.834351e-01 5.992084e-01
0.058 bottomWall 4.279095e-01 6.821836e-01 5.971061e-01
0.059 bottomWall 4.245221e-01 6.809329e-01 5.950163e-01
0.06 bottomWall 4.211628e-01 6.796831e-01 5.929388e-01
0.061 bottomWall 4.178332e-01 6.784341e-01 5.908735e-01
0.062 bottomWall 4.145346e-01 6.771863e-01 5.888206e-01
0.063 bottomWall 4.112684e-01 6.759399e-01 5.867799e-01
0.064 bottomWall 4.080356e-01 6.746950e-01 5.847513e-01
0.065 bottomWall 4.048376e-01 6.734517e-01 5.827350e-01
0.066 bottomWall 4.016753e-01 6.722102e-01 5.807310e-01
0.067 bottomWall 3.985497e-01 6.709706e-01 5.787391e-01
0.068 bottomWall 3.954626e-01 6.697331e-01 5.767600e-01
0.069 bottomWall 3.924149e-01 6.684975e-01 5.747934e-01
0.07 bottomWall 3.894046e-01 6.672636e-01 5.728381e-01
0.071 bottomWall 3.864079e-01 6.660293e-01 5.708842e-01
0.072 bottomWall 3.834329e-01 6.648026e-01 5.689403e-01
0.073 bottomWall 3.805406e-01 6.635933e-01 5.670317e-01
0.074 bottomWall 3.776905e-01 6.623808e-01 5.651291e-01
0.075 bottomWall 3.748725e-01 6.611678e-01 5.632378e-01
0.076 bottomWall 3.720980e-01 6.599561e-01 5.613582e-01
0.077 bottomWall 3.693651e-01 6.587466e-01 5.594904e-01
0.078 bottomWall 3.666728e-01 6.575399e-01 5.576346e-01
0.079 bottomWall 3.638041e-01 6.563364e-01 5.557909e-01
0.08 bottomWall 3.609299e-01 6.551364e-01 5.539595e-01
0.081 bottomWall 3.580968e-01 6.539406e-01 5.521404e-01
0.082 bottomWall 3.553050e-01 6.527487e-01 5.503337e-01
0.083 bottomWall 3.525546e-01 6.515607e-01 5.485393e-01
0.084 bottomWall 3.498455e-01 6.503767e-01 5.467574e-01
0.085 bottomWall 3.471777e-01 6.491968e-01 5.449879e-01
0.086 bottomWall 3.445508e-01 6.480211e-01 5.432307e-01
0.087 bottomWall 3.419651e-01 6.468499e-01 5.414861e-01
0.088 bottomWall 3.394202e-01 6.456837e-01 5.397540e-01
0.089 bottomWall 3.369156e-01 6.445221e-01 5.380343e-01
0.09 bottomWall 3.344512e-01 6.433651e-01 5.363270e-01
0.092 bottomWall 3.296422e-01 6.410654e-01 5.329501e-01
0.094 bottomWall 3.249912e-01 6.387853e-01 5.296237e-01
0.095 bottomWall 3.227224e-01 6.376523e-01 5.279787e-01
0.096 bottomWall 3.203673e-01 6.365246e-01 5.263469e-01
0.097 bottomWall 3.177192e-01 6.354036e-01 5.247308e-01
0.098 bottomWall 3.151147e-01 6.342874e-01 5.231283e-01
0.099 bottomWall 3.125565e-01 6.331759e-01 5.215393e-01
0.1 bottomWall 3.099769e-01 6.320555e-01 5.199387e-01
```Kutalmış BerçinKutalmış Berçinhttps://develop.openfoam.com/Development/openfoam/-/issues/2802snappyHexMesh enable patch refinement for refinementRegions similar to refine...2023-07-07T09:08:46ZJulius BergmannsnappyHexMesh enable patch refinement for refinementRegions similar to refinementSurfaces### Functionality to add/problem to solve
Add the possibility to set refinementRegions for individual patches of a geometry. This is already possible in refinementSurfaces so workload for implementation should be feasable.
### Target ...### Functionality to add/problem to solve
Add the possibility to set refinementRegions for individual patches of a geometry. This is already possible in refinementSurfaces so workload for implementation should be feasable.
### Target audience
In CFD, we often have to define boundary layer regions close to the surface of a geometry. Especially for WMLES the thickness may vary greatly for individual parts of the surface, thus individual patch addressing by setting distance refinemed is very benificial in comparison to only being able to address the whole geometry. I believe that this change should not be tough to implement but is a nice QoL addition from which all fellow SHM-users can benefit.
Many users may find this especially useful if they have a geometry with several individual elements. One example may be a profile with multiple elements, where one may want to set distance refinement individually for each of the elements based on there flow importance.
### Detailed explanation
In order to refine individual patches of a geometry from a geometry file, I currently have to extract the patch as an additional geometry file and include it as another refinement region to use it for shell refinement.
This works well with surface-only geometry together with distance refinement, so why should it not be possible to directly apply region refinement from geometry patches as well? It is possible for refinementSurfaces but why not for refinementRegions?
As I am working with a geometry with several dozen surfaces to be individually refined, this creates many unnecessary and essentially duplicate files from the main geometry.
Here a simplified excerption of the code that I have to do at the moment to achieve surface distance refinement:
"CRMHL_WB_09222022_NoDomain_BLT_1.obj.gz"
{
type triSurfaceMesh;
regions
{
ww_wing_SS_01 { name ww_wing_SS_01; }
ww_wing_SS_02 { name ww_wing_SS_02; }
}
name Airplane_Body;
}
"CRMHL_WB_09222022_NoDomain_BLT_1_ww_wing_SS_01.obj.gz" { type triSurfaceMesh; }
"CRMHL_WB_09222022_NoDomain_BLT_1_ww_wing_SS_02.obj.gz" { type triSurfaceMesh; }
refinementSurfaces
{
Airplane_Body
{
level ($resMin $resMin);
regions
{
ww_wing_SS_01 { level ($LSS01 #eval{$LSS01} ); }
ww_wing_SS_02 { level ($LSS02 #eval{$LSS02} ); }
}
}
}
refinementRegions
{
Airplane_Body
{
mode distance;
levels ((10 #eval{$resMin - 3}) (20 #eval{$resMin - 5}));
}
CRMHL_WB_09222022_NoDomain_BLT_1_ww_wing_SS_01.obj.gz { mode distance; levels (( 320e-3 #eval{$LSS01})); }
CRMHL_WB_09222022_NoDomain_BLT_1_ww_wing_SS_02.obj.gz { mode distance; levels (( 160e-3 #eval{$LSS02})); }
}
What I would like to be able to do is the following, where I only have to reference the patch name in the refinement regions:
"CRMHL_WB_09222022_NoDomain_BLT_1.obj.gz"
{
type triSurfaceMesh;
regions
{
ww_wing_SS_01 { name ww_wing_SS_01; }
ww_wing_SS_02 { name ww_wing_SS_02; }
}
name Airplane_Body;
}
refinementSurfaces
{
Airplane_Body
{
level ($resMin $resMin);
regions
{
ww_wing_SS_01 { level ($LSS01 #eval{$LSS01} ); }
ww_wing_SS_02 { level ($LSS02 #eval{$LSS02} ); }
}
}
}
refinementRegions
{
Airplane_Body
{
mode distance;
levels ((10 #eval{$resMin - 3}) (20 #eval{$resMin - 5}));
regions
{
ww_wing_SS_01 { mode distance; levels (( 320e-3 #eval{$LSS01})); }
ww_wing_SS_02 { mode distance; levels (( 160e-3 #eval{$LSS02})); }
}
}
}
### Possible changes in source code
I had a short look at the source code. This change probably needs to be implemented in [shellSurfaces.C](https://develop.openfoam.com/Development/openfoam/-/blob/master/src/mesh/snappyHexMesh/shellSurfaces/shellSurfaces.C) around line 748-786 by extending the region loop. This probably can be made similar to how it is done in [refinementSurfaces.C](https://develop.openfoam.com/Development/openfoam/-/blob/master/src/mesh/snappyHexMesh/refinementSurfaces/refinementSurfaces.C), where we also define a level for the whole geometry as well as each individual region / patch.
However, I am not experienced enough / do not have enough time to take a deeper look at this.
### Previous work
This was already mentioned in issue #1005 but nothing happend in 4 years so I am reopening it.https://develop.openfoam.com/Development/openfoam/-/issues/2935Patch: Visual Studio Code Support Fix #22023-07-06T15:25:32ZVolker WeißmannPatch: Visual Studio Code Support Fix #2Please apply the following patch:
```diff
diff --git a/bin/tools/vscode-settings b/bin/tools/vscode-settings
index 80a9f30898..a585e50abc 100755
--- a/bin/tools/vscode-settings
+++ b/bin/tools/vscode-settings
@@ -141,10 +141,10 @@ fi
...Please apply the following patch:
```diff
diff --git a/bin/tools/vscode-settings b/bin/tools/vscode-settings
index 80a9f30898..a585e50abc 100755
--- a/bin/tools/vscode-settings
+++ b/bin/tools/vscode-settings
@@ -141,10 +141,10 @@ fi
cat << JSON_CONTENT
- "C_Cpp.autocomplete": "Disabled",
- "C_Cpp.errorSquiggles": "Disabled",
- "C_Cpp.formatting": "Disabled",
- "C_Cpp.intelliSenseEngine": "Disabled"
+ "C_Cpp.autocomplete": "disabled",
+ "C_Cpp.errorSquiggles": "disabled",
+ "C_Cpp.formatting": "disabled",
+ "C_Cpp.intelliSenseEngine": "disabled"
}
}
JSON_CONTENT
```https://develop.openfoam.com/Development/openfoam/-/issues/2926Confusing/misleading GeometricField constructor2023-07-06T06:29:11ZMark OLESENConfusing/misleading GeometricField constructorAs raised as [cfd-online issue](https://www.cfd-online.com/Forums/openfoam-programming-development/250569-how-create-field-without-reading-0-directroy.html), the following field constructor can be misleading:
```
//- Construct and read g...As raised as [cfd-online issue](https://www.cfd-online.com/Forums/openfoam-programming-development/250569-how-create-field-without-reading-0-directroy.html), the following field constructor can be misleading:
```
//- Construct and read given IOobject
GeometricField
(
const IOobject& io,
const Mesh& mesh,
const bool readOldTime = true
);
```
One could suppose that the constructor respects the readOption of the IOobject but it does not. It always reads!
For a non-read constructor, the preferred form would be
```
GeometricField
(
const IOobject& io,
const Mesh& mesh,
const dimensionSet& ds,
const word& patchFieldType = PatchField<Type>::calculatedType()
);
```
but this may be non-obvious.
- Minimum fix: more explicit documentation, add a warning message when using with incorrect readOption so that it emits something before possibly failing.
- TBD: have the constructor switch to readIfPresent behaviour or even no-read. In these cases, not really sure if the implied boundaries are also "calculated" etc. Could potentially change some existing code?Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/2932processorLOD boxes with odd mapping2023-07-06T06:28:21ZMark OLESENprocessorLOD boxes with odd mappingBy inspection - the processorLOD in meshToMesh appears to use regular mapDistribute ordering (local proc first) whereas AABBTree definitely uses linear ordering (as noticed in regression: 7b20e888a80).By inspection - the processorLOD in meshToMesh appears to use regular mapDistribute ordering (local proc first) whereas AABBTree definitely uses linear ordering (as noticed in regression: 7b20e888a80).v2312Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/2927OpenFOAM 2306 build instructions and source tgz files2023-07-03T15:02:57ZDavid HuckabyOpenFOAM 2306 build instructions and source tgz files
The file for the current build instructions from source reference the v2212 files:
https://develop.openfoam.com/Development/openfoam/-/blob/master/doc/Build.md
```
* Source: https://dl.openfoam.com/source/v2212/OpenFOAM-v2212.tgz
* Thi...
The file for the current build instructions from source reference the v2212 files:
https://develop.openfoam.com/Development/openfoam/-/blob/master/doc/Build.md
```
* Source: https://dl.openfoam.com/source/v2212/OpenFOAM-v2212.tgz
* ThirdParty: https://dl.openfoam.com/source/v2212/ThirdParty-v2212.tgz
```
And the directory for the latest distribution: https://dl.openfoam.com/source/latest/
does not include a source file, e.g. "OpenFOAM-v2306.tgz" for the 2306 version.