LTspice singular matrix error by changing model parameters

Question

I am trying to create a model of an IGBT with the Z-model from LTspice.

Started with the default values it works. When I change parameters more and more I get the "singular matrix error" for certain combinations.

I make a DOE, i.e. I change every value plus/minus 10% and simulate every possible combination; 1024 combinations with 10 parameters. With the fractional method I reduced it to 64 combinations, mostly 60-63 run through and 1-4 make the error, i.e. similar values work.

I have already added Rs and Cs that make no sense electrically, but I have reduced the error rate from initially 25% to said 1-4 errors.

Does anyone have an idea what else can be done?

If I delete the schematic in the red box then the green boxed circuit will run; if the circuit in the red box is present I also have wrong results for the green boxed circuit.

I know that LTspice compiles one circuit in one matrix, and if anything goes wrong in the matrix it will also affect electrically independent things.

It is important to calculate the output characteristic Ic vs Uce and Uce max in the same schematic, because the optimizer handles only one schematic at a time.

Any idea for options or additional parts to fix this? .options noopiter or gmin=0 have no result to right directions.

===============================================

APPENDIX:

To allow a better understanding of what the problem is, here is my complete project with the simulation and the singular matrix error:

I defined the IGBT parameters as variables and changed this by a tool to simulate a fractional DOE table. The tool will write a netlist and start LTspice in batch mode, but with a single manual start of LTspice with the same IGBT parameters I have the same error; it is independent from the tool: the netlist is the same, the errors are the same.

When I simulate the circuit in the red box and the circuit in the green box separately I get no error.

Therefore I deleted one time the cicuit in the red and one time the circuit in the green, so I'm sure there is no difference between the circuits.

This is the table with the results for the green box, it is complete:

And this is the result for the red box, it is also complete:

If I simulate both together, red and green box in one schematic, the green box has the yellow marked errors, if I simulate these points manually I get a singular matrix error most times; sometimes LTspice chrashes.

I need both together because the optimizer which is running behind the DOE table has to find the output chracteristic and the max Uce voltage for given values in the datasheet. It can't run two separate files.

To find the max Uce voltage it is possible to change the current for I1, also to change it to a voltage source, but everything I tried has the error in some cases.

The results from the DOE table must be complete to create a valid transfer function for the optimizer.

I have changed times in a voltage source, have limited the max voltage otherwise there are even more problems

And although the DC sweep does not change anything when determining the max. voltage there are different results

And also here, although electrically not relevant with the DC Sweep, the capacitors have an influence on the results.

The procedure with the 65 setups is automated, it is an optimizer which creates a transfer function from the 65 setups for previously defined output variables, which are simulated with LTspice, from the results and the input variables. Then the input variables are defined in order to hit the target values for the output variables as well as possible via the transfer function. With these new variables a DOE table is created again and the whole thing is repeated, the number of iterations is defined by me, between 10 and 25, that means 650 to 1625 simulations and the solution must then work for all, without C's the error rate is >20% with C's it is ~3%, but that is then also no solution, it must be 0%.

Now for the reason why I didn't simulate it separately, the optimizer so far only works with a single netlist, from the one "LOG file" the results are then read. If I simulate it separately, I cannot take into account the mutual influence of the output characteristic and the max. voltage when creating the transfer function.

But it seems that the only solution is to change the optimizer to take into account the multiple netlists.

UPDATE: I have changed the optimizer so that several ltspice files can be called to collect the data for a setup. This means the determination of the max. voltage can be done separately from the output map in a separate simulation. The .op and .dc simulation only for the max. voltage did not bring the 100% success, there were less simulation errors but still too many. Changing R from 100n to 1m increased the number of errors, contrary to the theory that it is easier when the numbers are closer together. Capacities in the .op or .dc simulation actually have no influence on the error behavior of the simulator, but in the end are no solution when it has to run stable over hundreds of setups.

The last idea then was today, I do a .tran analysis and measure the DC voltage after the system is settled, this is not noticeably slower and so far over 400 simulations without errors Important the option "start external dc supply voltage at 0V", because at the operating point there were problems di must be bypassed

Regarding the simulation errors I have for 400 simulations no difference if I have the R's = 100n or Rg=1 and Rs=1m, both runs fine

It seems that the IGBT model is more robust for the transient simulation.

Update on further findings to follow

Answer 1

FWIW, here's how I tried your circuit:

A few things to note:

• I didn't use any R or C but, if I had to, I would resort to mΩ, not less (after all, you're already dealing with Amperes);
• The result you see there is the only one out of the 4 that needed pseudo-transient method in order to converge but, it did converge (after ~1 s or so) -- the rest went smooth, no problems but, those were the only parameters I used, no .STEP;
• You are using a 150° temperature which may push the numerical calculations behind the scenes, e.g. the parameters you see are intermediary and they set the values for internal quantities, which are temperature-dependent;

There's something that puzzles me, though: you're saying that, separately, the red and green circuit work but, you need to simulate them together. Why? The way I see it is you're sweeping the supply voltage source for reading the current but, the red circuit is very much "static", it has no variations. That one could be simulated at a single point, externally, and it wouldn't matter at all for the green circuit. And it can't be that you need some quantity to be read from red in order to use in in green, or vice-versa, since you are simulating them in the same circuit. If the red gives some reading to be used in a future run for the green (or vice-versa) then, again, you can run them in parallel just as well and consider n+1 for red and n for green (or vice-versa) -- it should be no difference. Unless there is something else?

Answer 2

Singular matrix means too few equations for the number of variables.

Usually a floating node (only capacitors or current sources connecting to it), or a loop of zero impedances (voltage sources or ideal inductors), is the culprit, though a huge dynamic range for the components can also cause trouble. I can't see any of those errors in the red box.

However, I don't see any definition of {R} and {C}. This should not matter if as they are finite, and not too many orders of magnitude away from the other components. Perhaps update your picture to show the whole simulation input.

Answer 3

The IGBT z-model in LT-spice is very critical in DC analysis, regardless of all parameters the error rate that the simulation aborts is in the range of 1% or higher. But there is a solution to the problem, one performs a transient analysis, here of course the variable variables must be changed so slowly that one makes a quasi static analysis. Decisive here, however, is to set the option STARTUP to determine the determination of the operating point alternative.

I have now simulated several thousand runs without errors or aborts.