You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
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:
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.
The text was updated successfully, but these errors were encountered:
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:
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:
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:
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.
The text was updated successfully, but these errors were encountered: