Skip to content

Validation status and limitations

Demonstrated in Assignment 14

  • A newly installed Windows application ran real RASAero II and RocketPy evaluations.
  • Six unique fin geometries were evaluated; both span and sweep varied.
  • Initial Latin-hypercube sampling and Powell refinement executed.
  • Static and flutter constraint settings were recorded for each candidate, with one feasible configuration.
  • The winner was correctly distinguished from the highest valid but infeasible predicted altitude.

Not fully verified in this build

  • Completing GUI CDX1 export after opening the native Save As dialog.
  • Fresh-process reopening of a saved run.
  • Pause/resume/stop against a live active evaluation.
  • A numerical search actually crossing a flutter-violation boundary (all six sample candidates passed flutter screening).

Engineering limits

  • The physical model and supporting motor assumptions were built around a supported Sorcerer reference; arbitrary CDX1 compatibility is not established.
  • The 3.0 GPa flutter modulus in the demonstration is an assumption, not measured material data.
  • The empirical flutter formula does not replace structural analysis.
  • Static margin alone is not complete dynamic-stability validation.
  • Pitch/yaw dynamics and angular-rate peaks have model/numerical uncertainties and are diagnostic.
  • Small optimizer runs do not prove a global optimum.

For independent design decisions, verify the currently assembled mass, CG, motor, and fin materials, then rerun a candidate in native RASAero before committing to hardware.

Source basis: Assignment 14 review materials supplied with this documentation. Internal archive paths and raw evidence are not published.