Material ID incorrect about pymapdl-reader

[pmaroneh]

Hello @NDfp. To reply to your comment: Mechanical will create one material ID per body, so if only one material is defined in Engineering Data but the model has three different bodies, the .rst file will show three mat IDs (but the material properties will be the same of course).

[nasdr]

Hey everyone,
also from my side: sorry for the delay. I'm currently familiarizing myself with the issue. I am trying to reproduce the error to be able to give more insights. In general I can say that we do not work with contacts but with merged nodes.
I will keep you posted.
Best regards
Sven

[NDfp]

Some more details:
The key is defined in:
self._materials[mat_data_ptr[0]] = material
mat_data_ptr is defined in:
idx_st = 3 + i*(n_mat_prop + 1)
idx_en = 3 + i*(n_mat_prop + 1) + 1 + n_mat_prop
mat_data_ptr = mat_table[idx_st:idx_en]
From the documentation, "last 2 data contains the active table number and material ID". I however did not find in the record anything similar to the ID (apart from the first value).

[akaszynski]

I'll look into this. Thanks for posing the issue!

[NDfp]

Another point. With a model (which unfortunately I cannot share) I had more unique entries in material_type than in materials.
Btw, Ansys appears to duplicate the the material definitions: I have significantly more materials in the rst as in Engineering Data.

[NDfp]

Hi Alex,
do you have an update concerning this issue?
Regards
Francesco

[akaszynski]

Hi @NDfp,

I've looked into this and it appears that the result is reading in the material type correctly:

In:

mat_data_ptr = mat_table[idx_st:idx_en]

We store the material data by material number in:

# store by material number
self._materials[mat_data_ptr[0]] = material

Which is the first item in the material data pointer array.

Please email me at [email protected] and let's see if there's a way we can share the rst file.

[NDfp]

Hi Alex,
in the file I have sent you, the ID of the materials in self._materials ranges from 1 to 7.
In self.mesh.material_type the IDs range between 1 to 14.
np.unique(self.mesh.material_type)
[ 1 2 3 4 5 12 14]
(maybe it is just a coincidence but 12 and 14 are double 6 and 7, which are the two missing material IDs)
Is there another variable containing the material ID for all the elements?
Regards
Francesco

[NDfp]

Maybe a question first. Is self.mesh.material_type the correct entity? If not, where do I find the material ID for each element?

[akaszynski]

This is really strange. You're 100% correct, there are "unlisted" material types in the raw mesh:

>>> import numpy as np
>>> from ansys.mapdl.reader import read_binary
>>> rst = read_binary('file.rst')

Show the actual materials.

>>> rst.materials.keys()
dict_keys([1, 2, 3, 4])

However, there seems to be "bonus" materials 5-15:

>>> np.unique(rst.mesh.material_type)
array([ 1,  2,  3,  4,  5,  6,  7,  8,  9, 10, 11, 12, 13, 14, 15],
      dtype=int32)

Checking the fortran header file published with the unified install fdresu.inc shows that nummat in the result file should show the number of materials:

# *comdeck,fdresu
#
# c *** Copyright ANSYS.  All Rights Reserved.
# c *** ansys, inc
#
# c     **********  description of results file  **********
# c     --- used for the following files:
# c       .rmg
# c       .rst
# c       .rth
# c       .lnn(lxx)
# c ...
# c                                   nummat - the number of materials
# c                                            in the model

This, however, evaluates to 4 in rst.py:
https://github.com/pyansys/pymapdl-reader/blob/5d688f77eb44d541e89e8af466464f7cbcb5aca7/ansys/mapdl/reader/rst.py#L366

I checked the raw tables as well, there's absolutely only 4:

[  1 792 800 808 816 824 832 840 848 856   0   0   0   0   0   0   0   0
   0   0   0   0   0   0   0   0   0   0 864 872 880   0   0   0   0   0
   0   0   0   0   0   0   0   0   0   0   0   0   0   0   0   0   0   0
   0   0   0   0   0   0   0   0   0   0   0   0   0   0   0   0   0   0
   0   0   0   0   0   0   0   0   0   0 888   0   0   0   0   0   0   0
   0   0   0   0   0   0   0   0   0   0   0   0   0   0   0   0   0   0
   0   0   0   0   0   0   0   0   0   0   0   0   0   0   0   0   0   0
   0   0   0   0   0   0   0   0   0   0   0   0   0   0   0   0   0   0
   0   0   0   0   0   0   0   0   0   0   0   0   0   0   0   0   0   0
   0 951   0   0   0   0   0   0   0   0   0   0   0   0   0   0   0   0
   0   0   0   0   0   0   0   0   0   0   0   0   0   0   0   0]
[   2 1131 1139 1147 1155 1163 1171 1179 1187 1195    0    0    0    0
    0    0    0    0    0    0    0    0    0    0    0    0    0    0
 1203 1211 1219    0    0    0    0    0    0    0    0    0    0    0
    0    0    0    0    0    0    0    0    0    0    0    0    0    0
    0    0    0    0    0    0    0    0    0    0    0    0    0    0
    0    0    0    0    0    0    0    0    0    0    0    0 1227    0
    0    0    0    0    0    0    0    0    0    0    0    0    0    0
    0    0    0    0    0    0    0    0    0    0    0    0    0    0
    0    0    0    0    0    0    0    0    0    0    0    0    0    0
    0    0    0    0    0    0    0    0    0    0    0    0    0    0
    0    0    0    0    0    0    0    0    0    0    0    0    0    0
    0    0    0    0    0    0    0    0    0 1290    0    0    0    0
    0    0    0    0    0    0    0    0    0    0    0    0    0    0
    0    0    0    0    0    0    0    0    0    0    0    0    0    0]
