Error Parsing a SOL 144 OP2

[David Sztajnbok]

Hello Steven,

My name is David and I'm an aerospace engineering student. First of all, thank you so much for the incredible piece of code that is pyNastran!

I encountered an error that I figured I'd share here: I am trying to generate shear-moment-torque diagrams from results of a SOL 144 run with rigid body trim enabled. However, I get thrown the following error code:

NotImplementedError: (12, 101, 0)

I did some (albeit shallow) digging and this is what I found so far: the error comes from an attempt to read the Data Block OAEROTV (table 5.17 in the DMAP Programmer's Guide, page 5-37). I tried setting the argument:

skip_undefined_matrices=True

In read_op2(). That did not solve the problem. I dug some more and found that on lines 2195/2196 in op2_scalar.py, under the _read_tables() function, this is called:

elif self.skip_undefined_matrices:

   read_matrix(op2_reader, table_name)

And it is read_matrix() that calls read_matrix_matpool() that itself calls read_matpool_results() where the error is thrown:

    elif code == (2014, 20, 243):

        # C:\NASA\m4\formats\git\examples\pyNastran_examples\demo_sort2_post_m2\hd15306.op2

        op2_reader.log.warning('  skipping MATPOOL-RADLST')

    elif code == (9614, 96, 0):

        # some axisymmetric matrix

        read_matpool_bndfl(op2_reader, op2, data, utable_name, debug=False)

    else:

        print(f'  code = {code}')

        op2_reader.show_data(data, types='ifs', endian=None, force=False)

        raise NotImplementedError(code)

Do you have any ideas of how to approach this? Is there any other argument I have to pass or some way of handling these unknown tables? And out of curiosity, why is read_matrix() called if self.skip_undefined_matrices is True?

I put together a toy problem here. The Drive link includes the bulk data file, OP2, and F06, as well as code that throws the same error I'm seeing.

Thank you and sorry if I'm missing something here!

Best regards,

David Moeller Sztajnbok

[Steven Doyle]

David;

The table skipping code doesn’t work for the OAEROTV table because there’s some nonstandard short circuiting going on. If you use the latest dev version, it should work. I didnt get to the new release last weekend, but it’s close..

--
You received this message because you are subscribed to the Google Groups "pyNastran Discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to pynastran-disc...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/pynastran-discuss/16da8197-0f19-4e25-8a86-5c754bc3a0a9n%40googlegroups.com.

[David Sztajnbok]

Hello Steven,

Wonderful, thank you so much! I just pip installed it from the source under the main branch and it works great - commenting out some trim tables that are giving me trouble skips them without a problem, and I'm able to read the OP2. Looking forward to the new release!

About the troublesome trim tables: this is probably low on your priority list but I'll leave it here either way: I believe OAEROHMD is being read with a slightly incorrect order, at least for Simcenter NASTRAN which is what I have access to. Please do correct me if I'm wrong (I'm a student and therefore quite new to pyNastran and for that matter NASTRAN in general) but OAEROHMD is throwing me an AssertionError here (lines 5322-5326 in op2_reader.py):

allowed = [

    (1, 1),

    (1, 0),

]

assert (one_a, one_b) in allowed, f'Allowed={allowed}; actual=({one_a:d} ,{one_b:d})'

And the outputs of the table are in the following order (lines 5307-5310 in op2_reader.py):

(acode, tcode, method_int, subcase_id,

point_device, mach, q, aerosg2d_bytes, numwide, symxy, symxz,

cs_name_bytes, one_a, one_b, *outi,

title, subtitle, subcase) = out

However, this is the OAEROHMD table from Simcenter's DMAP QRG:

 

So is it not the case that after symxy and symxz we expect the reference chord, span, and area would be there instead of cs_name_bytes, one_a, and one_b? It also does seem that some of the outputs to the log.debug that I'm seeing indicate that the order of outputs is slightly off. Additionally, later in the same file the following lines are present:

chord = 0.

span = 0.

sref = 0.

derivs = HingeMomentDerivatives(

    mach, q, chord, span, sref,

    cs_name, names, values, subcase=subcase_id,

    title=title, subtitle=subtitle, label=label)

Overwriting the chord, span, and Sref.

Just wanted to check if this is on purpose, or perhaps due to an NX vs MSC NASTRAN issue. Either way, if I comment the table name in the mapping dictionary, table skipping works just fine so not a big issue.

Thank you once again for the awesome codebase!

Best,

David 

[Steven Doyle]

Yeah unfortunately that’s on purpose. The DMAP guide is incorrect. I assume they updated the output a couple years ago, but never updated the manual. I haven’t collected enough cases to totally know what they’re doing.

To view this discussion visit https://groups.google.com/d/msgid/pynastran-discuss/81ad9835-ea07-4812-bd98-f17d9fa00472n%40googlegroups.com.

[David Sztajnbok]

Gotcha, interesting!

Thanks again for the help!