Diagnosing Convergence and Estimation Failures

Why Estimation Failures Are Design Outcomes

A simulation replicate can generate data exactly as planned and still produce no usable estimate. An optimizer may stop without meeting its convergence criteria; a fit may reach a parameter constraint; or the algorithm may report convergence while the likelihood surface is too flat to support precise estimation. These outcomes matter when comparing designs. A design that gives excellent precision among successfully fitted replicates may be less useful if it frequently produces unusable fits.

The task here is to measure convergence and estimation problems consistently across designs, and to diagnose their likely source. A nonconverged fit is not automatically evidence that the design is poor: it may reflect an avoidable numerical problem. Conversely, a software convergence flag does not establish that the data are informative or that the resulting estimates are trustworthy.

Define the Outcomes Before Counting Them

For each simulated replicate, record the design, scenario, generated data identifier, fitting status, parameter estimates, objective value, optimizer messages, and diagnostic results. Define a status rule before inspecting which design performs best. For example, “converged” might require both the optimizer’s success flag and a scaled gradient below a stated tolerance. A boundary rule might require an estimate within a chosen tolerance of a lower or upper constraint. Tolerances should be appropriate to the parameter scale and estimation method, rather than selected after seeing the results.

Use all attempted replicates as the denominator for the primary convergence rate. Let \(R\) be the number of attempted replicates for a design and \(C_r=1\) if replicate \(r\) meets the convergence rule, and 0 otherwise. Then the estimated convergence rate is the proportion of attempts that converged. The failure rate is its complement when each attempt is classified as either converged or failed. If a fit is flagged as converged but fails a separate reliability check, report that category explicitly rather than silently counting it as an ordinary success.

These are estimates of the probabilities of convergence and failure under the simulation’s specified data-generating and fitting procedures. Their interpretation assumes the simulation replicates are generated according to the intended scenario and are analyzed consistently. If some attempts are missing because of a programming or infrastructure interruption, report them separately; do not treat them as successful fits or hide them by changing the denominator without explanation.

For parameter \(j\), define a boundary indicator \(B_{rj}\) using the parameter’s allowable range and a prespecified tolerance. Report the boundary rate over all attempts and, when useful, also among converged fits. The first describes how often the design-and-analysis procedure produces boundary estimates overall; the second describes boundary behavior conditional on obtaining a converged fit. These answer different questions and should not be conflated. A boundary estimate may be a legitimate estimate, so it is not automatically a failed fit.

Boundary Estimates Need Their Own Interpretation

A boundary estimate can arise because the true parameter is at a boundary, because the data are weakly informative about that parameter, because the model’s likelihood is irregular, or because optimization has failed. A boundary percentage alone cannot distinguish these explanations. Report which parameter reached which boundary, the tolerance used, and the denominator. When constraints differ by parameter, state the boundary rules separately.

For example, if a variance parameter is constrained to be nonnegative, an estimate of zero is on the boundary. That may be consistent with little estimated variability in the simulated data, or with insufficient information to distinguish a small positive variance from zero. If estimates repeatedly stop at a constraint with poor gradients or sensitivity to starting values, a computational explanation becomes more plausible. Neither interpretation follows from the boundary count alone.

Diagnose the Pattern, Not Just the Flag

Treat an optimizer flag as one piece of evidence. Examine the scaled gradient at the reported solution, whether the objective value is finite, whether estimates satisfy constraints, and whether the estimated information matrix or Hessian supports local uncertainty calculations. A small gradient is reassuring about local stationarity, but does not prove that the optimizer found the relevant optimum. A singular or poorly conditioned Hessian may indicate weak curvature, parameter redundancy, or another numerical problem. Inspect parameter correlations and uncertainty estimates as well, while recognizing that none is a standalone diagnosis.

