Nodal stresses in CTRIA3 type elements

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

Hello everybody,

I would like to discuss with you the applied task of obtaining normal and tangential stresses (in the global coordinate system) at the nodes of CTRIA3 elements.

I have a model file (.dat) and a results file (.op2 and .xdb), which I got from NX/Nastran. The model consists of quadrangular elements CQUAD4 and triangular elements CTRIA3. After static analysis, the results were written to a file. Moreover, in elements of the CQUAD4 type, the stresses in the nodes are explicitly exported. In elements of type CTRIA3, only displacements are exported. When uploading the results from a file to the Femap pre-/post processor, I observe a stress fields, it looks like the postprocessor did all the dirty work for us. But a question arose. Are there ready-made functions in the FeResPost library for calculating: displacements -> strains -> stresses?

I attach test files of the model and results. For example, node 87.

Do I understand correctly that FeResPost just copies .op2 and the getResultCopy(...) function it will just return everything that is in it, and nothing that is missing there? :)

If I start implementing this functionality on my own, do not hesitate to advise me how to do it more optimally. Perhaps you can advise me on any modules in FeResPost, if they exist.

All the best to you!

[FeResPost]

Hello Niko,

The issue is very probably related to the fact that Nastran produces stresses and strains  only at element center for CTRIA3 elements. For CQUAD4, stresses and strains are produced at element center and corners. If you ask stresses at element corners (ElemCorners or ElemNodes options) with getResultCopy, you obtain nothing for the CTRIA3 elements.

Please, have a look to the output of the attached ruby script, it clarifies the problem. The output for a CQUAD4 looks as follows:

                58      NONE        Z2      NONE    elemCS      -24.2421      -7.63334             0       30.7364             0             0
                58      NONE        Z1      NONE    elemCS      -24.2421      -7.63334             0       30.7364             0             0
                58        27        Z2      NONE    elemCS      -19.3802      -4.72847             0       30.3991             0             0
                58        27        Z1      NONE    elemCS      -19.3802      -4.72847             0       30.3991             0             0
                58        28        Z2      NONE    elemCS      -19.3007      -10.5409             0       30.6738             0             0
                58        28        Z1      NONE    elemCS      -19.3007      -10.5409             0       30.6738             0             0
                58        49        Z2      NONE    elemCS      -29.3808      -10.8963             0       31.1022             0             0
                58        49        Z1      NONE    elemCS      -29.3808      -10.8963             0       31.1022             0             0
                58        71        Z2      NONE    elemCS      -29.2731      -4.40644             0       30.7874             0             0
                58        71        Z1      NONE    elemCS      -29.2731      -4.40644             0       30.7874             0             0

For a CTRIA3, you only have this:

                59      NONE        Z2      NONE    elemCS       59.7547       187.778             0       97.7334             0             0
                59      NONE        Z1      NONE    elemCS       59.7547       187.778             0       97.7334             0             0

When you think about it, it makes sense: shape functions on triangular elements are linear (a plane is defined by three points), and displacement gradiants are constant on CTRIA3 elements. On the other hand, CTRIA6 elements also have corner stress values.

You should check the options you are using when displaying with NX. (You probably extrapolate/average element stress at nodes.)

Note also that FeResPost:

