Skip to content

Add response/reference transformation files to the SPR random control law - #26

Open
bzwink wants to merge 1 commit into
sandialabs:mainfrom
bzwink:spr-random-transformations
Open

bzwink wants to merge 1 commit into
sandialabs:mainfrom
bzwink:spr-random-transformations

Conversation

@bzwink

@bzwink bzwink commented Sep 23, 2026

Copy link
Copy Markdown

Summary

Lets the Rattlesnake SPR random control law (RandomControlSourcePathReceiver) use forcefinder's response and reference transformations, supplied as files through the Rattlesnake control-parameters box:

response_transformation = /path/to/response_transformation.npz
reference_transformation = /path/to/reference_transformation.npy
  • parse_extra_parameters accepts the two new keys. Each is a path to a .npy file or a .npz file containing a single array; the array can be 2D (broadband) or 3D (frequency dependent, frequency on the first axis).
  • __init__ loads the arrays into _response_transformation_array_ / _reference_transformation_array_ and sets use_transformation when either is supplied. The private arrays are written directly because the public setters need SDynPy Matrix objects with coordinates, which aren't available inside Rattlesnake.
  • If only one is supplied, system_id_update fills the other with an identity sized from the transfer function (the number of drives isn't known until then).
  • The inverse methods are called with use_transformation=self.use_transformation instead of False. Existing parameter strings without the new keys behave exactly as before.

When these are used, the specification and FRFs Rattlesnake passes in should be in physical coordinates (no Rattlesnake-side transformation), otherwise the transformation is applied twice.

Testing

Closed-loop simulations of a plate (24 triaxial control channels, 12 drives, manual_inverse, inverse_method = standard), run headlessly on both Rattlesnake main (the class loaded natively as a Type 2 control law, SDynPy system virtual hardware) and dev (SDynPy FRF virtual hardware). A diagonal response transformation weighting one node's three channels by 2 (an importance weighting in the least-squares inverse) reduced that node's Z-channel control error from 11.4 dB to 4.4 dB RMS on main (5.5 to 3.3 dB on dev), with the unweighted channels' average error also slightly lower. A reference-transformation-only case was checked offline for the identity fill-in.

🤖 Generated with Claude Code

parse_extra_parameters now accepts response_transformation and
reference_transformation, each a path to a .npy file or a .npz file
holding a single array (2D broadband or 3D frequency dependent).
RandomControlSourcePathReceiver loads them into the transformation
arrays and sets use_transformation when either is given; a missing one
is filled with an identity sized from the transfer function in
system_id_update.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

This branch has not been deployed

No deployments
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant