QUESTION: My Valuation / Core Projection takes a long time to run. Are there ways to change my setup to make it run faster?

ANSWER: Yes, by using WinTech’s Grid Platform. The Grid Platform is a separate software product requiring a separate license. Without a license, ProVal will use up to 4 local processors. With a license, ProVal can use an unlimited number of local processors. In addition, a license allows the use of an unlimited number of grid agent processors on your network. See What's New in ProVal 3.04 for details.

In addition, there are some other techniques that can be used to speed up execution times:

• Data:  group data.  Use ProVal's Group Data tool to compress seriatim data. Rerun your Valuation with grouped data and then use ProVal's Scaling Factors tool to calculate scaling factors, which, when applied, ensure liability changes caused by grouping are within a tolerable range.

• Data:  minimize the number of new entrants.  The number of new entrant records greatly impacts Core Projection processing speed. Consolidate to as few new entrant records as possible and eliminate new entrant records with tiny weightings (e.g., Count=1 vs. other records with Count=1000).

• Benefit formulas:  use subformula components. If a certain computation appears in multiple Benefit Definitions (e.g., “A + (B #MAX C)” appears in the benefits initiated by retirement, termination and death), then the underlying operations will occur several times. Placing this kind of repetitive calculation in a Subformula type of component will speed processing, in addition to enhancing readability. This tip applies also to complicated computations in the Accrual Basis Expression (Basis Formula topic) of an accrual definition type of Benefit Formula Component.

• Benefit formulas:  for "IF THEN ELSE" operators, avoid use of structures based on database fields. If different benefit structures are combined using many "#IF - #THEN - #ELSEIF" expressions (e.g., for different union locations or business classifications), then values for all of the referenced Benefit Formula Components will be calculated before ProVal evaluates the benefit formulas, even if some of the component calculations were ultimately unnecessary.  Instead of one Benefit Definition utilizing the "IF THEN ELSE" operator, put the benefit formulas into multiple Benefit Definitions, using Selection Expressions to exclude records from processing.

• Benefit formulas:  eliminate unnecessary lump sum factors. Lump sum factor Benefit Formula Components are calculated “on the fly” when the Valuation / Core Projection is run and require significant processing power. In the U.S. qualified and Canadian registered modes, lump sum factors (and optional forms) facilitate valuing "specialized" liabilities under their own, differing, interest and/or mortality rate bases. If, however, a lump sum factor is based on fixed interest and mortality rates, processing time can be saved by populating a Benefit Component Table with the lump sum present values and then referencing the table in a Benefit Formula Component.

• Benefit Definitions:  remove unnecessary or immaterial optional forms. Each optional form coded in ProVal – either in its own, separate (i.e., a second), Benefit Definition or using the "Optional forms" topic of a single Benefit Definition – is functionally a separate Benefit Definition, requiring separate evaluation. If any optional forms do not have a material impact on liabilities or cash flows (e.g., 5 year certain J&S as compared to J&S without a certain period), consider removing them (especially for a Core projection). Also see the discussion above of lump sum factors, which may be relevant to the optional forms conversion basis.

• Benefit Definitions:  minimize the use of post-decrement death benefits. Payment Form Definitions of the “Post-decrement Death Benefit” type involve very intensive computations for active records, requiring calculation of both decrement from active status and subsequent death before the benefit commences. If the liability for these payment forms is immaterial (especially for a Core Projection), removing them can improve run time. If they are retained, the parameter selection in the Payment Form Definition that runs fastest is Beneficiary determined at decrement.

• Valuation Assumptions:  use advanced COLA expressions only when other COLA parameters are insufficient for the COLA's complexity.  These expressions take a long time to run.  They can often be avoided by using the parameters behind the COLA Limits button of the Benefit Definition or by specifying COLA rate tables that vary by coded database field or calendar year.     

• Valuation Assumptions:  turn off unnecessary liabilities. In the U.S. qualified, Canadian registered and German pension modes, some liabilities (such as target, funding and Teilwert liabilities, in those respective modes) will always be calculated, but other liabilities will not be evaluated unless requested in the Valuation Assumptions. Turn off calculation of any liabilities that are not necessary for your analysis.

• Valuation Assumptions:  for Solvency liabilities in Canadian mode, use the check for optimal value up to 100% retirement age option, if possible. Specifying an age may result in a greater number of ages being checked and therefore increase processing time.

• Valuations:  turn off +.01 / -.01 valuation assumption sensitivities. These sensitivities (trend, interest rates, etc.) are frequently needed for accounting disclosure purposes and are run, by default, whenever accounting assumptions are used, but the Valuation will run substantially faster if they are turned off.

• Valuations and Core Projections:  turn off projected benefit payments (Note that this option is only available in Public mode). In a Valuation with subtotals, behind the Census Data button, turn off projected benefit payments and head counts for subtotals, if you don't need this breakdown of cash flow streams (or, in the pension modes, you may limit it to projected unit credit liability). In a Core Projection, you can turn off projected benefit payments behind the Sensitivities button, either completely or just for sensitivities other than the baseline, except as required for certain calculations (e.g., PPA effective interest rates in US qualified mode).

• Core Projections:  turn off unnecessary sensitivities. If you will not be running a forecast and need only baseline liabilities, i.e., you don't need to vary inflation, interest rates, lump sum rates or the alternate benchmark, then, for purposes of computing liabilities, you could run only the baseline sensitivity. Note that ProVal is smart enough to skip the lump sum and alternate benchmark sensitivities if they don’t apply.

• Valuations and Core Projections:  turn off unnecessary subtotals. This saves time writing results to disk because ProVal accumulates the grand totals in memory but accumulates subtotal results on disk.  (Time spent calculating values, however, is not significantly reduced.)

​