[R-SIG-Finance] timout using "evalWithTimeout" in looped rugarch estimation

[Johannes Moser]

I guess that the problem is due to the processing in C as part of the 
ugarchfit routine.

Is there any way to timeout a ugarchfit command or to constrain the 
number if iterations?

At one time the loop seems to be stuck completely.
I waited for several hours for a single ugarchfit step which just didn`t 
complete. Then I manually stopped the process.

Separate calculation of the respective model also seems to be "stuck" 
(CPU is still working, the "hybrid" algorithms seem to find no solution 
though and just keep running).

As I want to set up a GARCH model-preselection battery there hopefully 
is a way to handle such problems?

Best, Johannes





Am 09.05.2014 13:58, schrieb Johannes Moser:
> Dear all,
>
> I`ve set up a double loop which loops through different GARCH-orders 
> and ARMA-orders in a rugarch estimation (of several models and error 
> distributions) and each time writes the AIC and other information into 
> a data frame.
> The resulting data frame should be used for the pre-selection of a 
> model, which then will be examined manually.
>
> A small part of the model estimation steps using "ugarchfit" take very 
> long time. So I implemented a timeout function using "evalWithTimeout" 
> which stops the current estimation step and proceeds with the next 
> step in the loop and estimates the next model.
>
> The timeout function is wrapped into a "tryCatch" function which 
> assures thet the loop keeps running after e.g. convergence problems.
>
> A small toy model works fine:
>
>
> #######################################################################
> require('R.utils')
> abc <- matrix(NA,10,3)
>
> foo <- function() {
>      print("Tic");
>      for (kk in 1:50) {
>           print(kk);
>           Sys.sleep(0.1);
>      }
>      print("Tac");
> }
>
>
> for (i in 1:10){
>      ptm <- proc.time()
> tryCatch( { abc[i,1] <- evalWithTimeout({foo()} ,timeout=(4+i*0.2) 
> ,onTimeout="silent" )
>             abc[i,2] <- 1
> }
> , error = function(x) x)
> tt<- proc.time() - ptm
> abc[i,3]<-tt[3]
> }
>
> abc
> #####################################################################
>
>
> However, in the rugarch setup the "evalWithTimeout" doesn't seem to 
> stop the "ugarchfit" estimation reliably. E.g. in one instance the 
> recorded time for a step was 1388.03 seconds even though the limit was 
> set to be 300 seconds. The next example illustrates my setup in a 
> simplified version (unfortunately my results depend on the data I have 
> used, so you will not be able to reproduce them):
>
>
> #####################################################################
> require('rugarch')
> quiet1 <- read.table( "dax_quiet1.txt" , header=T)
> tempdata <- quiet1$logreturns
>
> g_order <- matrix(NA,5,2)
> g_order[1,]<-c(1,1)
> g_order[2,]<-c(1,8)
> g_order[3,]<-c(9,6)
> g_order[4,]<-c(9,8)
> g_order[5,]<-c(3,10)
>
> overview <- data.frame(matrix(NA,5,2))
>
> for(i in 1:5){
>      ptm <- proc.time()
>
>      spec <- ugarchspec(
>           variance.model = list(model = "fGARCH", garchOrder = 
> g_order[i,], submodel = "TGARCH", external.regressors = NULL, 
> variance.targeting = FALSE),
>           mean.model = list(armaOrder = c(0,0), external.regressors = 
> NULL), distribution.model = "sged")
>
>      tryCatch( {tempgarch <- evalWithTimeout({ugarchfit(spec=spec, 
> data=tempdata ,solver="hybrid")} ,timeout=20 ,onTimeout="silent" )
>                 overview[i,1]<-infocriteria(tempgarch)[1]
>      }
>      , error = function(x) x)
>
>      tt<- proc.time() - ptm
>      overview[i,2]<-tt[3]
> }
>
> overview
>
> # If the timeout is set set to 20, this setup leads to:
> # 2.87 sec.
> # 6.95 sec.
> # 125 sec.     ... here, tryCatch interrupted the process
> # 51.73 sec.
> # 27.11 sec.
> # for the 5 different estimation steps.
>
> # timeout set to 300:
> # 2.81 sec.
> # 6.85 sec.
> # 743.58 sec.
> # 41.70 sec.
> # 26.85 sec.
> # no process was interrupted by tryCatch
> #######################################################################
>
>
> As can be seen even from this simplified example, when the timeout was 
> set to be 20 there still was a process that took 125 seconds (which is 
> more than 5 times longer!).
> I would be very thankful for any ideas or comments!
>
> Best, Johannes
>
>
>
>
>
>
>
>
>
>
>

--