Development issueshttps://develop.openfoam.com/groups/Development/-/issues2020-10-29T08:14:54Zhttps://develop.openfoam.com/Development/openfoam/-/issues/1901Add searchable spheroid2020-10-29T08:14:54ZMark OLESENAdd searchable spheroidThis is an idea that I discussed offline with @Mattijs. Having spheroid as a shape could be useful for external surroundings etc. Found some ideas, but equally importantly I have someone willing to implement it (@victorOle). The first ef...This is an idea that I discussed offline with @Mattijs. Having spheroid as a shape could be useful for external surroundings etc. Found some ideas, but equally importantly I have someone willing to implement it (@victorOle). The first efforts look good, but would likely make most sense to merge into searchableSphere and treat the uniform radii as a special optimized case.
Largely able to work from [Geometric Tools](https://www.geometrictools.com/Documentation/DistancePointEllipseEllipsoid.pdf) documentation (CC-BY 4.0), but needs rework for the OpenFOAM frameworkMark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/1887Using the -case argument with extrudeMesh to specify the case directory does ...2020-11-02T09:15:54ZGerhard HolzingerUsing the -case argument with extrudeMesh to specify the case directory does not apply to paths stated in extrudeMeshDict<!--
*** 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 utility extrudeMesh fails to read a triSurface file, when I provide the case directory using the '-case' command line flag. The path to the triSurfaceFile is provided in the extrudeMeshDict as 'constant/triSurface/filename'.
Using a working directory which is the case directory, all is well. However, if I call extrudeMesh from the case's parent directory, and provide the case directory using the '-case' argument, the triSurface file can not be found.
Maybe, this is a bug of the VTK-file reader; and not of extrudeMesh itself. However, the unexpected behaviour of extrudeMesh described here is the symptom I encountered. The root-problem may be well something else.
### Steps to reproduce
<!-- How one can reproduce the issue - this is very important -->
Go to the 'overRhoSimpleFoam/hotCylinder' tutorial case.
Change to 'cylinderMesh', and call 'extrudeMesh' -> all is well
Go back up (call 'cd ..'), clear the case (call './Allclean'), and call 'extrudeMesh -case cylinderMesh' -> error: 'Cannot read file "constant/triSurface/cylinder.vtk"'
### 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
-->
Use the 'overRhoSimpleFoam/hotCylinder' tutorial case.
### What is the current *bug* behaviour?
<!-- What actually happens -->
extrudeMesh fails to read the provided triSurface file, which is provided in extrudeMeshDict.
If I change the entry in the file extrudeMeshDict from 'constant/triSurface/cylinder.vtk' to 'cylinderMesh/constant/triSurface/cylinder.vtk', then extrudeMesh finds the file.
`Extruding surfaceMesh read from file "cylinderMesh/constant/triSurface/cylinder.vtk"`
### What is the expected *correct* behavior?
<!-- What you should see instead -->
I would expect extrudeMesh to take the path from extrudeMeshDict, i.e. 'constant/triSurface/cylinder.vtk', and form a path from the specified case directory.
The output of extrudeMesh lists the correct case directory:
`Case : /home/gerhard/OpenFOAM/OpenFOAM-v2006/tutorials/compressible/overRhoSimpleFoam/hotCylinder/cylinderMesh`
I would expect, that the path to the triSurface file is treated as a relative path, which is combined with the provided case directory.
### Relevant logs and/or images
```
gerhard@host:~/OpenFOAM/OpenFOAM-v2006/tutorials/compressible/overRhoSimpleFoam/hotCylinder$ ls
Allclean Allrun Allrun.pre cylinderAndBackground cylinderMesh
gerhard@host:~/OpenFOAM/OpenFOAM-v2006/tutorials/compressible/overRhoSimpleFoam/hotCylinder$ extrudeMesh -case cylinderMesh
/*---------------------------------------------------------------------------*\
| ========= | |
| \\ / F ield | OpenFOAM: The Open Source CFD Toolbox |
| \\ / O peration | Version: v2006 |
| \\ / A nd | Website: www.openfoam.com |
| \\/ M anipulation | |
\*---------------------------------------------------------------------------*/
Build : _b45f8f6f58-20200629 OPENFOAM=2006
Arch : "LSB;label=32;scalar=64"
Exec : extrudeMesh -case cylinderMesh
Date : Oct 20 2020
Time : 14:09:57
Host : host
PID : 20346
I/O : uncollated
Case : /home/gerhard/OpenFOAM/OpenFOAM-v2006/tutorials/compressible/overRhoSimpleFoam/hotCylinder/cylinderMesh
nProcs : 1
trapFpe: Floating point exception trapping enabled (FOAM_SIGFPE).
fileModificationChecking : Monitoring run-time modified files using timeStampMaster (fileModificationSkew 5, maxFileModificationPolls 20)
allowSystemOperations : Allowing user-supplied system call operations
// * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * //
Create time
Create mesh for time = 0
Selecting extrudeModel linearNormal
Selected extrudeModel for linearNormal using coeffs
{
thickness 0.7;
}
Extruding from surface using model linearNormal
Not collapsing any edges after extrusion
Extruding surfaceMesh read from file "constant/triSurface/cylinder.vtk"
--> FOAM FATAL ERROR:
Cannot read file "constant/triSurface/cylinder.vtk"
From bool Foam::fileFormats::VTKsurfaceFormat<Face>::read(const Foam::fileName&) [with Face = Foam::face]
in file surfaceFormats/vtk/VTKsurfaceFormat.C at line 98.
FOAM exiting
gerhard@host:~/OpenFOAM/OpenFOAM-v2006/tutorials/compressible/overRhoSimpleFoam/hotCylinder$
```
### 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 : 2006
- Operating system : Ubuntu-18.04
- Hardware info :
- Compiler : gcc
### 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/1647More control for making or skipping make2020-11-05T17:36:59ZMark OLESENMore control for making or skipping makeWhen building with or without modules, it will be useful to selective suppress building of some components.
- compile all of OpenFOAM, but without any modules
- later compile a module indvidually
I'm thinking of places where we might w...When building with or without modules, it will be useful to selective suppress building of some components.
- compile all of OpenFOAM, but without any modules
- later compile a module indvidually
I'm thinking of places where we might want to have a module such as visualization, or adios added as an additional RPM or spack package **on top** of an existing OpenFOAM installation.
Ideas:
1. If a `Allwmake.disabled` exists at the same level as a `Allwmake` file, skip it.
2. Use a `Allwmake.override` instead of `Allwmake` file at the same level.
3. Rename `Allwmake` file to `Allwmake.enabled` and symlink back to `Allwmake` when it is enabled.
4. Add in a minor logic into the overridable `Allwmake`. For example,
```
enabled=true
if [ "$enabled" != true ]
then
echo "$0: is disabled"
exit 0
fi
```
@Development Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/1768update lemon version and syntax2020-11-09T14:45:35ZMark OLESENupdate lemon version and syntax- newer lemon is available with minor bugfixes and additional `%else` handling.
- change patch to handle `%static` directive instead of `%namespace` directive.
After [forum discussions](https://sqlite.org/forum) there is no foreseeable ...- newer lemon is available with minor bugfixes and additional `%else` handling.
- change patch to handle `%static` directive instead of `%namespace` directive.
After [forum discussions](https://sqlite.org/forum) there is no foreseeable upstream acceptable for the `%namespace` patches we have introduced (the `-e` option might still be open to debate). Since OpenFOAM only uses the anonymous namespace to encapsulate the Lemon parser routines, just use a simpler static linkage instead. This results in a smaller, less intrusive patch, with the vague possibility that it could be upstreamed.v2012Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/1912Compiling OpenFOAM v.20062020-11-10T12:10:41ZTasman Van LoonCompiling OpenFOAM v.2006Hi there, I'm trying to compile OpenFOAM v.2006 and have followed the instructions as per this webpage:
https://develop.openfoam.com/Development/openfoam/blob/develop/doc/Build.md
There are no issues with the foamSystemCheck. But when I...Hi there, I'm trying to compile OpenFOAM v.2006 and have followed the instructions as per this webpage:
https://develop.openfoam.com/Development/openfoam/blob/develop/doc/Build.md
There are no issues with the foamSystemCheck. But when I go to execute the ./Allwmake command, there is an error message (which I have attached).
Any advice would be appreciated!
Kind regards,
Tasman. ![Screen_Shot_2020-11-05_at_11.04.27_pm](/uploads/60136129f5c4821f4a97e5281f02c7b7/Screen_Shot_2020-11-05_at_11.04.27_pm.png)https://develop.openfoam.com/Development/openfoam/-/issues/1916Testcases with Reacting Parcels Fail ('constantVolume' or 'volumeUpdateMethod...2020-11-10T17:34:34ZThorsten ZirwesTestcases with Reacting Parcels Fail ('constantVolume' or 'volumeUpdateMethod' must be provided)In the current develop branch (1d544540), many tutorial cases with reacting parcels fail. For example:
```
cd $FOAM_TUTORIALS/combustion/fireFoam/LES/smallPoolFire2D/
./Allrun
```
or
```
cd /work/fh2-project-devel/np4075/commit_Bilge...In the current develop branch (1d544540), many tutorial cases with reacting parcels fail. For example:
```
cd $FOAM_TUTORIALS/combustion/fireFoam/LES/smallPoolFire2D/
./Allrun
```
or
```
cd /work/fh2-project-devel/np4075/commit_Bilger_2006/openfoam-com/tutorials/lagrangian/reactingParcelFoam/counterFlowFlame2DLTS/
blockMesh
reactingParcelFoam
```
will both yield
```
--> FOAM FATAL ERROR: (openfoam-2010 patch=201012)
Either 'constantVolume' or 'volumeUpdateMethod'
must be provided.
The new keyword is 'volumeUpdateMethod'.
Available methods are :
constantRho, constantVolume or updateRhoAndVol.
'constantVolume' is either true/false
```
Adding the following entry in `constant/reactingCloud1Properties` fixes the problem.
```
constantProperties
{
constantVolume true;
}
```
In version v2006, the cases work fine. The problem seems to originate from commit 11d17fec5f, more specifically here:
https://develop.openfoam.com/Development/openfoam/-/blob/develop/src/lagrangian/intermediate/parcels/Templates/ReactingParcel/ReactingParcelI.H#L73
The constructor of constantProperties always requires a value to be specified, regardless if the particles are active or not.https://develop.openfoam.com/Development/openfoam/-/issues/1813compressibleInterFoam: unphysical oscillations in transonic flows2020-11-10T17:34:53ZMartin HeinrichcompressibleInterFoam: unphysical oscillations in transonic flows### Summary
compressibleInterFoam produces unrealistic oscillations for transonic flow simulations. This can be demonstrated using a simple shockTube tutorial case. Interestingly, this problem was not present prior to OpenFOAM 5.0.
###...### Summary
compressibleInterFoam produces unrealistic oscillations for transonic flow simulations. This can be demonstrated using a simple shockTube tutorial case. Interestingly, this problem was not present prior to OpenFOAM 5.0.
### Steps to reproduce
Use the shockTube tutorial case of rhoCentralFoam and solve it with compressibleInterFoam with OpenFOAM v2006
### Example case
I have attached the shockTube tutorial case set up for compressibleInterFoam and for comparison also the case for rhoPimpleFoam with OpenFOAM v2006 [summary.zip](/uploads/f912e1f72bfd05fd7edd866bc4417c04/summary.zip). The solution for rhoPimpleFoam matches quite well with rhoCentralFoam. However, compressibleInterFoam is quite far off and oscillates strongly between x = 2 and x = 4. This happens for all OpenFOAM versions starting with 5.0, including the latest v2006. However, it does not happen in OpenFOAM 4.x and earlier.
![shockTube](/uploads/fae665ca0e06cef72810a3349011f4b6/shockTube.png)
### Environment information
- OpenFOAM version : v2006
- Operating system : Debian 10
- Hardware info :
- Compiler : gcc 9.1
### Possible fixes
This problem started somewhere around [commit e8daaa5c767ac9731fb7ec3259043a4aae5ae972](https://github.com/OpenFOAM/OpenFOAM-5.x/commit/e8daaa5c767ac9731fb7ec3259043a4aae5ae972) in OpenFOAM 5.x. Prior to that (for example OpenFOAM 4.x), the results agree quite well with rhoCentralFoam and rhoPimpleFoam.https://develop.openfoam.com/Development/openfoam/-/issues/1828actuationDiskSource: Usage and description2020-11-13T09:23:41ZHassan KassemactuationDiskSource: Usage and descriptionHello,
According to the usage description of the ``actuationDiskSource``, ``diskDir`` is Surface-normal vector of the actuator disk pointing upstream. This contradicts the ``turbineSiting`` tutorial where ``diskDir`` is pointing ``(1 0 ...Hello,
According to the usage description of the ``actuationDiskSource``, ``diskDir`` is Surface-normal vector of the actuator disk pointing upstream. This contradicts the ``turbineSiting`` tutorial where ``diskDir`` is pointing ``(1 0 0)`` which the same direction as the flow (downstream). In order to double check, I ran the tutorial four times using the two available force models with ``diskDir (1 0 0)`` (downstream) and ``diskDir (-1 0 0)`` (upstream). The attached figure shows the results along horizontal line through the centre of the ``disk1``. It clear from the pressure that downstream is the right direction. This has been done using ``OpenFOAM-v2006``.
![compare_disks](/uploads/124c335c5864f36ffe0aef5b660c9441/compare_disks.png)
Anther point which sounds confusing is this comment
```cpp
//- Flag for body forces to act as a source (true) or a sink (false)
label sink_;
```
From what I see in the code and OF sign convention as far as I understand, true ``sink_`` leads to positive term which acts as sink (momentum extraction) and vice versa. Hence, the comment isn't accurate unless I'm missing something here.
Thanks for your effort and continues support,
Best wishes,
Hassanv2012Kutalmış BerçinKutalmış Berçinhttps://develop.openfoam.com/Development/openfoam/-/issues/1143reconstructPar crashes with cyclicAMI2020-11-13T09:25:15ZAdminreconstructPar crashes with cyclicAMIIn a case using cyclicAMI to make the grid periodic across two patches, the simulation runs successfully but crashes when trying to reconstruct the solution at the end of the parallel run, giving the following error:
AMI: Creating addre...In a case using cyclicAMI to make the grid periodic across two patches, the simulation runs successfully but crashes when trying to reconstruct the solution at the end of the parallel run, giving the following error:
AMI: Creating addressing and weights between 66 source faces and 45 target faces
--> FOAM Warning :
From function void Foam::AMIMethod<SourcePatch, TargetPatch>::checkPatches() const [with SourcePatch = Foam::PrimitivePatch<Foam::face, Foam::SubList, const Foam::Field<Foam::Vector<double>> &, Foam::Vector<double>>, TargetPatch = Foam::PrimitivePatch<Foam::face, Foam::SubList, const Foam::Field<Foam::Vector<double>> &, Foam::Vector<double>>]
in file lnInclude/AMIMethod.C at line 57
Source and target patch bounding boxes are not similar
source box span : (0.05 0 0.001)
target box span : (0.0449116 0 0.001)
source box : (-0.05 -0.00965 -0.0015) (1.92091e-11 -0.00965 -0.0005)
target box : (-0.05 -0.00965 -0.0015) (-0.00508841 -0.00965 -0.0005)
inflated target box : (-0.0522461 -0.0118961 -0.00374614) (-0.00284227 -0.00740386 0.00174614)
The same case works fine with an older grid differing only by few cells in the total count.
Please also note this issue has been reported but not solved here:
https://bugs.openfoam.org/view.php?id=1234
and discussed here on CFD online:
https://www.cfd-online.com/Forums/openfoam-solving/100325-problems-using-reconstructpar-case-involving-ami.html
The issue has been tested and rises with both the v1806 and v1606 releases.
\## Reattaching the author to the issue ticket: @Ricky\-11 ##v2012Kutalmış BerçinKutalmış Berçinhttps://develop.openfoam.com/Development/openfoam/-/issues/1913SolidificationMeltingSource acts different on 2D and 3D2020-11-13T10:41:39ZEren ColakSolidificationMeltingSource acts different on 2D and 3D<!--
*** Please read this first! ***
B[SolidMeltSource.7z](/uploads/dab9f2ec6ea41b67fd1a825073253679/SolidMeltSource.7z)
-->
<!--
All text between these markers are comments and will not be present in the
report
-->
### Summar...<!--
*** Please read this first! ***
B[SolidMeltSource.7z](/uploads/dab9f2ec6ea41b67fd1a825073253679/SolidMeltSource.7z)
-->
<!--
All text between these markers are comments and will not be present in the
report
-->
### Summary
SolidificationMeltingSource gives different results with 2D and 3D solutions. While 3D solution gives accurate results there is no change in the z direction(3rd direction). So it makes no sense and increases the computational time up to 10 times.
### Steps to reproduce
just run buoyantPimpleFoam for test cases I sent. Files also contains some of the results.
### 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?
Somehow "Benard Cells" appears in 2D case and it changes melting front drastically.
### What is the expected *correct* behavior?
There should be no "Benard Cells" so melting front will be like 3D case I attached.
### 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
- OpenFOAM version : v2002
- Operating system : ubuntu 18.04
- Hardware info : ryzen 5 3600
- Compiler : gcc
### Possible fixes
I have no idea about this.[SolidMeltSource.7z](/uploads/bcf207105fb5bded154a3552c4cb5fc8/SolidMeltSource.7z)https://develop.openfoam.com/Development/openfoam/-/issues/1910rationalize mpi config tuning2020-11-17T12:06:14ZMark OLESENrationalize mpi config tuningThe tuning of mpi parameters is difficult to distinguish from regular configurations.
Eg, `config.sh/mpi` vs `config.sh/openmpi`.
I would propose that we unify this with a common prefix or suffix.
My current tendency is with a prefix, t...The tuning of mpi parameters is difficult to distinguish from regular configurations.
Eg, `config.sh/mpi` vs `config.sh/openmpi`.
I would propose that we unify this with a common prefix or suffix.
My current tendency is with a prefix, to have nicely sorted items. The prefix `tune.` looks nice to me, but `prefs.` is probably better since it bears resemblance to `prefs.sh` etc.
After the change, we could add in additional preference tuning for mpich, intelmpi etc. The optional files would then look like this:
- config.sh/prefs.mpich
- config.sh/prefs.openmpi
- config.sh/prefs.openmpi-system
- ...
This mostly affects @Prashant and perhaps @Pawan I would suspect.v2012Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/1884surfaceFieldValue : doesn't handle volumeField2020-11-17T12:06:40ZPrashant SonakarsurfaceFieldValue : doesn't handle volumeField### Functionality to add/problem to solve
surface field value doesn't handle volume fields when using in faceZone mode.
Cross reference: EP#1316 and EP#1415
@mark @andy### Functionality to add/problem to solve
surface field value doesn't handle volume fields when using in faceZone mode.
Cross reference: EP#1316 and EP#1415
@mark @andyMark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/1907PDRsetFields fails with non-orthogonal outer region2020-11-17T12:06:53ZMark OLESENPDRsetFields fails with non-orthogonal outer regionnoticed while testing #1906noticed while testing #1906Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/1919gap refinement /proximity refinement: snappyHexMesh tutorial fails in windows2020-11-17T12:49:52ZPawan Ghildiyalgap refinement /proximity refinement: snappyHexMesh tutorial fails in windowsEP:1434EP:1434Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/1060improvements for topoSet2020-11-17T13:16:45ZMark OLESENimprovements for topoSet- need to distinguish between topoSetSource (CELL, FACE, POINT)
- support multiple zones, multiple patches
- keyword consistency (eg, centre vs origin)- need to distinguish between topoSetSource (CELL, FACE, POINT)
- support multiple zones, multiple patches
- keyword consistency (eg, centre vs origin)v1812Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/1928BUG: geometricVoF included twice in interIsoFoam/Make/options2020-11-18T21:44:09ZJohan RoenbyBUG: geometricVoF included twice in interIsoFoam/Make/options`-I$(LIB_SRC)/transportModels/geometricVoF/lnInclude`
appears twice under EXE_INC in:
[https://develop.openfoam.com/Development/openfoam/-/blob/master/applications/solvers/multiphase/interIsoFoam/Make/options](https://develop.openfoam....`-I$(LIB_SRC)/transportModels/geometricVoF/lnInclude`
appears twice under EXE_INC in:
[https://develop.openfoam.com/Development/openfoam/-/blob/master/applications/solvers/multiphase/interIsoFoam/Make/options](https://develop.openfoam.com/Development/openfoam/-/blob/master/applications/solvers/multiphase/interIsoFoam/Make/options)Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/1926Paraview_plugins compilation error2020-11-19T03:22:19ZRamkumarParaview_plugins compilation errorHi,
recently i was trying to compile OpenFOAM v2006 with paraview. I am successful on compilation of OpenFOAM and Paraview on my machine.. now when i try to compile the paraview_plugins, i am getting following error
`
/usr/bin/ld: canno...Hi,
recently i was trying to compile OpenFOAM v2006 with paraview. I am successful on compilation of OpenFOAM and Paraview on my machine.. now when i try to compile the paraview_plugins, i am getting following error
`
/usr/bin/ld: cannot find -lvtkPVFoamCommon-pv5.6
/usr/bin/ld: cannot find -lvtkPVFoamReader-pv5.6
collect2: error: ld returned 1 exit status
CMakeFiles/ParaFoamReader.dir/build.make:452: recipe for target 'libParaFoamReader.so' failed
make[2]: *** [libParaFoamReader.so] Error 1
CMakeFiles/Makefile2:67: recipe for target 'CMakeFiles/ParaFoamReader.dir/all' failed
make[1]: *** [CMakeFiles/ParaFoamReader.dir/all] Error 2
Makefile:129: recipe for target 'all' failed
make: *** [all] Error 2
WARNING: incomplete build of ParaView plugin: foamReader
`
i tried many times but i am getting this error continuously..this occurs not only for foamReader, but also for all the plugins for paraview.. i tried many suggesstions online but nothing worked, hence i am posting in here.. i have attached the log of compilation of paraview_plugins here with.
thanks
[log.linux64GccDPInt32Opt](/uploads/e81cec764db5a0fbb8ec7c13fc708b8b/log.linux64GccDPInt32Opt)https://develop.openfoam.com/Development/openfoam/-/issues/1921Use "names" for sampled items2020-11-19T15:13:26ZMark OLESENUse "names" for sampled itemsAs a comment raised on EP1415, if we support sampling on faceZones and patches we have a naming discrepancy between sampling and surfaceFieldValue.
In surfaceFieldValue we select the type (patch/zone/surface etc) and use "names" to spec...As a comment raised on EP1415, if we support sampling on faceZones and patches we have a naming discrepancy between sampling and surfaceFieldValue.
In surfaceFieldValue we select the type (patch/zone/surface etc) and use "names" to specify the selection. For sampledPatch, we specify the type (Eg, type patch), but there we use "patches" to specify the selection instead of "names". If we add faceZones into the mix, we then have "zones" as well.
@Prashant figured that going with "patches" and "zones" might be better. I'm not so sure at the moment.
Currently tending towards "names" for both with a silent compatibility handling of "patches".Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/1463snappyHexMesh : Add an option to disable self-proximity in region proximity r...2020-11-25T16:11:15ZAdminsnappyHexMesh : Add an option to disable self-proximity in region proximity refinement### Functionality to add/problem to solve
The proximity refinement added to the refinementRegions in snappyHexMesh is super powerful. However, unless I'm mistaken, one feature I believe it lacks is the ability to limit refinement to be ...### Functionality to add/problem to solve
The proximity refinement added to the refinementRegions in snappyHexMesh is super powerful. However, unless I'm mistaken, one feature I believe it lacks is the ability to limit refinement to be between two separate regions/surfaces only (disable self-proximity). We can already override the gapLevel and gapMode settings on a per surface basis, but this also overrides refinement in gaps between two separate regions/surfaces.
I know that this can be made moot by specifying a very specifically shaped and sized refinementRegion that only covers the gap I want to capture, but I would much rather just throw a bounding box around two objects and have it only refine where they get close to each other and not do self-proximity, which can open up unintended gaps in the surfaces.
### Target audience
Anyone needing proximity refinement between two surfaces on a complex geometry where it is difficult to specify or create a closed surface around only a region you wish to resolve a gap.
### Proposal
Being ignorant of the complexities of snappyHexMesh, it seems like the hard work of finding the gaps is already being done, we just need to recognize whether the gap is between triangles on separate surfaces/regions or the same surface/region and refine or not refine based on a user specified bool input. I envision adding a selfProximity option to the refinementRegion section that can be overridden on a per-surface basis like the other proximity settings.
### What does success look like, and how can we measure that?
I can provide a simple test case if required. A test case where two objects are close to each other and where one of the objects has a small "self-gap" is a good test case. Success would be throwing a bounding box around the two objects, defining it as a proximity region, and only having it refine between the objects and not the small gap that exists within one of the objects.
### Funding
No sponsorship is available right now, I'm just hoping that this is easy enough to add and useful enough to a wide range of groups that it might make the cut in a future release.
\## Reattaching the author to the issue ticket: @graups ##Prashant SonakarPrashant Sonakarhttps://develop.openfoam.com/Development/openfoam/-/issues/1935meshToMesh field mapping incorrect when mapping from tgt to src2020-11-26T01:16:19ZAndrew HeathermeshToMesh field mapping incorrect when mapping from tgt to srcThe `mapInternalTgtToSrc` incorrectly divert to `*SrcToTgt` routines instead of `*TgtToSrc`The `mapInternalTgtToSrc` incorrectly divert to `*SrcToTgt` routines instead of `*TgtToSrc`v2012Andrew HeatherAndrew Heather