Development issueshttps://develop.openfoam.com/groups/Development/-/issues2019-11-14T18:32:54Zhttps://develop.openfoam.com/Development/openfoam/-/issues/815vanDriestDelta documentation - the default value of Cdelta2019-11-14T18:32:54ZKutalmış BerçinvanDriestDelta documentation - the default value of CdeltaHi,
Please see the two remarks below for `vanDriestDelta` implementation:
1. As can be seen in `vanDriestDelta.C` lines: [87-91], the van Driest function formulation (doi: 10.2514/8.3713, 1956) is slightly different from its original ...Hi,
Please see the two remarks below for `vanDriestDelta` implementation:
1. As can be seen in `vanDriestDelta.C` lines: [87-91], the van Driest function formulation (doi: 10.2514/8.3713, 1956) is slightly different from its original form. A *minimum switch* was introduced by de Villiers (http://bit.ly/1unTPaB, 2006) as shown in pages: [124, 260]. IMHO, it would be nice of you as well as useful to some users if his heuristic modification/work is noted and cited in the Extended Code Guide, which is currently absent.
2. In addition, `vanDriestCoeffs`'s `Cdelta` is (most of the time) kept equal to `0.158` by default in the tutorials as can be found in `tutorials/incompressible/pimpleFoam/LES/channel395DFSEM/constant/turbulenceProperties` of v1712, for instance. However, as shown in de Villiers, the unnumbered equation in page 260, `Cdelta` is actually `Cs`. This may suggest, at least for `channel395DFSEM` tutorial, that `Cdelta` needs to equate `Cdelta=Cs=0.065` rather than `0.158`. Not sure if it is of practical importance though. Just an observation :)
Kind regards,Kutalmış BerçinKutalmış Berçin2018-12-31https://develop.openfoam.com/Development/openfoam/-/issues/1479Broken link on openfoam.com2019-11-12T21:12:22ZAdminBroken link on openfoam.comOn [this website](https://www.openfoam.com/documentation/guides/latest/doc/openfoam-guide-input-types.html) and many other sites, you have a button labeled "Create an issue" with a link to [this site](https://develop.openfoam.com/Communi...On [this website](https://www.openfoam.com/documentation/guides/latest/doc/openfoam-guide-input-types.html) and many other sites, you have a button labeled "Create an issue" with a link to [this site](https://develop.openfoam.com/Community/Documentation/issues/new?issue[title]=Doc%20improvement:%20Add%20your%20title%20here&issue[description]=Page:%20openfoam-guide-input-types%0A%0ADescribe%20your%20proposed%20changes%0A%0A%3C!--%20Do%20not%20edit%20below%20this%20line%20--%3E%0A%0A%2Flabel%20~improvement) . The link is HTTP 404 Not found.
I would recommend fixing this link and the use of an automatic broken link checker.https://develop.openfoam.com/Development/openfoam/-/issues/1429Suggestions for the Submitting Issues page2019-11-12T14:37:03ZAdminSuggestions for the Submitting Issues page# Problem
During the OpenFOAM Workshop 2019, it was noted that several people are not sure how to submit (good) bug reports, mainly due to not knowing how to report system-related technical information. @bgschaid @mark
# Suggested fix...# Problem
During the OpenFOAM Workshop 2019, it was noted that several people are not sure how to submit (good) bug reports, mainly due to not knowing how to report system-related technical information. @bgschaid @mark
# Suggested fixes
## Patches for page "Submitting Issues"
I had a look into the page [Submitting Issues](https://develop.openfoam.com/Development/OpenFOAM-plus/wikis/page-submitting-issues) and I added a bit more information, trying to keep the text short and the instructions precise and platform-independent. Since I cannot open merge requests or even fork the repository, I attach a set of patches here (they are for the Wiki repository, anyway). These patches are based on d8c4d7 and I have tested them locally.
[wiki_Submitting-Issues_patches.tar.gz](/uploads/3ad5ce768f455724b1077150d59c21ab/wiki_Submitting-Issues_patches.tar.gz)
<p>
<details>
<summary>Here is a preview:</summary>
![Screenshot_from_2019-09-05_16-40-55](/uploads/422c9f0ab4f069a1bdbc713814bc87fb/Screenshot_from_2019-09-05_16-40-55.png)
</details>
</p>
## Add link on openfoam.com
A link to the page [Bug Reporting](https://www.openfoam.com/code/bug-reporting.php) is very prominent both in the side menu and in the "Code" drop-down. :+1:
However, the statement:
> Bug and issue reporting is provided via the repository hosting site https://develop.openfoam.com described [here](https://www.openfoam.com/code/repositories.php)
leads to a generic page, while it should lead to the page [Submitting Issues](https://develop.openfoam.com/Development/OpenFOAM-plus/wikis/page-submitting-issues).https://develop.openfoam.com/Development/openfoam/-/issues/1413`apt update` missing from the System Requirement instructions2019-11-12T14:03:21ZAdmin`apt update` missing from the System Requirement instructionsI've noticed a few minutes ago, while looking into this thread: https://www.cfd-online.com/Forums/openfoam-installation/220196-question-cmake-ubuntu-prerequisite.html - that the "System Requirements" page: https://www.openfoam.com/docum...I've noticed a few minutes ago, while looking into this thread: https://www.cfd-online.com/Forums/openfoam-installation/220196-question-cmake-ubuntu-prerequisite.html - that the "System Requirements" page: https://www.openfoam.com/documentation/system-requirements.php - is missing a critical command:
```
sudo apt-get update
```
for Ubuntu/Debian instructions; without this, `apt` and `apt-get` will fail miserably if the auto-update system didn't kick-in soon enough or because it never does when using WSL.
As a side note, you can change `apt-get` to `apt` for the more recent versions of Ubuntu/Debian, which provides a nicer interface and progress bar... even though it still doesn't run `update` on its own...https://develop.openfoam.com/Development/openfoam/-/issues/1482MinGW doesn't appear to have a download link2019-11-09T16:01:41ZAdminMinGW doesn't appear to have a download linkhttps://www.openfoam.com/download/install-binary-windows-mingw.php
@Pawan @andyhttps://www.openfoam.com/download/install-binary-windows-mingw.php
@Pawan @andyAdminAdminhttps://develop.openfoam.com/Development/openfoam/-/issues/938illegal instruction constexpr v1712 v18062019-11-09T15:21:15ZAdminillegal instruction constexpr v1712 v1806Trying to compile a new solver on windows 10 bash with ubuntu. Compiler returns an error saying illegal instruction constexpr. This has occurred on versions 1712 and 1806 in the header file floatScalar.H. I believe it has been a repeated...Trying to compile a new solver on windows 10 bash with ubuntu. Compiler returns an error saying illegal instruction constexpr. This has occurred on versions 1712 and 1806 in the header file floatScalar.H. I believe it has been a repeated issue from what I have seen on the forums so others will probably be able to provide more information. I don't know if this is a version issue because I updated all my compilers. I only come because the only solution I have seen found to this anywhere is revert to OF5. I have seen this exact issue reported on v1706 as well.Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/1268avoid use of gatherList (e.g. fvMeshDistribute)2019-11-08T07:11:42ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comavoid use of gatherList (e.g. fvMeshDistribute)### Functionality to add/problem to solve
Currently in the code it sometimes uses a gatherList to collect data from other processors. This becomes expensive for large numbers of processors.
### Proposal
Replace with an allToAll type ...### Functionality to add/problem to solve
Currently in the code it sometimes uses a gatherList to collect data from other processors. This becomes expensive for large numbers of processors.
### Proposal
Replace with an allToAll type wrapper.https://develop.openfoam.com/Development/openfoam/-/issues/1342GAMG uses hardcoded coarse-level solver2019-11-08T07:11:42ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comGAMG uses hardcoded coarse-level solver### Functionality to add/problem to solve
GAMG currently has two different methods for solving the coarsest level : direct or CG. It would be nice to override this behaviour
### Target audience
(Who will benefit from the changes?)
(W...### Functionality to add/problem to solve
GAMG currently has two different methods for solving the coarsest level : direct or CG. It would be nice to override this behaviour
### Target audience
(Who will benefit from the changes?)
(What type of cases?)
Parallel running
### Proposal
(How are we going to solve the problem?)
Allow specification of coarse-level solverMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comhttps://develop.openfoam.com/Development/openfoam/-/issues/1107BUG: turbulentDFSEMInlet; Option = planarInterpolation; decomposePar causes F...2019-11-06T18:38:30ZKutalmış BerçinBUG: turbulentDFSEMInlet; Option = planarInterpolation; decomposePar causes Floating Point Exception for Fields R/L/U### Summary
When `turbulentDFSEMInlet` with `planarInterpolation` option is ON, `decomposePar` causes FPE with the following error message:
```
Time = 0
Turbulent DFSEM patch inlet: interpolating field R from "/home/snoopy2/kuta/OpenFO...### Summary
When `turbulentDFSEMInlet` with `planarInterpolation` option is ON, `decomposePar` causes FPE with the following error message:
```
Time = 0
Turbulent DFSEM patch inlet: interpolating field R from "/home/snoopy2/kuta/OpenFOAM/kuta-v1806/run/channel395DFSEM/constant/boundaryData/inlet/0/R"
#0 Foam::error::printStack(Foam::Ostream&) at ??:?
#1 Foam::sigFpe::sigHandler(int) at ??:?
#2 ? in /lib64/libc.so.6
#3 Foam::pointToPointPlanarInterpolation::calcCoordinateSystem(Foam::Field<Foam::Vector<double> > const&) const at ??:?
#4 Foam::pointToPointPlanarInterpolation::pointToPointPlanarInterpolation(Foam::Field<Foam::Vector<double> > const&, Foam::Field<Foam::Vector<double> > const&, double, bool) at ??:?
#5 Foam::turbulentDFSEMInletFvPatchVectorField::patchMapper() const at ??:?
#6 Foam::tmp<Foam::Field<Foam::SymmTensor<double> > > Foam::turbulentDFSEMInletFvPatchVectorField::interpolateBoundaryData<Foam::SymmTensor<double> >(Foam::word const&) const at ??:?
#7 Foam::turbulentDFSEMInletFvPatchVectorField::turbulentDFSEMInletFvPatchVectorField(Foam::fvPatch const&, Foam::DimensionedField<Foam::Vector<double>, Foam::volMesh> const&, Foam::dictionary const&) at ??:?
#8 Foam::fvPatchField<Foam::Vector<double> >::adddictionaryConstructorToTable<Foam::turbulentDFSEMInletFvPatchVectorField>::New(Foam::fvPatch const&, Foam::DimensionedField<Foam::Vector<double>, Foam::volMesh> const&, Foam::dictionary const&) at ??:?
#9 Foam::fvPatchField<Foam::Vector<double> >::New(Foam::fvPatch const&, Foam::DimensionedField<Foam::Vector<double>, Foam::volMesh> const&, Foam::dictionary const&) at ??:?
#10 Foam::GeometricField<Foam::Vector<double>, Foam::fvPatchField, Foam::volMesh>::Boundary::readField(Foam::DimensionedField<Foam::Vector<double>, Foam::volMesh> const&, Foam::dictionary const&) at ??:?
#11 Foam::GeometricField<Foam::Vector<double>, Foam::fvPatchField, Foam::volMesh>::readFields(Foam::dictionary const&) at ??:?
#12 Foam::GeometricField<Foam::Vector<double>, Foam::fvPatchField, Foam::volMesh>::readFields() at ??:?
#13 Foam::GeometricField<Foam::Vector<double>, Foam::fvPatchField, Foam::volMesh>::GeometricField(Foam::IOobject const&, Foam::fvMesh const&, bool) at ??:?
#14 ? at ??:?
#15 ? at ??:?
#16 __libc_start_main in /lib64/libc.so.6
#17 ? at /home/abuild/rpmbuild/BUILD/glibc-2.18/csu/../sysdeps/x86_64/start.S:125
Floating point exception
```
### Steps to reproduce
Please consider `tutorials/incompressible/pimpleFoam/LES/channel395DFSEM` case.
Change the following under `0/U`:
```
inlet
{
type turbulentDFSEMInlet;
...
mapMethod nearestCell;
...
}
```
to
```
inlet
{
type turbulentDFSEMInlet;
...
mapMethod planarInterpolation;
...
}
```
Then execute the following respectively:
`blockMesh`
`decomposePar`
PS: `scotch` and `hierarchial` were tested with various numbers of `numberOfSubdomains`.
@andyv1906Kutalmış BerçinKutalmış Berçinhttps://develop.openfoam.com/Development/openfoam/-/issues/1480Spelling mistake on openfoam.com2019-11-06T13:03:50ZAdminSpelling mistake on openfoam.comOn [this site](https://www.openfoam.com/documentation/guides/latest/doc/openfoam-guide-input-types.html) there is the row:
string quoted test "this is a string value"
I think "quotet text" instead of "quoted test" would be correct.On [this site](https://www.openfoam.com/documentation/guides/latest/doc/openfoam-guide-input-types.html) there is the row:
string quoted test "this is a string value"
I think "quotet text" instead of "quoted test" would be correct.AdminAdminhttps://develop.openfoam.com/Development/openfoam/-/issues/1467Not all entries in etc/controlDict InfoSwitches can be overwritten in the sys...2019-11-04T15:15:40ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comNot all entries in etc/controlDict InfoSwitches can be overwritten in the system/controlDict### Functionality to add/problem to solve
Not all entries in etc/controlDict InfoSwitches can be overwritten in the system/controlDict
- grep for all occurences of infoSwitch
- subtract all occurences of registerInfoSwitch
and the fol...### Functionality to add/problem to solve
Not all entries in etc/controlDict InfoSwitches can be overwritten in the system/controlDict
- grep for all occurences of infoSwitch
- subtract all occurences of registerInfoSwitch
and the following seem to be unimplemented:
```
OpenFOAM/db/IOobjects/IOdictionary/baseIOdictionary.C: debug::infoSwitch("writeDictionaries", 0)
OpenFOAM/db/IOstreams/IOstreams.C: Foam::debug::infoSwitch("writePrecision", 6)
OpenFOAM/db/Time/Time.C: Foam::debug::infoSwitch("printExecutionFormat", 0)
OpenFOAM/db/dictionary/dictionary.C: Foam::debug::infoSwitch("writeOptionalEntries", 0)
OpenFOAM/db/dictionary/entry/entry.C: Foam::debug::infoSwitch("disableFunctionEntries", 0)
OpenFOAM/db/dynamicLibrary/dynamicCode/dynamicCode.C: Foam::debug::infoSwitch("allowSystemOperations", 0)
OpenFOAM/global/JobInfo/JobInfo.C:bool Foam::JobInfo::writeJobInfo(Foam::debug::infoSwitch("writeJobInfo", 0));
OpenFOAM/global/profiling/profiling.C:int Foam::profiling::allowed(Foam::debug::infoSwitch("allowProfiling", 1));
OpenFOAM/primitives/strings/fileName/fileName.C: Foam::debug::infoSwitch("allowSpaceInFileName", 0)
```
@Prashant Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/1476Cannot find libtriSurface.so2019-11-04T12:35:44ZAdminCannot find libtriSurface.soI am trying to build the project [mimmo](https://github.com/optimad/mimmo) that depends on OpenFOAM. my OpenFOAM version is `1806`.
The build fails because it cannot find the library `libtriSurface.so`. I searched manually:
```
find ~/...I am trying to build the project [mimmo](https://github.com/optimad/mimmo) that depends on OpenFOAM. my OpenFOAM version is `1806`.
The build fails because it cannot find the library `libtriSurface.so`. I searched manually:
```
find ~/OpenFOAM/OpenFOAM-v1806 -type f -iname 'libtriSurface.so'
```
But the search returns nothing.
What I am missing?Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/1474Missing "value" entry in decomposed pointDisplacement2019-11-03T10:09:55ZAdminMissing "value" entry in decomposed pointDisplacementHi,
When running decomposedPar on a case with moving mesh (using pointDisplacement field), the "value" entry of some patches does not get written. Then, when running the solver, the following error occurs:
[1] --> FOAM FATAL IO ERROR: ...Hi,
When running decomposedPar on a case with moving mesh (using pointDisplacement field), the "value" entry of some patches does not get written. Then, when running the solver, the following error occurs:
[1] --> FOAM FATAL IO ERROR:
[1] Essential entry 'value' missing
[1]
[1] file: /home/mathieu/OpenFOAM/OpenFOAM-v1906/tutorials/mesh/moveDynamicMesh/SnakeRiverCanyon/processor1/0/pointDisplacement.boundaryField.minZ
I am running OpenFOAM-v1906.
**Steps to reproduce:**
tut
cd mesh/moveDynamicMesh/SnakeRiverCanyon/
blockMesh
decomposePar
mpirun -np 2 moveDynamicMesh -parallel
Best regards.Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/1468provide dictionary context for writeOptionalEntries2019-11-03T10:06:39ZMark OLESENprovide dictionary context for writeOptionalEntriescross-ref EP#1160 @svilfayecross-ref EP#1160 @svilfayeMark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/1447nFaces differ in faces and owner files for binary writes2019-10-30T16:04:28ZAdminnFaces differ in faces and owner files for binary writesWhen writing binary, nFaces in polyMesh/faces is one larger than the nFaces value in polyMesh/owner.When writing binary, nFaces in polyMesh/faces is one larger than the nFaces value in polyMesh/owner.https://develop.openfoam.com/Development/openfoam/-/issues/1177allow adjustment of write precision for foamDictionary2019-10-29T10:59:04ZMark OLESENallow adjustment of write precision for foamDictionary- since foamDictionary doesn't use `system/controlDict` it will use the standard default precision.
- Add -precision option to allow adjusting this value.
@amutzk @svilfaye- since foamDictionary doesn't use `system/controlDict` it will use the standard default precision.
- Add -precision option to allow adjusting this value.
@amutzk @svilfayeMark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/1450redistributePar + dyM + lagrangian leads to creash2019-10-25T11:46:06ZAdminredistributePar + dyM + lagrangian leads to creash### Summary
The redistribution of cells for each processor in parallel can be performed via
`mpirun -np 4 redistributePar -parallel -overwrite`
However, when using this for a case with dynamic Mesh and lagrangian particles, this leads...### Summary
The redistribution of cells for each processor in parallel can be performed via
`mpirun -np 4 redistributePar -parallel -overwrite`
However, when using this for a case with dynamic Mesh and lagrangian particles, this leads to a crash at the very first time step after redistribution.
### Steps to reproduce
Start any lagrangian solver with dynamic Mesh in parallel. Stop at first write out. Use redistributePar in parallel, restart the solver at latest timestep.
### Example case
This bug can easily be reproduced using `sprayDyMFoam` in combination with the aachenBomb tutorial case. I attached [aachenBomb.zip](/uploads/8c10285231317d5a4f48247de25fb9de/aachenBomb.zip) tutorial with minimal changes to include dynamic mesh. Just run the Allrun script.
### What is the current *bug* behaviour?
The solver crashes at first time step after executing redistributePar
### What is the expected *correct* behavior?
The solver should run.
### Relevant logs and/or images
The error message looks as following:
`
[3] [2] #0 #0 Foam::error::printStack(Foam::Ostream&)Foam::error::printStack(Foam::Ostream&) at ??:?
at ??:?
[3] #1 Foam::sigSegv::sigHandler(int)[2] #1 Foam::sigSegv::sigHandler(int) at ??:?
[3] #2 ? at ??:?
[2] #2 ? in /usr/lib64/libc.so.6
in /usr/lib64/libc.so.6
[3] #3 [2] #3 Foam::tetIndices::faceTriIs(Foam::polyMesh const&, bool) constFoam::tetIndices::faceTriIs(Foam::polyMesh const&, bool) const at ??:?
[3] #4 at ??:?
[2] #4 Foam::particle::position() constFoam::particle::position() const at ??:?
[3] #5 at ??:?
[2] #5 ?? at ??:?
[2] #6 at ??:?
[3] #6 ?? at ??:?
[3] #7 __libc_start_main at ??:?
[2] #7 __libc_start_main in /usr/lib64/libc.so.6
[3] #8 in /usr/lib64/libc.so.6
[2] #8 ?? at ??:?
[tauruslogin3:22317:0] Caught signal 11 (Segmentation fault)
at ??:?
[tauruslogin3:22316:0] Caught signal 11 (Segmentation fault)
`
### Environment information
- OpenFOAM version : v1906
- Operating system : ubuntu
- Hardware info : Intel CPU, openmpi
- Compiler : gcchttps://develop.openfoam.com/Development/openfoam/-/issues/1455Wrong sign in equation regarding thermal creep in Maxwell boundary condition2019-10-19T18:46:20ZAdminWrong sign in equation regarding thermal creep in Maxwell boundary conditionHello.
Could you please check the sign in equation regarding thermal creep in Maxwell boundary condition?
According to the literature (for example, file colin.pdf, page 32, eq. 2.58), in the code below it should be "+=", and in code l...Hello.
Could you please check the sign in equation regarding thermal creep in Maxwell boundary condition?
According to the literature (for example, file colin.pdf, page 32, eq. 2.58), in the code below it should be "+=", and in code line in maxwellSlipUFvPatchVelocityField.C, it is "-=", as you can see.
refValue() -= 3.0*pnu/(4.0*pT)*transform(I - n*n, gradpT);
Best regards,
Darko Radenkovic
[colin.pdf](/uploads/aa8177bc46358af2611d0b4d557d7580/colin.pdf)
[maxwellSlipUFvPatchVectorField.C](/uploads/9e8e718443376c7ecdd691f930f94ac5/maxwellSlipUFvPatchVectorField.C)https://develop.openfoam.com/Development/openfoam/-/issues/1462Make blending wieghts in LUST user selectable2019-10-17T13:21:06ZAdminMake blending wieghts in LUST user selectable### The proposal
LUST is a scheme that linearly blends linear interpolation with a linear upwind scheme using a 0.25 weight for for the latter.
It is claimed that this
```c
optimises the balance between accuracy and stability on a range ...### The proposal
LUST is a scheme that linearly blends linear interpolation with a linear upwind scheme using a 0.25 weight for for the latter.
It is claimed that this
```c
optimises the balance between accuracy and stability on a range of LES cases with a range of mesh quality.
```
I don't necessarily disagree with this, but 0.25 upwinding is quite a lot in some situations, and insufficient in other. There seems to be no particular reason to not allow the user to choose the weight. I suggest that we do just that, with 0.75 remaining the default value when no user input is provided.
### Beneficiaries
Mainly folk doing LES on unsructured grids.
### Funding
I may be wrong, but implementing this should be pretty trivial and require minimal resources.
### Bonus
The paper in which LUST appears to be introduced, different weights are tested. The paper is written by H. Weller. **HILARY** Weller :).
Weller, H. (2012). Controlling the computational modes of the arbitrarily structured C grid. Monthly Weather Review, 140(10), 3220–3234. https://doi.org/10.1175/MWR-D-11-00221.1
This reference should probably be added to LUST.H unless someone is aware of prior art.
Kind regards,
Timofeyhttps://develop.openfoam.com/Development/openfoam/-/issues/1454postProcess clears pointer (to output file) when mesh moved during the simula...2019-10-16T12:15:53ZAdminpostProcess clears pointer (to output file) when mesh moved during the simulationThe "guilty" code is in the file postProcess.H, around line 175 (depending on your version):
```
if (mesh.readUpdate() != polyMesh::UNCHANGED)
{
// Update functionObjects if mesh changes
// Note c...The "guilty" code is in the file postProcess.H, around line 175 (depending on your version):
```
if (mesh.readUpdate() != polyMesh::UNCHANGED)
{
// Update functionObjects if mesh changes
// Note clearing the dictionary to avoid merge warning
functionsDict.clear();
functionsPtr = functionObjectList::New
(
args,
runTime,
functionsDict,
selectedFields
);
}
```
It actually destroys the pointer to the file used for output in the *postProcessing/xxx* directory and therefore makes it impossible to have more than two timesteps outputted there (the first, in the xxx.dat file and the last in the xxx_latestTime.dat file).
I got so far as to identify the source of my issue, can anyone suggest an alternative to destroying the whole functionsPtr when the mesh moves? My only realistic alternative as of now is to actually extract the desired data from the piped output date (ie Log).
Kind regards,
-Louis