search

SteveDoyle2 / pyNastran

A Python-based interface tool for Nastran's file formats
Other
396 stars 154 forks source link

Some data from OP2 in random analysis not shown #518

Open AlejandroStewart opened 6 years ago

AlejandroStewart commented 6 years ago

For random analysis when PSDF,CRMS and RMS are requested only the following data is available:

image

Apparently only the stress data is filled although all is requested and printed in f06. image

Is it related to https://github.com/SteveDoyle2/pyNastran/issues/295? or should already be working?

Alejandro

SteveDoyle2 commented 6 years ago

295 is related to the PSDF table not being supported. I closed it because there was no example after a long period of time.

Random results are definitely better now than they were back then, but it's still not a solution I use very frequently, so there are still issues to work through. Random stresses show up in tables like OESRMS1, OESNO1, OESPSD1, OESCRM1, and OESATO1.

However, this one seems at least easier. It looks like Nastran doesn't like:

STRESS(PLOT,RALL,PRINT)=ALL

and instead wants IMAG/PHASE to actually output the table to the OP2:

STRESS(PLOT,RALL,PRINT,IMAG)=ALL
STRESS(PLOT,RALL,PRINT,PHASE)=ALL

However, that still leaves another problem of the SORT1 vs. SORT2. Regardless, of if I use SORT1 or not, I get the data outputting in SORT2 form, which is not supported. I'm using MSC 2005, so maybe that's why.

So if you're data is in SORT1, it should work.

AlejandroStewart commented 6 years ago

I haven't had time to run this, but i made a check on the f06 couple if days ago and there was no difference between sort1 and sort2. It may be also because I was not using IMAG or PHASE Keys.

SteveDoyle2 commented 6 years ago

You can definitely see which OP2 tables get written out in the F06. You sometimes have to play around with silly flags (e.g., PARAM,POST,-1 vs. -2 or PARAM,POSTEXT,YES), but sometimes Nastran is just weird.

Here's an example where if you don't call out stress, you get the force results in SORT1, but if you put the stress in there, the force flips to SORT2 despite requesting SORT1. I didn't even know this was a thing until now. Nastran is weird.

random_test_bar_plus_tri.txt

SteveDoyle2 commented 6 years ago

I looked a bit deeper into the missing data. It looked like the data was being read, but it was actually just being skipped. I have random SORT2 working for CBARs, but there are some issues with the element ids being pulled incorrectly. What I might do for now is say just don't grab the element ids from the random stresses/strains. What elements do you actually care about?

Additionally, there's this whole complexity for OESNO2 and OESRMS2 that they're not actually in SORT1 format despite the flags saying they're in SORT2. It'll take some time to get all the bugs with that worked out.

AlejandroStewart commented 6 years ago

Ideally..... All the usual suspects, CBAR,ROD,BEAM,TRIA3,QUAD4,HEXA,PENTA,TETRA.... BUSH But I am mainly interested in RMS to be honest. Such complex analysis for such short data! OESRMS1 is my table.

So far I have been extracting this data with complex setups that involved ad-hoc version dependent dmaps to avoid having to deal with crazy big f06 (I´d usually even run out of lines and get a FATAL error despite the MAXLINES and NLINES setup without this dmap). And that is not a very elegant approach.

SteveDoyle2 commented 6 years ago

I added quite a bit to the stress/strain random capability this weekend. It's all MSC-based for now (NX random is frequently different). It'll do ATO/autocorrelation CRM/cumulative RMS, and PSD.

RMS and NO/number of crossings are harder for some reason. It's fine for SORT1, but is a mess for SORT2 despite using the same code as the ATO/CRM/PSD data. I'm not clear on how to interpret a static (analysis code=1) SORT2 table. I think Nastran just lies for those tables. There's also some inconsistency with how MSC vs NX handles these tables.

On Mon, Jul 2, 2018, 12:15 AM Alejandro Stewart notifications@github.com wrote:

Ideally..... All the usual suspects, CBAR,ROD,BEAM,TRIA3,QUAD4,HEXA,PENTA,TETRA.... BUSH But I am mainly interested in RMS to be honest. Such complex analysis for such short data! OESRMS1 is my table.

So far I have been extracting this data with complex setups that involved ad-hoc version dependent dmaps to avoid having to deal with crazy big f06 (I´d usually even run out of lines and get a FATAL error despite the MAXLINES and NLINES setup without this dmap). And that is not a very elegant approach.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/SteveDoyle2/pyNastran/issues/518#issuecomment-401693412, or mute the thread https://github.com/notifications/unsubscribe-auth/ABAqWYay9xMTzhiHi_8TdSxWsHy2lrhkks5uCcingaJpZM4U5fL3 .

SteveDoyle2 commented 6 years ago

It looks like there's an issue with Nastran not writing the tables correctly for large tables.

SteveDoyle2 commented 5 years ago

I forget if that's an MSC or NX issue ,but I think it was with MSC. If I recall correctly, the static (RMS/NO) table ends up being split in a weird way. Whichever one is sane just works, so the MSC/NX flag will finally have a purpose vs. just try-excepting things like I've been doing in the geometry reader.

SteveDoyle2 commented 5 years ago

To be clear, the RMS and NO (number of crossings) tables are static because they're actually partner tables (e.g., the RMS stress at a frequency of the "NO stress" (it's really a frequency) value for each element id.