Development issueshttps://develop.openfoam.com/groups/Development/-/issues2020-03-13T13:32:51Zhttps://develop.openfoam.com/Development/openfoam/-/issues/1343Bug2020-03-13T13:32:51ZAdminBugI am trying to compile a new application on Ubuntu(new turbulence model), I get the following error:
In file included from /home/rozie/OpenFOAM/ThirdParty-v1812/platforms/linux64/gcc-6.3.0/include/c++/6.3.0/x86_64-pc-linux-gnu/bits/c++c...I am trying to compile a new application on Ubuntu(new turbulence model), I get the following error:
In file included from /home/rozie/OpenFOAM/ThirdParty-v1812/platforms/linux64/gcc-6.3.0/include/c++/6.3.0/x86_64-pc-linux-gnu/bits/c++config.h:507:0,
from /home/rozie/OpenFOAM/ThirdParty-v1812/platforms/linux64/gcc-6.3.0/include/c++/6.3.0/utility:68,
from /home/rozie/OpenFOAM/OpenFOAM-v1812/src/OpenFOAM/lnInclude/autoPtr.H:51,
from ../turbulenceModels/lnInclude/turbulenceModel.H:39,
from incompressibleTurbulenceModel.H:38,
from incompressibleTurbulenceModel.C:26:
/home/rozie/OpenFOAM/ThirdParty-v1812/platforms/linux64/gcc-6.3.0/include/c++/6.3.0/x86_64-pc-linux-gnu/bits/os_defines.h:39:22: fatal error: features.h: No such file or directory
#include <features.h>
^
compilation terminated.
\## Reattaching the author to the issue ticket: @Rozie123 ##https://develop.openfoam.com/Development/openfoam/-/issues/1344pressure with isentropic fails2019-06-19T13:30:19ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.compressure with isentropic fails<!--
*** 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 ...<!--
*** 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 -->
Following fails in e.g. rhoSimpleFoam tutorial:
```
isentropicPressure
{
type pressure;
libs ("libfieldFunctionObjects.so");
enabled yes;
writeControl writeTime;
calcIsen yes;
calcTotal no;
calcCoeff no;
result isenTropicP;
}
```
### Example case
compressible/rhoSimpleFoam/squareBend
<!--
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
-->Mattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comhttps://develop.openfoam.com/Development/openfoam/-/issues/1345derivedFields fo creating fields without time instance2019-06-27T12:31:48ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comderivedFields fo creating fields without time instance@mark@markMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comhttps://develop.openfoam.com/Development/openfoam/-/issues/1346sampling (of sets) on patch only2019-06-27T12:31:49ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comsampling (of sets) on patch only### Functionality to add/problem to solve
Sample boundary faces only using a definition similar to `uniform` set i.e. start & end
### Proposal
New sampledSet### Functionality to add/problem to solve
Sample boundary faces only using a definition similar to `uniform` set i.e. start & end
### Proposal
New sampledSetMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comhttps://develop.openfoam.com/Development/openfoam/-/issues/1347rhoMax/rhoMin defined but not used in buoyantSimpleFoam2022-04-26T16:10:40ZAdminrhoMax/rhoMin defined but not used in buoyantSimpleFoamIn the solver `applications/solvers/heatTransfer/buoyantSimpleFoam`, the `rhoMax` and `rhoMin` variables are defined in `createFields.H`, but never used in this solver.
I noticed this today with v1806, but have checked and this also occu...In the solver `applications/solvers/heatTransfer/buoyantSimpleFoam`, the `rhoMax` and `rhoMin` variables are defined in `createFields.H`, but never used in this solver.
I noticed this today with v1806, but have checked and this also occurs in v1812 and v1906-rc1.
According to `git blame`, the commit 1a701d9eac55a49f22b983683826d3ead8a8c85b is when this was added, but the min-max restriction was not imposed into this solver, the same way it was in chtMultiRegionSimpleFoam: https://develop.openfoam.com/Development/OpenFOAM-plus/blob/1a701d9eac55a49f22b983683826d3ead8a8c85b/applications/solvers/heatTransfer/chtMultiRegionFoam/chtMultiRegionSimpleFoam/fluid/pEqn.H#L91
\## Reattaching the author to the issue ticket: @wyldckat ##v2206Kutalmış BerçinKutalmış Berçinhttps://develop.openfoam.com/Development/openfoam/-/issues/1348Adaptive mesh refinement fails when field relaxation is applied2019-12-09T22:37:29ZAdminAdaptive mesh refinement fails when field relaxation is applied<!--
*** 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 ...<!--
*** 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 -->
If field relaxation combined with adaptive mesh refinement are used together, a simulation will fail. The following error is produced:
```
GAMGPCG: Solving for p_rgh, Initial residual = 9.32957e-07, Final residual = 5.87573e-11, No Iterations 3
[1]
[1]
[1] --> FOAM FATAL ERROR:
[1] Field<scalar> f1(15738), Field<scalar> f2(15738) and Field<scalar> f3(8906)
for operation f1 = f2 - f3
[1]
[1] From function void Foam::checkFields(const Foam::UList<T>&, const Foam::UList<Key>&, const Foam::UList<Type3>&, const char*) [with Type1 = double; Type2 = double; Type3 = double]
[1] in file /home/gavin/code/OpenFOAM-plus/src/OpenFOAM/lnInclude/FieldM.H at line 76.
```
My code is on commit d9cbe69c81c9382a8f55d11673ea7260f5907a5c.
This can be easily reproduced. Just go to tutorials/multiphase/interFoam/RAS/motorBike, set nOuterCorrectors to 2, and add relaxation to any field.AdminAdminhttps://develop.openfoam.com/Development/openfoam/-/issues/1349possible build issue with non-MPI vtk and runTimePostProcessing2019-07-02T09:40:17ZMark OLESENpossible build issue with non-MPI vtk and runTimePostProcessingFlagged by @PawanFlagged by @PawanMark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/1350Xeus-cling and OpenFOAM2020-03-13T14:45:38ZAdminXeus-cling and OpenFOAMI have recently stumbled upon the existence of [xeus-cling](https://github.com/QuantStack/xeus-cling), a C++ kernel for Jupyter notebooks. One can toy around with it [here](https://mybinder.org/v2/gh/QuantStack/xeus-cling/stable?filepath...I have recently stumbled upon the existence of [xeus-cling](https://github.com/QuantStack/xeus-cling), a C++ kernel for Jupyter notebooks. One can toy around with it [here](https://mybinder.org/v2/gh/QuantStack/xeus-cling/stable?filepath=notebooks/xcpp.ipynb). I would like to bring the attention of the developers and the community to this technology, because I think it provides an amazing way for demonstrating and documenting what OpenFOAM code does. For example, imagine an interactive document where matrix coefficients for a given scheme are derived and then an OpenFOAM code-snippet is used to generate said coefficients, which are then printed -- extremely satisfying :).
That being said I don't know how easy it is to make xeus-cling and OF work together. You can add include and library paths, so that is not an issue, but having the whole OF "environment" work properly inside the notebook is perhaps more difficult? I only tried a very naive approach of just installing xeus-cling and try using an existing OF installation with it. Not surprisingly, including headers failed due to e.g. WM_LABEL_SIZE not being defined. I could make some stuff work by manually #defining some stuff in the notebook directly, but e.g. creating a list failed anyway :).
I would greatly appreciate if someone competent could look into this and provide the steps for making this work, if it is possible!
Kind regards,
Timofey
\#\# Reattaching the author to the issue ticket: @timofeymukha \#\#https://develop.openfoam.com/Development/openfoam/-/issues/1351Typo in the example2019-07-03T19:25:30ZAdminTypo in the exampleIn this link: https://www.openfoam.com/documentation/guides/latest/doc/guide-bcs-general-uniform-fixed-value.html
Under the **Usage** section, We can find the following:
> The uniformValue is a Foam::Function1 type, allowing the value to...In this link: https://www.openfoam.com/documentation/guides/latest/doc/guide-bcs-general-uniform-fixed-value.html
Under the **Usage** section, We can find the following:
> The uniformValue is a Foam::Function1 type, allowing the value to be prescribed as a function of time. For example, to ramp vector values from (0 0 0) to (10 0 0) over 5 seconds:The uniformValue is a Foam::Function1 type, allowing the value to be prescribed as a function of time. For example, to ramp vector values from (0 0 0) to (10 0 0) over 5 seconds:
> ```
> <patchName>
> {
> type uniformFixedValue;
> uniformValue table
> (
> (0 (0 0 0))
> (5 (0 0 0)) // Here, should be (10 0 0)
> );
> }
> ```
As you can see in the comment the velocity component should be `(10 0 0)` instead of `(0 0 0)`.https://develop.openfoam.com/Development/openfoam/-/issues/1352snappyHexMesh - mergeAcrossPatches fails on symmetryPlane2023-12-07T19:05:02ZAdminsnappyHexMesh - mergeAcrossPatches fails on symmetryPlane<!--
*** 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 ...<!--
*** 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
The new feature of snappyHexMesh "mergeAcrossPatches" works well on patch boundaries and greatly improves layer coverage. Unfortunately it damages a symmetry plane.
<!-- Summarize the bug encountered concisely -->
### Steps to reproduce
Generate mesh for a case where the geometry intersects the symmetry plane.
<!-- How one can reproduce the issue - this is very important -->
### Example case
Is attached.
<!--
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?
When mergeAcrossPatches is true, not only the faces at patch boundaries on the geometry are merged (which is very desirable for layer coverage), but also the faces at the boundary between geometry and symmetry plane. Consequently, the symmetry plane is substantially not planar. See attached images.
<!-- What actually happens -->
### What is the expected *correct* behavior?
The faces should only be merged at patch boundaries on the geometry. Intersections between the geometry and the domain boundaries should be treated as features where the faces won't be merged.
For a symmetry plane the current behavior leads to an error (as it is not planar), but the same applies for boundaries which are patches, e.g. the lowerWall boundary in the motorbike tutorial.
<!-- What you should see instead -->
### Relevant logs and/or images
Attachements:
* mergeAcrossPatches-false.png - No merged faces; symmetry plane planar
![mergeAcrossPatches-False](/uploads/28e6b35c64a4c145176636ff2b066e53/mergeAcrossPatches-False.png)
* mergeAcrossPatches-true.png - merged faces; "crimpled" edge between symmetry plane and geometry.
![mergeAcrossPatches-True](/uploads/8359d4e8e853512d121e0146fd7080ec/mergeAcrossPatches-True.png)
* mergeAcrossPatches.tgz - example case. Use Allrun to run (runs a few seconds).
(/uploads/9917f61abe18891cca38d55325d8db74/mergeAcrossPatches.tgz)
<!--
Paste any relevant logs - please use code blocks (```) to format console
output, logs, and code as it's very hard to read otherwise.
-->
### Environment information
<!--
Providing details of your set-up can help us identify any issues, e.g.
OpenFOAM version : v1806|v1812|v1906 etc
Operating system : ubuntu|openSUSE|centos etc
Hardware info : any info that may help?
Compiler : gcc|intel|clang etc
-->
- OpenFOAM version : v1906
- Operating system : ubuntu
- Hardware info :
- Compiler : gcc
### Possible fixes
Ideas:
* Explicitly exclude certain patches from the merge mechanism
* Identify feature at intersection of geometry with domain boundary.[mergeAcrossPatches.tgz]
<!--
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/1353topoSet: No warning when using inconsistent setup2019-07-03T04:56:26ZPrashant SonakartopoSet: No warning when using inconsistent setup### Functionality to add/problem to solve
When setup is inconsistent, e.g. type cellSet, while source e.g. boxToFace, there is no warning/ error.
The cellSet is created with faces as labels. This should be checked for consistency.
@mark### Functionality to add/problem to solve
When setup is inconsistent, e.g. type cellSet, while source e.g. boxToFace, there is no warning/ error.
The cellSet is created with faces as labels. This should be checked for consistency.
@markhttps://develop.openfoam.com/Development/openfoam/-/issues/1354Metis decomposition is not working using OpenFOAM-v19062019-07-08T18:49:33ZAdminMetis decomposition is not working using OpenFOAM-v1906Metis decomposition is not working using OpenFOAM-v1906
Steps to reproduce:
* compile metis
```
cd $WM_THIRD_PARTY_DIR
wget http://glaros.dtc.umn.edu/gkhome/fetch/sw/metis/metis-5.1.0.tar.gz
tar -xzf metis-5.1.0.tar.gz
rm metis-5.1.0.t...Metis decomposition is not working using OpenFOAM-v1906
Steps to reproduce:
* compile metis
```
cd $WM_THIRD_PARTY_DIR
wget http://glaros.dtc.umn.edu/gkhome/fetch/sw/metis/metis-5.1.0.tar.gz
tar -xzf metis-5.1.0.tar.gz
rm metis-5.1.0.tar.gz
cd $WM_PROJECT_DIR
./Allwmake -j -l
```
* modify decomposeParDict in twoSimpleRotors tutorial (OpenFOAM-v1906/tutorials/multiphase/overInterDyMFoam/twoSimpleRotors)
```
method metis;
```
* output
```
/*---------------------------------------------------------------------------*\
| ========= | |
| \\ / F ield | OpenFOAM: The Open Source CFD Toolbox |
| \\ / O peration | Version: v1906 |
| \\ / A nd | Web: www.OpenFOAM.com |
| \\/ M anipulation | |
\*---------------------------------------------------------------------------*/
Build : v1906 OPENFOAM=1906
Arch : "LSB;label=32;scalar=64"
Exec : decomposePar -cellDist
Date : Jul 04 2019
Time : 09:16:22
Host : coastal2
PID : 118852
I/O : uncollated
Case : /home/u0109460/OpenFOAM/u0109460-v1906/run/twoSimpleRotors
nProcs : 1
trapFpe: Floating point exception trapping enabled (FOAM_SIGFPE).
fileModificationChecking : Monitoring run-time modified files using timeStampMaster (fileModificationSkew 10)
allowSystemOperations : Allowing user-supplied system call operations
// * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * //
Create time
Overriding DebugSwitches according to controlDict
overset 0;
dynamicOversetFvMesh 0;
cellVolumeWeight 0;
Decomposing mesh region0
Create mesh
Calculating distribution of cells
Selecting decompositionMethod metis [3]
--> FOAM FATAL ERROR:
Attempted non-const reference to const object from a tmpNrc<N4Foam4ListIiEE>
From function T& Foam::tmpNrc<T>::ref() const [with T = Foam::List<int>]
in file /home/u0109460/OpenFOAM/OpenFOAM-v1906/src/OpenFOAM/lnInclude/tmpNrcI.H at line 234.
FOAM aborting
#0 Foam::error::printStack(Foam::Ostream&) at ??:?
#1 Foam::error::abort() at ??:?
#2 Foam::metisDecomp::decomposeSerial(Foam::UList<int> const&, Foam::UList<int> const&, Foam::UList<double> const&, Foam::List<int>&) const at ??:?
#3 Foam::metisLikeDecomp::decomposeGeneral(Foam::UList<int> const&, Foam::UList<int> const&, Foam::UList<double> const&, Foam::List<int>&) const at ??:?
#4 Foam::metisLikeDecomp::decompose(Foam::polyMesh const&, Foam::Field<Foam::Vector<double> > const&, Foam::Field<double> const&) const at ??:?
#5 Foam::decompositionMethod::decompose(Foam::polyMesh const&, Foam::Field<Foam::Vector<double> > const&) const at ??:?
#6 Foam::decompositionMethod::decompose(Foam::polyMesh const&, Foam::Field<double> const&, Foam::List<bool> const&, Foam::PtrList<Foam::List<int> > const&, Foam::List<int> const&, Foam::List<Foam::Pair<int> > const&) const at ??:?
#7 Foam::decompositionMethod::decompose(Foam::polyMesh const&, Foam::Field<double> const&) const at ??:?
#8 ? in ~/OpenFOAM/OpenFOAM-v1906/platforms/linux64GccDPInt32Opt/bin/decomposePar
#9 ? in ~/OpenFOAM/OpenFOAM-v1906/platforms/linux64GccDPInt32Opt/bin/decomposePar
#10 ? in ~/OpenFOAM/OpenFOAM-v1906/platforms/linux64GccDPInt32Opt/bin/decomposePar
#11 __libc_start_main in /lib/x86_64-linux-gnu/libc.so.6
#12 ? in ~/OpenFOAM/OpenFOAM-v1906/platforms/linux64GccDPInt32Opt/bin/decomposePar
Aborted (core dumped)
```Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/ThirdParty-common/-/issues/44cannot build paraview 5.6.0 on OF19062019-07-29T12:31:46Zsariew8cannot build paraview 5.6.0 on OF1906hi developer!
what is the cause of failures like the attached file for the paraview5.6.0 build?
---
ubuntu18.04
gcc (Ubuntu 7.4.0-1ubuntu1~18.04.1) 7.4.0
(Note that the file has about 76.7MB after extraction.)
[log.makePV-0.t...hi developer!
what is the cause of failures like the attached file for the paraview5.6.0 build?
---
ubuntu18.04
gcc (Ubuntu 7.4.0-1ubuntu1~18.04.1) 7.4.0
(Note that the file has about 76.7MB after extraction.)
[log.makePV-0.tar.bz2](/uploads/c1c60c67ef53b1584f8b7693f1676d08/log.makePV-0.tar.bz2)https://develop.openfoam.com/Development/openfoam/-/issues/1355faceZones option ignored in foamToEnsight v18062019-08-31T20:45:12ZAdminfaceZones option ignored in foamToEnsight v1806This works correctly in v1712, and v1906. But in v1806 the "faceZones" option in foamToEnsight is treated as an on/off flag rather than obeying the input.
foamToEnsight -latestTime -fields U -faceZones '(face_zone_name)' -patches '(wall...This works correctly in v1712, and v1906. But in v1806 the "faceZones" option in foamToEnsight is treated as an on/off flag rather than obeying the input.
foamToEnsight -latestTime -fields U -faceZones '(face_zone_name)' -patches '(wall_radiator)'
On any case you can run something like the above, and the ensight file will contain ALL the faceZones rather than just the listed ones. Using a list, or just naming a single faceZone, the behavior is the same.Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/1356pressure functionObject in v1906 does not calculate total pressure coefficien...2020-03-13T13:32:29ZAdminpressure functionObject in v1906 does not calculate total pressure coefficient (fix attached)In v1906, the pressure function object uses a new "mode" specification. The documentation is not up yet, but from the source code it looks like the options are: static, total, isentropic, staticCoeff, totalCoeff.
The block of code below...In v1906, the pressure function object uses a new "mode" specification. The documentation is not up yet, but from the source code it looks like the options are: static, total, isentropic, staticCoeff, totalCoeff.
The block of code below correctly handles the difference between static and total pressure, and when I calculate these, the values are correct.
However, when the mode is totalCoeff or staticCoeff, the output of both is the same: staticCoeff (i.e., the default in the switch below). I think the switch needs some kind of "startswith" logic.
To fix this, I have replaced this switch case with an if statement similar to the one used for the coeff logic and resultName logic. After compiling and running, I am getting proper values for totalCoeff. I've attached the modified file.
[pressure.C](/uploads/1d39079c9ef69f73369b474f4f1e9ed2/pressure.C)
```c
Foam::tmp<Foam::volScalarField> Foam::functionObjects::pressure::calcPressure
(
const volScalarField& p,
const tmp<volScalarField>& tp
) const
{
switch (mode_)
{
case TOTAL:
{
return
tp
+ dimensionedScalar("pRef", dimPressure, pRef_)
+ rhoScale(p, 0.5*magSqr(lookupObject<volVectorField>(UName_)));
}
case ISENTROPIC:
{
const basicThermo* thermoPtr =
p.mesh().lookupObjectPtr<basicThermo>(basicThermo::dictName);
if (!thermoPtr)
{
FatalErrorInFunction
<< "Isentropic pressure calculation requires a "
<< "thermodynamics package"
<< exit(FatalError);
}
const volScalarField gamma(thermoPtr->gamma());
const volScalarField Mb
(
mag(lookupObject<volVectorField>(UName_))
/sqrt(gamma*tp.ref()/thermoPtr->rho())
);
return tp()*(pow(1 + (gamma - 1)/2*sqr(Mb), gamma/(gamma - 1)));
}
default:
{
return
tp
+ dimensionedScalar("pRef", dimPressure, pRef_);
}
}
}
```
\## Reattaching the author to the issue ticket: @aerogt3 ##AdminAdminhttps://develop.openfoam.com/Development/openfoam/-/issues/1357OpenFOAM setup alters LD_PRELOAD2019-12-09T22:37:29ZMark OLESENOpenFOAM setup alters LD_PRELOADIn the setup files, we currently have some adjustments for `LD_PRELOAD`, most notably with foamClean.
I don't think that we should probably be touching this variable at all.
Cross-ref: EP1056
Comments? @Stefan @PrashantIn the setup files, we currently have some adjustments for `LD_PRELOAD`, most notably with foamClean.
I don't think that we should probably be touching this variable at all.
Cross-ref: EP1056
Comments? @Stefan @PrashantMark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/1358foamFormatConvert compresses boundary file in v1906 (all other utilities leav...2021-07-06T15:42:35ZAdminfoamFormatConvert compresses boundary file in v1906 (all other utilities leave it uncompressed)In order to take advantage of the SPDP solver precision, I am using ascii format. When using writeCompression on, snappyHexMesh, renumberMesh, insideCells, etc. compress/gzip all the files in processor*/constant/polyMesh/ EXCEPT boundary...In order to take advantage of the SPDP solver precision, I am using ascii format. When using writeCompression on, snappyHexMesh, renumberMesh, insideCells, etc. compress/gzip all the files in processor*/constant/polyMesh/ EXCEPT boundary, which is always left uncompressed. This is convenient as boundary can be parsed for scripted setup of cases.
foamFormatConvert however, compresses the boundary file. Testing is easy, in controlDict just set:
writeFormat ascii;
writeCompression on;
and run:
foamFormatConvert -constant
Obviously the workaround is simple and it's a minor issue. But consistency is always nice :-)
\#\# Reattaching the author to the issue ticket: @wyldckat \#\#https://develop.openfoam.com/Development/openfoam/-/issues/1359no convenient access to original point id in treeDataPoint2019-07-09T18:03:37ZMark OLESENno convenient access to original point id in treeDataPointWhen using a treeDataPoint with a subset of points in search, the index of pointIndexHit will return the subset index, not the original index. Add some more functionality to treeDataPoint to make the reverse mapping easier.When using a treeDataPoint with a subset of points in search, the index of pointIndexHit will return the subset index, not the original index. Add some more functionality to treeDataPoint to make the reverse mapping easier.v1912Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/1360double definition for long output (mingw)2019-07-09T17:44:48ZMark OLESENdouble definition for long output (mingw)@Pawan@PawanMark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/1361createPatch does not update fields in v19062022-04-26T16:10:39ZAdmincreatePatch does not update fields in v1906when using createPatch to merge patches, the mesh is updated but the accompanying mesh fields are not. This causes crashes with running other utilities, which complain that patches are missing or that number of faces on patches do not ma...when using createPatch to merge patches, the mesh is updated but the accompanying mesh fields are not. This causes crashes with running other utilities, which complain that patches are missing or that number of faces on patches do not match. The field data also cannot be plotted, as it's missing/incomplete on the patches in question.
This is easy and quick to reproduce on the motorbike tutorial. Just put the attached createPatchDict in /system, and run the attached Allrun. snappyHexMesh write the layers fields, which createPatch doesn't update, and then redistributePar fails due to a missing patch.
[Allrun](/uploads/caae2587d08e5ceb8f99c3deacfbe3e1/Allrun)[createPatchDict](/uploads/acb1c63a321d3da71d448d90dcc0a216/createPatchDict)
EDIT: mapFields does not handle this either. command:
**mapFields -noFunctionObjects -parallelSource -parallelTarget -consistent .**
\#\# Reattaching the author to the issue ticket: @aerogt3 \#\#v2206Kutalmış BerçinKutalmış Berçin