search

dss-extensions / OpenDSSDirect.py

OpenDSSDirect.py: a cross-platform Python package that implements a native/direct library interface to the alternative OpenDSS engine from DSS-Extensions.org
https://dss-extensions.org/OpenDSSDirect.py/
Other
88 stars 22 forks source link

Circuit Total Power Mismatch #35

Closed AkshayKuJain closed 4 years ago

AkshayKuJain commented 6 years ago

Versions

Bug

DSS_comparisons.pdf

DSS_comp_results.pdf

PMeira commented 6 years ago

Thank you for reporting. We should investigate this but it can take some days depending on what we find.

Some points to consider:

First we need to:

With that done, I could imagine several things to try with it:

kdheepak commented 6 years ago

I'll try to generate a test case that I can share that reproduces the issue in the parent comment.

PMeira commented 6 years ago

@kdheepak Thanks, I can take care of the rest on Windows if you prefer.

One more thing we could do:

kdheepak commented 6 years ago

I ran a very simple test on my Mac and can say that the problem is not actually with the dss.Circuit.TotalPower() function.

screen shot 2018-08-23 at 11 46 51 am

Edit:

On my mac there's no issue. On windows, I see a difference.

screen shot 2018-08-23 at 12 26 33 pm

kdheepak commented 6 years ago

I'm not able to replicate these issues on my Mac. On my Mac, v0.2.14 and v0.3.4 give identical results. On Windows however, there is a difference.

screen shot 2018-08-23 at 12 21 21 pm

More to come...

kdheepak commented 6 years ago

OpenDSS v816_01 on Windows gives results are do not match the v0.3.4 results, when comparing results from the GUI to that from Python.

kdheepak commented 6 years ago

v765 and v816_01 both give the same results, which are not the same as v0.3.4. Tested using x64 bit for both versions.

kdheepak commented 6 years ago

I replaced the KLUSolve from the official distribution in dss_python and got the same result that we get in v0.3.4.

kdheepak commented 6 years ago

We've narrowed it down to running allocateloads. Without that command in the OpenDSS master file, the total circuit power is approximately equal (to 2 decimal places) for the real and imaginary components. Once allocateloads is run, the difference becomes much larger.

kdheepak commented 6 years ago

The AllocationFactors are different for all the loads when comparing results from Windows and Mac. I used dss.run_command("Dump AllocationFactors") to get the text file. The following is the first few lines from the files.

Load.XXXXX-abc-1_1.AllocationFactor=1.8941
Load.XXXXX-abc-1_2.AllocationFactor=1.8941
Load.XXXXX-abc-1_3.AllocationFactor=1.8941
...
...
...
Load.XXXXX-abc-1_1.AllocationFactor=1.7553
Load.XXXXX-abc-1_2.AllocationFactor=1.7553
Load.XXXXX-abc-1_3.AllocationFactor=1.7553
...
...
...
PMeira commented 6 years ago

@kdheepak Well done! Your results so far suggest it's a Delphi vs. Free Pascal issue then, since on Mac the results didn't change across ODDpy versions.

Looking into the test files from the official distribution, allocateloads commands are not present in any of them. No wonder we didn't catch this before. It doesn't seem we use it in our lab at Unicamp either.

I did a simple compilation to test if it would be possible to build the DLL with Delphi, at least for testing, and it seems it wouldn't be too much trouble (https://github.com/PMeira/electricdss-src/issues/4).

kdheepak commented 6 years ago

This is really odd. I went through the files that I have line by line, and the only things that are in those files that are not in the 13 node test system are EnergyMeters and Monitors. Additionally, I've added an EnergyMeter and Monitor to the 13 node test system in the tests/data folder in this repository, and when I run dss.run_command("Dump AllocationFactors") it returns an empty file. However, when I read the source files into OpenDSS, and run dss.run_command("Dump AllocationFactors") I get a long list of loads and their allocationfactors. Any idea what is going on here?

These are the lines I added to the IEEE13Nodeckt.dss

! add to bottom of IEEE13Nodeckt.dss
New EnergyMeter.Energy_Meter element=Line.650632 terminal=1
New monitor.sub1 element=Transformer.Sub terminal=2 mode=0
New monitor.sub2 element=Transformer.Sub terminal=1 mode=65 PPolar=No

allocateloads

Solve

Why is dss.run_command("Dump AllocationFactors") not returning anything?

kdheepak commented 6 years ago

On a somewhat unrelated note, running dss.run_command("Dump AllocationFactors") tries to write a file into /tmp/OpenDSSCMD/AllocationFactors.txt instead of the current folder.

kdheepak commented 6 years ago

I also tried changing the power factors on the loads and that did not make a difference to this result. Oddly, when I change the power factor the total power is still the same. Like the power factor of the load is not being taken into effect?

screen shot 2018-08-24 at 8 03 46 am

PMeira commented 6 years ago

It could be some detail in the meters, I wonder if the circuit has loops and for some reason the meter tree ends up different in Delphi or something in that line of thought.

On a somewhat unrelated note, running dss.run_command("Dump AllocationFactors") tries to write a file into /tmp/OpenDSSCMD/AllocationFactors.txt instead of the current folder.

Yep, that's fixed in the current revision of the library. I'll release a new version in the coming days to address that.

However, when I read the source files into OpenDSS, and run dss.run_command("Dump AllocationFactors") I get a long list of loads and their allocationfactors. Any idea what is going on here?

On the official GUI, for the IEEE13, my Dump AllocationFactors is empty too, I think it's expected. Did you check the document OpenDSS Load Allocation Algorithm.pdf? It mentions this:

You must define some (ideally, most) of the loads with one of the last two (4 or 5) methods for the Allocation and Estimation algorithms to have the greatest success. If all the loads were known and fixed, there would be no need for Allocation or Estimation. Load objects that are subject to allocation are defined using either the xfkVA or kWh properties and related properties.

Since the loads in IEEE13 already specificy both kW and kvar for the definition, they won't be affected by the allocation algorithm.

Like the power factor of the load is not being taken into effect?

Yes, setting the pf at the end doesn't really change it in this case, e.g.

New Load.671 Bus1=671.1.2.3  Phases=3 Conn=Delta Model=1 kV=4.16   kW=1155 kvar=660 pf=0.66575478
? load.671.pf

This returns 0.8682 instead of 0.66575478. The value 0.8682 is the pf computed from the provided kW and kvar values. Removing either of the power inputs will use the input power factor. I think there should be an optional warning for many of these situations, but that will require a large change in the DSS language parser.

kdheepak commented 6 years ago

Thanks for the detailed answers! Sorry, I keep forgetting that the fix for the working directory is not in a release yet. And that power factor explanation makes sense, thanks.

The linked PDF is interesting; I hadn't seen that before. I was trying to modify the IEEE13 node feeder to replicate the issue. But it looks like I won't be able to get to this until later in the weekend unfortunately.

PMeira commented 4 years ago

I imagine this is stale and we can close it. Feel free to reopen.

EDIT (2023-12-27): I noticed some traffic to this old issue. If you have a similar situation, feel free to post a sample circuit so we can check, but most likely the issue is due to tiny impedances, like exaggerated values for switches, which can cause the Y matrix to be badly/ill conditioned. At a glance, in such situation a tiny change in the voltage state can result in large deviations in the power state (almost a "garbage in, garbage out" situation). See https://en.wikipedia.org/wiki/Condition_number