I am new to GridLAB-D and currently playing with some examples. I just run the subsecond_diesel_generator_example.glm demo.
I changed the dateformat to ISO which left me with data only for every second in Gen_1_speed.csv. Changing the the interval of the recorder of Gen 1 to 0 leaves me even more confused with a lot of duplicated timestamps. I then switched back to US format wich made the output even more confusing as I now get the following timestamps:
I guess it is obvious for you but it would be nice if you could add something like: "A frequency of 0 indicates that they should be read & written every iteration (note that there can be multiple iterations for every timestep)"
Also I had some troubles finding the right documentation.
I still have some troubles. If I let the example run for more than 40 seconds (say 10 minutes) with the interval of the generator recorders set to -1 I get:
I guess I should just ignore the first line which for some reasons also contains "i" instead of "j" as the imaginary unit. I think the second output for the 5th second is probably a bug when switching back from DELTAMODE?
Kind Regards,
Florian
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hello Florian,
Regarding the duplicate time recording for 5.0 seconds, please try the latest version GridLAB-D (version 3.1 release candidate). The bug you are experiencing I believe was fixed as part of that version update. If updating to 3.1 doesn't fix it, please let us know.
-Frank
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Thanks for the tip on the documentation -- it has been updated.
Also, thanks for the note on the 'i' vs. 'j' -- hadn't noticed that before (i rarely record out the full complex number, usually using the double format with .real and .imag, as its easier to parse). Looks like it has something to do with how the recorder is pulling the initial value versus after the value has been "touched". Will ticket and look into it.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
after some troubles with SVN I successfully compiled version 4.0 ;-) and 3.1 and I now can report that the bug is gone but the output is quite different.
The simulations stays in deltamode for a much shorter amount of time 12s vs 40s and the output seams different too. Should I look in too the details or is this expected for the beta versions?
Also the timestamps for with sub-second precision know carry the timezone with them which they did not do before and which in opposite to what is written in the documentation.
Kind Regards,
Florian
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I would say this is probably (somewhat) expected. The delta-mode tools were definitely alpha release for v3.0 and beta for v3.1. We hope to have them in better shape when we finish validation for v3.2 in late winter 2015.
Interesting point on the TZ...I'm not sure whether the documentation is lagging the code or if that's a bug. Will look into. Please keep pointing these out - crowd-sourcing for consistency and operation is invaluable.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I don't think it's a bug so much as feature creep. I think it arose because timestamp handling was harmonized to support subsecond timestamps in the same function as the existing timestamps. In the process the standardization of TZ was incorporated without thought being given to the effect.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I am new to GridLAB-D and currently playing with some examples. I just run the subsecond_diesel_generator_example.glm demo.
I changed the dateformat to ISO which left me with data only for every second in Gen_1_speed.csv. Changing the the interval of the recorder of Gen 1 to 0 leaves me even more confused with a lot of duplicated timestamps. I then switched back to US format wich made the output even more confusing as I now get the following timestamps:
01-01-2001 00:00:00,
01-01-2001 00:00:00,
01-01-2001 00:00:00.000000
01-01-2001 00:00:00.010000
01-01-2001 00:00:00,
01-01-2001 00:00:02,
01-01-2001 00:00:03,
01-01-2001 00:00:03,
01-01-2001 00:00:04,
01-01-2001 00:00:04,
01-01-2001 00:00:05,
01-01-2001 00:00:05,
01-01-2001 00:00:05.000000
01-01-2001 00:00:05.010000
01-01-2001 00:00:05.020000
01-01-2001 00:00:05.030000
What am I doing wrong here? How can I interpret this data?
GridLAB-D 3.0.0-4524 (Hassayampa) 64-bit MACOSX RELEASE
BTW: What ISO format is it supposed to be?
Kind Regards,
Florian
Florian,
This is discussed in the recorder documentation at:
http://gridlab-d.sourceforge.net/wiki/index.php/Recorder
If that doesn't answer your question, please let me know and we will update the documentation.
Jason
Hi Jason,
I guess it is obvious for you but it would be nice if you could add something like: "A frequency of 0 indicates that they should be read & written every iteration (note that there can be multiple iterations for every timestep)"
Also I had some troubles finding the right documentation.
I still have some troubles. If I let the example run for more than 40 seconds (say 10 minutes) with the interval of the generator recorders set to -1 I get:
01-01-2001 00:00:00,+376.991,+0,+0,+0,+0+0i,+0+0i,+0+0i,…
01-01-2001 00:00:00.000000,+376.991,+0.169362,+0.997841,-0.151534,+0.138906+1.0268j,…
01-01-2001 00:00:00.010000,+376.991,+0.169362,+0.997841,-0.151534,+0.138906+1.0268j,…
01-01-2001 00:00:05.000000,+376.991,+0.169362,+0.997841,-0.151534,+0.138906+1.0268j,…
01-01-2001 00:00:05.010000,+377.159,+0.16981,+1.00012,-0.15017,+0.138597+1.02691j,…
...
01-01-2001 00:00:37.930000,+399.211,…
01-01-2001 00:00:37.940000,+399.211,…
01-01-2001 00:00:05,+399.207,+2.13693,…
01-01-2001 00:00:40,+399.207,+2.25479,…
01-01-2001 00:00:41,+399.207,+2.31372,…
I guess I should just ignore the first line which for some reasons also contains "i" instead of "j" as the imaginary unit. I think the second output for the 5th second is probably a bug when switching back from DELTAMODE?
Kind Regards,
Florian
Hello Florian,
Regarding the duplicate time recording for 5.0 seconds, please try the latest version GridLAB-D (version 3.1 release candidate). The bug you are experiencing I believe was fixed as part of that version update. If updating to 3.1 doesn't fix it, please let us know.
-Frank
Florian,
Thanks for the tip on the documentation -- it has been updated.
Also, thanks for the note on the 'i' vs. 'j' -- hadn't noticed that before (i rarely record out the full complex number, usually using the double format with .real and .imag, as its easier to parse). Looks like it has something to do with how the recorder is pulling the initial value versus after the value has been "touched". Will ticket and look into it.
Hi Frank,
there seams to be no 3.1 version for Mac at the moment. I will try to compile it from source. And see how far I will come.
Last edit: Florian Kühnlenz 2014-09-12
Hi Frank,
after some troubles with SVN I successfully compiled version 4.0 ;-) and 3.1 and I now can report that the bug is gone but the output is quite different.
The simulations stays in deltamode for a much shorter amount of time 12s vs 40s and the output seams different too. Should I look in too the details or is this expected for the beta versions?
Also the timestamps for with sub-second precision know carry the timezone with them which they did not do before and which in opposite to what is written in the documentation.
Kind Regards,
Florian
Florian,
I would say this is probably (somewhat) expected. The delta-mode tools were definitely alpha release for v3.0 and beta for v3.1. We hope to have them in better shape when we finish validation for v3.2 in late winter 2015.
Interesting point on the TZ...I'm not sure whether the documentation is lagging the code or if that's a bug. Will look into. Please keep pointing these out - crowd-sourcing for consistency and operation is invaluable.
I don't think it's a bug so much as feature creep. I think it arose because timestamp handling was harmonized to support subsecond timestamps in the same function as the existing timestamps. In the process the standardization of TZ was incorporated without thought being given to the effect.