This was my third PhD project, and it took far less time than my first project, as I had already learned much of the coding and theory, so it was a matter of reading papers on the subject, while trying to find something no one else had done before.
This paper builds upon my first project on realised volatility, and tries to identify specific dates in which there was a break in volatility, and hence a different set of parameters would be more suited. I use up to 3 breaks, and hence 4 separate models need to be estimated for one time series. This can be very computationally intensive, as not only are the four times the models, but we are also estimating a few more parameters which govern the break point.
I was fortunate enough to be granted access to USYD’s High Performance Cluster (HPC) Artemis.
It took a few days to refactor my code so it would be suited to an HPC, as well as writing a bash script that is compatible. It’s a game really, as you need to convince the scheduler to process your jobs before everyone else’s. It’s a classic Goldilocks problem, you can’t submit a job that is too big, or it will never be processed. At the same time if you submit a job that is too small it will take just as much time if you did it on a single core on your own computer. The clock speed on the HPC isn’t all that fast, where it does win is in the sheer number of cores. In the thousands.
Once that problem was solved, it was quite a pleasure to see my jobs be swallowed up, processed and output spit out the other end.
The results were actually much better than I expected, with there being clear structural breaks in volatility in nearly all time series. At first glace this looks like utopia, and a chance to beat all other univariate GARCH models which are stuck using irrelevant data to forecast volatility. The bubble is popped when you realise you need anything from 600-1000 daily data points (3 to 4 years) before my models can make an accurate prediction of the break date. It will still outperform similar models, but it will also not make a prediction as to when the next break will be.
After having wrapped this paper up quickly, I proceeded to finalising my thesis, which due to the fact that my previous papers were very thesis friendly, it didn’t take too much effort to write up a suitable introduction to make the thesis flow.
Obvious extension to this model would be to try and make break predictions, but I feel this will be a herculean task given the data hungry GARCH models involved.
This paper formed the third and final chapter of my thesis which was submitted on 1 December 2015, returned in February 2016 and finalised in March 2016. A copy can be downloaded here
If you have questions about any aspect of this project (code, theory etc), please shoot me an email and I will do my best to get back to you as soon as possible.