[petsc-users] Writing VTK output
Matthew Knepley
knepley at gmail.com
Mon Jun 13 08:18:56 CDT 2022
Can you just send your GMsh file so I can see what you are asking for?
Also, Plex stores hexes with outward normals, but some other programs store
them with some inward normals. This
should be converted in the output. I can check this if you send your mesh.
Thanks,
Matt
On Sun, Jun 12, 2022 at 10:48 AM Sami BEN ELHAJ SALAH <
sami.ben-elhaj-salah at ensma.fr> wrote:
> Dear Matthew and Jed,
>
> Thank you very much for explaining and your help. I am sorry for my late
> reply.
> For me, the .vtu file is wrong when the <AppendedData> section seems to be
> not correct (I mean the raw encoding because when I visualize the .vtu file
> on paraview, the geometry is not good). The header is OK (see attached
> file). To generate the vtu file, I use the routine suggested by Matthew and
> the commande line proposed by Jed (-dm_plex_filename 2C3D8_msh.msh -dm_view
> vtk:2C3D8_msh.vtu).
>
> On the other hand, when I use the routine below and write my output to a
> vtk file and not vtu, the result is ok except the rotation of the elements
> nodes (the nodes rotation is not good for me and not saved comparing to
> gmsh file).
>
> PetscViewer vtk;
> PetscViewerVTKOpen(FOX::Parallel::COMM_WORLD,"solution.vtk",FILE_MODE_WRITE,&vtk);
> VecView(solution,vtk);
> PetscViewerDestroy(&vtk);
>
> I put here an example of a vtk file that I have generated
>
> # vtk DataFile Version 2.0
> Simplicial Mesh Example
> ASCII
> DATASET UNSTRUCTURED_GRID
> POINTS 12 double
> 0.000000e+00 1.000000e+01 1.000000e+01
> 0.000000e+00 0.000000e+00 1.000000e+01
> 0.000000e+00 0.000000e+00 0.000000e+00
> 0.000000e+00 1.000000e+01 0.000000e+00
> 1.000000e+01 1.000000e+01 1.000000e+01
> 1.000000e+01 0.000000e+00 1.000000e+01
> 1.000000e+01 0.000000e+00 0.000000e+00
> 1.000000e+01 1.000000e+01 0.000000e+00
> 2.000000e+01 1.000000e+01 1.000000e+01
> 2.000000e+01 0.000000e+00 1.000000e+01
> 2.000000e+01 0.000000e+00 0.000000e+00
> 2.000000e+01 1.000000e+01 0.000000e+00
> CELLS 2 18
> 8 0 3 2 1 4 5 6 7
> 8 4 7 6 5 8 9 10 11
> CELL_TYPES 2
> 12
> 12
> POINT_DATA 12
> VECTORS dU_x double
> 2.754808e-10 -8.653846e-11 -8.653846e-11
> 2.754808e-10 8.653846e-11 -8.653846e-11
> 2.754808e-10 8.653846e-11 8.653846e-11
> 2.754808e-10 -8.653846e-11 8.653846e-11
> 4.678571e-01 -9.107143e-02 -9.107143e-02
> 4.678571e-01 9.107143e-02 -9.107143e-02
> 4.678571e-01 9.107143e-02 9.107143e-02
> 4.678571e-01 -9.107143e-02 9.107143e-02
> 1.000000e+00 -7.500000e-02 -7.500000e-02
> 1.000000e+00 7.500000e-02 -7.500000e-02
> 1.000000e+00 7.500000e-02 7.500000e-02
> 1.000000e+00 -7.500000e-02 7.500000e-02
>
>
> To obtain the good geometry, the two lines
>
> 8 0 3 2 1 4 5 6 7
> 8 4 7 6 5 8 9 10 11
>
> Should be like this in order to have a good geometry defined in the gmsh
> file.
>
> 8 0 1 2 3 4 5 6 7
> 8 4 5 6 7 8 9 10 11
>
>
> - - - > So I m trying now to compile my code with petsc 3.16, may be it
> solves the problem of the rotation order of nodes.
>
> Thank you and have a good day,
>
> Sami,
>
> --
> Dr. Sami BEN ELHAJ SALAH
> Ingénieur de Recherche (CNRS)
> Institut Pprime - ISAE - ENSMA
> Mobile: 06.62.51.26.74
> Email: sami.ben-elhaj-salah at ensma.fr <sami.ben-elhaj-salah at ensma.fr>
> www.samibenelhajsalah.com
> <https://samiben91.github.io/samibenelhajsalah/index.html>
>
>
>
> Le 8 juin 2022 à 17:57, Matthew Knepley <knepley at gmail.com> a écrit :
>
> On Wed, Jun 8, 2022 at 11:24 AM Sami BEN ELHAJ SALAH <
> sami.ben-elhaj-salah at ensma.fr> wrote:
>
>> Yes, the file "sami.vtu" is loaded correctly in paraview and I have the
>> good output like you.
>>
>> In my code, I tried with the same command given in your last answer and I
>> still have the wrong .vtu file.
>>
>
> Hi Sami,
>
> What do you mean by wrong?
>
> Can you just use the simple procedure:
>
> PetscCall(DMCreate(comm, dm));
> PetscCall(DMSetType(*dm, DMPLEX));
> PetscCall(DMSetFromOptions(*dm));
> PetscCall(DMViewFromOptions(*dm, NULL, "-dm_view"));
>
> This is the one that works for us. Then we can change it in your code one
> step at a time until you get what you need.
>
> Thanks,
>
> Matt
>
>
>> I use this:
>> mpirun -np 1 /home/benelhasa/fox_petsc/build_test/bin/Debug/FoXtroT
>> -snes_test_jacobian_view -snes_converged_reason -snes_monitor -ksp_monitor
>> -ksp_xmonitor -dm_plex_filename cub_2C3D8_msh.msh -dm_view
>> vtk:cub_2C3D8_msh.vtu cub_8C3D8.fxt
>>
>>
>> Thanks,
>> Sami,
>>
>> --
>> Dr. Sami BEN ELHAJ SALAH
>> Ingénieur de Recherche (CNRS)
>> Institut Pprime - ISAE - ENSMA
>> Mobile: 06.62.51.26.74
>> Email: sami.ben-elhaj-salah at ensma.fr <sami.ben-elhaj-salah at ensma.fr>
>> www.samibenelhajsalah.com
>> <https://samiben91.github.io/samibenelhajsalah/index.html>
>>
>>
>>
>> Le 8 juin 2022 à 16:25, Jed Brown <jed at jedbrown.org> a écrit :
>>
>> Does the file load in paraview? When I load your *.msh in a tutorial with
>> -dm_plex_filename sami.msh -dm_view vtk:sami.vtu, I get this good output.
>>
>> <sami.vtu><sami.png>
>> Sami BEN ELHAJ SALAH <sami.ben-elhaj-salah at ensma.fr> writes:
>>
>> Hi Jed,
>>
>> Thank you for your answer.
>>
>> When I use a ‘’solution.vtu'', I obtain a wrong file.
>>
>> <?xml version="1.0"?>
>> <VTKFile type="UnstructuredGrid" version="0.1" byte_order="LittleEndian">
>> <UnstructuredGrid>
>> <Piece NumberOfPoints="12" NumberOfCells="2">
>> <Points>
>> <DataArray type="Float64" Name="Position" NumberOfComponents="3"
>> format="appended" offset="0" />
>> </Points>
>> <Cells>
>> <DataArray type="Int32" Name="connectivity" NumberOfComponents="1"
>> format="appended" offset="292" />
>> <DataArray type="Int32" Name="offsets" NumberOfComponents="1"
>> format="appended" offset="360" />
>> <DataArray type="UInt8" Name="types" NumberOfComponents="1"
>> format="appended" offset="372" />
>> </Cells>
>> <CellData>
>> <DataArray type="Int32" Name="Rank" NumberOfComponents="1"
>> format="appended" offset="378" />
>> </CellData>
>> <PointData>
>> <DataArray type="Float64" Name="dU_x(null)" NumberOfComponents="3"
>> format="appended" offset="390" />
>> </PointData>
>> </Piece>
>> </UnstructuredGrid>
>> <AppendedData encoding="raw">
>> _ $@$@$@$@$@$@$@$@$@$@$@$@4@$@$@4@$@4 at 4@$@@
>> �p�O��=��sT����sT���p�O��=��sT���=��sT���p�O��=��sT���=��sT���=�p�O��=��sT����sT���=o
>> _��?�� uP���� uP��o _��?�� uP�?�� uP��o _��?�� uP�?�� uP�?o _��?�� uP����
>> uP�?b#�����?�333����333��_#�����?
>> �333�?��333��b#�����?(�333�?'�333�?a#�����?�333��>�333�?
>> </AppendedData>
>> </VTKFile>
>>
>>
>> If I understand your answer, to solve my problem, should just upgrade all
>> my software ?
>>
>> Thanks,
>> Sami,
>>
>>
>> --
>> Dr. Sami BEN ELHAJ SALAH
>> Ingénieur de Recherche (CNRS)
>> Institut Pprime - ISAE - ENSMA
>> Mobile: 06.62.51.26.74
>> Email: sami.ben-elhaj-salah at ensma.fr <sami.ben-elhaj-salah at ensma.fr>
>> www.samibenelhajsalah.com <
>> https://samiben91.github.io/samibenelhajsalah/index.html>
>>
>>
>>
>> Le 8 juin 2022 à 15:37, Jed Brown <jed at jedbrown.org> a écrit :
>>
>> You're using pretty old versions of all software; I'd recommend
>> upgrading. I recommend choosing the file name "solution.vtu" to use the
>> modern (non-legacy) format. Does that work for you?
>>
>> Sami BEN ELHAJ SALAH <sami.ben-elhaj-salah at ensma.fr> writes:
>>
>> Dear Petsc Developer team,
>>
>> I solved a linear elastic problem in 3D using a DMPLEX. My system is
>> converging, then I would like to write out my solution vector to a vtk file
>> where I use unstructured mesh. Currently, I tried two algorithms and I have
>> the same result.
>>
>> 1) Algorithm 1
>> err = SNESSolve(_snes, bc_vec_test, solution);
>> CHKERRABORT(FOX::Parallel::COMM_WORLD,err);
>> PetscViewer vtk;
>>
>> PetscViewerVTKOpen(FOX::Parallel::COMM_WORLD,"solution.vtk",FILE_MODE_WRITE,&vtk);
>>
>> VecView(solution,vtk);
>> PetscViewerDestroy(&vtk);
>>
>>
>> 2) Algorithm 2
>> err = SNESSolve(_snes, bc_vec_test, solution);
>> CHKERRABORT(FOX::Parallel::COMM_WORLD,err);
>> PetscViewer vtk;
>> PetscViewerCreate(FOX::Parallel::COMM_WORLD, &vtk);
>> PetscViewerSetType(vtk, PETSCVIEWERVTK);
>> PetscViewerFileSetName(vtk, "sol.vtk");
>> VecView(solution, vtk);
>> PetscViewerDestroy(&vtk);
>>
>> The result seems correct except for the rotation order of the nodes (see
>> the red lines on gmsh and vtk file respectively). Then, I visualized my vtk
>> file with paraview, and I remarked that my geometry is not correct and not
>> conserved when comparing it with my gmsh file. So, I didn’t understand why
>> the rotation order of nodes is not conserved when saving my result to a vtk
>> file?
>>
>> Other information used:
>> - gmsh format 2.2
>> - Vtk version: 7.1.1
>> - Petsc version: 3.13/opt
>>
>> Below my two files gmsh and vtk:
>>
>> Gmsh file:
>> $MeshFormat
>> 2.2 0 8
>> $EndMeshFormat
>> $Nodes
>> 12
>> 1 0.0 10.0 10.0
>> 2 0.0 0.0 10.0
>> 3 0.0 0.0 0.0
>> 4 0.0 10.0 0.0
>> 5 10.0 10.0 10.0
>> 6 10.0 0.0 10.0
>> 7 10.0 0.0 0.0
>> 8 10.0 10.0 0.0
>> 9 20.0 10.0 10.0
>> 10 20.0 0.0 10.0
>> 11 20.0 0.0 0.0
>> 12 20.0 10.0 0.0
>> $EndNodes
>> $Elements
>> 2
>> 1 5 2 68 60 1 2 3 4 5 6 7 8
>> 2 5 2 68 60 5 6 7 8 9 10 11 12
>> $EndElements
>>
>> Vtk file :
>> # vtk DataFile Version 2.0
>> Simplicial Mesh Example
>> ASCII
>> DATASET UNSTRUCTURED_GRID
>> POINTS 12 double
>> 0.000000e+00 1.000000e+01 1.000000e+01
>> 0.000000e+00 0.000000e+00 1.000000e+01
>> 0.000000e+00 0.000000e+00 0.000000e+00
>> 0.000000e+00 1.000000e+01 0.000000e+00
>> 1.000000e+01 1.000000e+01 1.000000e+01
>> 1.000000e+01 0.000000e+00 1.000000e+01
>> 1.000000e+01 0.000000e+00 0.000000e+00
>> 1.000000e+01 1.000000e+01 0.000000e+00
>> 2.000000e+01 1.000000e+01 1.000000e+01
>> 2.000000e+01 0.000000e+00 1.000000e+01
>> 2.000000e+01 0.000000e+00 0.000000e+00
>> 2.000000e+01 1.000000e+01 0.000000e+00
>> CELLS 2 18
>> 8 0 3 2 1 4 5 6 7
>> 8 4 7 6 5 8 9 10 11
>> CELL_TYPES 2
>> 12
>> 12
>> POINT_DATA 12
>> VECTORS dU_x double
>> 2.754808e-10 -8.653846e-11 -8.653846e-11
>> 2.754808e-10 8.653846e-11 -8.653846e-11
>> 2.754808e-10 8.653846e-11 8.653846e-11
>> 2.754808e-10 -8.653846e-11 8.653846e-11
>> 4.678571e-01 -9.107143e-02 -9.107143e-02
>> 4.678571e-01 9.107143e-02 -9.107143e-02
>> 4.678571e-01 9.107143e-02 9.107143e-02
>> 4.678571e-01 -9.107143e-02 9.107143e-02
>> 1.000000e+00 -7.500000e-02 -7.500000e-02
>> 1.000000e+00 7.500000e-02 -7.500000e-02
>> 1.000000e+00 7.500000e-02 7.500000e-02
>> 1.000000e+00 -7.500000e-02 7.500000e-02
>>
>> Thank you in advance and have a good day !
>>
>> Sami,
>>
>> --
>> Dr. Sami BEN ELHAJ SALAH
>> Ingénieur de Recherche (CNRS)
>> Institut Pprime - ISAE - ENSMA
>> Mobile: 06.62.51.26.74
>> Email: sami.ben-elhaj-salah at ensma.fr
>> www.samibenelhajsalah.com <
>> https://samiben91.github.io/samibenelhajsalah/index.html>
>>
>>
>>
>
> --
> What most experimenters take for granted before they begin their
> experiments is infinitely more interesting than any results to which their
> experiments lead.
> -- Norbert Wiener
>
> https://www.cse.buffalo.edu/~knepley/
> <http://www.cse.buffalo.edu/~knepley/>
>
>
>
--
What most experimenters take for granted before they begin their
experiments is infinitely more interesting than any results to which their
experiments lead.
-- Norbert Wiener
https://www.cse.buffalo.edu/~knepley/ <http://www.cse.buffalo.edu/~knepley/>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mcs.anl.gov/pipermail/petsc-users/attachments/20220613/99858d9f/attachment-0001.html>
More information about the petsc-users
mailing list