Gridlab-D version: GridLAB-D 3.0.0-4522 (Hassayampa) 64-bit LINUX RELEASE
I tried to set the status of Switch (671-692) to OPEN, while the 13 node demo running in real-time server mode. However that seems not work. I use command 'wget http://localhost:6267/671-692/status=OPEN -q -O -'.
Furthermore, I tried to set status to 'OPEN' with players in Switch. That works, but shows lots of WARNING.
So is that possible to change switch status while real-time server mode is running?
Hope for your help!
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hello Kenny,
It should be possible to set the switch status in real-time server mode, but you may be encountering some oddities in how things are executed. You mention that a lot of warning show up when you open the switch using a player. This prompts a variety of questions:
Can you post one of those messages?
Which solver method are you utilizing: Forward-Backward Sweep (FBS) or Newton-Raphson (NR)? The two different solvers often have their own little quirks related to how they handled switches.
Is it possible to post your file up to the forums (you mention it is the 13-node example, but the specific file may help in tracking down what is going on).
If you can provide this information, it will help us track down what is going on.
-Frank
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Thank you for your reply. I paste one of WARNING as below:
WARNING [2014-11-18 20:46:13 UTC] : house3C_tm_C_3_675 - house:386 is outside of ANSI standards (voltage = 10 percent of nominal 120/240)
Then I do test real-time server mode for 13-node example again. I found the status of Switch could only be changed at the initialization period. While simulation is running, this value could not be modified.
Hello Kenny,
The ANSI warnings are probably normal, though a little surprising. They are theoretically coming from houses disconnected from the switch opening, though they should be 0%, not 10%. To get a proper "0%" response, you may need to look into using the reliability module. I'm not sure how well this module works with server mode.
In terms of only being able to modify switch states during INIT on the server mode run, we'll have to look into that. I wouldn't expect the server mode to behave that way, so this may be a bug we need to track down. We'll try to keep you updated on progress, but the upcoming holiday next week may delay a definitive response.
-Frank
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I toyed around with this, and found that it actually is changing the switch status to OPEN if you spam the wget requests, but promptly resets it back to CLOSED right afterwards. Try it a dozen or so times and you will see a reply from the server occasionally indicating the switch is indeed OPEN.
I am using version 3.1, and the same IEEE 13 node test model and targeting the same switch. Maybe it is something about the model (I am learning gridlabd), or maybe it is a bug resetting the switch status after each iteration.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Per another thread, I wasn't able to get the manipulation of the switch objects to occur with the web-server interface (though admittedly, I don't know all the details of how to use it and may be missing something).
To do the player example in realtime, I've attached your earlier 13-node case with a player. The main thing to note here is the time for the player - it appears there may be some issues with it where the time for the player needs to be basically GMT offset for the timezone again. For example, the files attached were running in realtime mode on my computer at 11:52 AM PDT. However, the player needs to be for 2:52 AM the next day (15 hour offset, basically) -- this is probably a bug in how players are working that we need to look into, but I wanted to toss that detail out here.
As a note, someone pointed out the problem with the player times is actually the timezone specification.
It should be:
timezone PST+8PDT;
The PST-8PDT designation is not correct, which is why the player was having issues. Once it is set to the proper timezone, player values associated with you location's timezone work properly (no odd 15-hour offsets).
-Frank
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Dear Frank Tuffner,
Thanks for your detailed answer about player and switch.
By using your mentioned method, I find that I can control IEEE13node, however, I can't control IEEE123node correctly. No matter I run gridlabd realtime or not realtime.
The 13node model is from "branch\3.2\powerflow\tests\13node\IEEE-13.glm", and 123node model is from "branch\3.2\powerflow\tests\123node\IEEE-123.glm".What I have changed is shown in attached picture "0-changed.png"
Q1(realtime): why I can control IEEE13node, but I can't control IEEE123node using the method you mentioned? Please see the following for details "1_IEEE-13-realtime.glm",'2_IEEE-123-case1-status-realtime.glm', '1_testoutput_13node.csv','2_testoutput_123node_case1.csv'
Q2(realtime): I can control IEEE123node by using "status,phase_A_state,phase_B_state,phase_C_state" at the same time, however, the power_in of switch is not 0 when the switch is OPEN, it's strange. Please see the following for details '3_IEEE-123-case2-status-phase_ABC_state-realtime.glm', '3_testoutput_123node_case2.csv'
Q3: when I control IEEE13node not realtime, it will repeat at the time switch is OPEN, I don't know why? Please see the following for details '4_IEEE-13-notreal.glm', '4_testoutput_13node.csv'
Q4: IEEE123node not realtime has the same question as Q1,Q2. Please see the following for details '5_IEEE-123-case1-status-notrea.glm', '5_testoutput_123node_case1.csv', '6_IEEE-123-case2-status-phase_ABC_state-notrea.glm', '6_testoutput_123node_case2.csv'
I'm just barely getting back to this, so I apologize for the delay in the response.
1) The IEEE 13-node example you provided is running the NR solver. The IEEE 123-node is running the FBS solver. The FBS method doesn't support a lot of the "disconnect" abilities. GridLAB-D actually puts up a warning message when it starts with FBS and a switch, indicating it does not always work properly and is not recommended.
2) This is likely a consequence of the solver method. Basically, it probably isn't registering as opening properly. Use NR for these types of operations.
3) I'm not sure I follow the question here. By "it will repeat", do you mean it gets stuck on that timestep and never moves? I don't see a fault_check object in the file anywhere, so it is probably trying to solve an infeasible power system and basically hitting the convergence limit.
4) This is probably the same answer as (1) and (2).
Basically, now that you appear to be able to control the switches, you need to add the fault_check and eventgen objects (part of powerflow and reliability, respectively) to get it to handle the topology changes properly. Unfortunately, they are not very well tested in realtime mode, so they may introduce their own set of issues.
-Frank
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi Frank
It's really so kind of you to answer my question.
Q1:The IEEE-123 node model you provide in "branch\3.2\powerflow\tests\123node\IEEE-123.glm" does not support NR to calculate powerflow, and has the following questions.
ERROR [2000-01-01 00:00:00 EST] : syncnode(obj=181;150): Newton-Raphson method is unable to converge to a solution at this operation point
ERROR [2000-01-01 00:00:00 EST] : 2000-01-01 00:00:00 EST: object 150 stopped its clock (exec)!
ERROR [2000-01-01 00:00:00 EST] : exec halted: synchronization failed
DEBUG [2000-01-01 00:00:00 EST] : main loop ended at -1; stoptime=946789200, nevents=1, exitcode=0
FATAL [2000-01-01 00:00:00 EST] : environment startup failed: Invalid argument
DEBUG [2000-01-01 00:00:00 EST] : exit code 2
DEBUG [2000-01-01 00:00:00 EST] : last debug message was repeated 1 times
So I used FBS, but FBS can't control switch successfully.
Q2: to the Q3 previous, what I means is that GLD will get stuck on the timestep when switch is OPEN and never move. But it's right with realtime. The following is what GLD shows when it gets stuck.
*DEBUG [2016-06-07 11:31:00 EST] : main loop event at 1465270260; stoptime=9223372036854775807, nevents=1, exitcode=0
DEBUG [2016-06-07 11:31:00 EST] : globalclock=1465270260
... Max solver mismatch of failed solution 2653.249729
... Newton-Raphson failed to converge, sticking at same iteration.
DEBUG [2016-06-07 11:31:00 EST] : main loop event at 1465270260; stoptime=9223372036854775807, nevents=1, exitcode=0
DEBUG [2016-06-07 11:31:00 EST] : globalclock=1465270260
... Max solver mismatch of failed solution 5664.207973
... Newton-Raphson failed to converge, sticking at same iteration.
Processing 2016-06-07 11:31:00 EST...
DEBUG [2016-06-07 11:31:00 EST] : main loop event at 1465270260; stoptime=9223372036854775807, nevents=1, exitcode=0
DEBUG [2016-06-07 11:31:00 EST] : globalclock=1465270260
... Max solver mismatch of failed solution 238613.741255
... Newton-Raphson failed to converge, sticking at same iteration.**
Thanks for your help,Frank
Jsh
Last edit: jsh 2016-06-15
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi,
Gridlab-D version: GridLAB-D 3.0.0-4522 (Hassayampa) 64-bit LINUX RELEASE
I tried to set the status of Switch (671-692) to OPEN, while the 13 node demo running in real-time server mode. However that seems not work. I use command 'wget http://localhost:6267/671-692/status=OPEN -q -O -'.
Furthermore, I tried to set status to 'OPEN' with players in Switch. That works, but shows lots of WARNING.
So is that possible to change switch status while real-time server mode is running?
Hope for your help!
Hello Kenny,
It should be possible to set the switch status in real-time server mode, but you may be encountering some oddities in how things are executed. You mention that a lot of warning show up when you open the switch using a player. This prompts a variety of questions:
If you can provide this information, it will help us track down what is going on.
-Frank
Hi Frank,
Thank you for your reply. I paste one of WARNING as below:
WARNING [2014-11-18 20:46:13 UTC] : house3C_tm_C_3_675 - house:386 is outside of ANSI standards (voltage = 10 percent of nominal 120/240)
Then I do test real-time server mode for 13-node example again. I found the status of Switch could only be changed at the initialization period. While simulation is running, this value could not be modified.
I use
wget http://localhost:10000/671-692/status=OPEN -q -O -
in order to open the switch (671-692) while simulation is running in real-time server mode.
Attached please find the .glm file.
Hello Kenny,
The ANSI warnings are probably normal, though a little surprising. They are theoretically coming from houses disconnected from the switch opening, though they should be 0%, not 10%. To get a proper "0%" response, you may need to look into using the reliability module. I'm not sure how well this module works with server mode.
In terms of only being able to modify switch states during INIT on the server mode run, we'll have to look into that. I wouldn't expect the server mode to behave that way, so this may be a bug we need to track down. We'll try to keep you updated on progress, but the upcoming holiday next week may delay a definitive response.
-Frank
Hi Frank,
I appreciate your help.
Xin
I toyed around with this, and found that it actually is changing the switch status to OPEN if you spam the wget requests, but promptly resets it back to CLOSED right afterwards. Try it a dozen or so times and you will see a reply from the server occasionally indicating the switch is indeed OPEN.
I am using version 3.1, and the same IEEE 13 node test model and targeting the same switch. Maybe it is something about the model (I am learning gridlabd), or maybe it is a bug resetting the switch status after each iteration.
Owen,
Thanks for the update. Most of our developers are off on holiday right now. We'll take a look as soon as we can.
Jason
Dear Jason,
I met the same question with Owen.
So how to use switch with realtime correctly? Could you please give me some examples?
Thanks
Hello again jsh,
Per another thread, I wasn't able to get the manipulation of the switch objects to occur with the web-server interface (though admittedly, I don't know all the details of how to use it and may be missing something).
To do the player example in realtime, I've attached your earlier 13-node case with a player. The main thing to note here is the time for the player - it appears there may be some issues with it where the time for the player needs to be basically GMT offset for the timezone again. For example, the files attached were running in realtime mode on my computer at 11:52 AM PDT. However, the player needs to be for 2:52 AM the next day (15 hour offset, basically) -- this is probably a bug in how players are working that we need to look into, but I wanted to toss that detail out here.
-Frank
As a note, someone pointed out the problem with the player times is actually the timezone specification.
It should be:
The PST-8PDT designation is not correct, which is why the player was having issues. Once it is set to the proper timezone, player values associated with you location's timezone work properly (no odd 15-hour offsets).
-Frank
Dear Frank Tuffner,
Thanks for your detailed answer about player and switch.
By using your mentioned method, I find that I can control IEEE13node, however, I can't control IEEE123node correctly. No matter I run gridlabd realtime or not realtime.
The 13node model is from "branch\3.2\powerflow\tests\13node\IEEE-13.glm", and 123node model is from "branch\3.2\powerflow\tests\123node\IEEE-123.glm".What I have changed is shown in attached picture "0-changed.png"
Q1(realtime): why I can control IEEE13node, but I can't control IEEE123node using the method you mentioned? Please see the following for details "1_IEEE-13-realtime.glm",'2_IEEE-123-case1-status-realtime.glm', '1_testoutput_13node.csv','2_testoutput_123node_case1.csv'
Q2(realtime): I can control IEEE123node by using "status,phase_A_state,phase_B_state,phase_C_state" at the same time, however, the power_in of switch is not 0 when the switch is OPEN, it's strange. Please see the following for details '3_IEEE-123-case2-status-phase_ABC_state-realtime.glm', '3_testoutput_123node_case2.csv'
Q3: when I control IEEE13node not realtime, it will repeat at the time switch is OPEN, I don't know why? Please see the following for details '4_IEEE-13-notreal.glm', '4_testoutput_13node.csv'
Q4: IEEE123node not realtime has the same question as Q1,Q2. Please see the following for details '5_IEEE-123-case1-status-notrea.glm', '5_testoutput_123node_case1.csv', '6_IEEE-123-case2-status-phase_ABC_state-notrea.glm', '6_testoutput_123node_case2.csv'
Thanks again for your help
Jsh
Hello jsh,
I'm just barely getting back to this, so I apologize for the delay in the response.
1) The IEEE 13-node example you provided is running the NR solver. The IEEE 123-node is running the FBS solver. The FBS method doesn't support a lot of the "disconnect" abilities. GridLAB-D actually puts up a warning message when it starts with FBS and a switch, indicating it does not always work properly and is not recommended.
2) This is likely a consequence of the solver method. Basically, it probably isn't registering as opening properly. Use NR for these types of operations.
3) I'm not sure I follow the question here. By "it will repeat", do you mean it gets stuck on that timestep and never moves? I don't see a fault_check object in the file anywhere, so it is probably trying to solve an infeasible power system and basically hitting the convergence limit.
4) This is probably the same answer as (1) and (2).
Basically, now that you appear to be able to control the switches, you need to add the fault_check and eventgen objects (part of powerflow and reliability, respectively) to get it to handle the topology changes properly. Unfortunately, they are not very well tested in realtime mode, so they may introduce their own set of issues.
-Frank
Hi Frank
It's really so kind of you to answer my question.
Q1:The IEEE-123 node model you provide in "branch\3.2\powerflow\tests\123node\IEEE-123.glm" does not support NR to calculate powerflow, and has the following questions.
ERROR [2000-01-01 00:00:00 EST] : syncnode(obj=181;150): Newton-Raphson method is unable to converge to a solution at this operation point
ERROR [2000-01-01 00:00:00 EST] : 2000-01-01 00:00:00 EST: object 150 stopped its clock (exec)!
ERROR [2000-01-01 00:00:00 EST] : exec halted: synchronization failed
DEBUG [2000-01-01 00:00:00 EST] : main loop ended at -1; stoptime=946789200, nevents=1, exitcode=0
FATAL [2000-01-01 00:00:00 EST] : environment startup failed: Invalid argument
DEBUG [2000-01-01 00:00:00 EST] : exit code 2
DEBUG [2000-01-01 00:00:00 EST] : last debug message was repeated 1 times
So I used FBS, but FBS can't control switch successfully.
Q2: to the Q3 previous, what I means is that GLD will get stuck on the timestep when switch is OPEN and never move. But it's right with realtime. The following is what GLD shows when it gets stuck.
*DEBUG [2016-06-07 11:31:00 EST] : main loop event at 1465270260; stoptime=9223372036854775807, nevents=1, exitcode=0
DEBUG [2016-06-07 11:31:00 EST] : globalclock=1465270260
... Max solver mismatch of failed solution 2653.249729
... Newton-Raphson failed to converge, sticking at same iteration.
DEBUG [2016-06-07 11:31:00 EST] : main loop event at 1465270260; stoptime=9223372036854775807, nevents=1, exitcode=0
DEBUG [2016-06-07 11:31:00 EST] : globalclock=1465270260
... Max solver mismatch of failed solution 5664.207973
... Newton-Raphson failed to converge, sticking at same iteration.
Processing 2016-06-07 11:31:00 EST...
DEBUG [2016-06-07 11:31:00 EST] : main loop event at 1465270260; stoptime=9223372036854775807, nevents=1, exitcode=0
DEBUG [2016-06-07 11:31:00 EST] : globalclock=1465270260
... Max solver mismatch of failed solution 238613.741255
... Newton-Raphson failed to converge, sticking at same iteration.**
Thanks for your help,Frank
Jsh
Last edit: jsh 2016-06-15