Development issueshttps://develop.openfoam.com/groups/Development/-/issues2021-10-29T20:19:32Zhttps://develop.openfoam.com/Development/openfoam/-/issues/1631Writing fields with layer information makes snappyHexMesh crash in motorbike ...2021-10-29T20:19:32ZRiccardo RossiWriting fields with layer information makes snappyHexMesh crash in motorbike tutorial (reopen)I've just tried to test the issue reported in #1420 with the v1912 and it's still there:
`
Writing fields with layer information:
nSurfaceLayers : actual number of layers
thickness : overall layer thickness
[0] #0 [1...I've just tried to test the issue reported in #1420 with the v1912 and it's still there:
`
Writing fields with layer information:
nSurfaceLayers : actual number of layers
thickness : overall layer thickness
[0] #0 [1] #0 [2] #0 [3] #0 [4] #0 [5] #0 Foam::error::printStack(Foam::Ostream&)Foam::error::printStack(Foam::Ostream&)Foam::error::printStack(Foam::Ostream&)Foam::error::printStack(Foam::Ostream&)Foam::error::printStack(Foam::Ostream&)Foam::error::printStack(Foam::Ostream&) at at ??:?
`https://develop.openfoam.com/Development/openfoam/-/issues/1616CrankNicolson ddtScheme isn't working with MPPICInterFoam2022-04-26T16:10:39ZLinus KCrankNicolson ddtScheme isn't working with MPPICInterFoam### Summary
MPPICInterFoam isn't working when using the CrankNicolson ddtScheme. After my own project didnt work, I tried the "twoPhasePachuka" tutorial case with the same result. After the first time step it crashes, showing the error ...### Summary
MPPICInterFoam isn't working when using the CrankNicolson ddtScheme. After my own project didnt work, I tried the "twoPhasePachuka" tutorial case with the same result. After the first time step it crashes, showing the error message attached further down.
### Steps to reproduce
Take the "twoPhasePachuka" tutorial case.
In file fvSchemes, change the ddtScheme to CrankNicolson:
```
ddtSchemes
{
default CrankNicolson 0.1;
}
```
In file fvSolution, change the number of AlphaSubCycles to 1:
```
solvers
{
"alpha.water.*"
{
nAlphaCorr 2;
nAlphaSubCycles 1;
cAlpha 1;
```
### Relevant logs and/or images
```
--> FOAM FATAL ERROR:
tmp<N4Foam14GeometricFieldIdNS_13fvsPatchFieldENS_11surfaceMeshEEE> deallocated
From function const T& Foam::tmp<T>::cref() const [with T = Foam::GeometricField<double, Foam::fvsPatchField, Foam::surfaceMesh>]
in file /OpenFOAM/v1812/OpenFOAM-v1812/src/OpenFOAM/lnInclude/tmpI.H at line 230.
FOAM aborting
```
### Environment information
OpenFOAM version : v1812v2206Kutalmış BerçinKutalmış Berçinhttps://develop.openfoam.com/Development/openfoam/-/issues/1615chtMultiregionFoam relaxation problem2021-07-06T17:09:26ZTj KimchtMultiregionFoam relaxation problemIn the Pimple mode with relaxation of p_rgh, the chtMultiregionFoam solver returns an error message of
"not stored. Use field.storePrevIter()"
I found the solver already includes a function call of storePrevIter().
So I think that it is ...In the Pimple mode with relaxation of p_rgh, the chtMultiregionFoam solver returns an error message of
"not stored. Use field.storePrevIter()"
I found the solver already includes a function call of storePrevIter().
So I think that it is out of my job.
The solver in v1906 is same as the v1912.
With the same fvSolution file, OF-7 runs good.
Could you please check the reason?
My recommendation is to update solutioncontrol classes in v1912 similar to those in OF-7Kutalmış BerçinKutalmış Berçinhttps://develop.openfoam.com/Development/openfoam/-/issues/1611Wrong curvature at finite area boundary2022-05-06T08:04:23ZChiara PesciWrong curvature at finite area boundary<!--
*** 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
Curvature computation at finite area boundaries is wrong.
### Steps to reproduce
<!-- How one can reproduce the issue - this is very important -->
To visualize the curvature field, one can modify for instance the *checkFaMesh* utility. A volScalarField can be added and the aMesh.faceCurvatures() can be written out on its boundary corresponding to the faMesh.
```
volScalarField curvVf
(
IOobject
(
"curvVf",
runTime.timeName(),
mesh,
IOobject::NO_READ,
IOobject::AUTO_WRITE
),
mesh,
dimensionedScalar(dimless/dimLength, Zero)
);
// Create volume-to surface mapping object
volSurfaceMapping vsm(aMesh);
vsm.mapToVolume(aMesh.faceCurvatures(), curvVf.boundaryFieldRef());
curvVf.write();
```
### 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
-->
Consider the surface of half a sphere, this is represented by a finite area mesh with a boundary, the circumference at the equator. The curvature of the sphere is known; in this case the radius of the sphere is 1 m, thus the curvature should be -2.
### What is the current *bug* behaviour?
<!-- What actually happens -->
The figures below show the local curvature and the error in its computation on half a sphere for which the analytical curvature is known.
![curvatureV1912boundary](/uploads/d5527f5f263d9bc311c9bf0c605480b1/curvatureV1912boundary.png)
Note that the error persists when refining the mesh or using different cell/face shapes.
### 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.
-->
```
Curvature: min = min(faceCurvatures) [0 -1 0 0 0 0 0] -2.0005
max = max(faceCurvatures) [0 -1 0 0 0 0 0] -1.48813
```
### 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 : v1912 (problem present also in older versions)
- 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
-->
A correction for the faces having a point on the boundary of the finite area mesh has to be included. The curvature computation depends on the pointAreaNormals and at the boundary of the finite area mesh these normals introduce the error. A solution for cases where the mesh is not being highly deformed close to the boundary may be possible.v2206Kutalmış BerçinKutalmış Berçinhttps://develop.openfoam.com/Development/openfoam/-/issues/1592Proposal: alphatWallBoilingWallFunctionFvPatchScalarField.C wall temperature ...2021-07-08T14:12:44ZRobin KamenickyProposal: alphatWallBoilingWallFunctionFvPatchScalarField.C wall temperature iterationHello everyone,
I have noticed that in the release OF-v1906 in the file OpenFOAM-v1906/src/phaseSystemModels/reactingEulerFoam/derivedFvPatchFields/alphatWallBoilingWallFunction/alphatWallBoilingWallFunctionFvPatchScalarField.C there wa...Hello everyone,
I have noticed that in the release OF-v1906 in the file OpenFOAM-v1906/src/phaseSystemModels/reactingEulerFoam/derivedFvPatchFields/alphatWallBoilingWallFunction/alphatWallBoilingWallFunctionFvPatchScalarField.C there was a for loop to evaluate wall temperature Tw. The for loop was, however, not executed because of lagging (line 1124 // NOTE: lagging Tw update.).
Thus, the wall temperature was not evaluated after the calculation of the thermal turbulent diffusivity. This led to zero error between TsupPrev and TsupNew and so the for loop was not executed. The fix to that would be the evaluation of the maximum error from all CPUs. Thus
`scalar maxErr(gMax(mag(TsupPrev - TsupNew)));`
instead of
`scalar maxErr(max(mag(TsupPrev - TsupNew)));`
When the original version is used then each processor might evaluate the error if condition on the line 1260
if (maxErr < 1e-1) differently, which means that some processor exits the for loop and some processor loops again. In this manner, the processors enter different parts of the code. Once they encounter a mpi function which requests information also from the other processor, it waits (forever, deadlock). This exactly happens when alphatWallBoilingWallFunctionFvPatchScalarField.C is used together with the turbulentTemperatureCoupledBaffleMixedFvPatchScalarField.C
I propose that the for loop to find wall temperature is implemented (as it was removed from OF-v1912) and the lagging to be fixed in the manner I showed above. It is generally recommended by literature to do this looping. Its absence might not be a big issue for heat transfer which uses correlations (film boiling and transitional boiling) but might be an issue for more complicated nucleate boiling.
Thank you,
Kind regards,
RobinKutalmış BerçinKutalmış Berçinhttps://develop.openfoam.com/Development/openfoam/-/issues/1583checkMesh : patch geometry : include flatness2020-02-05T13:34:26ZPrashant SonakarcheckMesh : patch geometry : include flatness### Functionality to add/problem to solve
Would be nice for checkMesh to report whether a patch is flat for e.g. follow-on extrudeMesh.
### Proposal
Add to -allGeometry check the reporting of the maximum deviation of (face) normal w....### Functionality to add/problem to solve
Would be nice for checkMesh to report whether a patch is flat for e.g. follow-on extrudeMesh.
### Proposal
Add to -allGeometry check the reporting of the maximum deviation of (face) normal w.r.t. average.
Q:
- how much deviation is non-flat
- report per patch-region (e.g. for lid-driven cavity tutorial where single patch has 3 different orientations)
Cross-ref : EP#1159https://develop.openfoam.com/Development/openfoam/-/issues/1581transient solver with suitable ddtScheme2020-02-03T12:37:26ZPrashant Sonakartransient solver with suitable ddtScheme### Functionality to add/problem to solve
Trying to run a transient solver with 'steadyState' as ddtScheme usually causes a divide by zero (sigfpe). This is quite an easy mistake to make when starting from a steady-state solution.
###...### Functionality to add/problem to solve
Trying to run a transient solver with 'steadyState' as ddtScheme usually causes a divide by zero (sigfpe). This is quite an easy mistake to make when starting from a steady-state solution.
### Proposal
Would be nice to give a warning message. It still should be possible in general (e.g. to replace an outer loop with the time loop).
Cross Ref: EP#1204https://develop.openfoam.com/Development/openfoam/-/issues/1576coded FO does not support mesh changes2020-01-27T15:19:10ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comcoded FO does not support mesh changes### Functionality to add/problem to solve
coded FO never gets warned of mesh changes (movePoints, updateMesh). These calls are defaulted in functionObject but should be redirected instead.
Needs:
- functionObjectTemplate[CH] to specify...### Functionality to add/problem to solve
coded FO never gets warned of mesh changes (movePoints, updateMesh). These calls are defaulted in functionObject but should be redirected instead.
Needs:
- functionObjectTemplate[CH] to specify missing callbacks
- syntax inside codedFunctionObject to specify the missing code ('codeMovePoints'?)
- redirection callshttps://develop.openfoam.com/Development/openfoam/-/issues/1570Cloud post-processing data not written when steady case converges using resid...2020-01-28T09:28:57ZAndrew HeatherCloud post-processing data not written when steady case converges using residualControl<!--
*** 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 -->
When using clouds in steady solvers combined with case termination controls set using `residualControl` in the `fvSolution` file, cloud post-processing data are not written on the last iteration.
### Steps to reproduce
<!-- How one can reproduce the issue - this is very important -->
Add `residualControl` settings to a steady flow solver with cloud functionality and cloud a post-processing object, e.g. `particleTracks`
```
particleTracks
{
type particleTracks;
trackInterval 5;
maxSamples 1000000;
resetOnWrite yes;
}
```
and notice that the cloud post-processing data are not written
### 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?
When the criteria specified in the `residualControls` dictionary are achieved the solver loop calls `time.writeAndEnd()` to write any objects registered with `AUTO_WRITE` and exits. Operations such as cloud post-processing are currently only triggered when evolving the cloud and intercept the `writeTime()` flag and are therefore missed.
### 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 : v1806|v1812|v1906 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
-->
Couple of options
- instead of exiting straight away, run for 1 more iteration with the `writeTime_` flag set (e.g. using `time.writeOnce()` and exit
- intercept the `write()` call to trigger other post-processing actionsv2006Andrew HeatherAndrew Heatherhttps://develop.openfoam.com/Development/openfoam/-/issues/1542checkMesh aspect ratio2024-01-10T16:47:46ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comcheckMesh aspect ratio### Functionality to add/problem to solve
checkMesh calculates an aspect ratio in the global coordinate system. More relevant would probably using a cell-local coordinate system.
### Proposal
Use the cell-local coordinate system calc...### Functionality to add/problem to solve
checkMesh calculates an aspect ratio in the global coordinate system. More relevant would probably using a cell-local coordinate system.
### Proposal
Use the cell-local coordinate system calculation from e.g. the cellDeterminant check and determine the aspect ratio in that.
### What does success look like, and how can we measure that?
Make e.g. cavity with a lot of grading. See if the reported aspect ratio changes if the case is rotated (e.g. using `transformPoints -rotate`)https://develop.openfoam.com/Development/openfoam/-/issues/1528snappyHexMesh castellation step creates gaps between curved triangulated surf...2024-01-02T13:17:31ZDries AllaertssnappyHexMesh castellation step creates gaps between curved triangulated surfaces### Summary
In multiRegion cases, the castellation step of snappyHexMesh creates small gaps between curved triangulated surfaces (specified by stl files exported from CAD software AutoDesk Invecntor) when they are not exactly equal, eve...### Summary
In multiRegion cases, the castellation step of snappyHexMesh creates small gaps between curved triangulated surfaces (specified by stl files exported from CAD software AutoDesk Invecntor) when they are not exactly equal, even when stl files are exported at very high resolution (highest resolution available in the CAD software).
### Steps to reproduce
The issue can be reproduced by applying snappyHexMesh on a multiregion case with a curved interface between two regions, and with the different regions specified by different stl files exported from CAD software.
### Example case
Attached is a minimal working example consisting of two concentric cylinders corresponding to a fluid and a solid region. Only the castellation step of snappyHexMesh is run. [MWE.tar.gz](/uploads/21ca31e1c36f1f0e4a2673ec786c5fd9/MWE.tar.gz)
### What is the current *bug* behaviour?
The castellation step of snappyHexMesh creates small gaps between two triangulated surfaces, i.e., on the interface between two regions. As a result, some faces on the interface are identified as walls instead of mappedWalls between the two surfaces. In the snapping step, the gaps are closed but the patch type of some faces remains wall instead of mappedWall.
### What is the expected *correct* behavior?
snappyHexMesh should not remove cells located between two triangulated surface when the two triangulated surfaces coincide within a certain tolerance. The tolerance should be such that coinciding surfaces exported by CAD software can be meshed without creating small gaps. Possibly, this tolerance could be a user input.
### Relevant logs and/or images
Attached is a log file ([log.txt](/uploads/d20cb17863dbfce7ae643e6f8d23c929/log.txt)) of the provided minimal working example (logs of surfaceFeatureExtract - blockMesh - snappyHexMesh - splitMeshRegions) as well as some figures showing the case setup and the gaps on the interface.
Overview of the multiRegion geometry.
![MWE_fig1](/uploads/46a8588961f77c7616bdefac7eede9f1/MWE_fig1.png)
Detailed view of the interface.
![MWE_fig2](/uploads/a691486b653b0a97414885d0052784e1/MWE_fig2.png)
View of the interface, showing some faces that are identified as type wall (white) instead of mappedWall (red)
![MWE_fig3](/uploads/d6a1e6157024dad044c6cc8306f2dd6c/MWE_fig3.png)
### 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 : CentOS Linux release 7.6.1810
- Hardware info :
- Compiler : intel
### Possible fixeshttps://develop.openfoam.com/Development/openfoam/-/issues/165setSet writing unreconstructed VTK files2020-01-03T12:05:35ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comsetSet writing unreconstructed VTK filessetSet could use the same mechanism as checkMesh for writing vtk files on master only.
Attached a hack which uses vtkSurfaceWriter and the checkTools*[CH] from checkMesh to enable this. What it doesn't do:
- output field with origina...setSet could use the same mechanism as checkMesh for writing vtk files on master only.
Attached a hack which uses vtkSurfaceWriter and the checkTools*[CH] from checkMesh to enable this. What it doesn't do:
- output field with original face/cell ID (in parallel also e.g. processorID ?)
- reconstruct point fields
[setSet.C](/uploads/ce5595b7068316f020b1bc8552768ec4/setSet.C)Mattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comhttps://develop.openfoam.com/Development/openfoam/-/issues/1122snappyHexMesh automatic gap level refinement : 'small feature' phase should i...2020-09-10T14:39:28ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comsnappyHexMesh automatic gap level refinement : 'small feature' phase should ignore min levelThe `Small surface feature refinement iteration` only works if minimum gap level is triggered. So if
- the specified min level is > 0
- and the geometry is inside a single cell
it will not do anything (since the initial cell level is zer...The `Small surface feature refinement iteration` only works if minimum gap level is triggered. So if
- the specified min level is > 0
- and the geometry is inside a single cell
it will not do anything (since the initial cell level is zero and never increases).
If we leave this behaviour the problem is that the behaviour depends on whether the geometry is fully inside a cell or does intersect. Which is illogical.
Or we fix and then ideally have a switch to bypass this behaviour (since it can be very slow on large cases). Maybe supply a 'maxIter' parameter for the snappyRefineDriver::smallFeatureRefine.
Mattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comhttps://develop.openfoam.com/Development/openfoam/-/issues/1239paraFoam needs 0/ directory2020-03-13T14:42:41ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comparaFoam needs 0/ directory### Steps to reproduce
<!-- How one can reproduce the issue - this is very important -->
lid driven cavity
mv 0 0.orig
ln -s 0.001 0.orig
paraFoam now complains about no mesh.### Steps to reproduce
<!-- How one can reproduce the issue - this is very important -->
lid driven cavity
mv 0 0.orig
ln -s 0.001 0.orig
paraFoam now complains about no mesh.Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/1089primitiveMesh::cells needed only from wall functions2018-11-21T15:38:46ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comprimitiveMesh::cells needed only from wall functionsin simpleFoam only fvMatrix<Type>::setValuesFromList gets the cellList. Could this be rewritten to use face-based addressing and save memory? (but more runtime?)
But postprocessing/tracking needs cells so probably little effect for real...in simpleFoam only fvMatrix<Type>::setValuesFromList gets the cellList. Could this be rewritten to use face-based addressing and save memory? (but more runtime?)
But postprocessing/tracking needs cells so probably little effect for real cases.https://develop.openfoam.com/Development/openfoam/-/issues/1016Paraview only reading cases with constant2019-12-11T12:31:11ZRoger AlmenarParaview only reading cases with constantHello,
I just came across an interesting case:
1) I create a blockMesh based on latestTime, hence mesh is located under results folder (like in 0.2/polyMesh).
2) I decompose that case. It creates the processorX folders, which contained 0...Hello,
I just came across an interesting case:
1) I create a blockMesh based on latestTime, hence mesh is located under results folder (like in 0.2/polyMesh).
2) I decompose that case. It creates the processorX folders, which contained 0.2/polyMesh but no constant/folders, as there is nothing there.
3) Paraview cannot read the case based on a "decomposed" input, because there are no processorX/constant folders.
The case is actually valid, just that it cannot be opened in Paraview.Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/1187DOCU/ENH: lagrangian utilities2024-01-16T06:05:40ZPrashant SonakarDOCU/ENH: lagrangian utilities- [ ] particleTrack writes to processor0/VTK when run in parallel
- [x] $FOAM_APP/utilities/postProcessing/lagrangian/particleTracks/particleTrackProperties please correct cloudName->cloud
- [ ] ~~$FOAM_APP/utilities/postProcessing/lagra...- [ ] particleTrack writes to processor0/VTK when run in parallel
- [x] $FOAM_APP/utilities/postProcessing/lagrangian/particleTracks/particleTrackProperties please correct cloudName->cloud
- [ ] ~~$FOAM_APP/utilities/postProcessing/lagrangian/steadyParticleTracks/particleTrackDict please correct cloudName->cloud~~
- [ ] change alphaName->alpha in ParticleTrap.H
@andyv2206Kutalmış BerçinKutalmış Berçinhttps://develop.openfoam.com/Development/openfoam/-/issues/1029hole value zeroing gives problems in overRhoPimpleDyMFoam since solves for rho2021-07-08T20:28:32ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comhole value zeroing gives problems in overRhoPimpleDyMFoam since solves for rhoZero rho gives sigFpe when e.g. calculating nu (mu/rho).Zero rho gives sigFpe when e.g. calculating nu (mu/rho).https://develop.openfoam.com/Development/openfoam/-/issues/326ENH: wmake for file with future timestamp2021-07-06T11:04:27ZPrashant SonakarENH: wmake for file with future timestampPlaceholder for check for files with future time stamp (when transferred between different systems)Placeholder for check for files with future time stamp (when transferred between different systems)Mattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comhttps://develop.openfoam.com/Development/openfoam/-/issues/602redistributePar -reconstruct produces different phi field w.r.t. reconstructPar2024-01-10T16:22:29ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comredistributePar -reconstruct produces different phi field w.r.t. reconstructPar- take parallel/filter tutorial
- reconstruct time 0.8 (using ascii, 16 digits writeprecision) with both
```
reconstructPar -time 0.8
mpirun -np 3 redistributePar -reconstruct -time 0.8
```
The phi field differs in the last digits on som...- take parallel/filter tutorial
- reconstruct time 0.8 (using ascii, 16 digits writeprecision) with both
```
reconstructPar -time 0.8
mpirun -np 3 redistributePar -reconstruct -time 0.8
```
The phi field differs in the last digits on some faces.