pyNastran
pyNastran copied to clipboard
SteveDoyle2
MSC Nastran 2012 double writes stress table
Hi!
When I try to load results from an op2 file, I get the following error:
ERROR: oes.py:897 stress_mapper (~line 850 of oes.py) does not contain the following key and must be added
key=(element_type=64, format_code=3, num_wide=77, table_name='OES1')
.
.
.
KeyError: (64, 3, 77, 'OES1')
I then add the following line to oes.py:588
(64, 3, 77, b'OES1') : ('cquad8_stress', ComplexPlateStressArray), # mag/phase
Now I get this error instead:
{u'subtitle': u'', u'stress_bits': [0, 0, 0, 0, 0], u'load_set': 15000, u'thermal': 0, u's_code': 0, u'sort_bits': [0, 0, 1], u'isubcase': 1, u'element_name': u'CQUAD8', u'nonlinear_factor': 25.0, u'title': u'VEP4HP X0 AWG45, FL, FORCED RESPONSE CALCULATION.', u'approach_code': 52, u'is_stress_flag': True, u'label': u'1.5:TH ORDER EXCITATIONS, FL. SUBCASE 1', u'table_name': u'OES1X', u'num_wide': 77, u'format_code': 3, u'device_code': 2, u'superelement_adaptivity_index': u'', u'_times_dtype': u'float32', u'thermal_bits': [0, 0, 0, 0, 0], u'freq': 25.0, u'is_strain_flag': False, u'sort_method': 1, u'name': u'freq', u'analysis_code': 5, u'table_code': 5, u'element_type': 64, u'is_msc': True, u'tCode': 1005, u'sort_code': 1, u'data_names': [u'freq']}
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
File "pyNastran/op2/op2.py", line 108, in read_op2
encoding=encoding)
File "pyNastran/op2/op2.py", line 545, in read_op2
OP2_Scalar.read_op2(self, op2_filename=op2_filename)
File "pyNastran/op2/op2_interface/op2_scalar.py", line 1330, in read_op2
table_names = self._read_tables(table_name)
File "pyNastran/op2/op2_interface/op2_scalar.py", line 1588, in _read_tables
self._read_results_table()
File "pyNastran/op2/op2_interface/op2_scalar.py", line 1976, in _read_results_table
self._read_subtables()
File "pyNastran/op2/fortran_format.py", line 455, in _read_subtables
self._read_subtable_3_4(table3_parser, table4_parser, passer)
File "pyNastran/op2/fortran_format.py", line 527, in _read_subtable_3_4
n = self._read_subtable_results(table4_parser, record_len)
File "pyNastran/op2/fortran_format.py", line 654, in _read_subtable_results
n = table4_parser(data, ndata)
File "pyNastran/op2/tables/oes_stressStrain/oes.py", line 240, in _read_oes1_4
n = self._read_oes1_4_sort1(data, ndata)
File "pyNastran/op2/tables/oes_stressStrain/oes.py", line 417, in _read_oes1_4_sort1
n = self._read_oes1_loads(data, ndata)
File "pyNastran/op2/tables/oes_stressStrain/oes.py", line 1023, in _read_oes1_loads
n, nelements, ntotal = self._oes_cquad4_144(data, ndata, dt, is_magnitude_phase, stress_name)
File "pyNastran/op2/tables/oes_stressStrain/oes.py", line 3416, in _oes_cquad4_144
nelements, result_name, slot, obj_vector_complex)
File "pyNastran/op2/op2_interface/op2_common.py", line 1905, in _create_oes_object4
self.create_transient_object(slot, obj_vector)
File "pyNastran/op2/op2_interface/op2_common.py", line 1386, in create_transient_object
self.obj.update_data_code(copy.deepcopy(self.data_code))
File "pyNastran/op2/result_objects/op2_objects.py", line 429, in update_data_code
self.apply_data_code() # take all the parameters in data_code and make them attributes of the class
File "pyNastran/op2/result_objects/op2_objects.py", line 356, in apply_data_code
raise RuntimeError(msg)
RuntimeError: old_table_name=u'OES1' new_table_name=u'OES1X'
Btw, thanks for a great piece of software!
Thanks! Glad you like it!
The stress mapper thing that you fixed looks correct.
The other issue is not related and can happen when you put xy plots into the op2, but also can happen for (I think) certain hyperelastic materials.
If you make a small test problem I could tell you a bit better.
The program is simply:
from pyNastran.op2.op2 import read_op2
filename = "/home/carl/data/freq_VEP4G3AWG45_X0_fl_eo15_170705.op2"
op2 = read_op2(filename, build_dataframe=True, debug=True)
The op2 file I use in the above example is very large and classified, however, for creating output I use
STRESS(plot) = 1
DISP(plot) = 1
Set 1 is a set of CQUAD8. As far as I can tell, the material is linearily elastic.
I need a small example (e.g., a flat plate) that demonstrates the problem or there's nothing I can do.
On Mon, Apr 16, 2018, 1:41 AM CarlSandstrom [email protected] wrote:
The program is simply:
from pyNastran.op2.op2 import read_op2 filename = "/home/carl/data/freq_VEP4G3AWG45_X0_fl_eo15_170705.op2" op2 = read_op2(filename, build_dataframe=True, debug=True)
The op2 file I use in the above example is very large and classified, however, for creating output I use
STRESS(plot) = 1 DISP(plot) = 1
Set 1 is a set of CQUAD8.
— You are receiving this because you commented.
Reply to this email directly, view it on GitHub https://github.com/SteveDoyle2/pyNastran/issues/501#issuecomment-381523944, or mute the thread https://github.com/notifications/unsubscribe-auth/ABAqWWZr20pRvOLTKrKw2Um3Ubmxg-Djks5tpFkygaJpZM4TS6mH .
Closing due to innactivity and insufficient info for an action to be taken.
I am facing the same issue here, just in case it may help I attach my patched lines for oes.py and a small zipped model
Thank you.
(102, 2, 13, b'OESVM1') : ('cbush', 'NA'),
(102, 2, 13, b'OES1'): ('cbush', 'NA'),#ASF
(102, 2, 13, b'OES1X'): ('cbush', 'NA'), # ASF
(39, 2, 74, 'OESVM1') : ('ctetra', 'NA'),
(67, 2, 130, b'OESVM1') : ('chexa', 'NA'),
(67, 2, 121, b'OES1'): ('chexa', 'NA'),#ASF
(67, 2, 121, b'OES1X'): ('chexa', 'NA'), # ASF
(68, 2, 102, b'OESVM1') : ('cpenta', 'NA'),
(68, 2, 95, b'OES1'): ('cpenta', 'NA'),#ASF
(68, 2, 95, b'OES1X'): ('cpenta', 'NA'), # ASF
Your model should hopefully work now (I also threw in CTETRA and results extraction). I'm probably running a different version of Nastran and don't have your OP2, so I'm not 100%.
The shells from before are still an issue.
Steve
On Tue, Jun 26, 2018 at 7:05 AM AlejandroStewart [email protected] wrote:
I am facing the same issue here, just in case it may help I attach my patched lines for oes.py and a small zipped model
Thank you.
(102, 2, 13, b'OESVM1') : ('cbush', 'NA'), (102, 2, 13, b'OES1'): ('cbush', 'NA'),#ASF (102, 2, 13, b'OES1X'): ('cbush', 'NA'), # ASF (39, 2, 74, 'OESVM1') : ('ctetra', 'NA'), (67, 2, 130, b'OESVM1') : ('chexa', 'NA'), (67, 2, 121, b'OES1'): ('chexa', 'NA'),#ASF (67, 2, 121, b'OES1X'): ('chexa', 'NA'), # ASF (68, 2, 102, b'OESVM1') : ('cpenta', 'NA'), (68, 2, 95, b'OES1'): ('cpenta', 'NA'),#ASF (68, 2, 95, b'OES1X'): ('cpenta', 'NA'), # ASFmini_rnadom.zip https://github.com/SteveDoyle2/pyNastran/files/2137468/mini_rnadom.zip
— You are receiving this because you modified the open/close state. Reply to this email directly, view it on GitHub https://github.com/SteveDoyle2/pyNastran/issues/501#issuecomment-400321364, or mute the thread https://github.com/notifications/unsubscribe-auth/ABAqWeEqTXFeAXZPjw3KNzLSNfk-00caks5uAj-_gaJpZM4TS6mH .
Hi Steve, thank you for your answer.
The problem is still there. I am using Nastran 2012.2.
I have tried with 2008 and it works. Apparently there is a table named OES1X that conflict with OES1 that does not exist in nast2008 op2. (left 2008, right 2012)
judging by the table description in the f06 for 2012 version it seems both are identical. (OES1 vs OES1X )
According to DMAP guide :
I have digged in the f04 and SDRXD is called in both versions:
May it be interesting to consider OES1X when availble as it consideres PLOAD1 and CBARAO?
In my previous example there is no difference as I do not have any of the 1D elements afected.
I upload an updated op2 for a model with a CBAR and CBARAO. though I see no difference in table size (OES1 vs OES1X ):
(left 2008 right 2012)
PS: in order to make it run with 2008 I have had to add line 546 is oes.py:
Alejandro
in order to make it run with 2008 I have had to add line 546 is oes.py
Thanks. That's been added to the code.
Apparently there is a table named OES1X that conflict with OES1 that does not exist in nast2008 op2. (left 2008, right 2012)
It looks like MSC 2008 has a bug. If you run:
test_op2 -b random_x_mini_2008.op2
vs.
test_op2 -b random_x_mini.op2
The first thing I noticed was the op2/binary debug file from MSC 2008 are twice as big.
I'd attach the data but it's kind of big. If you disable object creation (set auto_return to True if read_mode==1 and set is_vectorized=False in pyNastran/op2/tables/oes_stressStrain/oes.py and work through the crashes), you can print the full op2 in a semi-readable form. Then by hand you can split out the OES1 vs. OES1X results and diff them. You'll see the tables are exactly the same.
May it be interesting to consider OES1X when availble as it consideres PLOAD1 and CBARAO?
I'm not sure, especially considering this looks to be a version specific bug that MSC has acknowledged and fixed. I've seen this issue before in the TPL problems, but never knew what caused it. I suspect it's not limited to just the OES1X table.
I'm sorry, backwards. It looks like MSC 2008 is correct, but MSC 2012 has the duplicate data. It's like they recognized the data was not in OES1X form, like it's supposed to be, so they just double wrote the table...