About the MPC Engines

The Multiperiod Performance Calculator consists of two separate engines working together: the MPC Preprocessor engine and the MPC Calculation engine.
The MPC Calculation and MPC Preprocessor can be terminated from the Data Steward Event Queue.

MPC Preprocessor Engine

The MPC Preprocessor is an engine that runs and spawns individual instances of the MPC calculation engine for each entity, monitors those instances, and completes when all spawned events are completed.
The preprocessor queries PERF_SUMMARY for any records that have an UPDATE_DATE greater than the MPC_UPD_DATE.

The MPC_UPD_DATE is a column that is updated with a timestamp every time the Multiperiod Performance Calculator runs.

Records that do not have the MPC_UPD_DATE populated are picked up here as well. If it finds any records, it spawns one calculation engine for each entity it finds. List entities are rendered in the preprocessor so an engine can be spawned for each member.

In addition, if any fields have changed in the calculation rule or the calculation rule has changed since the rules were run last, the preprocessor identifies those fields and spawns calculation engine instances for every entity. Any entity not present during the last run is spawned as well.
The MPC preprocessor employs the logic described in the following table to determine which funds need to be run.

MPC Preprocessor Action

Description

MPC Preprocessor Action

Description

Rebuild

If the MPC rule was submitted with Rebuild, run for all entities in rule.

Rule change

If the MPC rule was changed, run for all entities in rule. Changes include: source, dictionary, dictionary level, starting frequency, selected derived frequencies, changes to derived fields, derived operations, and the derived business calendar option.

Field change

If an MPC field was changed, run for all entities in rule. Changes include: adding a field that was not included before, operation type, base field, result field, base value, use business calendar, period options, and annualization option.

New entity

If an entity is included in the rule that was not included last run, run that entity. This includes entities added through dynamic lists.

New or As Of Performance data

If an entity has a new PERF_SUMMARY record or existing PERF_SUMMARY record that has been changed, run that entity.
Once these conditions are examined, the preprocessor launches one MPC calculation engine for each entity that needs to be updated.

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.

DATE

FREQ

TOT_ RETURN

MTD_ RETURN

QTD_ RETURN

YTD_ RETURN

ITD_ RETURN

DATE

FREQ

TOT_ RETURN

MTD_ RETURN

QTD_ RETURN

YTD_ RETURN

ITD_ RETURN

7/1

D











7/16

D

CHANGED BY PERFCALC

MPC UPDATES

MPC UPDATES

MPC UPDATES

MPC UPDATES

…





MPC UPDATES

MPC UPDATES

MPC UPDATES

MPC UPDATES

7/31

D



MPC UPDATES

MPC UPDATES

MPC UPDATES

MPC UPDATES

7/31

M

MPC UPDATES

MPC UPDATES

MPC UPDATES

MPC UPDATES

MPC UPDATES

8/1

D





MPC UPDATES

MPC UPDATES

MPC UPDATES

…

D





MPC UPDATES

MPC UPDATES

MPC UPDATES

8/31

D





MPC UPDATES

MPC UPDATES

MPC UPDATES

8/31

M





MPC UPDATES

MPC UPDATES

MPC UPDATES

9/1

D





MPC UPDATES

MPC UPDATES

MPC UPDATES

…

D





MPC UPDATES

MPC UPDATES

MPC UPDATES

9/30

D





MPC UPDATES

MPC UPDATES

MPC UPDATES

9/30

M





MPC UPDATES

MPC UPDATES

MPC UPDATES

9/30

Q

MPC UPDATES



MPC UPDATES

MPC UPDATES

MPC UPDATES

10/1

D







MPC UPDATES

MPC UPDATES

…

D







MPC UPDATES

MPC UPDATES

10/31

D







MPC UPDATES

MPC UPDATES

10/31

M







MPC UPDATES

MPC UPDATES

11/1

D







MPC UPDATES

MPC UPDATES

…

D







MPC UPDATES

MPC UPDATES

11/30

D







MPC UPDATES

MPC UPDATES

11/30

M







MPC UPDATES

MPC UPDATES

12/1

D







MPC UPDATES

MPC UPDATES

…

D







MPC UPDATES

MPC UPDATES

12/31

D







MPC UPDATES

MPC UPDATES

12/31

M







MPC UPDATES

MPC UPDATES

12/31

Q







MPC UPDATES

MPC UPDATES

12/31

Y

MPC UPDATES





MPC UPDATES

MPC UPDATES

1/1

D









MPC UPDATES

…

D









MPC UPDATES

1/31

D









MPC UPDATES

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.

Field

Daily (D)

Monthly (M)

Quarterly (Q)

Yearly (Y)

Field

Daily (D)

Monthly (M)

Quarterly (Q)

Yearly (Y)

Week-to-date

X







Month-to-date

X

X





Quarter-to-date

X

X

X



Year-to-date

X

X

X

X

Fiscal-year-to-date

X

X

X



Inception-to-date

X

X

X

X