OpenComponents ‘Result Calculator’ Usage

OpenComponents ‘Result Calculator’ Usage

Expert articles on a wide range of topics​

By Tom Graham

 
 
 
The Result Calculator Extension Type in OpenComponents allows you to override – in the programming sense – the calculation of a particular standard Endur simulation result for one or more particular deal types.

This means than when you run a particular standard simulation result for an Instrument Type for which you have declared your Result Calculator applicable, then rather than call the standard core-code calculation method for that deal type, the system will execute the custom Result Calculator method you have implemented in Java/C#.

The Result Calculator (RC) can thus implement custom calculation logic for the result within its own code, or alternately can serve as a wrapper to call out to a function in an external library.

Previously, if you wanted to implement some custom calculation method for a particular deal type, you could write a completely new custom simulation result. The disadvantages of this approach were:

  1. If you only wanted custom logic for calculating, say, cumulative PnL, for one particular deal type, and would use the standard simulation result for all other deal types, then you would have to create a whole new result type for all trades, run the standard result for all trades as a dependency, then copy out the standard output for other deals into the custom result, and only then generate your custom data.
  2. Any other results that use the base standard result as in input dependency would not then see the custom version of the base result you have created as a completely separate result. The custom result would only be used by processes that are specifically set up / coded to reference it.

With an RC you need only calculate and save the result once for each deal, using the core method or RC override as specified. The output using the custom logic will now be seen by everything that has a reference to the original standard result, including other dependent results but also Report Builder Reports, APM Pages, RiskPak plugins, Credit Risk engines etc.

Only certain standard simulation results can be overridden via a Result Calculator – the list of result types available has been expanding with each new version of Endur.

The following sections describes a particular use-case for a Result Calculator extension of a standard Endur simulation result.

 

Storage Pricing Model

Gas storage capacity is essentially a calendar spread option – it gives the holder the ability to buy gas when it is cheap (in the summer) and sell when expensive (in winter). It is more complex than a simple spread option, as the ability to utilise the storage is subject to complex costs (variable fees for injecting, withdrawing and holding in store) and physical constraints (minimum/maximum injection & withdrawal rates which vary with time and with the quantity in-store).

Therefore the value of the capacity is not only a function of the seasonal forward price spread, and its associated volatility & correlation, but is also a complex optimisation problem to maximise the profit given the costs and constraints.

Although OpenLink now provides a standard storage valuation model in Endur, which works along the lines described above, several Endur clients use their own custom External Pricing Model (EPM) for gas storage valuation which are variations on this.

It is possible to plug an EPM into Endur using either the old pre-OpenComponents pricing model toolkit, or using the OC Instrument Model Extension type.

These storage valuation models must by definition take as inputs all the relevant valuation parameters – including the whole location forward price curve for the period covered by the storage facility. Other inputs include market data – volatilities & correlations & discounting rates – and also complete specification of all fee rates and constraint parameters, in order to generate the optimal injection/withdrawal profile and calculate the associated intrinsic/optional values.

In one case we worked with a client custom storage valuation EPM which could calculate and output not only the valuation of the storage facility, but also the Greeks – the first & second order sensitivities of the valuation to the market inputs. We were able to use the Result Calculator functionality to plug in these EPM Greeks calculations to the Endur standard Greeks simulation results.

 

Result Calculator for Tran Gridpoint Delta Result

As stated above, the client storage valuation EPM takes as one of its inputs the gas forward price curve for the duration of the storage facility, as a sequence of date / price value pairs. The model can calculate and return analytic delta values, as a sequence for each element in the input price curve vector.

Since we generate the input price curve for the model by simply taking the vector of gridpoint date/value pairs from the curve in Endur – specifically the Projection Index that is attached to the storage deal physical balance leg – whatever that curve structure is set up to be, then the sequence of Delta values generated by the EPM also correspond to the gridpoints on the curve in Endur. This means that the structure of the Delta output from the custom storage model corresponds to the structure of the Endur standard Tran Gridpoint Delta simulation result.

If we were to run the standard Tran Gridpoint Delta sim result for a Storage deal which was set up to use the external model for valuation – this would work as follows:

  • The Standard Tran Gridpoint Delta result calculates Delta numerically: For each gridpoint on the deal pricing curve, the system shocks the base input value up by a specified Delta Shift, then recalculates the deal value at the shocked price. Then it shocks the price input down by the same amount and does another deal valuation. Then it repeats this for each individual gridpoint of the valuation index attached to the deal.
  • For each gridpoint shock revaluation, we would get a call to the EPM valuation function – via the Instrument Model Extension wrapper. This means many calls to the EPM for a single run of the Delta simulation on one storage deal.

Because the storage valuation model is complex, as described above, it takes a relatively long time to run a single valuation (compared to any standard Endur Option model). It would take a very long time to run a Gridpoint Delta simulation via the standard sim result numerical method, making many individual calls to the model valuation.

Instead we implemented a Result Calculator for the Tran Gridpoint Delta simulation result, for the COMM-STOR instrument type (Actually a sub-type of COMM-STOR to make it more specific). As with the original Instrument Model, the RC extension class itself just acts as a wrapper to make a call to the external Storage Valuation Model: Instead of calling the model base valuation function, it calls the separate calc_delta function.

The RC has to pass in the same complete set of valuation parameters as the Instrument Model, but we now get the complete vector of gridpoint delta values in a single call to the model. The RC takes this model output and has to do some work to reformat it into the exact format of the Tran Gridpoint Delta result.

It still takes some time to run Tran Gridpoint Delta for a gas storage deal using this set up, but it is just about practical to do so, at least for an EoD batch run: This allows us to include the Storage deal in a delta simulation for a portfolio containing this plus associated physical gas deals, thus getting an aggregate view of Delta position for the whole extended storage strategy/book trade set.

 


Have your say:

Share on facebook
Facebook
Share on google
Google+
Share on twitter
Twitter
Share on linkedin
LinkedIn
error: Content is protected.