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

Home Page:https://dss-extensions.org/OpenDSSDirect.py/

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Bug: Different results on different operating systems

felipemarkson opened this issue · comments

Versions

  • Python version: 3.7
  • Python architecture: x64
  • Operating system and version: Windows 10 and Ubuntu 18.04
  • OpenDSSDirect.py version number: 0.3.7

Bug

  • What is the current behavior?

    When running the IEEE 13 Bus system on different operating systems, the line "671680" has a different angle value for the second bus, second phase. I'm using dss_python v0.10.1, installed as a dependence of OpenDSSDirect:

$ pip install OpenDSSDirect.py
  • What are the steps to reproduce this bug? Please provide a minimal working example of the bug if possible.
    A script to reproduce this bug with logs: bug-script.zip
import opendssdirect as dss

dss.run_command('Redirect ../../tests/data/13Bus/IEEE13Nodeckt.dss')
linename = "671680"
dss.Lines.Name(linename)
angle_bus2_ph2 = dss.CktElement.CurrentsMagAng()[9]

Logs:

On System: Linux
Circuit: ieee13nodeckt
Line: 671680
Phase 2 angle of bus 2: 65.55604521605676

On System: Windows
Circuit: ieee13nodeckt
Line: 671680
Phase 2 angle of bus 2: 163.3007557572332

That's expected -- the angle is meaningless, basically noise, when the magnitude is tiny like in this example (<1e-11).

In general it's better to compare complex numbers in their primary format (rectangular for most software), and avoid comparing a single component of the number (re, im, magn or angle) by itself.

Is there any difference between the implementation of OpenDSSDirec.py for Windows and Linux?

The ODD.py code itself is fully platform agnostic, but it just exposes the low-level C-API in Python, reusing the CFFI implementation from https://github.com/dss-extensions/dss_python/.

For the low-level C-API, we use Free Pascal on all OSs for the Pascal code, and for the C and C++ code various compilers are used.

The Pascal code is the main (slightly modified) OpenDSS code + the custom API code, resulting in the DSS C-API library, currently at https://github.com/dss-extensions/dss_capi/. We did observe some different results at Pascal level before that resulted in actual bugs and handled that already.

The linear solver used in OpenDSS is KLU. OpenDSS itself uses the KLUSolve library, which we initially forked to maintain it for better integration with DSS C-API. More recently, I rewrote part of the code and added some functionality which will be released in the coming months. This is at https://github.com/dss-extensions/klusolve and can be built using GCC, Clang or MSVC. Since the compiler apply different optimizations and we're dealing with floating-point numbers, this single fact (different compilers) could result in slightly different results. I imagine that if a system is badly conditioned, the differences will be accentuated -- note that, in this case, with the current solver, that doesn't mean any of the implementations is better than the others. There is some work on that for the future, mostly by allowing use of different solvers at run-time.

For the DSS C-API releases, I usually validate the results with the current official OpenDSS COM (which itself may contain some bugs). The results can be pickled and loaded later on Linux and macOS to validate most of the results. The tested files are listed on https://github.com/dss-extensions/dss_python/blob/0.10.x/tests/common.py and will be extended for the next version (there are some new files).

The test suites from ODD.py, ODD.jl and dss_python all were able to find minor issues in DSS C-API (sometimes the main OpenDSS code, sometimes in the API code) throughout the releases.

Thanks for that complete answer. I imagine that this difference is due to different compilers.
One last question, have you ever used the API with containers? Like Docker?

One last question, have you ever used the API with containers? Like Docker?

Sure, and many builds and tests from dss-extensions use Docker on Linux, via Travis-CI. See also dss-extensions/dss_capi#53

For just running, it's usually enough to download the pre-built binaries. For Python, the binaries (included in dss_python) are available on PyPI, we just need provide an update OpenDSSDirect.py there soon to complement it. The dss_python wheels (huge list here) are built and audited for the manylinux2010 standard, and are still compatible with the manylinux1 version too (CentOS 5, initially released on 2007, already reached EOL). That is, they should be compatible with most distributions. OpenDSSDirect.py itself is a source package, and in turn is easy to install from the git repo/snapshot.

Thanks, I have another project in mind and I was thinking about using the docker with this API!
This information helped a lot!