Development issueshttps://develop.openfoam.com/groups/Development/-/issues2017-12-30T21:27:06Zhttps://develop.openfoam.com/Development/openfoam/-/issues/687foamToVTK requires system/faSchemes2017-12-30T21:27:06ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comfoamToVTK requires system/faSchemesfoamToVTK on any case:
--> FOAM FATAL ERROR:
cannot find file ".../system/faSchemes"
(foamToEnsight is ok)
foamToVTK on any case:
--> FOAM FATAL ERROR:
cannot find file ".../system/faSchemes"
(foamToEnsight is ok)
Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/154foamToVTK produces invalid files2023-12-07T19:02:00ZMark OLESENfoamToVTK produces invalid filesIt looks like the number of components (eg, in CELL_DATA) are writing as a raw binary value instead as an integer - creating invalid files.
Eg,
p ^A 72 float
1.54262 1.72175 2.01311 2.248 1.38654 1.53183
and later
...It looks like the number of components (eg, in CELL_DATA) are writing as a raw binary value instead as an integer - creating invalid files.
Eg,
p ^A 72 float
1.54262 1.72175 2.01311 2.248 1.38654 1.53183
and later
U ^C 72 float
20 0 0 20 0 0 20 0 0 20 0
Found while testing `tutorials/incompressible/simpleFoam/motorBike/`
Allrun
foamToVTK; or foamToVTK -ascii
Results do not load in paraview.Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/516foamToVTK produces illegal (binary) files2017-07-04T13:08:27ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comfoamToVTK produces illegal (binary) files[fineMesh.tgz](/uploads/ed96068fdeb0d2f606129fdfdf5a321b/fineMesh.tgz)
I did
- lid driven cavity
- in setSet:
cellSet c0 new labelToCell ( 10 12 5)
cellSet c1 new cellToCell c0
cellSet c1 invert
- foamToVTK -cellSet c0
- foamToVTK -cel...[fineMesh.tgz](/uploads/ed96068fdeb0d2f606129fdfdf5a321b/fineMesh.tgz)
I did
- lid driven cavity
- in setSet:
cellSet c0 new labelToCell ( 10 12 5)
cellSet c1 new cellToCell c0
cellSet c1 invert
- foamToVTK -cellSet c0
- foamToVTK -cellSet c1
and VTK/c0_0.vtk is unreadable. c1_0 is fine.Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/829foamToVTK -poly produces unreadable vtk file2019-12-09T22:18:11ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comfoamToVTK -poly produces unreadable vtk file[polyMesh.tgz](/uploads/1ab421bc84de37ab82d0bbd87f419124/polyMesh.tgz)
If you run
foamToVTK -poly
on attached mesh the resulting vtk file cannot be read by paraview (tried 5.5.0 and 5.4.1): "vtkUnstructuredGridReader (0x350e130): Un...[polyMesh.tgz](/uploads/1ab421bc84de37ab82d0bbd87f419124/polyMesh.tgz)
If you run
foamToVTK -poly
on attached mesh the resulting vtk file cannot be read by paraview (tried 5.5.0 and 5.4.1): "vtkUnstructuredGridReader (0x350e130): Unrecognized keyword: 6"Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/1135foamToVTK -parallel fails with processor-cyclic2018-12-19T13:05:14ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comfoamToVTK -parallel fails with processor-cyclicOn `tutorials/incompressible/pimpleFoam/LES/periodicHill/steadyState` foamToVTK fails. Might be to do with cellZones.
```
VTK mesh topology: 2.51 s, 640008 kB
Time: 1
volScalar : nuTilda nut p
volVector : U
Internal :...On `tutorials/incompressible/pimpleFoam/LES/periodicHill/steadyState` foamToVTK fails. Might be to do with cellZones.
```
VTK mesh topology: 2.51 s, 640008 kB
Time: 1
volScalar : nuTilda nut p
volVector : U
Internal : "VTK/steadyState_1/internal.vtu"
Boundary : "VTK/steadyState_1/boundary/inlet.vtp"
Boundary : "VTK/steadyState_1/boundary/outlet.vtp"
Boundary : "VTK/steadyState_1/boundary/top.vtp"
Boundary : "VTK/steadyState_1/boundary/hills.vtp"
[preston:23831] *** An error occurred in MPI_Recv
[preston:23831] *** reported by process [140731114651649,9]
[preston:23831] *** on communicator MPI_COMM_WORLD
[preston:23831] *** MPI_ERR_TRUNCATE: message truncated
[preston:23831] *** MPI_ERRORS_ARE_FATAL (processes in this communicator will now abort,
[preston:23831] *** and potentially your MPI job)
Boundary : "VTK/steadyState_1/boundary/front.vtp"
Boundary : "VTK/steadyState_1/boundary/back.vtp"
[preston:23820] 4 more processes have sent help message help-mpi-errors.txt / mpi_errors_are_fatal
[preston:23820] Set MCA parameter "orte_base_help_aggregate" to 0 to see all help / error messages
```Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/708foamToVTK hangs in parallel with lagrangian data2019-12-09T22:18:10ZMark OLESENfoamToVTK hangs in parallel with lagrangian dataEg, `mpirun -np 4 foamToVTK -parallel`Eg, `mpirun -np 4 foamToVTK -parallel`Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/2010foamToVTK, foamToEnsight ignore pointValueField patches2021-07-29T13:58:15ZMark OLESENfoamToVTK, foamToEnsight ignore pointValueField patchesThey use internal field only.
@Prashant
Cross-ref : EP#1320They use internal field only.
@Prashant
Cross-ref : EP#1320Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/802FoamToVTK crashes on cyclic patches2018-04-18T08:11:48ZAdminFoamToVTK crashes on cyclic patchesOpenFOAM plus-20ffdb88930e crashes when I try to create VTK files using 'foamToVTK'. OpenFOAM plus-bb816234a13e runs fine on the same case.
The error is:
`From function virtual Foam::label Foam::cyclicPolyPatch::neighbPatchID() const
...OpenFOAM plus-20ffdb88930e crashes when I try to create VTK files using 'foamToVTK'. OpenFOAM plus-bb816234a13e runs fine on the same case.
The error is:
`From function virtual Foam::label Foam::cyclicPolyPatch::neighbPatchID() const
in file faMesh/faPatches/constraint/cyclic/cyclicFaPatch.C at line 286.`
I've attached my test case where I got the error.
[RotatingWall_64x16x32_WALE.zip](/uploads/c11d77860f50c026e548c03894480553/RotatingWall_64x16x32_WALE.zip)https://develop.openfoam.com/Development/openfoam/-/issues/1117foamToVTK cannot write faceZones only2018-12-12T15:29:45ZMark OLESENfoamToVTK cannot write faceZones onlyAs noted by @Prashant - used to be able to hack foamToVTK with -noInternal and -excludePatches to get faceZones only, but now these are linked to the internal mesh (so that -no-internal really doesn't generate internal data fields).
Agr...As noted by @Prashant - used to be able to hack foamToVTK with -noInternal and -excludePatches to get faceZones only, but now these are linked to the internal mesh (so that -no-internal really doesn't generate internal data fields).
Agreed that it probably makes more sense to explicitly request faceZones by name or regex as per foamToEnsight. This makes it more flexible and more consistent with foamToEnsight.Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/231foamToEnsight mask is too small/inflexible.2020-03-13T14:19:48ZMark OLESENfoamToEnsight mask is too small/inflexible.Currently have 4-digits, which artificially limits the number of output times to less than 9999.
http://exchange.openfoam.com/node/257Currently have 4-digits, which artificially limits the number of output times to less than 9999.
http://exchange.openfoam.com/node/257Version v1706Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/1286foamToEnsight leaks memory2020-07-28T15:15:56ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comfoamToEnsight leaks memory<!--
*** 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
-->
<!--
All text between these marker...<!--
*** 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
-->
<!--
All text between these markers are comments and will not be present in the
report
-->
### Summary
<!-- Summarize the bug encountered concisely -->
valgrind reports some in-use memory after finishing. E.g. foamToVTK does not.
### Steps to reproduce
<!-- How one can reproduce the issue - this is very important -->
valgrind --leak-check=full foamToEnsight
```
==3683== HEAP SUMMARY:
==3683== in use at exit: 171 bytes in 4 blocks
==3683== total heap usage: 67,611 allocs, 67,607 frees, 6,829,195 bytes allocated
==3683==
==3683== 143 (72 direct, 71 indirect) bytes in 1 blocks are definitely lost in loss record 4 of 4
==3683== at 0x4C2A6F0: operator new(unsigned long) (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==3683== by 0x6921081: Foam::IOobjectList::IOobjectList(Foam::objectRegistry const&, Foam::fileName const&, Foam::fileName const&, Foam::IOobject::readOption, Foam::IOobject::writeOption, bool) (in /home/preston2/mattijs/OpenFOAM/work/develop/OpenFOAM-plus/platforms/linux64GccDPInt32Opt/lib/libOpenFOAM.so)
==3683== by 0x44F58C: main (in /home/preston2/mattijs/OpenFOAM/work/develop/OpenFOAM-plus/platforms/linux64GccDPInt32Opt/bin/foamToEnsight)
```
### 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 : developMark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/1873foamToEnsight lagrangian fails in parallel2020-10-12T11:50:47ZMark OLESENfoamToEnsight lagrangian fails in parallel- as noted in EP1406 (@Prashant), converting Lagrangian fields in parallel fails for some simulations. Converting to VTK works without issue.- as noted in EP1406 (@Prashant), converting Lagrangian fields in parallel fails for some simulations. Converting to VTK works without issue.Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/613foamToEnsight in parallel leaks memory2019-06-28T09:55:38ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comfoamToEnsight in parallel leaks memoryRunning foamToEnsight -parallel produces under valgrind:
==4371== 88 bytes in 1 blocks are possibly lost in loss record 164 of 225
==4371== at 0x4C2B537: operator new[](unsigned long) (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-...Running foamToEnsight -parallel produces under valgrind:
==4371== 88 bytes in 1 blocks are possibly lost in loss record 164 of 225
==4371== at 0x4C2B537: operator new[](unsigned long) (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==4371== by 0x47332A: Foam::hashedWordList::hashedWordList(std::initializer_list<Foam::word>) (in /home/preston2/mattijs/OpenFOAM/OpenFOAM-plus.develop/platforms/linux64GccDPInt32Opt/bin/foamToEnsight)
==4371== by 0x44F003: main (in /home/preston2/mattijs/OpenFOAM/OpenFOAM-plus.develop/platforms/linux64GccDPInt32Opt/bin/foamToEnsight)
Error doesn't seem to be there non-parallel!Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/473foamToEnsight fails with missing field at time 02019-12-09T22:04:15ZMark OLESENfoamToEnsight fails with missing field at time 0Version v1706Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/132foamToEnsight crash when patch name > 80 char2016-06-30T22:09:38ZAdminfoamToEnsight crash when patch name > 80 charin OpenFOAM2.2.1 when using foamToEnsight binary output, if the patch name is equal or greater then 80 characters, it crashes. The crash can be avoided by doing the following modification:
```
+++ b/applications/utilities/postProcessi...in OpenFOAM2.2.1 when using foamToEnsight binary output, if the patch name is equal or greater then 80 characters, it crashes. The crash can be avoided by doing the following modification:
```
+++ b/applications/utilities/postProcessing/dataConversion/foamToEnsight/ensightBinaryStream.H
@@ -98,7 +98,7 @@ public:
virtual void write(const char* val)
{
char buffer[80] = {0};
- strcpy(buffer, val);
+ strncpy(buffer, val, 80);
str_().write(buffer, 80*sizeof(char));
}
```
The same crash happens with OpenFOAM-v3.0+. Would it be possible to use the above modification to fix ensightBinaryStream.H?
Thank you
AdminAdminhttps://develop.openfoam.com/Development/openfoam/-/issues/2002foamToEnsight cellZone conversion issues2021-02-16T07:45:04ZMark OLESENfoamToEnsight cellZone conversion issuesMark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/2469foamToCcm and ccmToFoam missing librairies2022-05-24T12:56:23ZalexfoamToCcm and ccmToFoam missing librairiesHello,
in OF v2112, doing ./Allwmake in the src/conversion/ccm folder leads to :
```
==> skip ccmio (no header)
==> skip optional libccm adapter
```
is there anything missing ? and how to fix this ?
regardsHello,
in OF v2112, doing ./Allwmake in the src/conversion/ccm folder leads to :
```
==> skip ccmio (no header)
==> skip optional libccm adapter
```
is there anything missing ? and how to fix this ?
regardshttps://develop.openfoam.com/Development/openfoam/-/issues/2638foamRestoreFields does not handle regions2022-11-25T08:05:19ZMark OLESENfoamRestoreFields does not handle regionscross-ref EP2048cross-ref EP2048Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/1006foamNewSource missing libraries in Make/options2019-12-09T22:22:46ZAdminfoamNewSource missing libraries in Make/optionsThe following will fail:
```
cd $WM_PROJECT_USER_DIR
mkdir -p applications/solvers/electromagnetics/rodFoam
cd applications/solvers/electromagnetics/rodFoam
foamNewSource App rodFoam
sed -i s/FOAM_APPBIN/FOAM_USER_APPBIN/g Make/files
wma...The following will fail:
```
cd $WM_PROJECT_USER_DIR
mkdir -p applications/solvers/electromagnetics/rodFoam
cd applications/solvers/electromagnetics/rodFoam
foamNewSource App rodFoam
sed -i s/FOAM_APPBIN/FOAM_USER_APPBIN/g Make/files
wmake
```
Error message:
```
$FOAM_SRC/finiteVolume/lnInclude/cyclicAMIFvPatch.H:39:10: fatal error: cyclicAMILduInterface.H: No such file or directory
#include "cyclicAMILduInterface.H"
^~~~~~~~~~~~~~~~~~~~~~~~~
compilation terminated.
```
It will compile if I manually add meshTools in Make/options. However, I think it would be nice of the template is at a state that allows it to be compiled without manual modifications.https://develop.openfoam.com/Development/openfoam/-/issues/1885foamNewBC incorrect for Function1 member data2020-10-24T09:01:27ZHÃ¥kanfoamNewBC incorrect for Function1 member data<!--
*** 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
foamNewBC incorrect for Function1 member data. It is not possible to compile the default output.
<!-- Summarize the bug encountered concisely -->
### Steps to reproduce
foamNewBC -f -v XYZ
wmake XYZ
<!-- How one can reproduce the issue - this is very important -->
### Example case
N/A
<!--
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?
Compilation fails
<!-- What actually happens -->
### What is the expected *correct* behavior?
It should compile, so that the user gets a good example from the script.
<!-- 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 : v2006
- Operating system : Ubuntu 20.04
- 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
-->
In last three constructors in the initialization (XYZ...C), it should be corrected to (from translatingWallVelocityFvPatchVectorField.C):
timeVsData_(ptf.timeVsData_.clone()),Mark OLESENMark OLESEN