SteveDoyle2
commented
1 month ago Rob,
So a few things:
- The file is way to big to really sift though. It's really helpful to be able to see an entire table in order to find patterns. 3 time steps with 5 elements and say 7 nodes would be a lot easier to read.
- Fewer result tables would also help. There is at least OUGV1 (displacement), OESNLXR (nonlinear stress), and OQG1 (constraint forces) in this model.
- Tables count down, so -1/-2 are headers, -3/-4 are the step info and results respectively, -5/-6 are the next step/results, -7/-8 is another, then it jumps to -14, which is bizarre
Printing out 100 bytes of each subtable (e.g., the -6 block), shows 2304 words (e.g., int or float or 4 characters). 23044=9216 bytes, which is seen in the -6/results block. Then you see the -7 block (step info) with 146 words and 1464=584 bytes. What's weird about
DEBUG: op2_reader.py:3780 op2.isubtable = -6
ndata = 36: ints = (4, -6, 4, 4, 1, 4, 4, 0, 4)
ndata = 100: strings = (b'\x04\x00\x00\x00\x00\t\x00\x00\x04\x00\x00\x00\x00$\x00\x00\x0c\x00\x00\x00\x01\x00\x00\x00\xf4\x0fA\xbf^\xde\xcb\ xbd\x1c\x93\x95\xc4\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x16\x00\x00\x00\x01\x00\x00\x00\xb3\x13o\xbf\xfc\xb5\xc6\xbd!\xa7R\xc4\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00 \x00\x00\x00\x01\x00\x00\x00\xb7\x18\x8a\xbf\x0bu\xc0\xbd\xe2\x14\xc7\xc3',) ints = (4, 2304, 4, 9216, 12, 1, -1086255116, -1110712738, -996830436, 0, 0, 0, 22, 1, -1083239501, -1111050756, -1001216223, 0, 0, 0, 32, 1, -1081468745, -1111460597, -1010363166) floats = (5.605193857299268e-45, 3.2285916618043785e-42, 5.605193857299268e-45, 1.2914366647217514e-41, 1.6815581571897805e-44, 1.401298464324817e-45, -0.7541496753692627, -0.09954522550106049, -1196.59716796875, 0.0, 0.0, 0.0, 3.0828566215145976e-44, 1.401298464324817e-45, -0.9338943362236023, -0.09702679514884949, -842.6113891601562, 0.0, 0.0, 0.0, 4.484155085839415e-44, 1.401298464324817e-45, -1.0788792371749878, -0.09397324174642563, -398.16314697265625)
DEBUG: op2_reader.py:3780 op2.isubtable = -7
ndata = 36: ints = (4, -7, 4, 4, 1, 4, 4, 0, 4)
ndata = 100: strings = (b'\x04\x00\x00\x00\x92\x00\x00\x00\x04\x00\x00\x00H\x02\x00\x00>\x00\x00\x00\x01\x00\x00\x00\x00\x00\x00\x00\x01\x00 \x00\x00o\x12\x83:\x00\x00\x00\x00\x00\x00\x00\x00\x01\x00\x00\x00\x01\x00\x00\x00\x08\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x0 0\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00 \x00\x00\x00\x00',) ints = (4, 146, 4, 584, 62, 1, 0, 1, 981668463, 0, 0, 1, 1, 8, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0) floats = (5.605193857299268e-45, 2.045895757914233e-43, 5.605193857299268e-45, 8.183583031656932e-43, 8.688050478813866e-44, 1.401298464324817e-45, 0.0, 1.401298464324817e-45, 0.0010000000474974513, 0.0, 0.0, 1.401298464324817e-45, 1.401298464324817e-45, 1.1210387714598537e-44, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0)
The -14 block has the header which was read correctly (and confused the program). Then it has what seems like another result step. ints = (4, -14, 4, 4, 1, 4, 4, 0, 4, 4, 2304, 4, 9216, 12, 1, -1252647053, -1280278724, 956341138, 0, 0, 0, 22, 1, -1250251459, -1286870231, 967167523, 0, 0, 0, 32, 1, -1249024117, -1324139971, 973724625, 0, 0, 0,... floats = (5.605193857299268e-45, nan, 5.605193857299268e-45, 5.605193857299268e-45, 1.401298464324817e-45, 5.605193857299268e-45, 5.605193857299268e-45, 0.0, 5.605193857299268e-45, 5.605193857299268e-45, 3.2285916618043785e-42, 5.605193857299268e-45, 1.29 14366647217514e-41, 1.6815581571897805e-44, 1.401298464324817e-45, -7.97669770236098e-07, -8.218782454605389e-08, 0.00012264985707588494, 0.0, 0.0, 0.0, 3.0828566215145976e-44, 1.401298464324817e-45, -9.338435233985365e-07, -4.7478497577913004e-08, 0.0003162483626510948, 0.0, 0.0, 0.0, 4.484155085839415e-44, 1.401298464324817e-45, -1.0535453611737466e-06, -2.1424420015847545e-09, 0.0005258890450932086, 0.0, 0.0, 0.0,
From that (just picking the reasonable numbers; we split into 8 fields because it's a displacement result), gives: data = (4, -14, 4, 4, 1, 4, 4, 0, 4, 4, 2304, 4, 9216, 12, 1, -7.97669770236098e-07, -8.218782454605389e-08, 0.00012264985707588494, 0.0, 0.0, 0.0, 22, 1, -9.338435233985365e-07, -4.7478497577913004e-08, 0.0003162483626510948, 0.0, 0.0, 0.0, 32, 1, -1.0535453611737466e-06, -2.1424420015847545e-09, 0.0005258890450932086, 0.0, 0.0, 0.0, ...
Not sure why there is more result data without step info, but checking the f06 and testing a smaller problem makes sense. It might be the -7 goes with the -14 for some reason?
On Wed, Jul 17, 2024 at 9:17 AM rrothschild @.***> wrote:
Hey Steve,
Really appreciate all the work you do on this! I have been diving into PyNastran to try and get it compatible with reading an op2 using the Adina nastran version. I've had some luck by forcing PyNastran to read it as NX but it gets hung up pretty quick reading the data due to op2 structure.
I'm pretty new to binary files (sorry if I use the wrong lingo anywhere) but I think I've tracked it the markers that precede the data table and the wrong data blocks being read due to this.
I included some content I have together to trace the issue, would love some guidance if this is an easy update to make and just update some marker values somewhere. I've traced the issue to read_3_markers4 in op2_reader, not being able to align the markers it sees with what it expects, causing the error (FortranMarkerError).
I also Included the op2 I use to recreate the issue and the debug results that PyNastran produces for each.
I'll continue to chase this down and I'm looking forward to contributing to PyNastran in the future!
Thanks, Rob
PyNastran_Adina_Error.png (view on web) https://github.com/user-attachments/assets/e711f135-d368-41cf-b4f2-65e69d917bd4 PyNastran_Adina_Op2Markers.png (view on web) https://github.com/user-attachments/assets/43ba41f8-f7c7-4b87-866b-4a8896aee986 dubugOutput_Adina.txt https://github.com/user-attachments/files/16269401/dubugOutput_Adina.txt DirectTransient-Adina.zip https://github.com/user-attachments/files/16269422/DirectTransient-Adina.zip
— Reply to this email directly, view it on GitHub https://github.com/SteveDoyle2/pyNastran/issues/794, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAICUWI3ZJWA3CRVQSYRLDLZM2KJDAVCNFSM6AAAAABLA6ZCACVHI2DSMVQWIX3LMV43ASLTON2WKOZSGQYTIMBTGA2TMNA . You are receiving this because you are subscribed to this thread.Message ID: @.***>
rrothschild
Hey Steve,
Really appreciate all the work you do on this! I have been diving into PyNastran to try and get it compatible with reading an op2 using the Adina nastran version. I've had some luck by forcing PyNastran to read it as NX but it gets hung up pretty quick reading the data due to op2 structure.
I'm pretty new to binary files (sorry if I use the wrong lingo anywhere) but I think I've tracked it the markers that precede the data table and the wrong data blocks being read due to this.
I included some content I have together to trace the issue, would love some guidance if this is an easy update to make and just update some marker values somewhere. I've traced the issue to read_3_markers4 in op2_reader, not being able to align the markers it sees with what it expects, causing the error (FortranMarkerError).
I also Included the op2 I use to recreate the issue and the debug results that PyNastran produces for each.
I'll continue to chase this down and I'm looking forward to contributing to PyNastran in the future!
Thanks, Rob
dubugOutput_Adina.txt
DirectTransient-Adina.zip