One additional thing worth mentioning: we noticed that switching to the FBDF() solver allows the system to advance (though only a few steps, Fig1), and when combined with the soft diode model it actually gets further than before (Fig2). However, it still stops prematurely at some point during the simulation.
Edit: Following the SciML FAQ (Frequently Asked Questions Β· DifferentialEquations.jl) we started testing different solvers to see what happened. Using KenCarp4() with a very small fixed timestep the simulation runs to completion and the waveform looks correct:
If anyone could give us more details on why certain solvers handle this type of problem better than others we would really appreciate it, as we are more used to working with commercial software where this kind of solver sensitivity for power electronics circuits is not nearly as apparent. Understanding the reasoning behind it would help us make better choices going forward.
Thank you so much for taking the time to add this as an example, that is really helpful. And yes, the results look exactly like what we were expecting. So at least for these cases it is now clear that solver tolerances play a much more important role than we were used to from commercial tools, something we will definitely keep in mind going forward. Thanks a lot .
If not, perhaps itβs possible to blend the smooth-but-ill-conditioned Shockley with a small-but-not-too-small resistance Ron in series (to limit the di/dv derivative of the I-V curve when conducting) and a large-but-not-too-large resistance in parallel (to limit reverse voltage when blocked). Or as put in Modelica Standard Library, a small conductance Goff.
I feel that using resistive βnumerical snubberβ is safer than capacitors (unless of course the goal is to model a genuine physical snubber in the circuit), because I find it easier to reason about (how much voltage or current error does it bring for a given forward current or reverse voltage).
Absolutely, both my colleagues and I come from a commercial tools background and have relatively little experience with MTK and Julia in general, so the community support throughout this forum has been extremely valuable and we are genuinely grateful for it. On that note, if we manage to scale EMT simulations successfully using ModelingToolkit, we would love to contribute back by putting together a library of predefined electrical components with proper documentation, to make MTK more accessible and appealing for electrical engineering applications. It could even be worth exploring whether some of these models could be incorporated into the ModelingToolkitStandardLibrary directly.
We have been running more tests and managed to implement a three-phase rectifier like the one shown earlier in the thread. The code and load current waveform are attached below so you can get an idea of the results. Note that to get the simulation to start we used ramped voltage sources, as suggested by @langestefan.
When comparing these results against Simulink there were no discrepancies, so we can consider this validated.
At this point we started wondering whether we could simulate the same diode rectifier but fed by a synchronous generator instead of ideal voltage sources. As a first step we implemented the system in Fig. 2, where the generator is driven by a constant torque and feeds resistive loads, just to verify the synchronous generator implementation on its own. Comparing those results with Simulink gave a perfect match, which is great.
However, problems arose when trying to combine the synchronous generator with the full bridge rectifier, we cannot get the system to converge. We have tried different solvers and so far none of them have worked (while the system in Simulink, Fig4, does work). At this point we are not sure whether there is a mistake somewhere in the definition of that last circuit that we are not catching, or whether there is still something about the solvers that we are missing. After spending the whole day on this, we are also willing to admit that fresh eyes might spot something obvious that we have been staring at for too long. Any ideas on how to approach this would be enormously helpful.
P.S.: You may wonder why in Code 2 the load is called Aload instead of simply load. As an extra curiosity, we noticed that depending on variable names, errors related to cyclic guesses can appear. For example, if load is used instead of Aload in Code 2, the following error shows up:
ERROR: Cyclic guesses detected in the system. Symbolic values were found for the following variables/parameters in the map:
genβpin_bβv(t) => 10.0genβia(t) - 10.0Initial(genβia(t)) - loadβpin_nβv(t) - loadβR_L*loadβpin_aβi(t)
In order to resolve this, please provide additional numeric guesses so that the chain can be resolved to assign numeric values to each variable.
...
I think this is again an initialization/numerical problem that more mature tools like simulink already have solutions for. Thatβs what you pay for in the end.
Thanks for the references, we will look into the cyclic guesses issue in more detail.
As a last attempt we tried several things at once: adding high-value resistors in parallel with the bridge diodes, clamping the diode exponential to make the switching less abrupt, adding a DC-side capacitor to smooth the system, and replacing the constant mechanical torque input to the synchronous machine with a ramp to ease initialization. Unfortunately the system still cannot complete the simulation.
We have to admit this is a bit of a disappointment, as there was quite a lot of excitement in our research group about the possibility of using ModelingToolkit for this kind of system. Hopefully it is just a matter of finding the right combination of tricks and we are not too far off.
To summarize where we stand: all the circuits we have tested with diodes and ideal voltage sources have ended up working. The synchronous machine with resistive load also works without issues. The problem appears specifically when combining the synchronous machine with the diode bridge. The three-phase rectifier on its own works too, with the only requirement being that the voltage sources need to ramp up slowly for initialization to succeed.
For the synchronous machine + diode bridge case, as you can see in the last plot, the system does initialize and starts running, but stops abruptly after just a few milliseconds. So it is not a complete failure, it gets going but cannot sustain the simulation.
Regarding the AI suggestion, we did try it, but honestly the most fruitful help so far has come from the contributions of everyone in this thread.
If it starts, then perhaps it is not an MTK problem, but a solver problem? Can you share the complete, failing example code? I would like to have a look at it myself.
And if the problem is that we are missing the right solver, then I would like to create an issue in the correct repository.
I think you are looking for a workaround; I am looking for a sustainable solution.
And this is the final system that initializes but stops abruptly.
Shall you need more information about the models, or if you encounter something that you may consider a mistake (which in that case, probably is) let me know so we cant try to make these kind of simulations work.
changed the plotting to ControlPlots (I need to be able to zoom in)
in the last example, I changed the solver to a fixed-step solver
The simulation finishes with a result and without any error message. The combined example has one warning, though:
β Warning: Did not converge after `maxiters = 100` substitutions. Either there \
β is a cycle in the rules or `maxiters` needs to be higher.
β @ Symbolics ~/.julia/packages/Symbolics/oZEAe/src/variable.jl:451
Thank you so much for putting this together, it should make investigating the problem much more comfortable for everyone. On our end we are looking into whether there is a way to make the system less stiff and continuing to dig into it to see if we can find the root cause or a working solution.
I donβt think any of the problems you have run into so far are unique to MTK. What we have learned, is that simulating circuits is non-trivial. And the industry standard tools must be doing a lot of βtricksβ to make it work out of the box for end users. Since MTK is not a tool dedicated to circuit analysis, it does not have those tricks available (yet). So disappointment isnβt the right response here. Especially if youβre in a research group, making existing tools better should be part of the job.
.
