pyNastran
pyNastran copied to clipboard
SteveDoyle2
read_op2 speed
I've written a short script to read CQUAD4 stresses from a sine vibration run (SOL SEMFREQ). I started with the iSat model since it's provided as an example. I've requested quite a bit of frequency data, but not unreasonable (my output is ~1000 frequencies and ~7700 elements).
It's taking about 2 min to read the op2, which doesn't seem wild to me, but is longer than I expected based on other comments. The op2 is only 263MB. I'm just using read_op2(op2_filename, debug=False).
Any ideas? I can post to the user discussion if you think that's more appropriate.
That data object is not vectorized, so it's slow. If you turn debug on, you'll see lots of messages about that. The OESVM1 support is still new.
Vectorization helps large data blocks the most. 7000 elements will have a much smaller data block vs a data block with 100,000 nodal displacements, so it's less efficient. The high number of frequencies also means that you have to reread the table #3 many times to get the data (vs. say a single frequency step).
On Tue, Oct 8, 2019 at 5:02 PM m-griebel [email protected] wrote:
I've written a short script to read CQUAD4 stresses from a sine vibration run (SOL SEMFREQ). I started with the iSat model since it's provided as an example. I've requested quite a bit of frequency data, but not unreasonable (my output is ~1000 frequencies and ~7700 elements).
It's taking about 2 min to read the op2, which doesn't seem wild to me, but is longer than I expected based on other comments. The op2 is only 263MB. I'm just using read_op2(op2_filename, debug=False).
Any ideas? I can post to the user discussion if you think that's more appropriate.
— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/SteveDoyle2/pyNastran/issues/572?email_source=notifications&email_token=AAICUWK3SZTVXHAEMH37RJLQNUNRZA5CNFSM4I6YODHKYY3PNVWWK3TUL52HS4DFUVEXG43VMWVGG33NNVSW45C7NFSM4HQPSZSQ, or mute the thread https://github.com/notifications/unsubscribe-auth/AAICUWNJE6JPOZR23NN7S3DQNUNRZANCNFSM4I6YODHA .
Fair enough. I figured it was a newer feature. Definitely helpful. I see you're already grabbing von mises stress (it's labeled maxshr, but I assume that's just a copy/paste), any plan to write that to the OP2 in the future instead of just directional stresses?
oohh...
It looks like I missed the von Mises part of OESVM1. The first part of the NX complex table (OESVM1) is the same as MSC's table, so the first 3 terms are correct (oxx, oyy, txy), but the von Mises was dropped.
I thought about just adding it, but I'm not familiar enough with the implications yet.
I've already got most of it.
The ComplexPlateArray class and RandomPlateArray should both have a property has_von_mises. The flag is based on the table name (e.g., OESVM1 has von mises, but OES1X does not). That way it works for MSC and NX and noone is the wiser.
I really just need the table list and that requires running ~10,000 examples.
Still slow (and probably missed some strain tables), but at least von Mises stress exists now.