I'm trying to control two loads in Gridlab-d under the following condition, if one load is ON, the other one must immediately turn OFF.
I looked at the wiki and found multiple objects to control loads such as schedule loads, transactive controls, and passive controls. However, non of these features lead to my goal.
Any help would be appreciated.
Thanks
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
To explicitly do what you're describing, you would need to either write a runtime class to handle the toggling, use an external interface (like HELICS to Python or similar, or the MATLAB link) to handle that toggling, or write your own class or subfunction to the load in question to do the toggling. In GridLAB-D directly, there is no function to do that "automatically" right now (it would need to be written).
That said, depending on how your load is being activated, you could fake it. For example, if you had a schedule controlling the load, you could just use a schedule transform to make the "complementary load" behave opposite. I've attached a simple GLM example.
This only works if the load is being driven by something like a schedule or player (player transforms work too). If it is a more state-driven load, then you have to do one of the methods I mentioned first.
I was thinking maybe I could toggle the switch status using player object. I'm not sure if players are able to read csv files or .player files with strings. I attached an example of the glm file and player files as well. In the attached files, the switches are always in CLOSED state even though switch2.player file has OPEN state in it. I wonder why that is. Is it simply because players don't understand strings?
The players understand strings/enumerations, but the player transforms do not. The lines status player_A.value; are player transforms and don't work with strings/enumerations (or even complex values, for that matter), so that was the initial problem. If you comment those lines out, your players look like they start to work.
Once you comment those lines out though, you get "hanging nodes" when the switch opens. This can cause singular matrices in the Newton-Raphson (NR) solver, so it will either fail, or give you horrible answers (assuming they don't become #IND or similar). Whenever you do any switching operations in GridLAB-D with the NR solver, a fault_check object is basically required. This is the one I added to your file:
//General fault_check object to remove things that aren't supportedobjectfault_check{nameflt_check;check_modeONCHANGE;strictly_radialfalse;grid_associationtrue;}
Once I add that in, everything appears to execute fine in your file.
Note that this was run on the /develop branch of GridLAB-D. There was a bug in some earlier versions of GridLAB-D (like 4.2) where this can sometimes have issues. I'm not sure if you're using a precompiled version, but for this type of operation, it may be useful to switch to a locally-compiled version of the develop branch (until we get 4.3 released, which hopefully is soon).
-Frank
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hello Everyone,
I hope all is well and safe.
I'm trying to control two loads in Gridlab-d under the following condition, if one load is ON, the other one must immediately turn OFF.
I looked at the wiki and found multiple objects to control loads such as schedule loads, transactive controls, and passive controls. However, non of these features lead to my goal.
Any help would be appreciated.
Thanks
Hello Midrar,
To explicitly do what you're describing, you would need to either write a runtime class to handle the toggling, use an external interface (like HELICS to Python or similar, or the MATLAB link) to handle that toggling, or write your own class or subfunction to the load in question to do the toggling. In GridLAB-D directly, there is no function to do that "automatically" right now (it would need to be written).
That said, depending on how your load is being activated, you could fake it. For example, if you had a schedule controlling the load, you could just use a schedule transform to make the "complementary load" behave opposite. I've attached a simple GLM example.
This only works if the load is being driven by something like a schedule or player (player transforms work too). If it is a more state-driven load, then you have to do one of the methods I mentioned first.
-Frank
Thank you for your reply, Frank.
Frank,
I was thinking maybe I could toggle the switch status using player object. I'm not sure if players are able to read csv files or .player files with strings. I attached an example of the glm file and player files as well. In the attached files, the switches are always in CLOSED state even though switch2.player file has OPEN state in it. I wonder why that is. Is it simply because players don't understand strings?
Hello Midrar,
The players understand strings/enumerations, but the player transforms do not. The lines
status player_A.value;are player transforms and don't work with strings/enumerations (or even complex values, for that matter), so that was the initial problem. If you comment those lines out, your players look like they start to work.Once you comment those lines out though, you get "hanging nodes" when the switch opens. This can cause singular matrices in the Newton-Raphson (NR) solver, so it will either fail, or give you horrible answers (assuming they don't become #IND or similar). Whenever you do any switching operations in GridLAB-D with the NR solver, a
fault_checkobject is basically required. This is the one I added to your file:Once I add that in, everything appears to execute fine in your file.
Note that this was run on the /develop branch of GridLAB-D. There was a bug in some earlier versions of GridLAB-D (like 4.2) where this can sometimes have issues. I'm not sure if you're using a precompiled version, but for this type of operation, it may be useful to switch to a locally-compiled version of the develop branch (until we get 4.3 released, which hopefully is soon).
-Frank