Integrating MMC in IEEE 9 bus system

Hello to fellow MATLAB users. I am studying electrical engineering and not so familiar with MATLAB and Simulink. Therefore I need your help.

I want to integrate a MMC system into IEEE 9 bus system to study how fault current behaves when an AC transmission line is replaced with a HVDC link. More specifically I want to integrate simscapeelectrical/ModularMultilevelConverterHVDCTransExample between bus 4 and bus 6 in simscapeelectrical/IEEE9BusSystemExample. However, I am at a dead end right now, no matter what I try I can't get it right. I'd appreciate if you could guide me on how to tackle this problem.

Answer 1

[Umar]

Hi @Mojtaba,

I had a look at both examples you mentioned and I think I can see exactly where you're getting stuck — so hopefully this helps.

The short version: the reason nothing works no matter what you try is almost certainly because Simscape's built-in load flow solver doesn't recognize power electronic switches. The moment you drop the MMC in, it sees the HVDC link as an open circuit and the whole initialization falls apart. That's not your fault — it's a known limitation and it trips up a lot of people.

Here's how I'd approach it:

1. Open both examples side by side using openExample('simscapeelectrical/IEEE9BusSystemExample') and openExample('simscapeelectrical/ModularMultilevelConverterHVDCTransExample') in the MATLAB Command Window.

2. Before you delete anything, run the 9-bus model as-is and note the power flow on the Bus 4–6 line. You'll need those numbers later to set your MMC power references correctly.

3. Delete the Bus 4–6 AC transmission line and replace it with the MMC subsystem from the second example — sending end at Bus 4, receiving end at Bus 6. Make sure you're connecting through the Simscape physical ports (the blue ones), not regular Simulink signal wires. Also double-check that your transformer voltage levels match up — the 9-bus runs at 230 kV AC and the MMC example uses 400 kV DC, so you'll need interface transformers configured accordingly.

4. Don't rely on the load flow for initialization. Instead, start the simulation from t=0 with a slowly ramping power reference on the MMC and let the system find its own steady state. Once it settles, then you can start injecting faults.

5. For the solver, switch to ode23tb or ode15s — stiff solvers handle these hybrid AC/DC models much better.

A couple of things to watch out for down the road: once you get the model running, the next challenge will be tuning the PI controllers inside the MMC to match your 9-bus operating conditions. If they're off, you'll get oscillations even if everything is wired correctly. And when you get to the actual fault current analysis, you'll want to think about where you're placing your current sensors and what you're comparing — the MMC behaves very differently from an AC line during a fault because of its built-in current-limiting characteristics.

Let me know how it goes.

Good luck!

[Mojtaba]

Hi @Umar. Thank you very much for the reply. I have done the setup according to the instructions. However, the problem still persists. Simulink throws an error on the configuration of the DC cable. Here is what it complains about

[Umar]

Hi @Mojtaba,

The error you posted actually gives me a much more specific diagnosis, so let me fill in the gaps.

The reason the DC cable is failing is that the cable_dc_single block uses travel-time delay equations that are fundamentally incompatible with Simscape's Frequency and Time equation formulation. That mode is designed purely for AC systems with a single sinusoidal source at a fixed nominal frequency. A DC cable has neither, so Simscape throws the error you're seeing. You can read the exact constraint in the MathWorks docs here: Frequency and Time Simulation Mode.

https://www.mathworks.com/help/simscape/ug/frequency-and-time-simulation.html

The fix that wasn't covered yet is that your model now has two physically separate networks — an AC side and a DC side — and each one needs its own Solver Configuration block with different settings. Simscape explicitly supports this. You set the AC side, which covers the generators, buses and transformers, to Frequency and Time as before, and you set the DC side, which covers the cable and MMC converters, to Time only. To do this, just drag a second Solver Configuration block from the Simscape Utilities library and wire it anywhere into the DC physical network. The full details are in the Solver Configuration docs here: Solver Configuration.

https://www.mathworks.com/help/simscape/ref/solverconfiguration.html

On the initialization side, my suggestion to ramp up from t=0 is the right instinct, but the MMC example you're already using actually ships with a dedicated script that does this properly. It's called ModularMultilevelConverterHVDCTransInitializeModel and you'll find it inside the example. It simulates the model to steady state at t=1s, captures a Simscape OperatingPoint object, and feeds it back as the starting condition for your actual run. This is far more reliable than a manual ramp, especially once you start injecting faults. You can find the full walkthrough here: Model High-Voltage Direct-Current Transmission Using Modular Multilevel Converters.

https://www.mathworks.com/help/sps/ug/high-voltage-direct-current-transmission-with-modular-multilevel-converters.html

