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.
Related
I have two openmdao groups with cyclic dependency between the groups. I calculate the derivatives using Complex step. I have a non-linear solver for the dependency and use SLSQP to optimize my objective function. The issue is with the choice of the non-linear solver. When I use NonlinearBlockGS the optimization is successful in 12 iterations. But when I use NewtonSolver with Directsolver or ScipyKrylov the optimization fails (Iteration limit exceeded), even with maxiter=2000. The cyclic connections converge, but it is just that the design variables does not reach the optimal values. The difference between the design variables in consecutive iterations is in the order 1e-5. And this increases the iterations needed. Also when I change the initial guess to a value closer to the optimal value it works.
To check further, I converted the model into IDF (by creating copies of coupling variables and consistency constraints) thereby removing the need for a solver. Now the optimization is successful in 5 iterations and the results are similar to the results when NonlinearBlockGS is used.
Why does this happen? Am I missing something? When should I use NewtonSolver over others? I know that it is difficult to answer without seeing the code. But it is just that my code is long with multiple components and I couldn't recreate the issue with a toy model. So any general insight is much appreciated.
Without seeing the code, you're right that its hard to give specifics.
Very broadly speaking, Newton can sometimes have a lot more trouble converging than NLBGS (Note: this is not absolutely true, but is a good rule of thumb). So what I would guess is happening is that on your first or second iteration, the newton solver isn't actually converging. You can check this by setting newton.options['iprint']=2 and looking at the iteration history as the optimizer iterates.
When you have a solver in your optimization, its critical that you also make sure that you set it to throw an error on non-convergence. Some optimizers can handle this error, and will backtrack on the line search. Others will just die. Either way, its important. Otherwise, you end up giving the optimizer an unconverged case that it doesn't know is unconverged.
This is bad for two reasons. First, the objective and constraints values it gets are going to be wrong! Second, and perhaps more importantly, the derivatives it computes are going to be wrong! You can read the details [in the theory manual,] but in summary the analytic derivative methods that OpenMDAO uses assume that the residuals have gone to 0. If thats not the case, the math breaks down. Even if you were doing full model finite-difference, non-convergenced models are a problem. You'll just get noisy garbage when you try to FD it.2
So, assuming you have set up your model correctly, and that you have the linear solvers set up problems (it sounds like you do since it works with NLBGS), then its most likely that the newton solver isn't converging. Use iprint, possibly combined with driver debug printing, to check this for yourself. If thats the case, you need to figure out how to get newton to behave better.
There are some tips here that are pretty general. You could also try using the armijo line search, which can often stablize a newton solve at the cost of some speed.
Finally... Newton isn't the best answer in all situations. If NLBGS is more stable, and computational cheaper you should use it. I applaud your desire to get it to work with Newton. You should definitely track down why its not, but if it turns out that Newton just can't solve your coupled problem reliably thats ok too!
the set it to throw an error on non-convergence is broken on your answer. I have added the link which I think is the right one. Please correct if the linked one is not the one you were thinking to link.
I'm estimating a Non-Linear system (via seemingly unrelated regressions - SUR), using systemfit (nlsystemfit() function) package with 4 equations, 32 parameters to estimate (!) and 412 observations. But my code is taking forever (my laptop it's not a super-powerful one tho). So far, the process was on a 13 hours run. I'm not an expert in computational stuff, but someone explained me some time ago the concept of Time Complexity of the algorithms (or big-o), then depending on this concept the time to compute a certain algorithm could rely on specific functional relation on the number of observations and/or coefficients.
Hence, I'm thinking of just stopping my process, and trying to simplify the model (temporarily) and trying to run something simpler, only to check-up if the estimated parameters had sens so far. And then, run a whole model.
But all this has a sense if I can change key elements in my model, which can reduce the time of processing significantly. That's why I was looking on google about the time complexity of nlm-package (nlsystemfit() function relies on nlm) but unsuccessfully. So, this is my question: Anybody knows where I can find that info, or at least give me advice on how test non-linear systems before run a whole model?
Since you didn't provide any substantial information regarding your model or some code for the same, its hard to express a betterment for your situation.
From what you said:
Hence, I'm thinking of just stopping my process, and trying to simplify the model (temporarily) and trying to run something simpler, only to check-up if the estimated parameters had sens so far. And then, run a whole model.
It seems you require benchmarking or to obtain the measured time taken to execute, as in your case. (although it can deal with memory usage or some other performance metric as well)
There are quite a few ways to benchmark code in R, which include the use of Sys.time() or system.time() just before and right after your algorithm/function executes, or libraries such as rbenchmark (which is a simple wrapper around the system.time function), tictoc, bench and microbenchmark.
Among these the last two are preferable options, as bench::mark includes system_time(), a higher precision alternative to system.time() and microbenchmark is known to be a reliable source to accurately measure and compare the execution time of R expressions/algorithms.
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 running a regression with lots of regressors (due to multiple interactions). R has been evaluating this regression for over 6 hours now and I keep receiving messages like:
...centering vec 2 i:6356053 c:2.0e-007 d:3.2e-001(t:2.1e-006)
ETA:7/21/2016 5:43:18 PM
I couldn't find anything about this type of message on the web, does anyone know what it means?
The error originates from the C source for lfe (line 214). According to the source:
i is the number of iterations you've gone through to try to converge on a solution (so in the OP's case, 6.35 million...)
c is your convergence rate for a given iteration
d is delta
t is your target
The message itself appears to be a primitive progress bar to keep you apprised of how many iterations you've done and the ETA of a result. In this case, it appears you are having troubles converging on a solution. The reason for why this is is be a better question for Cross Validated and you would be best served by providing them with a minimal reproducible example.
A good start on your own would be to carefully read the lfe documentation and vignettes. There is an entire vignette about speed that suggests other functions you may want to try (apart from felm) if your procedure is going slowly or not converging.
I am trying to calculate Gelman and Rubin's convergence diagnostic for a JAGS analysis I am currently running in R using the R package rjags.
For example, I would like to assess the convergence diagnostic for my parameter beta. To do this, I am using the library coda and the command:
library(coda)
gelman.diag(out_2MCMC$beta)
with out_2MCMC being an MCMC list object with more than one chain, resulting in correct output with no error messages or whatsoever. However, as I used a high amount of iterations as burn-in, I would like to calculate the convergence diagnostic for only a subset of iterations (the part after the burn in only!).
To do this, I tried:
gelman.diag(out_2MCMC$beta[,10000:15000,])
This resulted in the following error:
Error in mcmc.list(x) : Arguments must be mcmc objects
Therefore, I tried:
as.mcmc(out_2MCMC$beta[,10000:15000,]))
But, surprisingly this resulted in the following error:
Error in gelman.diag(as.mcmc(out_2MCMC$beta[, 10000:15000,]))
You need at least two chains
As this is the same MCMC list object as I get from the JAGS analysis and the same as I am using when I am assessing the convergence diagnostic for all iterations (which works just perfect), I don't see the problem here.
The function itself only provides the option to use the second half of the series (iterations) in the computation of the convergence diagnostic. As my burn in phase is longer than that, this is unfortunately not enough for me.
I guess that it is something very obvious that I am just missing. Does anyone have any suggestions or tipps?
As it is a lot of code, I did not provide R code to run a full 2MCMC-JAGS analysis. I hope that the code above illustrates the problem well enough, maybe someone encountered the same problem before or recognizes any mistakes in my syntax. If you however feel that the complete code is necessary to understand my problem I can still provide example code that runs a 2MCM JAGS analysis.
I was looking for a solution to the same problem and found that the window() function in the stats package will accomplish the task. For your case:
window(out_2MCMC, 100001,15000)
will return an mcmc.list object containing the last 5,000 samples for all monitored parameters and updated attributes for the new list.