I am running a very long simulation, and about 1 in every 20 iterations a model fails to converge which trashes the whole thing.
I know I can use try() with the offending model to skip past it in the event of an error, but I was wondering if this could be extended into a conditional? By which I mean if an error did occur, it would execute another short script instead of the code that caused the error. Kind of like an if statement for errors.
Thank you all.
You can use tryCatch function, a tutorial can be found here:
https://www.r-bloggers.com/2012/10/error-handling-in-r/
Related
I was running a spatstat envelop to generate simulations sample, however, it got stuck and did not run. So, I attempted to close the application but fail.
RStudio diagnostic log
Additional error message:
This application has requested the Runtime to terminate it in an
unusual way. Please contact the application's support team for more
information
There are several typing errors in the command shown in the question. The argument rank should be nrank and the argument glocal should be global. I will assume that these were typed correctly when you ran the command.
Since global=TRUE this command will generate 2 * nsim = 198 realisations of a completely random pattern and calculate the L function for each one of them. In my experience it should take only a minute or two to compute this, unless the geometry of the window is very complicated. One hour is really extraordinary.
So I'm guessing either you have a very complicated window (so that the edge correction calculation is taking a long time) or that RStudio is hanging somehow.
Try setting correction="border" or correction="none" and see if that makes it run faster. (These are the fastest choices.) If that works, then read the help for Lest or Kest about edge corrections, and choose an edge correction that you like. If not, then try running the same command in R instead of RStudio.
When running a rather complicated model in JAGS via rjags, I get an error
Error: Error in node ttt3[126,509]
Current value is inconsistent with data
The strange thing is that I get this error after the model has initialized (including an adaptation period) and burned in for 50000 iterations. That is, jags.model() runs fine, update() runs fine, but coda.samples() returns the above error after several days of computation (I expect the model to take about 20 days to fit, if everything worked properly). So it seems that the MCMC algorithm is accepting a proposal for a posterior sample that JAGS then feels is inconsistent with the data, which I would have thought was impossible!
I would greatly appreciate any insight about what might be going on here. Unfortunately, I have no reproducible example other than my full model, which takes several days to fit. I can probably provide the full model specification and the data upon request. I don't even know for sure if my example is reproducible, though I have encountered the same error twice in a row (but presumably the error arises stochastically during the MCMC fitting?).
I've posted a bit more about the outlines of the model at Martyn's page here.
Apparently, it's a bug in JAGS. I keep getting the same thing, too. It's about the beta conjugate distribution.
I am using the stepAIC function in R to run a stepwise regression on a dataset with 28 predictor variables. The backwards method is working perfectly, however the forward method has been running for the past half an hour with no output whatsoever this far. I believe it is to do with how I'm defining the scope attribute. Without the scope it runs instantaneously however only one step is run and no changes are made to the initial model.
Bstep.NNN.top<-step(lm(Response~X1+X2+X3+X4+.....+X28,data=df),
scope=list(upper=Response~X1*X2*X3*.....*X28,lower=Response~1),direction=c("forward"))
Does anybody know of a method that is quicker to run? Or if there is a way to simplify the scope attribute to a point where the run time will decrease?
Thanks
I am building a Monte Carlo simulation for the purpose of power estimation, and I need to run 10,000 iterations, each of which involves fitting a bunch of mixed linear & logistic models to data I generate. Once in a blue moon I get an error like this:
nlminb problem, convergence error code = 1 ; message = iteration limit
reached without convergence
I gather from Googling the error that this is common and probably a function of my data (since it does not happen on most runs through the simulation program). However, it is a pain because it makes my simulation crash and I can lose days worth of runtime. I would like to make the program more robust by adding some error-handling to it, but I don't know where the "convergence error code" is stored, if anywhere.
Checking the manual pages for lme, lmeObject, and nlminb didn't really help. Any ideas?
That sounds more like a warning than an error. The "convergence" element of the list that nlminb returns will be 0 for successful convergence. I would ask whether you might want to increase the "iter.max" element in the control list. This information is on the help page.
When I try to calculate Gest in spatstat I get the error:
bootstrap output matrix missing.
Does anyone know what am I doing wrong?
I think that "bootstrap output matrix missing" is a fairly generic error, and (unless someone has explicit experience with your case) I would imagine that more information is needed to solve this.
Without more information, I would suggest that you debug the Gest function. You have two good options for that:
1) Use the debug() function:
debug(Gest)
Now run your code. Then you can walk through the Gest function and see where is breaks. Before that point, look at all the environment variables by (for instance) using ls() and see if any assumptions are broken. Presumably something isn't being set correctly.
2) Use recover:
option(error=recover)
Then you will go into browser mode whenever the error occurs, and you can explore the workspace at that point.
This error message does not originate from the spatstat package.
To identify the location of the error, type traceback() immediately after the error has occurred. This will give you a list of the nested commands that were being executed at the time the error occurred. The top one is the location which raised the error.