One last thing worth mentioning is that the MMC example supports two fidelity levels, an average-value model which is low fidelity and an equivalent-switching model which is high fidelity. For now, use the low fidelity average-value model. It runs much faster and will let you confirm everything is wired correctly before you switch to the high fidelity version for the actual fault current waveforms. You configure this by running ModularMultilevelConverterHVDCTransVariantControl from the MATLAB command window.

Hope that unblocks you. The two Solver Configuration block fix should resolve the error in your screenshot straight away. Let me know how it goes.

[Mojtaba]

Thank you for the response @Umar. I tried to run the model with 2 Solver Configuration blocks, but it seems that does not work. The two grids are physically connected and two different Configuration blocks would lead to conflict for the Solver. The most frustrating part is that if you do small modifications on the control system of the converter, then an error will be gauranteed.

[Umar]

Hi @Mojtaba,

Thank you for the update — and you are absolutely right about the two Solver Configuration blocks not working. We should not have suggested that without fully verifying it first, and we apologise for the confusion it caused.

Before giving you any further guidance, I want to understand exactly where you are right now, so I do not send you in the wrong direction again. Could you help me with three quick questions?

1. In your current Solver Configuration block, what is the Equation Formulation set to — is it Frequency and Time, or Time?

2. Have you run the ModularMultilevelConverterHVDCTransInitializeModel script that ships with the MMC example? If yes, at what point in your setup did you run it?

3. When you say that small modifications to the control system are guaranteed to cause an error — could you share the exact error message you are seeing? Even a screenshot like the one you posted earlier would be very helpful.

Looking forward to your reply.

[Mojtaba]

Hi @Umar. The Solver Configuration in IEEE 9-bus system is currently set to Frequency and Time. If I change it to Time the model will become inconsistent. I played around a lot with the model, the solver type does not seem to cause any issues so it can be set to either fixed or variable.

About Q 2, I ran it after simulation was done. About Q 3, I don't have the exact message right now but I remember it was saying that a gain block in the control system behaves incorrectly.

I have come across the idea to change or rebuild the IEEE 9-bus system instead, that is, in a way that it become consistent with MMC. Do you think it is doable or maybe try harder on my first approach?

Thank you for helping me.

[Umar]

Hi @Mojtaba,

Thank you for answering those questions — they were very helpful and they actually explain a lot.

On the gain block error, we are fairly confident we know what is causing it. The initialization script is designed to run first, not last. What it does internally is simulate the model to steady state, capture an OperatingPoint object from that simulation data, and then configure the model to use that operating point as the starting condition for all subsequent runs. If you run the script after you have already been simulating and modifying the model, the operating point it captures reflects the model in whatever state it was in at that moment. So any time you change something in the control subsystem after that, the stored operating point becomes inconsistent with the new control configuration, and that is almost certainly why the gain block misbehaves. The fix is straightforward — any time you modify the control system, you must re-run the initialization script before simulating again. It needs to be treated as a mandatory step every time the model changes, not a one-time setup.

On the Frequency and Time versus Time conflict, you are correct that switching to Time breaks the 9-bus model. The reason is that the 9-bus generators rely on sinusoidal steady-state initialization, which only works in Frequency and Time mode. Switching to Time mode removes that initialization pathway, so the generators start from inconsistent initial conditions and the model falls apart.

Regarding your question about rebuilding the 9-bus — this is actually a sound idea and in our view it is the cleaner long-term path. The IEEE 9-Bus System documentation explains that you can retrieve the exact initial field circuit voltage, field circuit current, and mechanical torque for each generator by right-clicking the synchronous machine block and selecting Electrical > Display Associated Initial Conditions. If you record those values and specify them explicitly in the generator block parameters, the 9-bus model can run correctly in Time mode without needing the Frequency and Time sinusoidal initialization at all. At that point, your entire model runs in Time mode, the DC cable conflict disappears, and you have one clean Solver Configuration block that governs everything consistently.

So to directly answer your question — yes, rebuilding is doable and we think it is the better path forward. The current approach can technically work, but it requires fighting the solver formulation conflict every step of the way. The rebuild approach resolves that conflict at the root.

The steps we would suggest are: 1. Run the original 9-bus model as-is and use Display Associated Initial Conditions on each synchronous machine to get the initialization values. 2. Record those values before you change anything. 3. Rebuild the 9-bus with those values explicitly set in the generator initial conditions, switch the Solver Configuration to Time, and verify the 9-bus runs correctly on its own. 4. Then integrate the MMC subsystem into that Time-mode 9-bus. 5. From that point, treat the initialization script as a mandatory step before every simulation run.