Thanks. I will try different partitioners. I moved away from the virtual environment, anyway.
Rgds, Renato On Sun, May 12, 2019 at 9:42 AM Kirk, Benjamin (JSC-EG311) < benjamin.k...@nasa.gov> wrote: > There is some Hilbert space filling curve indexing that gets invoked with > the default partitioner, and who knows in a virtual environment. Also it’s > worth trying a different partitioner. You can set the partitioner to any > supported type, but I’ve not got the documentation handy at the moment. > > > > ------------------------------ > On: 11 May 2019 21:09, "Renato Poli" <rebp...@gmail.com> wrote: > > Hi > > It seems that partitioning is taking a lot of time. > If I skip it, it runs much faster. >> mesh.skip_partitioning(true); > Does that make any sense? > > Renato > > > On Sat, May 11, 2019 at 10:59 PM Renato Poli <rebp...@gmail.com> wrote: > >> Hi Kirk, >> >> I see there is something related to the parallelization. >> I am using mpirun.mpich. >> With a single processor, it runs much faster than with 4 processors. >> Please find data below. >> >> Why parallel reading would be so slower? >> Any suggestions? >> >> XDR - 1 processor >> # Stopwatch "LibMesh::read": 12.7637 s >> XDR - 4 processors >> # Stopwatch "LibMesh::read": 135.473 s >> EXO - 1 processor >> # Stopwatch "LibMesh::read": 0.294671 s >> EXO - 4 processrs >> # Stopwatch "LibMesh::read": 198.897 s >> >> This is the mesh: >> ====== >> Mesh Information: >> elem_dimensions()={2} >> spatial_dimension()=2 >> n_nodes()=40147 >> n_local_nodes()=40147 >> n_elem()=19328 >> n_local_elem()=19328 >> n_active_elem()=19328 >> n_subdomains()=1 >> n_partitions()=1 >> n_processors()=1 >> n_threads()=1 >> processor_id()=0 >> >> >> On Sat, May 11, 2019 at 7:15 PM Renato Poli <rebp...@gmail.com> wrote: >> >>> Thanks. >>> I am currently running on a virtual machine - not sure mpi is getting >>> along with that. >>> I will try other approaches and bring more information if necessary. >>> >>> rgds, >>> Renato >>> >>> On Sat, May 11, 2019 at 5:49 PM Kirk, Benjamin (JSC-EG311) < >>> benjamin.k...@nasa.gov> wrote: >>> >>>> Definitely not right, but that seems like something in your machine or >>>> filesystem. >>>> >>>> You can use the “meshtool-opt” command to convert it to XDR and try >>>> that for comparison. We’ve got users who routinely read massive meshes with >>>> ExodusII, so I’m skeptical of a performance regression. >>>> >>>> -Ben >>>> >>>> >>>> >>>> >>>> ------------------------------ >>>> On: 11 May 2019 15:24, "Renato Poli" <rebp...@gmail.com> wrote: >>>> >>>> Hi >>>> >>>> I am reading in a mesh of 20.000 elements. >>>> I am using Exodus format. >>>> It takes up to 4 minutes. >>>> Is that right? >>>> How can I enhance performance? >>>> >>>> Thanks, >>>> Renato >>>> >>>> _______________________________________________ >>>> Libmesh-users mailing list >>>> Libmesh- <Libmesh-users@lists.source>us...@lists.sourceforge.net >>>> <https://urldefense.proofpoint.com/v2/url?u=http-3A__forge.net&d=DwMFaQ&c=ApwzowJNAKKw3xye91w7BE1XMRKi2LN9kiMk5Csz9Zk&r=cL6XMjnReoBDeWspbxyIhOHmg_O4uY2LnJOBmaiGPkI&m=vIvYF97KzwC0P9yVGHmF5v40OVXd4xvJtJNPxXxB7yU&s=xd3JWceEFFMudAJy6xr6KaQVBlwoV36Vg2s6R5w0R_k&e=> >>>> >>>> https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.sourceforge.net_lists_listinfo_libmesh-2Dusers&d=DwICAg&c=ApwzowJNAKKw3xye91w7BE1XMRKi2LN9kiMk5Csz9Zk&r=cL6XMjnReoBDeWspbxyIhOHmg_O4uY2LnJOBmaiGPkI&m=g9IqMQsNW7V7TetwCxIPRjeT6JqEPzvKRkxJgwL-sl8&s=LvY_-3DUqPYdv-F9qjoCV95-Em1ASG0AXQvo6KvU308&e= >>>> >>>> _______________________________________________ Libmesh-users mailing list Libmesh-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libmesh-users