For a subset of problematic replicates, rerun the fit using reasonable alternative starting values or an alternative optimization strategy. Compare objective values and parameter estimates. If independent starts repeatedly reach similar estimates and objective values, that supports—but does not prove—that the solution is stable. If starts yield materially different solutions, or a modest change in numerical settings changes the result, suspect an optimization or identifiability problem requiring investigation. A lower objective value from another start may indicate that the original fit did not find the best solution.

Patterns across replicates also help. Failures concentrated in one parameter, scenarios with little variation in an important covariate, or designs with sparse observations in an informative time region can suggest that the data do not constrain certain parameters well. That is a design-relevant warning, even when the software terminates normally. Similar failures across many designs and scenarios may instead point toward an analysis-pipeline or model-implementation issue. These are clues, not conclusive tests: computational instability and weak information can occur together.

Worked Diagnostic: Computation or Weak Information?

Suppose two hypothetical designs each have 100 simulated replicates. Design X has 96 converged fits; four fail, and all four have large scaled gradients. Design Y has 96 converged fits; four fail, but all four have small gradients and estimates of a variability parameter at its lower bound. In a diagnostic rerun of those eight fits from three reasonable starting values, the Design X fits reach acceptable gradients and similar objective values in three of four cases. The Design Y fits repeatedly produce estimates near zero and similar objective values, while the corresponding Hessians show little curvature in the variability direction.

Both designs have \(\widehat{q}_{\mathrm{conv}}=96/100=0.960\), or 96.0%, and a 4.00% failure rate. Those equal rates conceal different patterns. For Design X, the large gradients and improvement after rerunning are evidence of an optimization problem in at least some fits. For Design Y, repeatable near-zero estimates combined with weak curvature are consistent with limited information about that variance parameter. They do not establish that the data alone caused the failures: model structure or numerical implementation could also contribute.

The appropriate conclusion is therefore not “the designs are equally reliable” solely because their rates match. Report the identical rates, then describe the contrasting diagnostics and the limited scope of the reruns. A further investigation might check the model implementation and explore whether the sampling design contains observations informative about the parameter. Do not simply alter the model or constraints to force convergence and then compare the modified analysis as though it were the original procedure.

How Failures Affect Other Performance Summaries

Bias, root mean squared error, and interval coverage computed only among converged replicates are conditional summaries. For example, mean bias among converged fits describes the estimates produced when the fitting procedure converged; it does not describe all attempted replicates. If failures are more common in difficult simulated data sets or with extreme estimates, excluding them can make the remaining estimates look more favorable. Report the convergence rate beside conditional summaries, and state the denominator for every reported quantity.

Where possible, inspect whether failure is associated with the generated parameter values, covariates, or data characteristics. Such patterns can reveal that missing estimates are selective rather than random. Do not impute a failed fit as though it were a numerical estimate without a defensible method. If a performance measure is undefined for a failure, present it as conditional on success and separately report the failure probability. A decision may reasonably favor a design with slightly less precision among successful fits but substantially fewer failures; the trade-off should be made visible rather than buried in a single summary.

Common Pitfall and Limitations

• Counting a software success flag as full validation. A termination message does not guarantee a good optimum, adequate curvature, or informative data. Pair it with prespecified diagnostics.
• Calling every boundary estimate a failure. Boundary estimates can be valid under the model and parameter constraints. Classify boundary behavior separately, then investigate its context.
• Dropping failed replicates without a denominator. This inflates the apparent success of the analysis and can bias conditional performance summaries. Keep the attempted count visible.
• Claiming weak information from a high failure rate alone. A rate does not identify its cause. Use diagnostic patterns and controlled reruns, and retain uncertainty about the explanation.

Diagnostics are necessarily imperfect. Gradient and Hessian criteria depend on scaling and numerical implementation; alternative starts can miss a better solution; and weak information can produce both broad uncertainty and optimization instability. Prespecified rules improve comparability, but they do not turn a numerical classification into a causal diagnosis. Report enough detail for readers to see what counted as success and how failures influenced the design comparison.