> On 11 May 2020, at 16:32, Hansjoerg Seybold <hansjo...@fisica.ufc.br> wrote: > > Hello, > Thanks a lot for the reply. Using the visibility filter worked. I > created a simple test case (attached) > which creates the two mesh pieces. So now I have two meshes > multizone_1.msh and multizone_2.msh > which I can load in a geo file > -------------------------------------- > Merge "multizone_1.msh"; > Merge "multizone_2.msh"; > Coherence Mesh; > Save "multizone_merged.msh"; > Save "multizone_merged.bdf"; > Exit; > -------------------------------------- > I understood that the coherence mesh removes the duplicate nodes on > the common edge and the above > script displays the mesh in the gui correctly. > However the export is distorted as the node ordering is not updated. > I would get the development snapshot to try to use the mesh tag > suggestion, but how would I do the reordering > starting from the script above? >
You would do: Mesh.FirstNodeTag=1; Mesh 2; Save "multizone_1.msh"; ... Mesh.FirstNodeTag=Mesh.NbNodes + 1; Mesh 2; Save "multizone_2.msh"; > regarding openmp: > > We (the IT cluster staff at ETH Zurich and myself) tried to get the > openmp version of gmsh running on the cluster (CentOS 6), but without > success. > I managed to compile and run it on my ubuntu PC, but with very little > speedup for the selected meshing algorithm. > I tested openmp with two physical groups active and -nt 2, on a finer > LC as in the attached geo for speed measurements and Mesh.Algorithm = > 9; gmsh-4.4.1, > a significant speedup could only be observed for del2d, but quality > tests showed that the 'pack' algorithm gave the best meshing result Ok I see. The "pack" algorithm has not been worked on for a while and is indeed currently sequential. We are working on updating this algorithm, so hopefully it will get much faster (and parallel) soon. > BTW, is it possible to apply different meshing algorithms to different > physical groups? > Yes. In .geo files: MeshAlgorithm Surface {...} = ...; Christophe > Regarding the 5 days meshing: I am using quad meshing (algo 9) with a > not too sophisticated sizing function but with a very large domain, > del2d is orders > of magnitudes faster. > > Thanks a lot for the help. > > Hansjoerg > > > > > > > > On Sun, May 10, 2020 at 9:05 AM Christophe Geuzaine <cgeuza...@uliege.be> > wrote: >> >> >> >>> On 9 May 2020, at 18:09, Hansjoerg Seybold <hansjo...@fisica.ufc.br> wrote: >>> >>> Hello, >>> I am trying to mesh a model consisting of several physical groups each >>> group at a time and then merge the meshes for the different physical >>> groups afterwards. The reason why I am trying to perform this "domain >>> decomposition" is that the meshing of the full model takes over 5 days >>> and exceeds the runtime limit of the queuing system. >>> >>> However I could not find a simple way to apply the "Mesh 2" to a >>> specific physical group. Gmsh always tries to mesh the whole model. >>> >> >> You could either delete the parts you don't want to mesh; or hide the parts >> you don't want to mesh (cf. the `Show` and `Hide` commands in .geo script, >> or `setVisibility()` in the api) and use the `Mesh.MeshOnlyVisible` option. >> >>> My question would be if anybody has a hint how to perform this meshing >>> in parts and how to combine the resulting meshes into a single final >>> model. >>> >> >> That's trickier as each mesh will be independent. The development snapshot >> allows you to set the starting node/element tag (Mesh.FirstNodeTag, >> Mesh.FirstElementTag), which will help. Removing duplicate nodes when you >> merge things together can be done with Coherence Mesh (in .geo files) or >> removeDuplicateNodes() in the api. >> >> PS: 5 days to perform a 2D mesh ? Anything special in the geometry/size >> field? If you don't do this already at least recompile Gmsh with OpenMP >> enabled, and mesh in parallel? >> >> Christophe >> >>> Thank you very much. >>> >>> Best, >>> hansjoerg >>> >>> _______________________________________________ >>> gmsh mailing list >>> gmsh@onelab.info >>> http://onelab.info/mailman/listinfo/gmsh >> >> — >> Prof. Christophe Geuzaine >> University of Liege, Electrical Engineering and Computer Science >> http://www.montefiore.ulg.ac.be/~geuzaine >> >> >> > <multizone_1.geo>_______________________________________________ > gmsh mailing list > gmsh@onelab.info > http://onelab.info/mailman/listinfo/gmsh — Prof. Christophe Geuzaine University of Liege, Electrical Engineering and Computer Science http://www.montefiore.ulg.ac.be/~geuzaine _______________________________________________ gmsh mailing list gmsh@onelab.info http://onelab.info/mailman/listinfo/gmsh