CBUSH - PSD ISSUE

[Cédric Dumoulin]

Hi Steve, 

I'm facing difficulties reading element force PSDs of CBUSH. 
The element field is of the size of the applied frequencies but with a unique element id (psd.cbush_force.element) while the frequency field is of the size of the number of elements filled with the last frequency of the range. 

Here is a short output, the actual number of excitation frequencies is 127 for a single element. 

 type=RealCBushForceArray ntimes=1 nelements=127
  data: [ntimes, nnodes, 6] where 6=[fx, fy, fz, mx, my, mz]
  data.shape = (1, 127, 6)
  element.shape = (127,)
  element name: CBUSH
  sort1
  freqs = [2000.]

For comparison, everything works fine with cbar.

For cbar_force, everything is ok, 
type=RealCBarForceArray ntimes=127 nelements=5; table_name='OEFPSD1'
  data: [ntimes, nnodes, 8] where 8=[bending_moment_a1, bending_moment_a2, bending_moment_b1, bending_moment_b2, shear1, shear2, axial, torque]
  data.shape = (127, 10, 8)
  element.shape = (5,)
  element name: CBAR-34
  sort1
  freqs = [  20.         20.942572   21.929564   22.963072   24.045288   24.867092 .... 2000]

I'm using Simcenter Nastran 2022.1 and using the main/dev  " version of pynastran.  response. I provided you with a minimum working example (a very similar one to to the one used for satk support).  I could produce the issue using SOL111 Random and Response Dynamics (SATK) Random. 

Do you already observe such an issue? 

Best regards, 

Cédric

[Steven Doyle]

Cédric,

Sorry, I’ve been busy.  I took a look.  It’s an issue with SORT2, which tends to be used for random analysis.  It’s probably going to take me week or so to fix.

Steve

--
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 on the web visit https://groups.google.com/d/msgid/pynastran-discuss/09146efc-d7ed-4636-ba7f-f94953577f8fn%40googlegroups.com.

[Cédric Dumoulin]

Hi Steve, 

Thank you for your answer. Are the examples provided sufficient to figure out what is happening there? Do you think that it is an issue only related to Simcenter Nastran ? Unfortunately, I cannot provide examples extracted using other distributions. 

Best regards, 

Cédric 

[Steven Doyle]

Is specifically related to SORT2, so if you have an OES2/OESPSD2/etc. table, it could have an issue.  The SATK model didn’t have that.

I fixed a lot of cases in other elements (like shells).  There are still probably a few more, it should be identified better.

Steve 

To view this discussion on the web visit https://groups.google.com/d/msgid/pynastran-discuss/cd02da90-7c90-4c5e-b87b-edef8a5658abn%40googlegroups.com.

[Cédric Dumoulin]

Hi Steve, 

I could find some time figuring out this issue. I used to calculate psd through frf, but people in my team were still pushing for being able to read it directly... :) 

In terms of version, I'm working with the main branch on github.  What I had for psd (sort2) for cbush was that only the last element was read, 

more specifically, in the example below where I have two cbush elements with respective ids 1005 and 1006, I had 

print(random.op2_results.psd.cbush_force[1].element)

>> [1006          0]
print(random.op2_results.psd.cbush_force[1].element_ids)
>> [1005      ,    1006]

and in data, only the first line was filled with the value corresponding to the last element as well (1006)

random.op2_results.psd.cbush_force[1].data

>> array([[[3.5451579e+00, 1.4228966e+00, 2.4901101e-05, 3.3304757e-06,
         1.3134211e-06, 0.0000000e+00],
        [0.0000000e+00, 0.0000000e+00, 0.0000000e+00, 0.0000000e+00,
         0.0000000e+00, 0.0000000e+00]],

In oef_force_objects.py, in RealForceMomentArray.add_sort2, I realized that self.ielement was not iterated and always stays at 0, I just add the following line

self.ielement = np.where(self.element_ids == eid) in the method and everything seems working properly now, 

print(random.op2_results.psd.cbush_force[1].element)

>> [1005    1006]
print(random.op2_results.psd.cbush_force[1].element_ids)
>> [1005      ,    1006]

random.op2_results.psd.cbush_force[1].data

>> array([[[3.5451579e+00, 1.4228966e+00, 2.4901101e-05, 3.3304757e-06,
         1.3134211e-06, 0.0000000e+00],
        [3.5451579e+00, 1.4228966e+00, 2.4901101e-05, 3.3304757e-06,
         1.3134211e-06, 0.0000000e+00]],

Is it clean enough as implementation ? Would it be possible to add that in the main branch? 

Best regards, 

Cédric