Keeping you up-to-speed with modelling software developments, we have recently released version 2.4 of our capital modelling and financial projection system, RiskAgility FM, which includes a number of exciting new features plus a number of enhancements and bug fixes.

New key features include:

  • Cross reference reports for variables and formulas in the Code Manager
  • Enhancements to the management and usability of code variable and input variable associations
  • Support for custom output files
  • Viewing debug information for code variables associated with input variables

Cross reference reports

RiskAgility FM version 2.4 now includes the ability to produce reports that show where selected code objects (variables or formulas) are used in the Code Manager and Input Managers of a project. This allows users to better understand their project dependencies and the complex interactions among the different parts of their project.

Reports can be generated from the Code Manager in different ways:

1. By selecting one or more code objects in the formulas and variables list and selecting 'Cross Reference Report' (Figure 1):

Figure 1

Towers Watson Media

2. By selecting the project node or model object in the model tree and selecting 'Cross Reference Report' (Figure 2):

Figure 2

Towers Watson Media

This then allows the user to choose which type of code objects (variables or formulas) can be included in the report. If the user chooses to produce a cross reference report from the project node of the model tree, then additionally, they can include project variables in the report (Figure 3).

Figure 3

Towers Watson Media

The cross reference report (Figure 4) includes information for all of the selected code objects about where those objects are used in the Code Manager and Input Managers of the project. For each use of the code object in the Code Manager a separate line is added to the report with a hyperlink to the appropriate formula. If the code object is used in the Input Managers, then each location (that is, the combination of input manager, input page, assumption set and input variable) is reported separately.

The cross reference report data can be copied to the clipboard for pasting into other applications, including Excel, for further analysis.

Managing code variable and input variable associations

We have added a number of enhancements to the ways that code variable and input variable associations are managed in RiskAgility FM version 2.4, including removing code variable associates in bulk, dealing with clone model associations.

Removing code variable associations

The user can select one or more code variables from the variable list within the Input Manager and select the ‘Remove Code Variable Associations’ to remove any existing associations (Figure 5).

Figure 5

Towers Watson Media

As long as one of the selected code variables is associated with an input variable, this option is enabled.

Associating a clone’s code variables in bulk

Often, a clone model object will want to associate most, if not all, of its code variables with the same input variables as the equivalent code variables from its peer model object. This has often entailed a manual process of associating each code variable in the clone with the appropriate input variable. With RiskAgility FM version 2.4, this process is now much simpler and can be done for many code variables in a single action.

Users can select one or more code variables from the variable list within the Input Manager and, if the code variables are from a single clone model object, select the following associate options (Figure 6):

  • Associate the selected code variables to the same input variables as their peer model objectz
  • Associate all code variables in the clone model object with the same input variables as their peer model object
Figure 6

Towers Watson Media

Towers Watson Media

If the clone’s code variable already has an input variable association (but not with the peer model’s input variable association) the ‘Broken association validation’ dialog is displayed, allowing users to decide how they want to deal with changing the association. RiskAgility FM will suggest an appropriate change in the associations which the user can override if required (Figure 7). The standard approach for associations is:

  • If the peer’s code variable is associated with a data variable, the clone’s code variable association is removed
  • If the peer’s code variable is associated with an input variable, the clone’s code variable is associated with the peer’s input variable
  • If the peer’s code variable is dissociated, the clone’s code variable is also dissociated
Figure 7

Towers Watson Media

Changes to the ability to associate clone model objects with data pages or run pages

Since the data values for a clone model are always the same as for its peer model, having a data page associated with a clone model resulted in redundant (and possibly misleading) information being recorded. We have removed this ability in RiskAgility FM version 2.4, and this has simplified the Input Manager structure and makes the Input Manager easier to understand.

Running a projection for a clone model alone is not appropriate in RiskAgility FM and we have therefore removed this ability in RiskAgility FM version 2.4.

Changing the model object associated with an Input Manager

Input Managers are always associated with a specific model object. This allows the code variables from that model object downward in the model tree to be included in the variable list in the Input Manager. This approach has provided a very flexible approach for defining the assumptions used in a complex model tree since an Input Manager can be defined for the top model in the model tree and this Input Manager can be used for any projections that only need to use part of the information from that Input Manager, that is when the target model in the projection, or the top model for a run page, is at a lower level in the Model Tree.

This approach does, however, have its drawbacks, particularly when developing the model tree further and including additional models which become a top model in the model tree. In this instance, it is not easy to transfer all of the input variables, external sources and input values from existing Input Managers into a new Input Manager associated with the new top model.

