Aquileo | Recent changes to ticketshttps://sourceforge.net/p/gridlab-d/tickets/2017-08-01T14:39:41.298000ZRecent changes to ticketsAquileo | Modification to schedule2017-08-01T14:39:41.298000Z2017-08-01T14:39:41.298000Ztom4321https://sourceforge.net/u/tom4321/https://sourceforge.netd1f2254940319e55fd35eccda4cba7cdd0682546Aquileo | #938 Schedule skews and random numbers2017-07-05T22:14:22.296000Z2017-07-05T22:14:22.296000ZJoe Z.https://sourceforge.net/u/joe588/https://sourceforge.net09fc6a2da938108e8643c1b632fd4d4501264f83<div class="markdown_content"><p>Hi Andy,</p> <p>Thank you!!!</p> <p>Joe</p></div>Aquileo | #938 Schedule skews and random numbers2017-07-05T22:09:44.198000Z2017-07-05T22:09:44.198000ZAndy Fisherhttps://sourceforge.net/u/andyfisher/https://sourceforge.netfd42d44d9d2e6e570ff66d8608af401dd341d904<div class="markdown_content"><p>Hi Joe,</p> <p>Unfortunately this issue has not been resolved but it is in the queue. Currently this issue can be circumvented through a use of a model generation script of some kind that randomly assigns a number to the schedule_skew. </p> <p>I was able to find the cause of why using the random number assignment to schedule_skew doesn't work. global object properties that are part of the object structure do not support any of the variable assignments like transforms and random numbers. Some additions to load.c need to be made for object structure assignments.</p> <p>Andy</p></div>Aquileo | #938 Schedule skews and random numbers2017-07-02T21:05:14.024000Z2017-07-02T21:05:14.024000ZJoe Z.https://sourceforge.net/u/joe588/https://sourceforge.net92dec117f7f24b6914c2268bacd979a8c5b64c82<div class="markdown_content"><p>Has this issue been solved? Thanks!</p> <p>Joe</p></div>Aquileo | #992 Documentation and reference material for underground cable2017-05-31T23:00:51.479000Z2017-05-31T23:00:51.479000ZJason Fullerhttps://sourceforge.net/u/jcfuller/https://sourceforge.net9e2166272500ad92b8292fd78e287a0b59fd38fb<div class="markdown_content"><ul> <li><strong>status</strong>: new --&gt; closed</li> <li><strong>Resolution</strong>: none --&gt; documented</li> </ul></div>Aquileo | #992 Documentation and reference material for underground cable2017-05-31T23:00:23.230000Z2017-05-31T23:00:23.230000ZJason Fullerhttps://sourceforge.net/u/jcfuller/https://sourceforge.netb3046a8c1a4faac5eb8f56280fc17381dfc03931<div class="markdown_content"><p>Please see power flow user guides:</p> <p><a href="http://gridlab-d.sourceforge.net/wiki/index.php/Power_Flow_User_Guide">http://gridlab-d.sourceforge.net/wiki/index.php/Power_Flow_User_Guide</a><br/> <a href="http://gridlab-d.sourceforge.net/wiki/index.php/Powerflow#Overhead_and_Underground_Lines">http://gridlab-d.sourceforge.net/wiki/index.php/Powerflow#Overhead_and_Underground_Lines</a></p> <p>(which end up directing you to Bill Kersting's book on Distribution Analysis).</p></div>Aquileo | Documentation and reference material for underground cable2017-05-23T21:03:40.158000Z2017-05-23T21:03:40.158000ZPoorva Bedgehttps://sourceforge.net/u/poorvab/https://sourceforge.netd64424c21789ce19fd9f6baf61630657c5928264<div class="markdown_content"><p>Where can I find documentation on how the underground cable Z matrix calculation has been done in grid lab D. I have gone through the cpp code for underground cable (http://www.gridlabd.org/documents/doxygen/1.1/underground__line_8cpp-source.html), but need the reference material to know the underlying formulas and constants</p></div>Aquileo | Documentation and reference material for underground cable2017-05-23T21:03:40.158000Z2017-05-23T21:03:40.158000ZPoorva Bedgehttps://sourceforge.net/u/poorvab/https://sourceforge.netb767cffad1503efe6509cd2906b3d149b5d50d6a<div class="markdown_content"><p>Ticket 992 has been modified: Documentation and reference material for underground cable<br/> Edited By: Jason Fuller (jcfuller)<br/> Status updated: u'new' =&gt; u'closed'<br/> _resolution updated: u'none' =&gt; u'documented'</p></div>Aquileo | #991 tzinfo.txt has incorrect offsets for Europe2017-01-29T20:46:01.590000Z2017-01-29T20:46:01.590000ZDavid P. Chassinhttps://sourceforge.net/u/dchassin/https://sourceforge.nete72444316d9104c115d68513cc4b0683a539719f<div class="markdown_content"><p>It certainly looks like the Europe TZ database is shifted so that CET cities are listed as WET, EET as CET, etc.<br/> </p></div>Aquileo | tzinfo.txt has incorrect offsets for Europe2017-01-29T18:40:54.269000Z2017-01-29T18:40:54.269000ZDerrick Oswaldhttps://sourceforge.net/u/derrickoswald/https://sourceforge.netd9d296e1b45225f56e2312519a53cab3218fb45d<div class="markdown_content"><p>In the Europe section of tzinfo.txt, entries are off by one hour. Entries for North Ameria appear to be corect.</p> <p>For example:<br/> MSK-4MSKS should be MSK-3MSKS - since MSK is UTC+3 (https://en.wikipedia.org/wiki/Moscow_Time)<br/> EET-3EEST should be EET-2EEST - since Eastern European Time is UTC+2 (https://en.wikipedia.org/wiki/Eastern_European_Time)<br/> CET-2CEST should be CET-1CEST - since Central European Time is UTC+1 (https://en.wikipedia.org/wiki/Central_European_Time)<br/> WET-1WEST should be WET0WEST - since Western European Time is UTC (https://en.wikipedia.org/wiki/Western_European_Time)</p> <p>Proof can also be had by using Google to search for "CET-1CEST" vs. "CET-2CEST" yielding 3380 hits vs. zero hits.</p> <p>Many (if not all) the cities/countries listed do not belong to the time zones they are listed under.</p> <p>For example:<br/> EU/DE/Berlin is listed under WET (Western European Time), but is in fact in CET-1CEST (https://en.wikipedia.org/wiki/Berlin)<br/> and many, many others.</p></div>