• Directly reads Stress/Strain results from Nastran output files. (One does not calculate displacement gradients.)
• Allows the remapping of results: from center to corners, or from corners to all element nodes... (See the different "FromTo" options of "deriveByRemapping" method.

Regards,

Renaud

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

Renaud thank you very much for such a quick response.

I'll see what I can do with the methods you suggested.
Please tell me if I can include your ruby-scripts in my opensource repository for quick "debugging" of models?

Regards, Niko.

пт, 29 июл. 2022 г. в 12:34, FeResPost <r6ra.fe...@proximus.be>:

--
You received this message because you are subscribed to a topic in the Google Groups "FeResPost" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/ferespost/rPXn4ycodWQ/unsubscribe.
To unsubscribe from this group and all its topics, send an email to ferespost+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/ferespost/8d01e2cc-a3ea-42eb-8f4e-4694db8f6eebn%40googlegroups.com.

--

С уважением,

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

[Renaud Sizaire]

Niko,

Of course, you can re-distribute the ruby scripts I sent you.

Renaud

Le 29-07-22 à 15:39, Николай Животенко a écrit :

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/CA%2BYrWr_oPdFvGyU4qctjNWa1yKyyPzyo8WtiBETGYSYWHCNXGw%40mail.gmail.com.

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

Renaud,

on your advice, I'm calling the deriveByRemapping method with the parameters "CentersToElemsAndNodes" and "average" from my dotNET app.

The fail occurs in the file deriveMethods.cpp, since the getMethod(...)can't find the mapping to method.

I also checked initMethodMappings() and clearly see "remap_fromTo_CentersToElemsAndNodes".

Could it be that the string passed from C# is not equal to the string in C++ because of the difference in encoding?

This is strange, because all other functions with passing string parameters work fine.

I can't test this under the debugger because the project is being built with a ready-made FeResPost dll.

пятница, 29 июля 2022 г. в 16:45:37 UTC+3, FeResPost:

[FeResPost]

Niko,

I see nothing wrong in your call to "deriveByRemapping". You should replace the remapping method "average" by "NONE", but it does not really matter in this case and does not explain the problem.

The difference of string encoding encoding is a plausible explanation. In the past, I have seen problems with people working with different character sets, but it was not related to string encoding. They had non-standard characters in file names (chinese or spanish). As you say, if it is the only string that causes problems, there might be another explanation than character encoding.

Did you try to use the variables "strFromToMethod" and "strRemappingMethod" instead of the litterals when calling deriveByRemapping? Make sure you are using proper string to call the methods. You could also try the "CentersToCorners" remapping, but this should not solve your problem.

The best way to investigate this kind of problem is to recompile the library and add intermediate write statement and perform comparisons (for example in deriveByRemapping method). I suggest you try to do that because I am not sure I can reproduce the bug.

I testsed with ruby to make sure that the "CentersToElemsAndNodes" method works. I will try later with .NET, but as I said, I am not sure that I can reproduce your bug.

Regards,

Renaud

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

Renaud,

I tried using enumerations converted to strings and also got an error.

I've been trying to build FeResPost from sources all morning and got stuck on the problem - the compiler version. Somehow I solved this problem, but I got an even bigger one - a problem with Ruby. It turned out to be non-trivial for me.

I have a suggestion that can simplify the situation for both you and me. During the assembly dotnet debug version, the compiler will generate a *.pdb file (storing debugging information about a library). You can send me 3 files - dll, manifest and pdb. I will be able to check the situation with strings under debugger mode.

Regards, Niko.

сб, 30 июл. 2022 г. в 09:16, FeResPost <r6ra.fe...@proximus.be>:

--
You received this message because you are subscribed to a topic in the Google Groups "FeResPost" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/ferespost/rPXn4ycodWQ/unsubscribe.
To unsubscribe from this group and all its topics, send an email to ferespost+...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/ferespost/f32aaf4c-3780-453f-a095-c3dc041cca03n%40googlegroups.com.

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

Renaud,

I solved the problem.

The user manual states the parameters are as follows: "FromTo", "Method", "DB".

The implementation in C++ also follows the order.

But in the dotNET assembly, the parameters are reversed - "Method", "FromTo", "DB".

I used the strings according to the documentation. When coding, I was hoping for documentation and didn't pay attention to the IDE prompt.

deriveByRemapping(const string &sFromTo, const string &sMethod, const dataBase &DB, result &toRes)
deriveByRemapping(string Method, string FromTo, DataBase DB)

сб, 30 июл. 2022 г. в 17:22, Николай Животенко <niko...@gmail.com>:

[FeResPost]

Niko,

You have found the explanation. It is a bug in FeResPost .NET assembly because the order of parameters should be as explained in User Manual. I checked ruby, python and COM libraries and those are in line with manual.

So in next version, parameters "Method" and "FromTo" will be swapped. (Version 5.0.3 should be available around August 15th.)

Thank you for the information and your help in debugging FeResPost.

Renaud

[FeResPost]

Niko,

I just shared new.NET assembles with a fix for the deriveByRemapping method. They are available in " DOWNLOADS/LATEST_DEV/20220730".

I hope it helps you.

Renaud

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

Renaud ,

Thank you for such a prompt response. But there was no need to worry, I would have waited for the new version. Thanks anyway.

Have you ever thought about changing the types of transmitted values from string to enumeration?

I also note that I have some doubts about the case-insensitivity of the parameters, which means that any typo "min" -> "Min"/"MIN" will lead to a crash.

A purely friendly note. :)

суббота, 30 июля 2022 г. в 19:08:21 UTC+3, FeResPost:

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

Hello Renaud!

I'm experimenting with different methods of remapping results and noticed one feature.
When calling remapping with the “CentersToElemsAndNodes” parameter, I expect to find both node values and element-averaged values in the resulting array. But I get only nodal values.

FeResPost Manual:
“CentersToElemsAndNodes”: one selects all the values at center of elements (i.e. the key of which has an elemId, but no nodeId), then one produce a new Result object with values associated to the corners and edges of those elements.

For example, I take "the very ill-fated model-000" for which there is a *.op2/*.xdb file with the results centered on the elements. FeResPost do a remapping and I lose all the element values, but get all nodal values.
Is this correct behavior? According to the description, yes, but the name says the opposite, that the element values will remain.

Regards, Niko.

суббота, 30 июля 2022 г. в 19:21:12 UTC+3, Николай Животенко:

[FeResPost]

Hello Niko,

I think the remapping works as explained in the manual. It must extrapolate the element center values to elment and nodes, which means to produce keys with a positive integer element ID and a positive integer node ID. The names of the extrapolated methods correspond to the type of source and destination keys. Table I.4.6 gives a clear summary of the different methods.

Regards,

Renaud