With RiskAgility FM version 2.4 we have added the ability to change the model object associated with an Input Manager. This allows all of the information already included in an Input Manager to be associated with a different top model object and allows more easily for the development of complex and evolving model trees.

Using custom outputs

Custom outputs

Within the context of a projection set, users have long been able to write C++ code to create their own output files. They have often used this capability to write information to these files in one projection, and read this information back in subsequent projections. This has proved to be a popular approach for users to transfer information across projections within a projection set.

While this was a very useful feature of RiskAgility FM, it did have some drawbacks, particularly when used as part of a distributed processing run or when used with our Unify platform. In a distributed processing run it was not easy to write output from each of the distributed calculations and have that output merged into a single output file. With Unify, the user-created output files were not visible and transferring these output files between steps in the workflow process, while possible, was not a straightforward matter.

Beginning with RiskAgility FM 2.4, new ‘custom outputs’ functionality has been introduced. This allows:

  • Easy specification and management of custom outputs within Solution Explorer
  • Easy retrieval of the file names that are relevant to the custom outputs
  • Merging of custom output files during distributed runs;
  • Availability of custom output files created during execution in subsequent steps in a Unify workflow.

Specifying custom outputs

Custom outputs are listed under a new node in Solution Explorer. Right-clicking the ‘Custom Outputs’ node, and then selecting ‘Add  New Custom Output’ allows a new custom output to be specified with an appropriate name (Figure 8).

Figure 8

Towers Watson Media

The ‘Base File Name’ property forms part of the file name that is created in relation to a custom output. This ‘Base File Name’ property can be changed as needed to avoid file name clashes.

Using custom outputs in code

Within the code, the ‘GetFullFileNameForWriting’ and ‘GetFullFileNameForReading’ methods of the custom output objects return full file names. These can be used to create and write to the relevant files.

Take an example of projection1 and projection2 in a projection set, where projection2 depends on projection1. With ‘my_custom_output’ as defined in the preceding screenshots, the relevant file can be created and written to in projection1, such as with the code shown in figure 9.

Figure 9

Towers Watson Media

The contents of the file can then be accessed from any subsequent projection. In projection2, code such as the following can be executed in order to read from the custom output file and display its contents in the run log (Figure 10).

Figure 10

Towers Watson Media

Finally the run log demonstrates that what was written to the custom output file in projection1 has been read back in correctly in projection2 (Figure 11).

Figure 11

Towers Watson Media

At the end of a projection run all custom output files are stored in the output location of the run, that is, they are stored in the same location as the column output files. If the custom output file is produced as part of a distributed run then the output is merged alongside the standard column output and Individual files.

There are additional considerations for dealing with custom output when run using projection set loops and projection set sub-loops. Please see the online help for further details.

Displaying look-up information in the RiskAgility FM debugger

The RiskAgility FM debugger is now able to show more information about a code variable’s external source look-ups. For example, using the Quick Start Tutorial Guide model, code variable ‘exp_death’ is linked to the external source look-up shown in figure 12.

Inserting a breakpoint, and starting a Debug job allows us to stop at the breakpoint (Figure 13).

Figure 13

Towers Watson Media

After adding code variable ‘exp_death’ to the watch window, the following information is available:

  • Name of external source
  • Column/row key size (number of look-up terms)
  • Column/row key values

Figure 14 below shows that other information related to the input variable associated with the code variable is available to view in the debugger, including the name of the input variable itself, plus the fallback actions and values, if appropriate, for each of the column and row keys.

Figure 14

Towers Watson Media

Additional enhancements

  • RiskAgility FM version 2.4 is compatible with Windows 10
  • Enhancements to the use of look-ups in the Input Manager, including:
    • Specifying ‘c’ and ‘r’ system variables as look-up terms
  • Additional functionality in code functions:
    • Extension to GetUniqueRowIndexValues() and GetUniqueColumnIndexValues() functions
    • Enhancements to the DoLookup() function
    • Ability to access look-ups in code with composite external sources
    • The introduction of a passDataVariables() function
  • Distributed processing improvements, including:
    • Merge performance and initial data file set up overhead
    • Azure batch task support for vGrid
    • vGrid stability improvements
  • Usability enhancements
    • External sources preview of Excel ranges expanded
    • New initial output location for job submission
  • SQLite Command Line Shell tool compatibility

For more information on RiskAgility FM version 2.4 please contact your local Willis Towers Watson consultant, your software sales account manager, or email