I found (test_multi_island.glm), but Actually in this example, I did not understand the concept of
islanding.
Question: In this example(test_multi_island.glm), I want to use diesel_dg to supply load4C (Figure 1)
but when switch2B_2C is open (manual_outages "switch2B_2C,2000-01-01 00:00:04,2000-01-01 00:00:35";) the output of
diesel_dg is zero and can not feed the load4C. (Figure 2), why !!
I want to feed the load4C by diesel_dg in islanding mode.
And please explain the concept of the (bustype SWING) in gridlabd??
I think that the concept of bustype SWING is infinite bus, and should not be used in Node1C.
What do I do to simulate correctly?
Also, I put the program code below.
Thank you very much
-mohamad
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The reason why your simulation fails has to deal with how islands are calculated and how the diesel_dg (or inverter) objects behave as sources.
By default, diesel_dg and inverter are "grid following" generation. They do not provide sourcing to the system in the event of a transmission system loss. The exception to this is if you are running in deltamode, which implies a microgrid.
Regarding SWING nodes: as you mention, SWING nodes are typically infinite buses, or a fixed voltage reference. However, this behavior is not necessarily persistent, depending on how you use them in GridLAB-D.
For static and quasi-steady-state/event-driven powerflow or simulations (i.e., not deltamode -- normal GridLAB-D), a SWING node is ALWAYS a fixed reference source in the powerflow (unless you adjust the voltage with a player, but it is still a fixed reference). One must be present on every islanded topology in your GLM, or it will remove that portion of the system and treat it as de-energized (which is what is happening with your diesel).
If you are doing a dynamic simulation, this changes a bit. If you run deltamode, a SWING bus starts as a SWING bus for the first few powerflow iterations of the simulation. This is to balance out the system and help a solution converge. After iterations to get to a feasible solution complete, the behavior of the SWING node depends on what is attached to it. If there is no appropriately configured diesel_dg or inverter attached to it, that node remains as a SWING node forever (a fixed voltage reference).
However, if you have an appropriately configured diesel_dg or inverter object attached and run deltamode, it is assumed you want to run this like a microgrid. After those initial powerflow iterations, the SWING node actually converts to a PQ bus. Your powerflow no longer has a fixed reference and requires the generator and loads to properly balance out. If you overload the system or change it too much, the powerflow will diverge, indicating a grid collapse.
Note that you can use a traditional SWING node (as a fixed voltage reference) and a SWING node with a diesel connected in the same topology. This way, if you open a switch and island the portion of the grid with the diesel, it will attempt to pick up all of the load and continue along. When grid-connected, it will still try to dispatch its output based on the control parameters, but may "fight" the fixed-reference SWING node.
For the file you mention to work with a diesel supplying the third branch, you have to do two things. The first is to enable deltamode on this file (since event-driven doesn't support it). Then, you must flag that attached bus as a SWING node too, knowing that it will get converted to a PQ bus right at the beginning of the simulation.
The basic functionality you are trying to replicate may work in the future. There is a flag in node objects (has_source) that is supposed to keep islanded sections active, if there is generation. However, this code is not working properly at this time, which is why the example you tried failed, as-is. We hope to have that fixed in a future version of GridLAB-D.
-Frank
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hello dear Frank
Thank you very much, you have read my question carefully and your advice was very good and complete.
After your guidance, I worked on the following network in deltamode (Figure 1). I put two switches (swBUS_2to_1) and (swBUS_2to_load) in the system. (BUS_1= bustype SWING) and (BUS_2= bustype SWING).
In t=8, I opened two switches and the load was only supplied by the first generator (Diesel_dg1). As you said, the bus_1 acts like a PQ bus and that node does not remains as a SWING node (a fixed voltage reference).
Is this simulation correct for islanding mode? (Time between t=8 and t=12)
(code: islanding_test_deltamode_diesel_dg.glm)
Figure 1
I also have some other questions:
question1: How to determine the amount of generator active power in GRIDLA_D?
For example, Output power equal to 50KW (all three phases), and not like the following code, that power be written for each phase separately.
How do I write the code?
question2: When (BUS_2 and BUS_1) are (bustype SWING). Output of two generators is as follows:
When only (BUS_2) is (bustype SWING). Output of two generators is as follows:
you said, If I run deltamode in GRIDLAB_D, a SWING bus starts as a SWING bus for the first few powerflow iterations of the simulation and this is to balance out the system and help a solution converge, but here, with the addition of the SWING bus, the outputs value (Diesel_dg1 & Diesel_dg2) is different. I do not know why?
(code: test_deltamode_diesel_dg.glm)
question3: does GRIDLAB_D tell anything about the cause of the grid collapse?
Regarding your new system (with the switch opening at t=8 seconds and closing at t=12 seconds), you do appear to have your GLM set up properly to do this operation. I only have two comments on your file.
The first is to specify two-digit seconds. Putting in 00:00:8 seems to work fine, but always makes me nervous. Specifying it as 00:00:08 helps ensure the interpreter doesn't do anything odd with it.
The second comment is on the response. Note that your output generator speed seems a bit odd (converging back to around 62 Hz). The simulation may need to just run for a bit longer, but you may also have the generators overloaded (in which case they behave oddly). If you're using the base autotest file, this is likely the case -- that autotest has the generators overloaded (I'm in the process of fixing it, so a bad example isn't floating around).
For your actual questions:
1) To determine the output of the generator, your two options in 4.0 are to either look at the pwr_electic with a recorder (as you do in question 2), or to put a recorder on a line or switch that only goes to the diesel. You can put a recorder on the power_out_A...power_out_C variables to get the unbalanced output amount. Theoretically, you can use a meter object to record these too, but there is a known bug I am finishing up the fixes for where diesel_dg and inverter (in VSI mode) do not properly post to meter objects. The powerflow is correct, but measured power is missing their contributions, until you go one line higher in the topology. This will be fixed here within the next week, but will likely only be in /develop and /feature/730 until we push a patch to 4.0 or a new release (4.1).
A note on the power_out_A-type values (and this ties into question 2) -- these are the initial values for the diesel_dg objects when deltamode starts. If that generator is on a SWING bus, these values will be over-written by the proper powerflow balance. These only serve as the "dispatched output" when applied to a PQ bus.
2) This is due to the comment I just made above. When you have a SWING bus in deltamode, it remains a SWING node for the first couple iterations of powerflow (to balance the system). After it feels it has reached a convergence point, it basically converts to a PQ bus. At this point, it also has updated the power output of the diesel generator attached to that point, and the full synchronous machine equations take over. As such, when you have both generators attached to a SWING node, the system is trying to find an equilibrium and changes both generator outputs. If the system were perfectly symmetrical (no cross-coupling in the lines or anything), they should theoretically converge to the same output (half the load). However, the system isn't that balanced, so a little bit of a mismatch occurs. When you only have bus_2 as the SWING, it is the only one balancing the system (and generator 1 is the dispatched value you have in the GLM). That's why its value only changes (and also why it is different than the initial dispatch you put into power_out_A...power_out_C).
3) Unfortunately, GridLAB-D doesn't provide any real indication of why the grid collapsed. In general, the only output you get is something akin to "powerflow failed", but that can happen for multiple reasons. Your best bet is to have recorders scattered in the system and examine the behavior. If you have proper line limits on all the line objects, line overloads can provide some clues too (i.e., if the lines suddenly are 500% overloaded, it is a good indication the system is going unstable). Otherwise, you have to extract why the failure occurred from looking at the voltage values, machine states (e.g., rotor speed) and power values on the system. You could probably create a heuristic-type object to help determine the cause, but it isn't something we have any near-term plans to develop. At this point, it is all post-processing and "engineering judgment" to figure out the reason for the failure.
-Frank
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Question received via email:
I found (test_multi_island.glm), but Actually in this example, I did not understand the concept of
islanding.
Question: In this example(test_multi_island.glm), I want to use diesel_dg to supply load4C (Figure 1)
but when switch2B_2C is open (manual_outages "switch2B_2C,2000-01-01 00:00:04,2000-01-01 00:00:35";) the output of
diesel_dg is zero and can not feed the load4C. (Figure 2), why !!
I want to feed the load4C by diesel_dg in islanding mode.
And please explain the concept of the (bustype SWING) in gridlabd??
I think that the concept of bustype SWING is infinite bus, and should not be used in Node1C.
What do I do to simulate correctly?
Also, I put the program code below.
Thank you very much
-mohamad
Hello Mohamad,
The reason why your simulation fails has to deal with how islands are calculated and how the diesel_dg (or inverter) objects behave as sources.
By default, diesel_dg and inverter are "grid following" generation. They do not provide sourcing to the system in the event of a transmission system loss. The exception to this is if you are running in deltamode, which implies a microgrid.
Regarding SWING nodes: as you mention, SWING nodes are typically infinite buses, or a fixed voltage reference. However, this behavior is not necessarily persistent, depending on how you use them in GridLAB-D.
For static and quasi-steady-state/event-driven powerflow or simulations (i.e., not deltamode -- normal GridLAB-D), a SWING node is ALWAYS a fixed reference source in the powerflow (unless you adjust the voltage with a player, but it is still a fixed reference). One must be present on every islanded topology in your GLM, or it will remove that portion of the system and treat it as de-energized (which is what is happening with your diesel).
If you are doing a dynamic simulation, this changes a bit. If you run deltamode, a SWING bus starts as a SWING bus for the first few powerflow iterations of the simulation. This is to balance out the system and help a solution converge. After iterations to get to a feasible solution complete, the behavior of the SWING node depends on what is attached to it. If there is no appropriately configured diesel_dg or inverter attached to it, that node remains as a SWING node forever (a fixed voltage reference).
However, if you have an appropriately configured diesel_dg or inverter object attached and run deltamode, it is assumed you want to run this like a microgrid. After those initial powerflow iterations, the SWING node actually converts to a PQ bus. Your powerflow no longer has a fixed reference and requires the generator and loads to properly balance out. If you overload the system or change it too much, the powerflow will diverge, indicating a grid collapse.
Note that you can use a traditional SWING node (as a fixed voltage reference) and a SWING node with a diesel connected in the same topology. This way, if you open a switch and island the portion of the grid with the diesel, it will attempt to pick up all of the load and continue along. When grid-connected, it will still try to dispatch its output based on the control parameters, but may "fight" the fixed-reference SWING node.
For the file you mention to work with a diesel supplying the third branch, you have to do two things. The first is to enable deltamode on this file (since event-driven doesn't support it). Then, you must flag that attached bus as a SWING node too, knowing that it will get converted to a PQ bus right at the beginning of the simulation.
The basic functionality you are trying to replicate may work in the future. There is a flag in node objects (has_source) that is supposed to keep islanded sections active, if there is generation. However, this code is not working properly at this time, which is why the example you tried failed, as-is. We hope to have that fixed in a future version of GridLAB-D.
-Frank
Hello dear Frank
Thank you very much, you have read my question carefully and your advice was very good and complete.
After your guidance, I worked on the following network in deltamode (Figure 1). I put two switches (swBUS_2to_1) and (swBUS_2to_load) in the system. (BUS_1= bustype SWING) and (BUS_2= bustype SWING).
In t=8, I opened two switches and the load was only supplied by the first generator (Diesel_dg1). As you said, the bus_1 acts like a PQ bus and that node does not remains as a SWING node (a fixed voltage reference).
Is this simulation correct for islanding mode? (Time between t=8 and t=12)
(code: islanding_test_deltamode_diesel_dg.glm)
Figure 1
I also have some other questions:
question1: How to determine the amount of generator active power in GRIDLA_D?
For example, Output power equal to 50KW (all three phases), and not like the following code, that power be written for each phase separately.
How do I write the code?
question2: When (BUS_2 and BUS_1) are (bustype SWING). Output of two generators is as follows:
When only (BUS_2) is (bustype SWING). Output of two generators is as follows:
you said, If I run deltamode in GRIDLAB_D, a SWING bus starts as a SWING bus for the first few powerflow iterations of the simulation and this is to balance out the system and help a solution converge, but here, with the addition of the SWING bus, the outputs value (Diesel_dg1 & Diesel_dg2) is different. I do not know why?
(code: test_deltamode_diesel_dg.glm)
question3: does GRIDLAB_D tell anything about the cause of the grid collapse?
thanks a lot
-Aro
Hello Aro,
Regarding your new system (with the switch opening at t=8 seconds and closing at t=12 seconds), you do appear to have your GLM set up properly to do this operation. I only have two comments on your file.
The first is to specify two-digit seconds. Putting in 00:00:8 seems to work fine, but always makes me nervous. Specifying it as 00:00:08 helps ensure the interpreter doesn't do anything odd with it.
The second comment is on the response. Note that your output generator speed seems a bit odd (converging back to around 62 Hz). The simulation may need to just run for a bit longer, but you may also have the generators overloaded (in which case they behave oddly). If you're using the base autotest file, this is likely the case -- that autotest has the generators overloaded (I'm in the process of fixing it, so a bad example isn't floating around).
For your actual questions:
1) To determine the output of the generator, your two options in 4.0 are to either look at the pwr_electic with a recorder (as you do in question 2), or to put a recorder on a line or switch that only goes to the diesel. You can put a recorder on the power_out_A...power_out_C variables to get the unbalanced output amount. Theoretically, you can use a meter object to record these too, but there is a known bug I am finishing up the fixes for where diesel_dg and inverter (in VSI mode) do not properly post to meter objects. The powerflow is correct, but measured power is missing their contributions, until you go one line higher in the topology. This will be fixed here within the next week, but will likely only be in /develop and /feature/730 until we push a patch to 4.0 or a new release (4.1).
A note on the power_out_A-type values (and this ties into question 2) -- these are the initial values for the diesel_dg objects when deltamode starts. If that generator is on a SWING bus, these values will be over-written by the proper powerflow balance. These only serve as the "dispatched output" when applied to a PQ bus.
2) This is due to the comment I just made above. When you have a SWING bus in deltamode, it remains a SWING node for the first couple iterations of powerflow (to balance the system). After it feels it has reached a convergence point, it basically converts to a PQ bus. At this point, it also has updated the power output of the diesel generator attached to that point, and the full synchronous machine equations take over. As such, when you have both generators attached to a SWING node, the system is trying to find an equilibrium and changes both generator outputs. If the system were perfectly symmetrical (no cross-coupling in the lines or anything), they should theoretically converge to the same output (half the load). However, the system isn't that balanced, so a little bit of a mismatch occurs. When you only have bus_2 as the SWING, it is the only one balancing the system (and generator 1 is the dispatched value you have in the GLM). That's why its value only changes (and also why it is different than the initial dispatch you put into power_out_A...power_out_C).
3) Unfortunately, GridLAB-D doesn't provide any real indication of why the grid collapsed. In general, the only output you get is something akin to "powerflow failed", but that can happen for multiple reasons. Your best bet is to have recorders scattered in the system and examine the behavior. If you have proper line limits on all the line objects, line overloads can provide some clues too (i.e., if the lines suddenly are 500% overloaded, it is a good indication the system is going unstable). Otherwise, you have to extract why the failure occurred from looking at the voltage values, machine states (e.g., rotor speed) and power values on the system. You could probably create a heuristic-type object to help determine the cause, but it isn't something we have any near-term plans to develop. At this point, it is all post-processing and "engineering judgment" to figure out the reason for the failure.
-Frank
Hello dear Frank
Thank you very much
-Aro