Algo Financial Modeler (AFM) models need to be modified to make the most of the functionality in Algo Financial Modeler Enterprise (AFME) 22.214.171.124 or later. Models created in AFM may have the portfolio date or the location of data and assumptions hard coded (and need changing each time the model is run). Whilst this may be suitable if the models are only being run in AFM as the model can be recompiled each time, they are not suitable to be used in AFME as you would not expect the model to be uploaded as a structure each time it needs to be run.
When a model is added into AFME, the only part of the model that can be modified are run-time parameters, so models need to be set up with the appropriate run-time parameters so they can be run in both AFM and AFME at different portfolio dates and with different inputs with only the values of run-time parameters needing to be changed. Models may already be parameterized using placeholders however the special run-time parameters (described below) provide more functionality and less risk.
It is necessary in both AFM and AFME to be able to run models at different portfolio dates without changing the model. To do this take the following two steps:
- Define a run-time parameter called Reporting_Date and supply a default value for it
- Define the portfolio date property of a model as
Running the model in AFM
When running the model in AFM the Reporting_Date run-time parameter should be changed to the required value.
Running the model in AFME
When the run archive for the model is added into AFME, the Reporting_Date run-time parameter will be displayed in the list of parameters for the AFM structure. However, Reporting_Date is a special run-time parameter so when scheduling an instance or template to a reporting period that has a date associated with it or to a reporting period template it will not be displayed in the list of parameters. Instead the value for the run-time parameter will automatically use the date for the reporting period that the AFM instance is scheduled to run against.
There is one situation where the date defined in the AFM structure will be used, that is when scheduling to a reporting period that does not have a date set for it (e.g. the System reporting period). This is an unusual situation and not typical of how we would now recommend models are run in AFME.
Location of input files
It is necessary to be able to structure a model to run in both AFM (where the input files are located on a network location) and AFME (where they have been uploaded to reside within the system). Whilst there may be different ways to ensure this is possible this note details one example.
Consider the situation where a workspace is located at c:\workspace, the data for a model is stored as c:\workspace\inputs\data_file.txt and the assumptions are stored as c:\workspace\inputs\assumptions_file.xls. When the run archive for the model and the data and assumptions are uploaded into AFME they will be scheduled to run into the same folder either manually or using a reporting period template.
In AFME the model and inputs are extracted to the reporting period output sub-folder of the physical location for the folder that the instances and templates are scheduled to (see AFME Reporting Periods and Templates for more details). There are two special run-time parameters that can be used to parameterize the location of the files:
- Folder_Path – the physical path of the folder the instance or template is scheduled to
- Reporting_Period_Folder – the output sub-folder for the reporting period
Parameterizing the model in AFM
In this situation where a model is required to be run in both AFM and AFME then the data and assumptions are usually located in the same folder in AFME. Given that production runs should all be done in AFME with AFM just being used for model development and testing then this should not be an issue. The following changes should be made to parameterize the input files:
- Create a run-time parameter called Folder_Path and assign it the value <Workspace_Folder>
- Create a run-time parameter called Reporting_Period_Folder and assign it the value Inputs
- For the data file redefine it to be located at <Folder_Path>\<Reporting_Period_Folder>\data_file.txt
- For the assumptions file redefine it to be located at <Folder_Path>\<Reporting_Period_Folder>\assumptions_file.xls
Running the model in AFM
When running the model in AFM no changes to these two run-time parameters are necessary as the model will pick up the files in the local inputs folder.
Running the model in AFME
Because Folder_Path and Reporting_Period_Folder are treated by AFME as special run-time parameters then they will not appear in the list of parameters for an AFM structure or when an instance or template is scheduled, hence their value can never be changed by the user. AFME will assign the appropriate values according to which folder and reporting period the instances and templates are scheduled to.
Additional special run-time parameters
There are a couple more special run-time parameters that can be used to parameterize the location of input files for more complex situations.
If a model has inputs (assumptions, data or results) from the previous reporting period then this run-time parameter can be used to ensure that they are accessed from this reporting period rather than the current one. You would need to add a run-time parameter called Previous_Reporting_Period_Folder (assigning it the value Inputs_Previous) and then use this in place of Reporting_Period_Folder for inputs that need to be from the previous reporting period. When running in AFM you can put the previous inputs in the Inputs_Previous folder and it will run without any changes to the run-time parameters.
If assumptions will be scheduled to the parent folder in AFME, e.g. four country folders using a single set of assumptions defined at the region level (with the country folders being children of the region folder). Then this run-time parameter can be used to always access the assumptions from the parent folder. You would need to add a run-time parameter called Parent_Folder_Path (assigning it the value <Workspace_Folder>) and then use this in place of Folder_Path for inputs that need to be accessed from the parent folder. When running in AFM you can put the assumption file in the inputs folder and it will run without any changes to the run-time parameters.
This is similar to Parent_Folder_Path but implies to two levels up instead of one, e.g. four country folders using a single set of assumptions defined at the group level, where the region folder is a child of the group folder. Usage of this folder would then be exactly the same as for Parent_Folder_Path.
Data source properties affecting AFME
Inputs reports are only available in AFME and they detail what known inputs are available for an AFM instance. An inputs report is created whenever an AFM instance is scheduled or modified, and can be rerun manually using the Check action. The overall status of the inputs report is used if the 'Wait for inputs' box is checked on an Instance, so only executes when the Inputs report status is Found. In AFM the 'Test for records' and 'Input reporting' properties of a data source can be used to modify the individual statuses in the inputs report as well as the overall status.
The 'Run-time action' property of a data source can be used to determine what happens if a data source is not found when the model executes, causing the instance to Fail or Complete in AFME depending on what is chosen.
Test for records
This property only applies to databases. If Yes is selected then, as well as checking for the existence of a database table, it will also check that the table contains at least one valid record (i.e. after applying any Where clause defined on the data source).
This property can take the values Required, Optional and Ignore and determine what statuses are returned for an input and what that status means when working out the overall inputs report status.
- If Required is chosen then the statuses returned are Found, Invalid (couldn't open the table or file) or Empty (only on database where Test for records is Yes and no records were found). The Invalid and Empty statuses are deemed to have failed input checking.
- If Optional is chosen then Found, Invalid and Empty can all be returned as for Required, but for input checking purposes Empty will be treated as failed and Found and Invalid will be treated as successful.
- If Ignore is chosen then the status returned will be Ignored and for input checking purposes will be treated as successful.
If all inputs are treated as successful then the overall inputs report status will be Found, otherwise it will be Missing.
This property defines the action to take if an input is missing, it can take the values Warning, Error or Stop.
- If Warning is chosen then a runtime warning is logged in the Run summary and it will not cause the model to fail, so the Instance in AFME will end up with a Completed status (so long as no other critical error occurs)
- If Error is chosen then a runtime error is logged in the Run summary and it will not cause the model to fail, so the Instance in AFME will end up with a Completed status (so long as no other critical error occurs)
- If Stop is chosen then a runtime error is logged in the Run summary and it will cause the model to fail, so the Instance in AFME will end up with a Failed status