Question about simscape.g​etLocalSol​verFixedCo​stInfo returning MaxIterations = -1

Hi,

I modified the local solver settings in the NonlinearElectromechanicalCircuitWithPartitioningSolver example to intentionally force the local solver analysis to fail.

openExample("simscape/NonlinearElectromechanicalCircuitWithPartitioningSolverExample")

As a result, the following command returns:

simscape.getLocalSolverFixedCostInfo('NonlinearElectromechanicalCircuitWithPartitioningSolver')

ans =

struct with fields:

SolverPath: 'NonlinearElectromechanicalCircuitWithPartitioningSolver/Solver Configuration'
MaxIterations: -1

From the documentation, my understanding is that MaxIterations = -1 indicates that the fixed-cost local solver analysis did not converge.

However, after obtaining this result, I can still run the simulation in Simulink without any errors or warnings, and the model appears to simulate normally.

My question is: why is the simulation still allowed to run if the fixed-cost local solver analysis did not converge? Shouldn't Simulink or Simscape generate an error or at least a warning indicating that the local solver convergence analysis failed?

Am I misunderstanding the meaning of MaxIterations = -1, or is this analysis independent from the actual simulation execution?

Thanks in advance for any clarification.

Answer 1

[Stephen23]

Your understanding is basically correct, but there is an important distinction between:

1. The fixed-cost local solver analysis performed by simscape.getLocalSolverFixedCostInfo, and
2. The actual simulation performed by Simulink/Simscape.

These are related, but they are not the same thing.

What does MaxIterations = -1 actually mean?

When you call:

simscape.getLocalSolverFixedCostInfo( 'NonlinearElectromechanicalCircuitWithPartitioningSolver')

Simscape runs an analysis whose goal is to determine whether the partitioned local solver can be executed with a fixed computational cost and, if so, what iteration count is required.

A result like:

MaxIterations = -1

does not mean: "The model cannot be simulated". Instead, it means something closer to:

"The analysis could not determine a finite fixed iteration count that guarantees convergence for the local solver."

In other words, the fixed-cost analysis failed, not necessarily the numerical simulation itself.

Why can the simulation still run?

Because the simulation engine does not require the fixed-cost analysis to succeed.

During simulation, the local solver can still:

• perform iterative solves,
• converge at runtime,
• adapt to the actual operating conditions encountered during the simulation.

The fixed-cost analysis is a pre-analysis that tries to characterize solver behavior over the model's nonlinear equations. It is generally used for:

• performance estimation,
• code generation workflows,
• real-time deployment suitability,
• determining fixed execution cost characteristics.

A failure of that analysis simply means:

"Simscape cannot prove ahead of time that a specific fixed iteration budget is sufficient."

That is very different from:

"The equations fail to converge while simulating."

An analogy

Suppose I ask:

"Can you guarantee that every nonlinear solve in this model will converge within exactly 5 Newton iterations?"

The fixed-cost analysis attempts to answer that question.

If it cannot establish such a guarantee, it returns something like:

MaxIterations = -1

But the actual simulation itself asks a different question:

"Can I solve the nonlinear equations at this particular time step?"

The answer may still be yes for every time step encountered in your simulation.

Can fixed-cost convergence be guaranteed? -> No (MaxIterations=-1)

Can the model simulate successfully? -> Possibly yes

These are not contradictory.

Why isn't there a warning?

Typically because Simscape treats the fixed-cost analysis as an informational request, not a simulation requirement.

If you explicitly invoke:

simscape.getLocalSolverFixedCostInfo(...)

you are requesting diagnostic information.

The simulation engine generally does not consider failure of that analysis to be a simulation error unless:

• a workflow requires fixed-cost execution,
• generated code requires those guarantees,
• a real-time target imposes fixed-step execution constraints,
• a specific setting enables validation of fixed-cost behavior.

For normal desktop simulation, there is usually no reason to prevent execution merely because the fixed-cost characterization failed.

What would cause a simulation error instead?

You would normally see simulation-time diagnostics only if the solver itself cannot converge during execution, for example:

• nonlinear iterations exceed limits,
• algebraic loop solution fails,
• partitioning solver encounters singular equations,
• state derivatives become inconsistent,
• tolerances cannot be satisfied.

Those are runtime numerical failures.

MaxIterations = -1 is a failure of the analysis algorithm, not necessarily a failure of the runtime solver.

[Telmo Belamendia]

Hi,

Thanks for the explanation. I think I understand the distinction between the fixed-cost analysis and the actual simulation.

However, I have a question about another model. When I run:

simscape.getLocalSolverFixedCostInfo(...)

the result is:

MaxIterations = 1

I then export the model as an FMU and run it in a different simulation environment. In that case, the FMU does not behave as expected when the number of nonlinear iterations is set to 1. However, if I export the FMU with Nonlinear iterations = 2, the behavior is correct and matches what I expect.

Given this, is it correct to say that MaxIterations = 1 only reflects the outcome of the Simscape fixed-cost analysis, but does not guarantee that a single nonlinear iteration will be sufficient when the model is executed as an FMU under a different master solver?

In other words, is it normal that a model for which simscape.getLocalSolverFixedCostInfo reports MaxIterations = 1 still requires a higher value for Nonlinear iterations in order to produce accurate or robust results after FMU export?

Thanks in advance.

[Telmo Belamendia]

Thanks. I tried to force a runtime solver failure by making the problem more restrictive:

• Local solver sample time = 0.01 s
• Nonlinear iterations = 1
• Tolerance = 1e-14

However, the model still simulates successfully and I do not get any convergence-related errors or warnings.

Does this simply mean that the model is numerically well-behaved enough to converge within those limits, or is there a more direct way to force a runtime nonlinear solver failure in Simscape?

In particular, is there any recommended test case or solver setting that would reliably trigger one of the runtime diagnostics you mentioned (nonlinear iteration limit exceeded, partitioning solver failure, tolerance violation, etc.)?

I'm trying to better understand the difference between a failed fixed-cost analysis (MaxIterations = -1) and an actual runtime convergence failure.

[Stephen23]

Yes, your interpretation is essentially correct. simscape.getLocalSolverFixedCostInfo(...) reports what the Simscape fixed-cost analysis observed or determined for the analyzed model configuration and test conditions. A reported value of:

MaxIterations = 1

does not constitute a general guarantee that one nonlinear iteration will be sufficient for every execution context, input trajectory, step size, initialization sequence, or FMU master.

What MaxIterations = 1 means

It should be interpreted approximately as:

Under the conditions used by the fixed-cost analysis, the analyzed Simscape local solver did not require more than one nonlinear iteration according to the analysis criterion. It does not prove that the model's nonlinear equations are globally solvable (or accurately solvable) with one iteration under all possible conditions.

The result is conditional on factors such as:

• the input trajectory used during analysis;
• initial conditions and operating point;
• local solver type and sample time;
• Simulink solver and step-size configuration;
• event and zero-crossing timing;
• switches, contacts, limits, and discontinuities encountered;
• parameter and variant selections;
• the numerical convergence behavior observed during that run.

If the FMU encounters a slightly different operating point or event sequence, the nonlinear solve can require an additional correction iteration.