Johannes, I suggest the following:
1. Don't use hybrid, use instead solnp or nlminb. 2. You can control a number of solver convergence criteria (e.g. number of iterations) using the solver.control argument. 3. Before running the code, do consider a little more how reasonable it is to be modelling a TGARCH(7,8) model. Investigate the model first (don't just return the AIC or BIC). Are any of the higher order ARCH/GARCH parameters different from zero or even significant? I have not seen a single study which shows that such very high order GARCH models have better performance than more parsimonious alternatives. 4. At the best of times it takes a considerable amount of data to estimate the GARCH persistence. Try running a simulation exercise using for example the ugarchdistribution function to obtain some insight into higher order GARCH models. 5. Finally, as mentioned numerous times on this forum, the fGARCH model is a highly parameterized omnibus model. Imposing stationarity during the optimization, particularly for non-symmetric distributions such as the ged, is a costly exercise. Consider using the GJR instead and a distribution which is a little faster to evaluate such as the JSU. Alternatively consider using the normal distribution to estimate the GARCH parameters for the purpose of model comparison. -Alexios On 10/05/2014 08:23, Johannes Moser wrote: > 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 >> >> >> >> >> >> >> >> >> >> >> > > -- > > _______________________________________________ > R-SIG-Finance@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-sig-finance > -- Subscriber-posting only. If you want to post, subscribe first. > -- Also note that this is not the r-help list where general R questions > should go. > > _______________________________________________ R-SIG-Finance@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-sig-finance -- Subscriber-posting only. If you want to post, subscribe first. -- Also note that this is not the r-help list where general R questions should go.