Automatic Bookkeeping, Sample Splitting, and Inverse Processing

Automatic Bookkeeping, Sample Splitting, and Inverse Processing#

In most cases, the data for the SPR object is passed to the initializer/constructor function as SDynPy objects, which allows ForceFinder to automatically organize the data. Once in the SPR object, the data is stored as NumPy arrays to reduce overhead and simplify the process for performing computations. As a result, the data is prepared for fundamental ISE operations upon object creation, meaning that the practitioner does not need to consider any bookkeeping operations.

Note

Individual pieces of data (FRFs, response, etc.) are recalled as class attributes for the SPR object, which are returned as SDynPy arrays. For example, spr_object.frfs will return a SDynPy TransferFunctionArray of the FRFs in the SPR object.

Sample Splitting#

The SPR object initializer function includes methods for splitting the response degrees of freedom (DOFs) into so-called “training” and “validation” DOFs. This allows the practitioner to split the response and FRF data so only the training data is used for the ISE and the validation data is held out for optional quality evaluations. The training and validation DOFs are concatenated to create a superset of “target” response DOFs, which are DOFs in the FRFs that have accompanying response data. The difference between the training and validation DOFs is intuited by the initializer function with one of two ways:

  1. The practitioner can supply the target and training response data as separate SDynPy objects. The function will determine the validation DOFs based on the DOFs that are not in the intersection between the target and training data.

  2. The user can supply the target response as a single SDynPy object and specify the training response DOFS with a SDynPy CoordinateArray. The function will split the supplied target_response into the training and validation responses accordingly. The validation DOFs are identified based on the DOFs that are not in the intersection between the target and training CoordinateArrays.

Tip

Accompanying response data is not required for all the response DOFs in the FRFs, meaning that responses can be predicted at locations where measured target_response data is unavailable.

Tip

The practitioner does not need to explicitly supply separate training and target response data or DOFs. The initializer will assume that the target and training DOFs are the same (i.e., there are not any validation DOFs) if it cannot intuit the sample split with the methods that are described above.

Note

The training and target data (for either the FRFs or responses) does not need to have the same ordinate, for cases where the data has been processed differently.

Inverse Processing Decorator Functions#

A so-called inverse_processing decorator function has been applied to every inverse method in ForceFinder (where there are different decorator functions for the different SPR types). These functions handle all the pre/post processing tasks that are common to every inverse method. These tasks include:

  • Applying transformations

  • Applying the buzz method (for PowerSourcePathReceiver objects)

  • Applying constant overlap and add (COLA) processing for the TransientSourcePathReceiver

Note

Optional kwargs exist in the function signature for the inverse methods to enable/disable or modify default parameters for some of the pre/post processing in the inverse_processing decorator functions.

These inverse_processing decorator functions follow the same general process for each SPR type:

  1. Collect the FRF and response data from the SPR object and preprocess it for the inverse method

  2. Supply the preprocessed FRF and response data to the inverse method

  3. Collect the estimated source data from the inverse method and convert it back to a physical quantity (if a transformation was applied)

  4. Store the estimated sources (as a physical quantity) to the SPR object

Note

The inverse_processing decorator functions require that additional kwargs be added to the function signature for the inverse methods, as described in Anatomy of an Inverse Method. Further, the use of the inverse_processing decorator functions should be transparent in most basic uses of ForceFinder. However, it is useful to understand the layout of the functions when reviewing code or implementing a new inverse method.

Contents