Personal tools
You are here: Home Forum How to use Salome? Coincident nodes

Coincident nodes

Up to How to use Salome?
  • Coincident nodes

    Posted by Manav Bhatia at May 24. 2008
    Hi,

       Is there a way to automatically find and merge coincident nodes in the mesh module?

    Regards,
    Manav
     
    • Re: Coincident nodes

      Posted by Erwan ADAM at May 26. 2008
      Hi Manav,

      It depends what you mean by automatically ...

      I you write a python script, you can use two methods
      on Mesh object :

      "FindCoincidentNodes(Tolerance)" return a list of nodes
      which are coincident in a certain tolerance.

      "MergeNodes(GroupsOfNodes)" does the job of merging.

      But I must admit that I have not tested that in a script.

      On the graphical part, you can use the dialog box
      Modification --> Transformation --> Merge nodes
      but I think you already saw that ...

      Regards,

                      E.A.
      • Re: Coincident nodes

        Posted by Manav Bhatia at May 26. 2008
        ADAM Erwan wrote:
        Hi Manav,

        It depends what you mean by automatically ...

        I you write a python script, you can use two methods
        on Mesh object :

        "FindCoincidentNodes(Tolerance)" return a list of nodes
        which are coincident in a certain tolerance.

        "MergeNodes(GroupsOfNodes)" does the job of merging.

        But I must admit that I have not tested that in a script.

        On the graphical part, you can use the dialog box
        Modification --> Transformation --> Merge nodes
        but I think you already saw that ...

        Regards,

                        E.A.

        Thanks, Adam.
        I am trying to use this through a python script. I was running into issues about multiple coincidental nodes, and that was because I was using geompy.MakeCompound() method, which I assumed would join the different surfaces that collectively form my geometry. Then I tried using different combination of MakeFuse(), MakeSewing() and MakePartition(), and got the right mix of commands to create a unified geometry. My experience with MakePartition is that for some general cases, it can take very long to execute. Hence, I create small chunks of geometry using fuse and sew, and then combine them using partition.
        For now, I have managed to circumvent the need for merging nodes.
        However while using MEDMEM, I noticed that MED_QUAD4 and MED_TRIA3, etc are element types of MED_CELL (instead of MED_FACE, as expected). For a mesh with quad4 elements, the command mesh.getNumberOfElements(MED_FACE, MED_QUAD4) returns 0, whereas mesh.getNumberOfElements(MED_CELL, MED_QUAD4) returns the number of elements. Is this the intended behavior? Or a bug?
        Seems more like a bug to me.
        Regards, Manav
        • Re: Coincident nodes

          Posted by Vincent Bergeaud at May 28. 2008

          Hello,

          Well, maybe it is a bug, maybe it is not... Depends
           on your mesh.

          MEDMEM CELL and FACE notions are based on the
           following principle : in a mesh, elements of different
           connectivity order are present. The elements that have
           highest dimensions are considered as CELL. All the
          other ones are named after their dimension:
          MED_FACE for 2D, MED_EDGE for 1D.

          So...
          If you have a mesh mixing MED_TETRA4 and MED_TRIA3 elements
          for instance, MED_TETRA4 are MED_CELL while MED_TRIA3
           are MED_FACE. Now if your mesh only contains MED_TRIA3 and
          MED_SEG2, MED_TRIA3 are MED_CELL and MED_SEG2 are MED_EDGE.

          Coming back to your bug, it depends : if your mesh
          is a 3D one, it is a bug, if it is a 2D one, it is
           the intended behavior.

          I hope this helps.

          Vincent

           

          • Re: Coincident nodes

            Posted by Manav Bhatia at May 28. 2008
            Vincent Bergeaud wrote:

            Hello,

            Well, maybe it is a bug, maybe it is not... Depends
             on your mesh.

            MEDMEM CELL and FACE notions are based on the
             following principle : in a mesh, elements of different
             connectivity order are present. The elements that have
             highest dimensions are considered as CELL. All the
            other ones are named after their dimension:
            MED_FACE for 2D, MED_EDGE for 1D.

            So...
            If you have a mesh mixing MED_TETRA4 and MED_TRIA3 elements
            for instance, MED_TETRA4 are MED_CELL while MED_TRIA3
             are MED_FACE. Now if your mesh only contains MED_TRIA3 and
            MED_SEG2, MED_TRIA3 are MED_CELL and MED_SEG2 are MED_EDGE.

            Coming back to your bug, it depends : if your mesh
            is a 3D one, it is a bug, if it is a 2D one, it is
             the intended behavior.

            I hope this helps.

            Vincent

             


            Thanks for your email Vincent. This is very helpful.
            I have a mesh, with QUAD4 and SEG2 elements. Then, by your reasoning, it seems to be the intended behavior.
            Is there a specific reason for keeping this behavior of calling all highest dimension elements as CELL?
            Regards,
            Manav
            • Re: Coincident nodes

              Posted by Vincent Bergeaud at May 30. 2008
              Hello Manav,

              MEDMEM reproduces the behavior of MED file which considers as MED_CELL highest dimension elements. A slight difference between MEDMEM and MED exists, though :
              in MED , the MED_FACE and MED_EDGE notions apply only to decending connectivity representation. In nodal connectivity, every element is regarded as a MED_CELL. In MEDMEM, even in nodal connectivity representation,
              element entity type is defined through the highest dimension element of the mesh.

              Vincent

Powered by Ploneboard
Document Actions