gridlab-d / gridlab-d

Source Code for GridLAB-D
Other
151 stars 109 forks source link

#760 Performance Improvement: Do not sync house when the voltage change from triplex meter is below a threshold, #760

Open nikhilgupta10 opened 7 years ago

nikhilgupta10 commented 7 years ago

Improve the performance by skipping residential objects if the change in voltage values (voltaged[x]) in triplex meter is below a certain threshold. The user should be able set the threshold.

Requires core and powerflow to be modified.

,

nikhilgupta10 commented 7 years ago

nikhilgupta10 imported these comments from Sourceforge: ciraci (user not in GitHub. This is the sourceforge username): * status changed from new to accepted ,

jcfuller1: * owner changed from ciraci to andyfisher

dchassin: Be careful with this one. There are plenty of reasons to sync house not stemming from voltage changes. It's always very difficult to know why a sync is happening, hence it is difficult to know whether it should happen.,

dchassin: - Description has changed:

Diff:

dchassin: This does not have any code associated with it yet so it really can't be in validation yet (unless somebody has code stashed away someplace else). I'll take this one and post my recommendation after I look at this issue more closely.,

dchassin: - status: assigned --> accepted

afisher1: Hi Dave,

I don't know but Selim didn't create a ticket repository for this but before he left he did send me his code changes that implement this feature. I'll have to look around for it. here and put it on a ticket.

Andy,

dchassin: This is a very suspicious change. I would advise looking at very carefully.

-----Original Message----- From: Andy Fisher [mailto:andyfisher@users.sf.net] Sent: Wednesday, July 09, 2014 12:36 PM To: [gridlab-d:tickets] Subject: [gridlab-d:tickets] #760 Performance Improvement: Do not sync house when the voltage change from triplex meter is below a threshold

Hi Dave,

I don't know but Selim didn't create a ticket repository for this but before he left he did send me his code changes that implement this feature. I'll have to look around for it. here and put it on a ticket.

Andy


\ [tickets:#760] Performance Improvement: Do not sync house when the voltage change from triplex meter is below a threshold**

Status: accepted Milestone: Version 3.1 RC1 Created: Sat Jul 06, 2013 12:02 AM UTC by Selim Ciraci Last Updated: Wed Jul 09, 2014 07:28 PM UTC Owner: David P. Chassin

Improve the performance by skipping residential objects if the change in voltage values (voltaged[x]) in triplex meter is below a certain threshold. The user should be able set the threshold.

Requires core and powerflow to be modified.


Sent from sourceforge.net because you indicated interest in https://sourceforge.net/p/gridlab-d/tickets/760/

To unsubscribe from further messages, please visit https://sourceforge.net/auth/subscriptions/

,

jcfuller1: Dave,

That is correct. You have to be very careful with this. The idea was to try out this type of application on meter-house interactions to see if we could see speed improvements by putting some limitations on re-iterations that were define by user specified thresholds, rather than an all inclusive \if anybody updates, we all need to update.

The hack version of this was just to see if it were worth doing. The idea was to quickly hack-in a threshold of voltage changes in the house and see if it sped up improvement. The results were promising (around 20% at a 0.1V threshold, if I remember correctly).

With positive results, the idea was to re-evaluate the way in which objects update. The great way to do this would be if any variable I have access to was touched, we need to consider an update. This is where the threshold could be applied to further reduce the need to re-iterate. If no variables were touched (whether mine or one's I access), then there is no reason to re-iterate. This idea was part of the reason to heavily encourage the new internal API of passing all cross-object information through the core...you could then track whether parameters had been touched.

This code should NOT be committed back to the main line without significant thought and discussion (and in this case, probably never).

Please note that this a MAJOR ticket and is considered low priority right now.,

jcfuller1: - status: accepted --> unassigned

dchassin: Interesting. I'd like to give this more thought and look at Selim's code. Can anyone post it to SVN/ticket/760 and post a quick guide to the test cases it uses? Thanks.,

dchassin: - status: unassigned --> assigned ,

dchassin: - Milestone: Unscheduled --> Knothole Interim ,

dchassin: There is no code posted ticket 760. This looks like an interesting and valuable upgrade but there is nothing to implement available. Can this upgrade be abandoned before the knothole?,

dchassin: Postponing for future milestone.,

dchassin: - Milestone: Knothole Interim --> Version 4.0 RC1 ,