[FEATURE] Use `OpenDSSDirect.jl` to parse `.dss` files instead of try to implement a parser

[felipemarkson]

I'm facing many problems with the parse_dss implementation since the parser doesn't have all the cases of OpenDSS syntax. Some of these problems can be found in #394, #396, and #397.

The proposal solution Since the parse_dss is just a secondary feature and maybe it is not the major concern of the development. I suggest using OpenDSSDirect.jl to compute all the elements and use its API to get the information needed for the package.

The OpenDSSDirect.jl is well documented and tested in several cases.

I'm very happy to help with this change :)

What do you guys think about it?

[ccoffrin]

I recommend that this code (PMD) maintains a dedicated parser for the subset of .dss files that are supported by this package.

[pseudocubic]

I agree with @ccoffrin's recommendation that we continue to support our parser for the subset of OpenDSS that is actively supported by this package.

There are a couple of reasons for this, the most important being that DSS files actually are scripts written in a programming language specified by OpenDSS, not a pure distribution network data specification. What this means is that there are a lot of things that happen when a DSS file is loaded with OpenDSSDirect.jl that could be inconsistent with users' expectations for this package. We are supporting only a subset of the DSS format in order to allow users to bring in distribution network data from a common source, but ultimately I would argue that this technically an abuse of that format.

Also, we are generally conservative in our core modeling packages about adding external dependencies, to ensure that our upgrade paths are relatively smooth, and because OpenDSSDirect.jl is outside of our organization, there would have to be a very significant added benefit over the existing parser that I am not sure I see yet based on the capabilities that exist in PMD today.

[felipemarkson]

There are a couple of reasons for this, the most important being that DSS files actually are scripts written in a programming language specified by OpenDSS, not a pure distribution network data specification. What this means is that there are a lot of things that happen when a DSS file is loaded with OpenDSSDirect.jl that could be inconsistent with users' expectations for this package.

Yes, it is not a pure distribution network data specification. However, if there is an inconsistency, the problem is the modeling of the.dss file, and I think this is not inside the scope of the package. (At least for loads, generators, and all PDElements)

To avoid some weird things happening, I suggest just removing the solve command from the .dss file and using the OpenDSSDirect.jl API to get the data. You can easily get all information from the OpenDSS and assure that the basic power flow (without optimization) will have the same result as a well know software.

We are supporting only a subset of the DSS format in order to allow users to bring in distribution network data from a common source, but ultimately I would argue that this technically an abuse of that format.

Yes, and I think this is so much hard to maintain. The OpenDSS format is great but not easy to parse (This is why I suggest the OpenDSSDirect.jl).

Also, we are generally conservative in our core modeling packages about adding external dependencies, to ensure that our upgrade paths are relatively smooth.

Sorry, but I don't see how this could hinder some update/upgrade since you guys have good CD/CI processes.

[...] there would have to be a very significant added benefit over the existing parser that I am not sure I see yet based on the capabilities that exist in PMD today.

I'm suggesting this approach because I can see problems in the future with keeping the parser working well. I don't know if this package has many users, but I faced problems (#394, #396, and #397) just using the package for one day, many of that was related to the parse, and it was not outside the subset of the DSS format that you mentioned.

But see, this is just a suggestion. From my experience and seeing all the hard work you guys did on the parser, I can see that this is not a good idea and is very difficult to maintain in a long term.

I understand the concern about adding a new dependency to the project, and if you guys don't like this suggestion, I'm happy to close this issue!