[   3 1470    0    0 1478    0    0    0    0    0    0    0    0    0
    0    0    0    0    0    0    0    0    0    0    0    0    0    0
    0    0    0    0    0    0    0    0    0    0    0    0    0    0
    0    0    0    0    0    0    0    0    0    0    0    0    0    0
    0    0    0    0    0    0    0    0    0    0    0    0    0    0
    0    0    0    0    0    0    0    0    0    0    0    0 1486    0
    0    0    0    0    0    0    0    0    0    0    0    0    0    0
    0    0    0    0    0    0    0    0    0    0    0    0    0    0
    0    0    0    0    0    0    0    0    0    0    0    0    0    0
    0    0    0    0    0    0    0    0    0    0    0    0    0    0
    0    0    0    0    0    0    0    0    0    0    0    0    0    0
    0    0    0    0    0    0    0    0    0    0    0    0    0    0
    0    0    0    0    0    0    0    0    0    0    0    0    0    0
    0    0    0    0    0    0    0    0    0    0    0    0    0    0]
[   4 1549    0    0 1557    0    0    0    0    0    0    0    0    0
    0    0    0    0    0    0    0    0    0    0    0    0    0    0
    0    0    0    0    0    0    0    0    0    0    0    0    0    0
    0    0    0    0    0    0    0    0    0    0    0    0    0    0
    0    0    0    0    0    0    0    0    0    0    0    0    0    0
    0    0    0    0    0    0    0    0    0    0    0    0 1565    0
    0    0    0    0    0    0    0    0    0    0    0    0    0    0
    0    0    0    0    0    0    0    0    0    0    0    0    0    0
    0    0    0    0    0    0    0    0    0    0    0    0    0    0
    0    0    0    0    0    0    0    0    0    0    0    0    0    0
    0    0    0    0    0    0    0    0    0    0    0    0    0    0
    0    0    0    0    0    0    0    0    0    0    0    0    0    0
    0    0    0    0    0    0    0    0    0    0    0    0    0    0
    0    0    0    0    0    0    0    0    0    0    0    0    0    0]

I think that there's additional material data being stored somewhere else. @rlagha, if I send over a result file can you check if DPF can see this material data?

[rlagha]

@akaszynski yes, I can do this for you.

[NDfp]

Hi Alex,
thank you for the feedback.
@pmaroneh comment might explain the reason for the "bonus" materials. (Unfortunately I cannot recheck the model as I currently do not have access to the office computer.)
However we still need either the properties of the bonus materials or a table connecting the bonus materials to the original ones.
It stays interesting :)

[NDfp]

@akaszynski FYI my office mail is not working. In case you need to contact me, please use github or my private email

[NDfp]

Hi,
Do you have any update on this issue?

[rlagha]

@NDfp Do you have Ansys 2022R2 install? if so you can try to get this data using pydpf.

[NDfp]

Unfortunately not. At the moment 2021R2.
If possible I would however prefer to stay in the pyansys environment; changing the whole code would be quite some work...

[NDfp]

Unfortunately at the moment I do not have 2022 (and I cannot install it since we have not yet fully recovered from a cyber attack).
@rlagha could you maybe test it for me? I can provide the model if Alex has not done so yet.
@akaszynski is there a chance of having the issue patched in pyansys?

[rlagha]

@NDfp , is your question to have the associativity between the elements and the materials? if so, the yes with DPF you can get this.

[NDfp]

@rlagha sounds great. Dos it work also with 2021R2?
Have you tried also with the model I sent Alex? Just to be sure.
Otherwise, could you help me on how to do it? I have tried to use DPF but so far with very little success.

[dpfbuild]

@NDfp I did this with a server based on 2022R1 unfortunately. If you have access to it, this is great, otherwise soon we will provide DPF as a standalone server.

[NDfp]

At the moment we are unfortunately still not able to install new software. The newest installed version is 2021R2

[mikerife]

Hi @NDfp @rlagha @akaszynski @pmaroneh Sorry I am coming so late to this discussion. NDfp I understand that you can't generally share the model, but can you tell us where it came from? Contact elements often have a material number used in the element properties definition, but no material model is defined for that material number ID. Mostly since the only material properties specific to contact elements are friction and wear coefficients.

If the model came from WB Mechanical, then each contact pair will have a unique material ID number associated with the contact/target elements. But no material model defined (unless frictional contact). Also WB Mechanical will create by default (in most cases) symmetric contact i.e. two contact pairs for each contact definition in the model where the contact/target side are swapped in the two pairs. This will result in two 'empty' materials in the model.

This type of model will definitely reproduce the behavior/listing as Alex showed with the following:

import numpy as np
from ansys.mapdl.reader import read_binary
rst = read_binary('file.rst')

rst.materials.keys()
np.unique(rst.mesh.material_type)

Where the last two items are different lists. If your model does have contact then the behavior seems correct to me.

Mike

[NDfp]

Hi Mike,
thank you for the suggestion and sorry for the delay.
I have passed the topic to my colleague Sven. He will get in touch with you.
Regards
Francesco

[germa89]

Hi @NDfp @mikerife

Is there any conclusion to bring to this issue? Can we close it? Do we need to implement anything in the reader?

[mikerife]

Hi @germa89 I don't think the reader needs anything - it is reporting exactly what is in the model. Mike

[germa89]

I'm closing this issue then. But if new related info appears, @nasdr and @NDfp feel free to reopen it or open a new one.

[mikerife]

Hi @nasdr Contact elements are not the only type that have material model capability but not always a reason to use a material model, and so could cause same behavior. For example surface effect elements. Some Joint elements. In WM Mechanical the 'Deformable' and 'Rigid' connection types for "Remote" type of objects are attached to the model via contact elements. As Joints can be. So there may be contact elements in the model and you may not know. Mike