Unexpected behavior when reading materials

[Николай Животенко]

Hello colleagues. I hope you feel well in this situation!

In the last few days, I have been using the FeResPost library and noticed an unusual behavior - after adding mechanical (MAT1) and thermophysical (MAT4) properties to the material, when reading the model, the iterator returns only the last ones specified in the *.dat file.

In other words, when describing several materials, Material_A (MAT1, MAT4), Material_B (MAT1, MAT4, ... MATn) and Material_C (MAT1), only 3 identifiers MAT4 from A, MATn from B, MAT1 from C, and so on will be written to the model. There may be more properties of materials. Is this correct behavior?

In fact, I could build a debug version of the library from the source code myself and try to test this case. Unfortunately on the current working machine I am working with .NET and rebuild the entire environment and rebuild the library for C++ will be very time-consuming for me. I would be very grateful if you can check this case. I attach the model file to the letter, I will specify a more detailed description below and attach screenshots.

Written by: Femap with NX Nastran

Version: 12.0.0

Translator: NX Nastran

Lib: FeResPost 4.5.7 (.NET)

Thank you in advance for your possible help.

[Николай Животенко]

[FeResPost]

Hi Niko,

This is an interesting observation. I checked FeResPost User Manual, MSC Nastran QRG and FeResPost source code...

When programming FeResPost, I assumed that each material is characterized by a unique MID. Therefore I use following C++ structure for the storage of materials in nastran::dataBase class :
            std::map<int,material> materials ;

This means that only one material with a given MID can be stored in the dataBase. Actually, Nastran allows using the same MID for some of the materials. This is the case for MAT4 type. There is no redundancy chek  by FeResPost and only the last read one is recorded in materials storage. This explains the behaviour you have observed.

I will have to solve this problem but it will take some time...

Remark however that only MAT1, MAT2, MAT8 and MAT9 are totally supported by FeResPost, and for these types of materials, the MID must be unique. This means that if your model contains only these four types of materials, you should have no strange behaviour. So, I suggest you remove the other "partially supported" materials from you model.

I have no better suggestion at the moment.

Renaud

[Николай Животенко]

Hi Renaud,

Thank you so much for such a quick check, it's super. I'm not currently using MAT4, just happened to notice. This can be a problem for other users, and if you have the opportunity to schedule such a fix - that's great!

I think at the first stage, you can try to simply replace std:: map with std:: multimap, this should not lead to a shot in the foot. Moreover, MID seems more essential to apply to the whole material, rather than to its parts MATn. And the use of specific material is left to the user's choice. That is, - MID will describe one material and will correspond to several characteristic categories (MATi, MATj,..., MATk) and the choice of a specific category is left to the user by its type (i, j, ..., k).

For my part, I would like to thank you for such an excellent library. Previously, I had to parse the model files myself. You make a useful product. If you need any additional help, please contact me. I have experience with geometric kernels-Parasolid, ACIS, RGK, and various CAE products.

воскресенье, 31 января 2021 г. в 17:47:49 UTC+3, FeResPost:

[FeResPost]

Hi Niko,

I developed a fix for the material iterator issue you have raised, but not by using multimap as you suggested.

But I realise I will have to fix other problems :

• Add a "fillCards" that can return several BDF cards sharing a common ID (for materials and MPC).
• "fillCard" throws an exception when the id argument corresponds to several cards.
• Better distinction between MPC and RBE.

This means that the behaviour of existing methods in NastranDB class will have to be modified. I intend to distribute a major revision, but it will take some time, probably several months...

I am happy to see that you appreciate FeResPost. Do not hesitate to promote it if you can.

Now, about your experience with geometry libraries, I do not really see an application for FeResPost which is devoted to FE post-processing. But I take note in case i have another use.

Regards,

Renaud

[Николай Животенко]

Hello Renaud,

Thank you so much for the information about the progress of the fixes! I will be very much waiting for new information from you. If you need my help, do not hesitate to contact me at any time.

With respect, Nikolay.

вс, 7 февр. 2021 г. в 11:08, FeResPost <r6ra.fe...@proximus.be>:

--
You received this message because you are subscribed to the Google Groups "FeResPost" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ferespost+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/ferespost/de6c215f-d6b2-4800-bbb4-82b563e9f947n%40googlegroups.com.

--

С уважением,

Николай Животенко.

[Николай Животенко]

Hello Renaud!
I hope you feel well. I wanted to clarify information on this issue. Have you made changes to new versions of the library? I address only with friendly interest.

воскресенье, 7 февраля 2021 г. в 13:46:40 UTC+3, Николай Животенко:

Nikolay Zhivotenko

[Steven Doyle]

Renaud,

Just as an Nastran FYI, MAT4/MAT5 are thermal materials and not structural materials.  For certain analyses (e.g., optimization with thermo cases and structural cases), they have to be duplicated because they’re referencing the same elements.

Steve

To view this discussion on the web visit https://groups.google.com/d/msgid/ferespost/5589f911-cd97-45ab-a2c1-b005701c628an%40googlegroups.com.

[FeResPost]

Hi Niko and Steve,

Niko,

I remember only vaguely what I did to fix the problems you identified last year. I just checked the sources and find in "NASTRAN/dataBase/dataBase.h" file the following lines for materials storage:

            std::map<int,int> u_materials ; // MAT1, MAT2, MAT3, MAT8 and MAT9

            std::map<std::pair<int,int>,material> p_materials ;

I also distinguishes the rbes and mpcs in "NASTRAN/dataBase/dataBase.h" :

            std::map<int,rbe> rbes ;
            ...
            std::multimap<int,mpc> mpcs ;

In the User Manual, I write: "Note that Nastran model may contain several material cards sharing a common ID, or several MPC cards with the same ID. When this case occurs, an exception is thrown. Therefore, for MPC or material cards, it is advised to use “fillCards” method instead of “fillCard”. An exception is also thown when no FEM item matching specified ID is found."

So it seems I did something to fix the problem. Note that MAT4, MAT5 and MAT11 are also  supported. I did a few tests to check the behaviour of the new solutions, but I do not track those. So I suggest that those who are interested make the tests themeslves and report their conclusions on the group.

Steve,

Indeed MAT4 and MAT5 are used for thermal calculations. Actually, for ALL the materials, the detailed properties generally do not matter. There is one exception: when material (mechanical or thermal) are scanned to define corresponding CLA material classes for composite calculations.

Regards,

Renaud

[Николай Животенко]

Hi!

Thank you so much for the work done, this was very much missed. I hope this will help not only me.

Regards, Niko.

пятница, 29 июля 2022 г. в 12:02:43 UTC+3, FeResPost: