Hi GRIDLAB-D Team,
I am sorry for bothering you and taking your time again
there is a problem with following program that has been shown in appendix.
this program is consist of two islands which has been connected by a switch (switch 37). when we open the switch, only in the island that is consist of "Bustype swing" , power is generated and generator dg in the other island does not generate any power.
in your opinion, what should be changed in order to solve this problem?
thanks a lot
Based on what you are describing, there are two answers. The first, and simplest, is "you can't do that right now". There's a caveat to this that I'll get into next, but the currently released versions of GridLAB-D do not support what you are suggesting. Basically, "current" functionality only maintains power to the side with the SWING bus. Anything beyond the swing is disconnected and ignored. To simulate two separate microgrids, you basically need to export the final state of the second island, then start a separate GLD simulation with those new parameters. Combining them back together can be a bit difficult, mostly relying on lots of players or external program applications. It's doable, but it is not easy to do and you could question the overall approach.
Now the caveat -- this is functionality we have developed and are currently testing. It exists only in a single GLD ticket branch (ticket 730), but has not been tested significantly yet.
THIS IS A DEVELOPMENT BRANCH AND SHOULD NOT BE CONSIDERED STABLE OR VALIDATED
As such, it might be completely unstable and do bad things to your results. Furthermore, the current implementation in ticket 730 is "all or nothing" on the powerflow. That is, even though it will allow you to separate into the two islands and solve them independently, if one of them goes unstable or has a powerflow convergence problem, the whole simulation fails. Our next step is to fix this limitation and handle individual powerflow failures in the different islands. However, the timeline on finishing that implementation and fully testing it is likely not until into next month (April), or later. Furthermore, this is only when the development would finish on that feature -- I have no idea on when its integration into a release branch and the subsequent release of that version (3.3 or 4.0) is scheduled to occur.
Hopefully that helps. The short answer is what you've described is "as intended" at the moment, and can only be worked around with some clever GridLAB-D usage, but the answers may still be questionable. The long answer is ticket 730 is developing the capability you mention, but it is in development and unsupported at this time. You are welcome to download ticket 730 and try it out, but little support will be offered, since it is a development branch and its stability/validity has not been confirmed.
-Frank
Last edit: Frank Tuffner 2016-03-08
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hello dear Frank,
thanks for your kindness, i want to simulate attached paper
so as you mentioned befor, it not possible to islanding via gridlab v3.1
but in this paper used islanding in gridlabD , how they do that?
tanks a lot,
saman zandi
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I am not explicitly familiar with the work in that paper, but I have seen some of the results and approach. As I understand it, they were basically using a variation of the earlier method I mentioned where you start a new simulation every time you create a new island. i.e., new "islands" of operation become separate GLMs to evaluate. In the version of the work I saw, they had a MATLAB script that coordinated the executions of GridLAB-D, creation of these new GLM files, and the overall compilation of the results (on top of their reconfiguration algorithms).
If you require more detail, I'd suggest contacting the authors of the paper, since they obviously will know what they did (I'm only speculating based on what I saw).
-Frank
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hello GRIDLAB-D Team
I'm having trouble with islanding the system in gridlab-d, I found (test_multi_island.glm), but Actually in this example, I did not understand the concept of islanding.
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, 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, I use the latest version of gridlab-d.
Please guide me in this case, what should I do?
Thank you very much
-mohamad.ghaleshakhani
//4-node-esque system to test multiple islands/solutions approach
//Simple test for multi-islanding capability
//Three systems, two with islanding capability, one that should be removed
//Event-mode test
#set suppress_repeat_messages=0
#set profiler=1
#set dateformat=US
#define rotor_convergence=0.001
#set deltamode_timestep=100000000 //100 ms
#set deltamode_maximumtime=60000000000 //1 minute
clock {
timezone "PST+8PDT";
starttime '2000-01-01 00:00:00 PST';
stoptime '2000-01-01 00:01:50 PST';
}
module tape;
module powerflow {
enable_subsecond_models true;
deltamode_timestep 10000000; //10 ms
solver_method NR;
};
module generators {
enable_subsecond_models TRUE;
deltamode_timestep 10000000; //Initial value - dictates how we want the models to run
}
module reliability {
enable_subsecond_models TRUE;
deltamode_timestep 10000000; //Initial value - dictates how we want the models to run
}
;
//Fault check option
object fault_check {
name base_fault_check_object;
check_mode ONCHANGE;
//strictly_radial false;
eventgen_object testgendev;
grid_association true; //Flag to ensure non-monolithic islands
}
//Manual object - open the "tie switches"
object eventgen {
name testgendev;
fault_type "SW-ABC"; //Type of fault for the object to induce
manual_outages "switch3_3B,2000-01-01 00:00:05,2000-01-01 00:00:30";
flags DELTAMODE;
}
object eventgen {
name testgendev_B;
fault_type "SW-ABC"; //Type of fault for the object to induce
manual_outages "switch2B_2C,2000-01-01 00:00:04,2000-01-01 00:00:35";
flags DELTAMODE;
}
//Switches, that would presumably make this three systems, eventually
object switch {
name switch3_3B;
phases ABCN;
from node3;
to node3B;
status CLOSED;
}
object switch {
name switch2B_2C;
phases ABCN;
from node2B;
to node2C;
status CLOSED;
}
object overhead_line_conductor {
name olc100;
geometric_mean_radius 0.0244 ft;
resistance 0.306 Ohm/mile;
}
object overhead_line_conductor {
name olc101;
geometric_mean_radius 0.00814 ft;
resistance 0.592 Ohm/mile;
}
object line_spacing {
name ls200;
distance_AB 2.5 ft;
distance_BC 4.5 ft;
distance_AC 7.0 ft;
distance_AN 5.656854 ft;
distance_BN 4.272002 ft;
distance_CN 5.0 ft;
}
object line_configuration {
name lc300;
conductor_A olc100;
conductor_B olc100;
conductor_C olc100;
conductor_N olc101;
spacing ls200;
}
object transformer_configuration {
name tc400;
connect_type WYE_WYE;
power_rating 6000;
primary_voltage 12470;
secondary_voltage 4160;
resistance 0.01;
reactance 0.06;
}
//First system
object meter {
name node1;
phases "ABCN";
bustype SWING;
nominal_voltage 7199.558;
flags DELTAMODE;
}
object overhead_line {
name ol12;
phases "ABCN";
from node1;
to node2;
length 2000;
configuration lc300;
}
object meter {
name node2;
phases "ABCN";
nominal_voltage 7199.558;
flags DELTAMODE;
}
object transformer {
name tran23;
phases "ABCN";
from node2;
to node3;
configuration tc400;
}
object meter {
name node3;
phases "ABCN";
nominal_voltage 2401.777;
flags DELTAMODE;
}
object overhead_line {
name ol34;
phases "ABCN";
from node3;
to load4;
length 2500;
configuration lc300;
}
object load {
name load4;
phases "ABCN";
constant_power_A +1275000.000+790174.031j;
constant_power_B +1800000.000+871779.789j;
constant_power_C +2375000.000+780624.750j;
nominal_voltage 2401.777;
flags DELTAMODE;
}
//Duplicate B
object meter {
name node1B;
phases "ABCN";
bustype SWING;
nominal_voltage 7199.558;
flags DELTAMODE;
}
object overhead_line {
name ol12B;
phases "ABCN";
from node1B;
to node2B;
length 2000;
configuration lc300;
}
object meter {
name node2B;
phases "ABCN";
nominal_voltage 7199.558;
flags DELTAMODE;
}
object transformer {
name tran23B;
phases "ABCN";
from node2B;
to node3B;
configuration tc400;
}
object meter {
name node3B;
phases "ABCN";
nominal_voltage 2401.777;
flags DELTAMODE;
}
object overhead_line {
name ol34B;
phases "ABCN";
from node3B;
to load4B;
length 2500;
configuration lc300;
}
object load {
name load4B;
phases "ABCN";
constant_power_A +1075000.000+790174.031j;
constant_power_B +1800500.000+871779.789j;
constant_power_C +2075000.000+780624.750j;
nominal_voltage 2401.777;
flags DELTAMODE;
// object recorder {
// property "voltage_A,voltage_B,voltage_C";
// interval -1;
// file load4Bout.csv;
// };
}
//Duplicate C -- No swing here, so it should get removed
object meter {
name node1C;
phases "ABCN";
nominal_voltage 7199.558;
flags DELTAMODE;
}
///
///
///
object diesel_dg {
parent node1C;
name Gen_Bus_1C;
Rated_V 12471;
Rated_VA 5000000;
flags DELTAMODE;
Gen_type DYN_SYNCHRONOUS;
rotor_speed_convergence ${rotor_convergence};
Exciter_type SEXS;
Governor_type GGOV1;
object recorder {
property rotor_speed,pwr_electric.real,pwr_electric.imag,pwr_mech;
flags DELTAMODE;
interval 1;
file "Gen_1_Speed.csv";
};
}
///
///
///
object overhead_line {
name ol12C;
phases "ABCN";
from node1C;
to node2C;
length 2000;
configuration lc300;
}
object meter {
name node2C;
phases "ABCN";
nominal_voltage 7199.558;
flags DELTAMODE;
}
object transformer {
name tran23C;
phases "ABCN";
from node2C;
to node3C;
configuration tc400;
}
object meter {
name node3C;
phases "ABCN";
nominal_voltage 2401.777;
flags DELTAMODE;
object recorder {
file node3C.csv;
flags DELTAMODE;
property voltage_A,measured_real_power,measured_reactive_power;
interval 1;
};
}
object overhead_line {
name ol34C;
phases "ABCN";
from node3C;
to load4C;
length 2500;
configuration lc300;
}
object load {
name load4C;
phases "ABCN";
constant_power_A +875000.000+0j;
constant_power_B +801000.000+0j;
constant_power_C +1605000.000+0j;
nominal_voltage 2401.777;
flags DELTAMODE;
// object recorder {
// property "voltage_A,voltage_B,voltage_C";
// interval -1;
// file load4Cout.csv;
// };
}
This all depends on what you mean by "islanding a system". The method shown here is dealing with steady-state solutions, which will always require a swing node to pick up any "left over" power needed to solve the equations. If you don't have an infinite bus, you run the risk of not being able to solve the system.
If you want the diesel device to reduce the swing node to zero power, then you will need to create the control algorithm that does that (or as most folks do, assume that the power at the swing node equals the generator output).
You can also go a layer deeper and look at machine dynamics during islanded operations. This requires a different mode in GridLAB-D and requires much more modeling depth. This allows you to model the electromechanical operations on the system, and would show you the actual effects of a generation shortfall or over-generation through a change in system frequency.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hello dear Jason Fuller
At first,thank you for your quick response.
And can you send an example (.glm file) that the local network is separated from the main network and supplied by the DGs (islanding mode)?
thanks a lot.
-Aro
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi GRIDLAB-D Team,
I am sorry for bothering you and taking your time again
there is a problem with following program that has been shown in appendix.
this program is consist of two islands which has been connected by a switch (switch 37). when we open the switch, only in the island that is consist of "Bustype swing" , power is generated and generator dg in the other island does not generate any power.
in your opinion, what should be changed in order to solve this problem?
thanks a lot
Last edit: saman zandi 2016-03-06
Hello Saman,
Based on what you are describing, there are two answers. The first, and simplest, is "you can't do that right now". There's a caveat to this that I'll get into next, but the currently released versions of GridLAB-D do not support what you are suggesting. Basically, "current" functionality only maintains power to the side with the SWING bus. Anything beyond the swing is disconnected and ignored. To simulate two separate microgrids, you basically need to export the final state of the second island, then start a separate GLD simulation with those new parameters. Combining them back together can be a bit difficult, mostly relying on lots of players or external program applications. It's doable, but it is not easy to do and you could question the overall approach.
Now the caveat -- this is functionality we have developed and are currently testing. It exists only in a single GLD ticket branch (ticket 730), but has not been tested significantly yet.
THIS IS A DEVELOPMENT BRANCH AND SHOULD NOT BE CONSIDERED STABLE OR VALIDATED
As such, it might be completely unstable and do bad things to your results. Furthermore, the current implementation in ticket 730 is "all or nothing" on the powerflow. That is, even though it will allow you to separate into the two islands and solve them independently, if one of them goes unstable or has a powerflow convergence problem, the whole simulation fails. Our next step is to fix this limitation and handle individual powerflow failures in the different islands. However, the timeline on finishing that implementation and fully testing it is likely not until into next month (April), or later. Furthermore, this is only when the development would finish on that feature -- I have no idea on when its integration into a release branch and the subsequent release of that version (3.3 or 4.0) is scheduled to occur.
Hopefully that helps. The short answer is what you've described is "as intended" at the moment, and can only be worked around with some clever GridLAB-D usage, but the answers may still be questionable. The long answer is ticket 730 is developing the capability you mention, but it is in development and unsupported at this time. You are welcome to download ticket 730 and try it out, but little support will be offered, since it is a development branch and its stability/validity has not been confirmed.
-Frank
Last edit: Frank Tuffner 2016-03-08
Hello dear Frank,
thanks for your kindness, i want to simulate attached paper
so as you mentioned befor, it not possible to islanding via gridlab v3.1
but in this paper used islanding in gridlabD , how they do that?
tanks a lot,
saman zandi
Hello Saman,
I am not explicitly familiar with the work in that paper, but I have seen some of the results and approach. As I understand it, they were basically using a variation of the earlier method I mentioned where you start a new simulation every time you create a new island. i.e., new "islands" of operation become separate GLMs to evaluate. In the version of the work I saw, they had a MATLAB script that coordinated the executions of GridLAB-D, creation of these new GLM files, and the overall compilation of the results (on top of their reconfiguration algorithms).
If you require more detail, I'd suggest contacting the authors of the paper, since they obviously will know what they did (I'm only speculating based on what I saw).
-Frank
Attachment removed due to potential copyright concerns -- paper linked is available via IEEE at: http://dx.doi.org/10.1109/PESGM.2015.7286551
Hello GRIDLAB-D Team
I'm having trouble with islanding the system in gridlab-d, I found (test_multi_island.glm), but Actually in this example, I did not understand the concept of islanding.
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, 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, I use the latest version of gridlab-d.
Please guide me in this case, what should I do?
Thank you very much
-mohamad.ghaleshakhani
//4-node-esque system to test multiple islands/solutions approach //Simple test for multi-islanding capability //Three systems, two with islanding capability, one that should be removed //Event-mode test #set suppress_repeat_messages=0 #set profiler=1 #set dateformat=US #define rotor_convergence=0.001 #set deltamode_timestep=100000000 //100 ms #set deltamode_maximumtime=60000000000 //1 minute clock { timezone "PST+8PDT"; starttime '2000-01-01 00:00:00 PST'; stoptime '2000-01-01 00:01:50 PST'; } module tape; module powerflow { enable_subsecond_models true; deltamode_timestep 10000000; //10 ms solver_method NR; }; module generators { enable_subsecond_models TRUE; deltamode_timestep 10000000; //Initial value - dictates how we want the models to run } module reliability { enable_subsecond_models TRUE; deltamode_timestep 10000000; //Initial value - dictates how we want the models to run } ; //Fault check option object fault_check { name base_fault_check_object; check_mode ONCHANGE; //strictly_radial false; eventgen_object testgendev; grid_association true; //Flag to ensure non-monolithic islands } //Manual object - open the "tie switches" object eventgen { name testgendev; fault_type "SW-ABC"; //Type of fault for the object to induce manual_outages "switch3_3B,2000-01-01 00:00:05,2000-01-01 00:00:30"; flags DELTAMODE; } object eventgen { name testgendev_B; fault_type "SW-ABC"; //Type of fault for the object to induce manual_outages "switch2B_2C,2000-01-01 00:00:04,2000-01-01 00:00:35"; flags DELTAMODE; } //Switches, that would presumably make this three systems, eventually object switch { name switch3_3B; phases ABCN; from node3; to node3B; status CLOSED; } object switch { name switch2B_2C; phases ABCN; from node2B; to node2C; status CLOSED; } object overhead_line_conductor { name olc100; geometric_mean_radius 0.0244 ft; resistance 0.306 Ohm/mile; } object overhead_line_conductor { name olc101; geometric_mean_radius 0.00814 ft; resistance 0.592 Ohm/mile; } object line_spacing { name ls200; distance_AB 2.5 ft; distance_BC 4.5 ft; distance_AC 7.0 ft; distance_AN 5.656854 ft; distance_BN 4.272002 ft; distance_CN 5.0 ft; } object line_configuration { name lc300; conductor_A olc100; conductor_B olc100; conductor_C olc100; conductor_N olc101; spacing ls200; } object transformer_configuration { name tc400; connect_type WYE_WYE; power_rating 6000; primary_voltage 12470; secondary_voltage 4160; resistance 0.01; reactance 0.06; } //First system object meter { name node1; phases "ABCN"; bustype SWING; nominal_voltage 7199.558; flags DELTAMODE; } object overhead_line { name ol12; phases "ABCN"; from node1; to node2; length 2000; configuration lc300; } object meter { name node2; phases "ABCN"; nominal_voltage 7199.558; flags DELTAMODE; } object transformer { name tran23; phases "ABCN"; from node2; to node3; configuration tc400; } object meter { name node3; phases "ABCN"; nominal_voltage 2401.777; flags DELTAMODE; } object overhead_line { name ol34; phases "ABCN"; from node3; to load4; length 2500; configuration lc300; } object load { name load4; phases "ABCN"; constant_power_A +1275000.000+790174.031j; constant_power_B +1800000.000+871779.789j; constant_power_C +2375000.000+780624.750j; nominal_voltage 2401.777; flags DELTAMODE; } //Duplicate B object meter { name node1B; phases "ABCN"; bustype SWING; nominal_voltage 7199.558; flags DELTAMODE; } object overhead_line { name ol12B; phases "ABCN"; from node1B; to node2B; length 2000; configuration lc300; } object meter { name node2B; phases "ABCN"; nominal_voltage 7199.558; flags DELTAMODE; } object transformer { name tran23B; phases "ABCN"; from node2B; to node3B; configuration tc400; } object meter { name node3B; phases "ABCN"; nominal_voltage 2401.777; flags DELTAMODE; } object overhead_line { name ol34B; phases "ABCN"; from node3B; to load4B; length 2500; configuration lc300; } object load { name load4B; phases "ABCN"; constant_power_A +1075000.000+790174.031j; constant_power_B +1800500.000+871779.789j; constant_power_C +2075000.000+780624.750j; nominal_voltage 2401.777; flags DELTAMODE; // object recorder { // property "voltage_A,voltage_B,voltage_C"; // interval -1; // file load4Bout.csv; // }; } //Duplicate C -- No swing here, so it should get removed object meter { name node1C; phases "ABCN"; nominal_voltage 7199.558; flags DELTAMODE; } /// /// /// object diesel_dg { parent node1C; name Gen_Bus_1C; Rated_V 12471; Rated_VA 5000000; flags DELTAMODE; Gen_type DYN_SYNCHRONOUS; rotor_speed_convergence ${rotor_convergence}; Exciter_type SEXS; Governor_type GGOV1; object recorder { property rotor_speed,pwr_electric.real,pwr_electric.imag,pwr_mech; flags DELTAMODE; interval 1; file "Gen_1_Speed.csv"; }; } /// /// /// object overhead_line { name ol12C; phases "ABCN"; from node1C; to node2C; length 2000; configuration lc300; } object meter { name node2C; phases "ABCN"; nominal_voltage 7199.558; flags DELTAMODE; } object transformer { name tran23C; phases "ABCN"; from node2C; to node3C; configuration tc400; } object meter { name node3C; phases "ABCN"; nominal_voltage 2401.777; flags DELTAMODE; object recorder { file node3C.csv; flags DELTAMODE; property voltage_A,measured_real_power,measured_reactive_power; interval 1; }; } object overhead_line { name ol34C; phases "ABCN"; from node3C; to load4C; length 2500; configuration lc300; } object load { name load4C; phases "ABCN"; constant_power_A +875000.000+0j; constant_power_B +801000.000+0j; constant_power_C +1605000.000+0j; nominal_voltage 2401.777; flags DELTAMODE; // object recorder { // property "voltage_A,voltage_B,voltage_C"; // interval -1; // file load4Cout.csv; // }; }Last edit: aro 2017-11-16
Aro,
This all depends on what you mean by "islanding a system". The method shown here is dealing with steady-state solutions, which will always require a swing node to pick up any "left over" power needed to solve the equations. If you don't have an infinite bus, you run the risk of not being able to solve the system.
If you want the diesel device to reduce the swing node to zero power, then you will need to create the control algorithm that does that (or as most folks do, assume that the power at the swing node equals the generator output).
You can also go a layer deeper and look at machine dynamics during islanded operations. This requires a different mode in GridLAB-D and requires much more modeling depth. This allows you to model the electromechanical operations on the system, and would show you the actual effects of a generation shortfall or over-generation through a change in system frequency.
Hello dear Jason Fuller
At first,thank you for your quick response.
And can you send an example (.glm file) that the local network is separated from the main network and supplied by the DGs (islanding mode)?
thanks a lot.
-Aro
For completeness (and further discussion), please see:
https://sourceforge.net/p/gridlab-d/discussion/842562/thread/6c00b077/
I believe you sent this question via email and I posted the response over there.
-Frank
Hello dear Frank
I have some other questions. I have expressed them here.
https://sourceforge.net/p/gridlab-d/discussion/842562/thread/6c00b077/
...
https://sourceforge.net/p/gridlab-d/discussion/842562/thread/6c00b077/#f56b
..
Thank you very much for your help and your advice.
-Aro