Plotting: add as a package extension

[PMeira]

This is a planning and tracking issue for the plotting implementation. As suggested by Tom, we can add this as a package extension so it won't affect negatively users that don't want or expect plots from DSS scripts. Toggling the AllowForms value would be enough to control whether plots would be enabled even if the dependencies are installed.

The main plotting alternatives seem to be Plots.jl and Makie.jl. Both have multiple backends and are not lightweight. Ideally, since most of the work is actually preparing the data, we can add basic support for both later.

Tasks:

• Add the basic code infrastruture
• For testing, add examples, even if they don't output any figures at first. One of the alternatives for notebooks could help.
• Implement most DSS plot commands:
  • Scatter
  • Daisy
  • TShape
  • PriceShape
  • LoadShape
  • Monitor
  • Circuit
  • Profile
  • Visualize
  • YearlyCurve
  • Matrix
  • GeneralData
  • DI
  • MeterZones
  • CompareCases (this one is a maybe)
• Formalize and document the API for plotting without using the DSS commands. This would also be useful when we reintroduce support for the official ODD.DLL.
  • Investigate what other (custom) plot types we could add
• Add support for old .DSV files?
• Evaluate adding support for the official TCP connection.

Some of basic plots are very easy to implement, some not so much (lots of details). Depending on the progress, we can add plot types piecewise since some plots would be better than none.

Plot commands

DSS-Python already implements most of plot commands and the code there can be used as a reference: https://dss-extensions.org/DSS-Python/examples/Plotting

Note that the plots are kinda ugly since they are intended to mirror the original OpenDSS experience. We probably should change that though (I was thinking in adding an option to use a custom style in Python too).

Current tests

The integration is achieved using a simple callback that returns a JSON-encoded string with the basic plot parameters. Most of the data is collected through the API to finally plot it. Julia makes this very easy. From my current tests:

function plot_cb(ctx::Ptr{Cvoid}, jsonParams_c::Cstring)::Int32
    # TODO: map context pointer
    # TODO: try/catch, returning the error to DSS C-API

    if jsonParams_c != C_NULL
        jsonParams = unsafe_string(jsonParams_c)
    else
        jsonParams = "{}"
    end
    params = JSON.parse(jsonParams)
    ptype = params["PlotType"]

    if ptype == "Profile"
        dss_profile_plot(params)
    end
    
    return 0
end

OpenDSSDirect.Lib.DSS_RegisterPlotCallback(OpenDSSDirect.DSS_DEFAULT_CTX.ctx, @cfunction(plot_cb, Int32, (Ptr{Cvoid}, Cstring)))

OpenDSSDirect.dss("""
    redirect electricdss-tst/Version8/Distrib/EPRITestCircuits/ckt5/Master_ckt5.dss
    solve
    plot profile
""")

I started playing with Plots.jl first:

I'll open a PR with some of this soon.

Extend the C-API?

It might be useful to extend the API to return some prepared data for circuit and profile plots to avoid redoing the work for every target language on DSS-Extensions.

On the official OpenDSS plots

There are two separate plotting implementations in the official OpenDSS:

• Legacy version uses DSSView.exe; this uses the .DSV files. The files are written and DSSView is started. Adding support for reading those files could be useful.
• The newer OpenDSS Viewer (it had different names in the past, a.k.a. OpenDSS Visualization Tool). This one is fed JSON from a TCP connection.

Both tools have minor issues, and some plot commands don't work on either, some for a few years, some for more than a decade. (technically, DSS-Python currently supports more plots than both, but no interactive features).

Although most of the plot setup code is in Pascal and open-source, the actual plotting tools are not open-source. I think OpenDSS-G is in a similar situation, as well as OpenDSS-GIS.

Note that I did remove the TCP connection code from DSS C-API since I don't like that enabled by default. DSS C-API will have a plug-in system soon, so we could readd it as an optional feature for interactive usage if required.

[tshort]

Wow. Cool ideas!