-
-
Notifications
You must be signed in to change notification settings - Fork 157
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Coordinate transformation of stresses/strains using CSTM, TRMBU, TRMBD result tables #684
Comments
I should mention that I also edited the cstm_reader in pyNastran. It reads the CSTM table and directly stores the extracted values in an array instead of creating CORD2X cards. That allows me to directly retrieve the transformation matrices in the code above. The edited pyNastran file (op2_reader) is included in the zip-file of the previous comment. |
The CSTM is for the undeformed state. I think you need to use the TRMBD data. As far as I can tell, you're just referencing CSTM in the deformed calculation. I see you have a trmbu_example that calculates a transform based on the TRMBU Euler angles. Are you sure the Euler angle transform is ZYX? I would try and get the TRMBU data block (element based) to calculate the CSTM matrices (coord based). Once that's right swap out the TRMBU datablock with the TRMBD datablock. It's probably good to start with a model with simpler loading as well. |
Hi Steve, Thanks for explaining! I'm following your advice and have been experimenting on a single CHEXA-element that is rotated through time with a simple load case. In the pre-processor I can specify a rotated material coordinate system through three subsequent euler angles. I'm able to check that the CSTM table contains the rotation matrix produced by these three euler angles (R1 @ R2 @ R3).
Results
I'm also able to create the CSTM matrix from the euler angles provided in TRMBU if there's only one non-zero euler angle (example: eul1=45 deg, eul2=eul3=0). In case there are multiple non-zero euler angles, the angles that I retrieve from TRMBU are not equal to those provided in the pre-processor. I tried a brute-force method to find the correct euler combination, to see if it was possible to create the CSTM table through some other combination:
Results
That doesn't seem to work for the moment. I attached the test model to this comment in case you're interested. I'll keep you updated should some 'breakthrough' happen. :) Best regards, Ben |
Small note: I'm quite sure that the provided euler angles in TRMBU are for rotations about the X, Y and Z axis, respectively (and not ZXZ or anything else). If I use a single non-zero euler angle in the pre-processor, it always turns up in the TRMBU data as a single non-zero angle along the respective axis. |
ZXZ is definitely a possibility. I’d just try the n! case and I guess 2n!
if you include the transpose..
Can you attach a sample model. I want to go poke at the DMAP and see if
there’s anything obvious. You can add DIAG,14 after the SOL x to dump the
core code. It’s cryptic, but you can search for TRMBU and look at the code
around it and print certain matrices.
Also dumb question? Is there a specific theory guide for the solution?
Rotations seem like a really basic question.
…On Wed, Feb 16, 2022 at 3:31 AM ben.vanbavel ***@***.***> wrote:
Small note: I'm quite sure that the provided euler angles in TRMBU are for
rotations about the X, Y and Z axis, respectively (and not ZXZ or anything
else). If I use a single non-zero euler angle in the pre-processor, it
always turns up in the TRMBU data as a single non-zero angle along the
respective axis.
—
Reply to this email directly, view it on GitHub
<#684 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAICUWNPAXOJ3JNERT33DNTU3ODH3ANCNFSM5OHLMEKQ>
.
Triage notifications on the go with GitHub Mobile for iOS
<https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675>
or Android
<https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>.
You are receiving this because you commented.Message ID:
***@***.***>
|
Hi Steve, I think you might've missed my previous comment (unless I'm confused), there I elaborate a bit about brute-forcing all possible euler combinations. I also attached a small model to that comment (test.zip). I didn't try the trick with DIAG,14 yet. I'll definitely try that as well, thanks! From the documentation it seems the TRMBU/TRMBD tables were added as of NX Nastran 12 (in the NX Nastran Release Guide they're listed under the section 'new data blocks') but not much else that elaborates about the theory behind it. There's a user's guide for SOL 401/402, but it doesn't explain the TRMBU/TRMBD tables. I'll try searching more in depth this week and I'll let you know if I find anything! Best regards, Ben |
In addition to my last comment: Here's a copy of the previous test model (a single CHEXA8 element that rotates through time with a simple load), but with the DIAG,14 line added to the .dat file. I also included the output f06 and op2 files. It's indeed pretty cryptic, but I'll try looking for clues. |
Hi Steve, A small update: I believe TRMBU/TRMBD contains the data in the axis-angle representation instead of the classical XYZ euler angles. That would explain the difference in angles between the pre-processor and the TRMBU/D tables. I've been able to confirm that I can retrieve the same values as those in TRMBU/D that way. I still have to write a small example, but I'll share it once I have done so. Best regards, Ben |
That’s good news. The DMAP was cryptic even for DMAP. I was only ever
referenced in the restart, so I think it was called something else in the
main code.
I ran some tests and got a more general reader. To add a new element, you
just need the number of nodes. For a CQUAD8, obviously you use 4 nodes.
Just for future reference, it’s probably just a linear interpolation for
the mudslide nodes either before or after the rotations are applied (and
that question is probably not solvable without a one element problem cause
the values are going to be close unless your strains are very large).
…On Thu, Feb 17, 2022 at 5:29 AM ben.vanbavel ***@***.***> wrote:
Hi Steve,
A small update: I believe TRMBU/TRMBD contains the data in the axis-angle
representation instead of the classical XYZ euler angles. That would
explain the difference in angles between the pre-processor and the TRMBU/D
tables. I've been able to confirm that I can retrieve the same values as
those in TRMBU/D that way.
I still have to write a small example, but I'll share it once I have done
so.
Best regards,
Ben
—
Reply to this email directly, view it on GitHub
<#684 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAICUWIXZANKHI3NU7MLUVDU3TZ2FANCNFSM5OHLMEKQ>
.
Triage notifications on the go with GitHub Mobile for iOS
<https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675>
or Android
<https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>.
You are receiving this because you commented.Message ID:
***@***.***>
|
Hi Steve, Thanks! Here's a small example code that I hope might be of interest to you, and others that might stumble upon this issue in the future while working with the TRMBU/D tables. It shows how to transform the stresses of a single node of a single element from the output coordinate system to the basic/absolute coordinate system. Results were checked with the test model. The TRMBU/D data is indeed using the axis-angle representation, instead of three XYZ euler angles (as it's written somewhat confusingly in the documentation). In order to be complete, these are the edited pyNastran files (I'll use your more general reader in the future): Once again, a big thank you for all the help! Best regards, Ben
|
Hi Steve, I noticed that the code for TRMBD/TRMBU tables has been implemented in the op2 reader, but that it was still commented out (and hence these tables are not read by the op2 reader). I'll send a pull request soon that uncomments the code alongside some small changes. Hope it helps! |
Hello Steve,
I would like to thank you for your great work on pyNastran. It's a wonderful package.
I'm writing a python script that can convert OP2 results (stresses/strains) from the output coordinate system to other coordinate systems (basic or material). The software I use for pre-processing is Simcenter 3D.
versions in use:
My plan was to use the CSTM, TRMBU and TRMBD result tables from the OP2 file to create the necessary transformation matrices T and get the transformed stress results through matrix multiplication: S' = T @ S @ T^T. Simcenter's documentation mentions this about the tables:
There's some code added to pyNastran in order to read the TRMBU/D tables. I've attached the edited files to this issue. For now, I've been able to get the stress results in the absolute coordinate system for a linear solution by using the transformation matrices of CSTM, but not for a non-linear one (the results start out close, but diverge with increasing time step). In the attached zip file, I added a small example code which performs this transformation on a given op2 file. I also attached the op2 files that I used while testing. The code is copied below:
Results
Presumably the stresses' coordinate systems change in orientation through time, but I'm not sure what extra information we need in that case to perform the correct transformations. I wrote a similar post on Reddit, and your responses prompted me to post this issue here.
I would like to thank you for taking a look at this. If you'd need any extra information or files, I'd be happy to provide them!
Best regards,
Ben Van Bavel
coordinate_transformations.zip
The text was updated successfully, but these errors were encountered: