Formalize superelement test cases

[vtpasquale]

Start by working with the existing superelement set test cases for cantilever bar. The following cases are tested:

• No superelement

  • No reduction
  • Guyan reduction
  • Dynamic reduction

• Part superelement, Guyan reduction

• Part superelement, dynamic reduction

  • One mode
  • Two modes
  • etc.

Implement modal-frequency check cases. Duplicate for the truss216 structure.

[vtpasquale]

I spent some time considering options for creating/storing commercial Nastran verification data. This is what I found:

• Punch output lacks complete superelement support - superelement data are output to the punch file, but superelement designations are not written to the punch headers. The output data can be ambiguous. I could work around this.
• HDF5 output isn't going to work for me right now
  • Simcenter Nastran 2019.2 doesn't support HDF5 output for superelement runs
  • MSC Nastran documentation implies that HDF5 output is supported for superelement runs, but I don't have access to enough MSC tokens to run MSC Nastran superelement jobs.
  • I don't want to parse output2 or f06 data

For now, the best choice is to keep the same process I've been using, which is reading output2 data using Femap and exporting csv data files from the Femap data table. The manual effort is done up front, which is annoying. An alternative choice would be to make punch files work.

[vtpasquale]

HDF5 format will be used for the verification data.

Part superelements have been implemented and are working for select test cases. The math for model reduction and model synthesis is not that hard - Guyan reduction and Hurty/Craig Bampton method have been implemented and work for simple test cases. Rubin method (CSET only, uncommon) and mixed boundary reduction (combined BSET and CSET, uncommon) have not been implemented yet.

The hardest parts with superelements are: (1) creating an architecture that supports them (this is effectively done), and (2) dealing with Nastran's input formatting for superelements. The latter may be, ironically, the hardest part. If you crack open a Nastran superelements user guide you will immediately realize that user has a plethora of options (in an enormously confusing way - not in a good way) to define their superelements. The absolute worst part is the semi-implicit nature in which the case control is handled across subcases and the set definitions dictate the dynamic reduction.

I think I've landed on a subset of features and options that work for me. However, if I could do it over again I wouldn't. I learned a lot, but these features add a layer of complexity to the architecture, and the implementation took a level of effort that is difficult to justify in retrospect.

Some superelement test cases are in the repository. More testing is needed and more documentation is needed to communicate the features and limitations to the user. I’m pausing superelement development for now and closing this specific task.