About the MPC Engines

MPC Calculation Engine

The MPC calculation engine recalculates and updates existing PERF_SUMMARY and PERF_SEC_RETURNS records dates that have changed and any subsequent days. For example, if you calculate a single-period daily return using a Performance Calculation report as of today, tonight the calculation engine updates the calculation fields in the "D" record created today.

Similarly, if you run a Performance Calculation report as of the 15th of last month, tonight when the calculation engine runs it updates the "D" records for that entity from the 15th of last month through tonight.

The MPC Calculation engine updates on a field-by-field basis. For example, if one MPC field is new and one field was changed two days ago, the calculation engine updates the new field for every record and update the field that changed two days ago only in the most recent two "D" records.
The MPC Calculation engine updates all necessary PERF_SEC_RETURNS records, with no limit applied to the number of records updated.

Log Modes

The MPC Preprocessor and MPC Calculation engines log the mode for which they are run, as follows:

• MPC Preprocessor engine:
• Rebuild
• MPC rule changed
• MPC fields added or changed
• Normal
• MPC Calculation engine:
• Rebuild or MPC rule changed
• New entity
• MPC field added or changed
• Normal

As Of Changes

The MPC Calculation engine picks up changes in the PERF_SUMMARY table and updates any records that might be relying on the data that has changed. The following table lists an example of an As Of change on July 16th in a daily Starting Frequency.

As you can see, when the MPC runs the changes ripple through the data from the starting frequencies through the derived frequencies. Any locked records are not updated and any primed or locked records are used to determine the correct values to update.

Gap Linking

If the dictionary level is not found on the prior day, the engine goes back to the most recent day in that period that contains that node. For example, if fixed income is not found on the prior day, but is found two days earlier, the value from two days earlier is used.

Locked Records

The Multiperiod Performance Calculator uses the same locking mechanism as Performance Returns reports. This avoids contention that may occur because both the Performance Returns report and Multiperiod Performance Calculator are working on the same entity.
In addition, multiple Multiperiod Performance Calculator rules can be run simultaneously without contention.

Primer Records

If converting to PACE from a legacy system, primer records can be created with a locked indicator of "P." These primer records allow the MPC to use existing to-date data going forward. For example, when using daily starting frequency, if the first day has a locked indicator "P" and the inception-to-date return calculated, every subsequent day links off that value. If a column in the primer record is null, the calculation occurs as if the primer record is not present.

Primer records using unit values must have the same base as the MPC field. When the MPC encounters a primed unit value, it converts it back into a cumulative return using the base entered in the MPC field. Once the unit value is converted to a cumulative return, subsequent returns can be linked and converted into unit values.

Primer records using annualization must be annualized from the inception date entered in MPC field. When the MPC encounters an annualized primer record, it deannualizes it and links subsequent returns to the cumulative return. Then the cumulative returns are annualized based on the inception date.

Null Inception or Fiscal Year End Dates

Inception-to-date and fiscal-year-to-date columns update null values if the entity does not have the corresponding inception date or fiscal year end dates populated.

Server Execution

If the PACE server is stopped while a calculation engine is running, it restarts when the server is restarted. The MPC Preprocessor does not resubmit the underlying calculation engines that have already completed successfully.

Derived Frequency Process

For daily starting frequencies, on the last calendar day of each period, the process inserts or updates a derived frequency record based on the derived frequency rule option. If a record of that frequency already exists it is updated, but not if a new one is added.
In addition, when a PERF_SUMMARY or PERF_SEC_RETURNS record changes, the derived frequencies must be updated as well. This process updates all subsequent derived frequencies as well. For example, if a PERF_SUMMARY record is updated for the 15th of the month, the monthly "M" record for that period is updated. The current quarter "Q" record and the current year "Y" record is updated to reflect the change in the 15th of the month.

Derived frequencies are more complicated than starting frequencies because of the need to update the Base column. The Result columns are populated directly from the most recent starting frequency record, but the Base column is derived from all the previous Base columns. For example, on the derived "M" records, the QTD Return is copied directly from the most recent day's QTD Return, but the Total Return is calculated by linking the daily total return for each day of the month.

The supported derived frequencies are monthly (M), quarterly (Q), and yearly (Y). The business calendar is updated when derived frequency records are created, unless the Use Business Calendar option is selected. Derived frequencies are committed with the same source as the starting frequency.

Some to-date fields are not applicable on derived frequencies. The following table lists to-date fields that are supported in starting and derived frequencies.