I am working on a Gridlabd simulation, where I would be interested in simulating things like inrush current of certain home appliances, so it would be useful to be able to output data to a csv file on an interval of microseconds; however, the recorder object seems to be incapable of this. I have attached my glm file, here but even when using deltamode and setting the recorder interval to -1, I do not get more than 3 datapoints. Does anyone have any advice for how to solve this issue or where I am going wrong?
The reason you don't get any subsecond data from the recorder is you don't have any object that triggers the simulation to enter deltamode. The common and easy way to do this is to provide a player object that plays a value at a subsecond timestamp to an inconsequential object's property. Unfortunately, besides the ev_charger object there are no dynamic models for any of the enduse load objects in the residential module at this time. The inclusion of such models is uncertain at this time.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Thanks for your response! I am still slightly confused on how to implement a sub-second player. Based on the documentation, I take it I add a player object to my GLM file and then also use a CSV file like the one I have attached below (with seconds to 6 decimal point precision). Am I understanding your feedback correctly? Also, since there are limited dynamic models for the residential model do you have any suggestions of other appliances or machinery from other modules that I might be able to simulate in deltamode to visualize inrush current (or is GridlabD not really designed to do this?)
object player {
name player;
parent house Meter;
property demand;
file subsecondPlayer.csv;
}
Update: I attempted the above as best as I could. Here are the glm files. I added an Ev charger and Ev charger_det, but still no sub-second values are recorded. Any idea of where I'm going wrong?
You were pretty close with your attempt, but a few things needed to be fixed.
The first is I specified a timezone entry in the clock portion of your GLM. Some GridLAB-D models can do some unexpected behaviors if you don't define this, so I always recommend people include it. I set it to CST/CDT, since that's where weather file being used was based. I also extended it to 5 seconds of runtime, just so it shows a transition in and out of deltamode.
The second item is the player file. You were close, but it needs full timestamps, not just a relative one (for deltamode, at least). You also have to wait at least 1-second for things to initialize.
Regarding your GLM, I changed the step time up to 10 ms for testing. While GridLAB-D can theoretically go down to 1 ns timesteps, none of our models are built around that. The motor model is one of our more stringent ones, and it only requires 0.1 ms, as I recall. Furthermore, if you go below microseconds, the recorder output doesn't have enough digits in the output (so you get what look like duplicated entries). The #set deltamode_timestep portion you had at the top was causing this, since you had it set to "1", which implied 1 ns timestep. I added a unit. I'll note that the deltamode_timestep is a global and the "default", which individual modules will try to override. Usually, we set it larger (to say 100 ms) and let the individual modules/models override it to a smaller timestep.
I added the module-level timesteps to the GLM. This makes sure you're explicitly defining how you want it to step when doing the deltamode simulations.
Finally, I changed one recorder from interval -1 to interval 1. Deltamode (and GridLAB-D, in general) require something to "drive" the simulation forward. An interval -1 is just a "if you happen to go forward", so it was ignoring the triggering of deltamode.
I've attached the modified GLM so you can see what is different.
Regarding in-rush, none of the residential end use models really have that capability right now. Per my other response, the closest is an undocumented way to tie the induction motor model in the powerflow module to the HVAC system, but it is not thoroughly tested. All of our current in-rush functionality is in the powerflow module (overhead lines, underground lines, loads, motor, and some transformer saturation models), so it is a bit limited.
In the "standard disclaimer" approach, GridLAB-D is open source, so you are more than welcome to develop in-rush capable end-use loads for GridLAB-D and submit a pull request to the GitHub repository!
I am working on a Gridlabd simulation, where I would be interested in simulating things like inrush current of certain home appliances, so it would be useful to be able to output data to a csv file on an interval of microseconds; however, the recorder object seems to be incapable of this. I have attached my glm file, here but even when using deltamode and setting the recorder interval to -1, I do not get more than 3 datapoints. Does anyone have any advice for how to solve this issue or where I am going wrong?
I am using the version 5.1.0-19458
Hello Lucas,
The reason you don't get any subsecond data from the recorder is you don't have any object that triggers the simulation to enter deltamode. The common and easy way to do this is to provide a player object that plays a value at a subsecond timestamp to an inconsequential object's property. Unfortunately, besides the ev_charger object there are no dynamic models for any of the enduse load objects in the residential module at this time. The inclusion of such models is uncertain at this time.
Hi Andy!
Thanks for your response! I am still slightly confused on how to implement a sub-second player. Based on the documentation, I take it I add a player object to my GLM file and then also use a CSV file like the one I have attached below (with seconds to 6 decimal point precision). Am I understanding your feedback correctly? Also, since there are limited dynamic models for the residential model do you have any suggestions of other appliances or machinery from other modules that I might be able to simulate in deltamode to visualize inrush current (or is GridlabD not really designed to do this?)
object player {
name player;
parent house Meter;
property demand;
file subsecondPlayer.csv;
}
Update: I attempted the above as best as I could. Here are the glm files. I added an Ev charger and Ev charger_det, but still no sub-second values are recorded. Any idea of where I'm going wrong?
Hello Lucas,
You were pretty close with your attempt, but a few things needed to be fixed.
The first is I specified a timezone entry in the clock portion of your GLM. Some GridLAB-D models can do some unexpected behaviors if you don't define this, so I always recommend people include it. I set it to CST/CDT, since that's where weather file being used was based. I also extended it to 5 seconds of runtime, just so it shows a transition in and out of deltamode.
The second item is the player file. You were close, but it needs full timestamps, not just a relative one (for deltamode, at least). You also have to wait at least 1-second for things to initialize.
Regarding your GLM, I changed the step time up to 10 ms for testing. While GridLAB-D can theoretically go down to 1 ns timesteps, none of our models are built around that. The motor model is one of our more stringent ones, and it only requires 0.1 ms, as I recall. Furthermore, if you go below microseconds, the recorder output doesn't have enough digits in the output (so you get what look like duplicated entries). The #set deltamode_timestep portion you had at the top was causing this, since you had it set to "1", which implied 1 ns timestep. I added a unit. I'll note that the deltamode_timestep is a global and the "default", which individual modules will try to override. Usually, we set it larger (to say 100 ms) and let the individual modules/models override it to a smaller timestep.
I added the module-level timesteps to the GLM. This makes sure you're explicitly defining how you want it to step when doing the deltamode simulations.
Finally, I changed one recorder from interval -1 to interval 1. Deltamode (and GridLAB-D, in general) require something to "drive" the simulation forward. An interval -1 is just a "if you happen to go forward", so it was ignoring the triggering of deltamode.
I've attached the modified GLM so you can see what is different.
Regarding in-rush, none of the residential end use models really have that capability right now. Per my other response, the closest is an undocumented way to tie the induction motor model in the powerflow module to the HVAC system, but it is not thoroughly tested. All of our current in-rush functionality is in the powerflow module (overhead lines, underground lines, loads, motor, and some transformer saturation models), so it is a bit limited.
In the "standard disclaimer" approach, GridLAB-D is open source, so you are more than welcome to develop in-rush capable end-use loads for GridLAB-D and submit a pull request to the GitHub repository!
-Frank