search

dss-extensions / dss_capi

A multi-platform, customized C-API library and alternative implementation of OpenDSS (EPRI Distribution System Simulator) aiming for full COM compatibility. Unofficial/unsupported by EPRI, but extensively tested.
https://dss-extensions.org/
BSD 3-Clause "New" or "Revised" License
33 stars 13 forks source link

mismatch Cmatrix calculated from Carson's equations with respect to OpenDSS versions 9.1.3.3 and 8.3.3.1 #89

Closed hei06j closed 3 years ago

hei06j commented 4 years ago

I used the test case Example 5.1 from Kersting's book "Distribution system modelling and analysis". https://gist.github.com/hei06j/e4c1958914c14bcd5e9bfd7f266c491c

OpenDss on windows versions 9.1.3.3 and 8.3.3.1 matches with the results in the book (i.e. first diagonal element is 15 nF/mile)

OpenDSSDirect.jl version 0.7.0 calculates Cmatrix which is different from the results in the book (i.e. first diagonal element is 10 nF/mile). https://gist.github.com/hei06j/3b90692f7c232dc0ea1c574b873b6ba3

PMeira commented 4 years ago

Please slow down, it's been a day since the bug was fixed upstream. Allow us a few days to port it. In the time being, you can downgrade to a version that does not include the CapRadius property or follow Roger Dugan's suggestion on the thread at the official forum: https://sourceforge.net/p/electricdss/discussion/beginners/thread/01989ee214/?limit=25#3e86

Note that, unless noted, we follow closely the changes in the official OpenDSS engine, including the forum and code repository. There's no need to replicate bug reports from the official OpenDSS here, especially in such a short term.

(I'll transfer this issue to DSS C-API since this is an engine issue)

hei06j commented 4 years ago

Thanks for the quick follow-up, I hadn't found the link you kindly provided. We will wait the new version and use the workaround in the meantime.

PMeira commented 3 years ago

@hei06j Releasing as soon as the remaining docs are updated. For ODD.jl, you can follow the release through https://github.com/dss-extensions/OpenDSSDirect.jl/pull/66

The issue was more complicated than I expected. When the CapRadius property was added in OpenDSS (December 2019), it made some line configurations to return NaN values, among other issues. One specific example: if you only defined GMRac without an explicit value for the radius/diameter, CapRadius was not initialized (left as a negative value, which in turn resulted in a NaN when used in a logarithm).

In July, a user reported issues. I found the root cause and suggested a fix which was adopted in OpenDSS. Unfortunately the fix still broke another situation: if you define both GMRac and Radius (in this order), it initialized CapRadius through the GMRac value and didn't update it with the Radius value. This was used in the first release of OpenDSS 9.1.

As someone else reported broken values in the same situation you reported here in the official forum, the change was reverted in OpenDSS 9.1.3.3, making it work for this specific scenario (like in your example, New Wiredata.Phase GMR=0.0244 DIAM=0.721 ... ), but leaving it broken if you don't provide the diameter/radius explicitly. This breaks compatibility with older versions. I sent two possible fixes here but I'm not sure this will be handled there anytime soon.

For the time being, I adopted the simpler fix that just checks for negative/invalid values for CapRadius as seen in https://github.com/dss-extensions/dss_capi/commit/8752b91e41ac65229c90f410049370bfa1bad03b -- this fixed all situations I tested to far, thus I'm going forward with the release here on DSS Extensions. Please feel free to report any potential issue you find directly to us.

One important note is that our current basic test suites didn't catch the issue (and looks like neither did EPRI's), even though they some include some large circuits. Another problem is that, for part of the validation process (this one includes all test/example DSS scripts), it was assumed the current version of OpenDSS is correct. In this situation, that wasn't the case.

I created some extra tests (not in the repository yet) and I'm also considering a slightly different approach when validating the results with the official OpenDSS: to avoid grabbing a buggy OpenDSS as reference, the tests will be updated to use saved known-good results for most of the test files (almost every script from electricdss-tst). Most of code in OpenDSS is very stable and can be validated this way, while "bleeding edge" features like the new models for PVSystem and Storage will need to be compared to the latest OpenDSS since we don't have another reference.

(@kdheepak: FYI)

PMeira commented 3 years ago

Besides DSS_Sharp (which will be rewritten for the 0.11.x series), all new packages are now released!