This file is corrupted. It ends with $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//+ Show "*";
That should be $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 If you fix it, then you can run $ make $PETSC_ARCH/tests/dm/impls/plex/tutorials/ex7 $ $PETSC_ARCH/tests/dm/impls/plex/tutorials/ex7 -dm_plex_filename ~/dl/cub_2C3D8_msh.msh -dm_view vtk:foo.vtu and open foo.vtu in Paraview. It looks correct. Sami BEN ELHAJ SALAH <sami.ben-elhaj-sa...@ensma.fr> writes: > Hi Matthew, > Please find attached the gmsh file, > Thank you in advance ! > 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-sa...@ensma.fr > www.samibenelhajsalah.com > <https://samiben91.github.io/samibenelhajsalah/index.html> > > > >> Le 13 juin 2022 à 15:18, Matthew Knepley <knep...@gmail.com> a écrit : >> >> 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-sa...@ensma.fr <mailto:sami.ben-elhaj-sa...@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-sa...@ensma.fr <mailto:sami.ben-elhaj-sa...@ensma.fr> >> www.samibenelhajsalah.com >> <https://samiben91.github.io/samibenelhajsalah/index.html> >> >> >> >>> Le 8 juin 2022 à 17:57, Matthew Knepley <knep...@gmail.com >>> <mailto:knep...@gmail.com>> a écrit : >>> >>> On Wed, Jun 8, 2022 at 11:24 AM Sami BEN ELHAJ SALAH >>> <sami.ben-elhaj-sa...@ensma.fr <mailto:sami.ben-elhaj-sa...@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-sa...@ensma.fr <mailto:sami.ben-elhaj-sa...@ensma.fr> >>> www.samibenelhajsalah.com >>> <https://samiben91.github.io/samibenelhajsalah/index.html> >>> >>> >>> >>>> Le 8 juin 2022 à 16:25, Jed Brown <j...@jedbrown.org >>>> <mailto:j...@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-sa...@ensma.fr >>>> <mailto:sami.ben-elhaj-sa...@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@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-sa...@ensma.fr >>>>> <mailto:sami.ben-elhaj-sa...@ensma.fr> >>>>> www.samibenelhajsalah.com <http://www.samibenelhajsalah.com/> >>>>> <https://samiben91.github.io/samibenelhajsalah/index.html >>>>> <https://samiben91.github.io/samibenelhajsalah/index.html>> >>>>> >>>>> >>>>> >>>>>> Le 8 juin 2022 à 15:37, Jed Brown <j...@jedbrown.org >>>>>> <mailto:j...@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-sa...@ensma.fr >>>>>> <mailto:sami.ben-elhaj-sa...@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-sa...@ensma.fr >>>>>>> <mailto:sami.ben-elhaj-sa...@ensma.fr> >>>>>>> www.samibenelhajsalah.com <http://www.samibenelhajsalah.com/> >>>>>>> <https://samiben91.github.io/samibenelhajsalah/index.html >>>>>>> <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/>
