hexagon logo
Register Sign in
  • State Not Answered
  • Replies 11 replies
  • Subscribers 3 subscribers
  • Views 99 views
  • Users 0 members are here
Options
Related

Material ID for an element

Boobalan
Hi,
​
​I have element ID and I need to get the property set ID and its material ID defined in the property.   db_element function returns part ID and its not matching with BDF file. Please suggest to get the material ID for an element.
  • 0
    Once you have the property set ID, you can get the material ID using db_get_region_definition. This will give you the material ID. If necessary, you can get the material name from its ID using db_get_material_name_from_id.
     
    Your comment about the bdf isn't clear to me - can you clarify? There isn't necessarily any relation between IDs in the bdf and IDs in the Patran db.
  • 0
    Use db_get_region_for_elements ( ) to get the region ids (property ids) for elements (input and return are arrays). Then use db_get_region_definition ( ) and db_get_material_name_from_id() as described above. The first 2 are documented in PCL and Customization. The third is is in Acumen Functions.
     
    There is a loose correlation between the MID in the Nastran BDF and Patran Database. When exporting, Patran has a couple of options:
    • By default, the Internal Patran DB MID is used as the Nastran MID. This guarantees unique MIDs in the BDF.
    • There is an option to append the desired Nastran MID to the material name using a delimiter. For example, steel.10 becomes MID=10 on export, and aluminium.20 becomes MID=20.
    • The same appended ID option is also available for Property Names and PIDs.
    • When using these options, the user must take care not to define duplicate IDs in the names. For example, if you have steel.10 and aluminium.10, results are unpredictable. (The same is true if you have properties named pshell.wing.11 and pshell.tail.11)
    On import, the Nastran MID is appended to the material name, so you can usually safely use the MID from the name for imported BDFs.
    However, as @Darrel Sinclair​ said, there isn't necessarily a relation between material IDs.
     
     
     
  • 0
    Comment on coding for performance.
     
    When working with PCL there is a relatively large CPU hit for every database transaction that you do, so you should seek to minimise the number of "db_..." calls that you make.
    When coding PCL it can be very tempting to count the number of elements, nodes etc and then do a FOR loop for 1 to number_of_elements (nodes etc) and within this loop get from the database the information you seek for a single element. This works fine for test models but in real life the loop that is calling db transactions for every item can be slow. (or even very slow)
     
    To minimise the performance impact of the db transactions most db_ routines allow you to get the information for arrays of ids in one go.
     
    In the attached example I have tried to illustrate this, the function retrieves the material names for an array of element ids . The number of db calls has been minimised. There is one "FOR" loop over all elements, this could possibly be improved by use of a 2d array and a sort..., but it is sufficient to demonstrate the basics of using arrays of ids to minimise db transactions within loops.
     
    Like most coding the first task is to make it work with a prototype, then you start to look at performance if it is actually an issue..
     
    best regards
    Arthur
     
    Attached Files (1)
  • 0
    Thanks for your answers. I am importing BDF file to create new DB. Please find the screenshot of the BDF and DB outputs... For element 68691 property ID & Material values are different.
    BDF - 920, 22
    ​DB - 204, 88
    Attached Files (1)
  • 0
    Hi,
    without your test bdf file and pcl code it is difficult to give meaningful comments.
    I think the code you are showing the dump for is modified from that which I posted.
    I'm concerned because I think the dump shows pcomp.61 as the property name and I would expect pcomp.920, (also good to know which Patran version you are using)
    Also what are you expecting? The material ID is patran's internal id of the material record.
     
     
     
  • 0
    I am using PATRAN 2012 and attached the DBF file.
    Attached Files (1)
  • 0
    Attached the session file for your reference.  Property ID & Material ID is not matching with BDF file.
    Attached Files (1)
  • 0
    @Boobalan Srinivasan​ , please reread my comments about appending the desired Nastran MID (PID) to the material (or property) name using a delimiter. In your case, CQUAD 68691 references PID 920 which points to PCOMP 920. That looks correct. Note that the internal Patran DB IDs usually do not match Nastran IDs.
    Your example did not have "name.#" in all of the comments, so I did not get matching MIDs when I imported the file.
    To demonstrate this behavior, I created a simple example that has 3 material properties referenced by 3 different PSHELLS + 1 composite layup (PCOMP). All materials and properties use the name.### convention to manage IDs when exported and imported.
    Also, I modified your PCL to retrieve and dump the material name, and loop thru elements #1-4.
    Import the BDF and run the attached session file to see the behavior.
     
    Rephrasing what Darrell said: the relation between material and property IDs in Patran and Nastran is highly dependent on how the user created them and exported/imported them (w/ or w/out the name.### convention).
     
    Attached Files (1)
  • 0
    Hi
    as @Ken Walker​  already said, and was stated earlier and in other posts the internal Patran id's are not the same as the PIDs written/read from Nastran.
    The 3.bdf was incomplete as it missed the begin bulk etc I modified it so that now when you read it in it correctly builds the prop and material names to correspond with either the names "Plate1", "Plate2", "Demo" adn "Demo1" or on import if you turn off the option "Retrieve names from comments" it builds them as "pshell.1", "pshell.2", "matrl.1" and "matrl.2". Here the ".xx" convention is being used for the names and ties up with the bdf ids. Note the internal Patran ids will not correspond.
    Attached Files (1)
© 2025 Hexagon AB and/or its subsidiaries. Privacy Policy | Cloud Services Agreement