helppyFormex - Support: sr #108266, fe_abq.py writes to many element...

 
 

sr #108266: fe_abq.py writes to many element sets

Submitted by:  gianluca de santis <gianlucadesi>
Submitted on:  Mon 18 Mar 2013 02:09:32 PM UTC  
 
Category:  Plugins Priority:  5 - Normal
Severity:  1 - Wish Privacy:  Public
Assigned to:  None Open/Closed:  Open
Operating System:  None

Add a New Comment (Rich Markup)
   

You are not logged in

Please log in, so followups can be emailed to you.

 

Mon 18 Mar 2013 05:49:10 PM UTC, comment #3: 

I do not like the idea of some generated set names are ESET and others are ZESET. That would be confusing. Maybe you give your own names such that they come out in front?

And I still think a good solution could be to add a feature like

NO RESULTS FOR SETS ESET_*_GRP_*

Or create an Abaqus/CAE script to
DELETE ALL SETS ESET_*_GRP_*

Need to check Abaqus to see how this could be done.

Benedict Verhegghe <bverheg>
Project Administrator
Mon 18 Mar 2013 05:07:15 PM UTC, comment #2: 

Thanks for the reply!

I am not sure if I know how to use groups because I have never thought of it. Indeed, I always used 1 element set per object

for example:
P.elemProp(set=quad,name='cylinder',section=surf_section,eltype='SFM3D4R')

If I needed one set with some quads and some hex together, I could just write

P.elemProp(set=[0, 10],name='addset' )#see set 'addset' in the attached .inp

where 0 is a hex and 10 is a quad, and it works nice (because they are not used in to define an element section).

I would not know how to define one element section with multiple element types or multiple materials.

Anyway, I see one easy solution: we could rename ESET to ZESET, so all the ESET in the CAE will appear at the bottom, and not in between the user-defined sets.

What do you think?

(file #27624)

gianluca de santis <gianlucadesi>
Project Member
Mon 18 Mar 2013 04:13:55 PM UTC, comment #1: 

There is a very good reason for this (as always ;) ).

In pyFormex we do not just have sets of elements like in Abaqus: we have groups and sets, and these are two orthogonal classifications of the elements.
This reflects the fact that pyFormex is not just intended as a Finite Element Mesh preprocessor, but rather as a general Geometry Modeler.

Element GROUPs are used to split the mesh in objects of the same plexitude, so that we can use single arrays for the geometry in a group.

Element SETs are used to split up the mesh in parts with the same (physical, not geometrical) properties. pyFormex sets are
not to be confused with Abaqus sets (though often coincident).

Thus you can e.g. have a group with triangles and a group with quads. But some triangles and some quads may be made of steel, while other triangles and quads are made of wood.

In Abaqus you will need 4 sets:
- steel triangles
- wooden triangles
- steel quads
- wooden quads

That is why pyFormex HAS to split up elements according to
groups * sets when exporting to Abaqus.

pyFormex also creates the accumulated sets according to groups and (pyFormex) sets. Depending on the case, the user may not be interested in the results for the split set, but rather in the agglomerate parts: e.g. results in the steel part, results in the quads, results in the loaded elements, ...

The sensible default is to generate all agglomerate sets, but that can be switched off. But you can not replace the individual set names by an agglomerate name, like you suggest. That would e.g. break the group_by_group feature.

Note also that defining a lot of extra sets is not a performance hit for Abaqus. So it is best to leave the feature in. The user can always disregard/delete extraneous sets from Abaqus CAE if he wishes (All the internally generated element sets start with 'ESET_'.) Or he can set res/out requests producing only results for the sets that he wants.

The only thing that could be left out is the user specified set name at the end of the generated names. Look at the following code:

for p in self.prop.getProp('e'):
    ...
    setname = esetName(p)
    ...
    for i,elnrs,els in zip(range(len(gl)),gl,elems):
    ...
        grpname = Eset('grp',i,setname)
        subsetname = Eset(p.nr,'grp',i,setname)

We have a double loop, so the generated name should reflect 'p' (the property record) and 'i' (the group number).
setname is the name for the set p, grpname is the name for the group i, subsetname is the name for p*i. The subsetname will be 'ESET_p.nr_GRP_i_setname', where setname and p.nr both refer to the same property record. We want to keep the ESET_p.nr for consistency and easy recognition as a generated name.
The final setname could be left out, but I guess I put it in to help the user in correlating the generated set name with his provided set name.

Benedict Verhegghe <bverheg>
Project Administrator
Mon 18 Mar 2013 02:09:32 PM UTC, original submission:  

The fe_abq.py makes a lot of duplicated element sets.

This is annoying when post-processing:

when viewing the odb results in Abaqus viewer (or CAE) the list of element sets contains 2 times the element sets: for each element set MYSET, there is also another set ESET_3_GRP_0_MYSET. This makes this list very difficult to read when the model contains hundreds of sections.

To what I see, the new sets are unneded to Abaqus (and probably to the user). Unless there are some other reasons I would suggest to replace line 2091:

-> subsetname = Eset(p.nr,'grp',i,setname)

with

-> subsetname = setname

Let me know!
Gianluca

gianluca de santis <gianlucadesi>
Project Member

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:
   
   
Comment:
   

Attached Files
file #27624:  dispCil.inp added by gianlucadesi (4KiB - chemical/x-gamess-input)

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by bverheg (Posted a comment)
  • -email is unavailable- added by gianlucadesi (Submitted the item)
  •  

    Do you think this task is very important?
    If so, you can add your encouragement to it.
    This task has 0 encouragements so far.

    Only logged-in users can vote.

     

     

     

    Follows 1 latest change.

    Date Changed by Updated Field Previous Value => Replaced by
    2013-03-18 gianlucadesi Attached File- => Added dispCil.inp, #27624

    Back to the top


    Powered by Savane 3.5