Re: [Gmsh] meshing partitions
> On 15 May 2020, at 15:04, Hansjoerg Seybold wrote:
>
> Hello,
> Thanks a lot for the support. Meshing in two steps and noting the
> NbNodes and elements (NbTriangles, Nbquads) worked. I get a correct
> mesh in gmsh and also saving the result is correct.
> I still have some problems importing the final BDF mesh into ansys
> fluent (gmsh reads and displays the BDF correctly)
>
> The BDF contains the diagonal edges twice although I use Coherence Mesh.
Ok that's normal: currently we only remove duplicate nodes, not elements (cf.
https://gitlab.onelab.info/gmsh/gmsh/-/issues/19 for tracking this.)
Christophe
>
> after deleting
> CBAR1 ...
> ...
> CBAR 16 ...
>
> by hand I can read the combined BDF mesh into ansys.
>
> I attached all three sample geo files for all three steps (mesh_1.geo,
> mesh_2.geo and mesh_combined.geo) for reference
>
>
> Thanks a lot again.
>
> Cheers,
> hj
>
>
>
>
>
>
> On Mon, May 11, 2020 at 5:30 PM Christophe Geuzaine
> wrote:
>>
>>
>>
>>> On 11 May 2020, at 16:32, Hansjoerg Seybold 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
>>> wrote:
> On 9 May 2020, at 18:09, Hansjoerg Seybold
> 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
Re: [Gmsh] meshing partitions
Hello,
Thanks a lot for the support. Meshing in two steps and noting the
NbNodes and elements (NbTriangles, Nbquads) worked. I get a correct
mesh in gmsh and also saving the result is correct.
I still have some problems importing the final BDF mesh into ansys
fluent (gmsh reads and displays the BDF correctly)
The BDF contains the diagonal edges twice although I use Coherence Mesh.
after deleting
CBAR1 ...
...
CBAR 16 ...
by hand I can read the combined BDF mesh into ansys.
I attached all three sample geo files for all three steps (mesh_1.geo,
mesh_2.geo and mesh_combined.geo) for reference
Thanks a lot again.
Cheers,
hj
On Mon, May 11, 2020 at 5:30 PM Christophe Geuzaine wrote:
>
>
>
> > On 11 May 2020, at 16:32, Hansjoerg Seybold 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
> > wrote:
> >>
> >>
> >>
> >>> On 9 May 2020, at 18:09, Hansjoerg Seybold
> >>> 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
> >>>
Re: [Gmsh] meshing partitions
> On 11 May 2020, at 16:32, Hansjoerg Seybold 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
> wrote:
>>
>>
>>
>>> On 9 May 2020, at 18:09, Hansjoerg Seybold 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
>>
>>
>>
> ___
> 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
Re: [Gmsh] meshing partitions
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? 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 BTW, is it possible to apply different meshing algorithms to different physical groups? 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 wrote: > > > > > On 9 May 2020, at 18:09, Hansjoerg Seybold 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 Description: Binary data ___ gmsh mailing list gmsh@onelab.info http://onelab.info/mailman/listinfo/gmsh
Re: [Gmsh] meshing partitions
> On 9 May 2020, at 18:09, Hansjoerg Seybold 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 ___ gmsh mailing list gmsh@onelab.info http://onelab.info/mailman/listinfo/gmsh
