DSS-Extensions based on DSS C-API 0.13

[PMeira]

The release cycle for the projects based on DSS C-API 0.13 (includes most features from OpenDSS v9.6.1.1) has started today. Today, we released:

• DSS C-API 0.13.0: https://github.com/dss-extensions/dss_capi/releases/tag/0.13.0
• DSS-Python 0.13.0: https://github.com/dss-extensions/dss_python/releases/tag/0.13.0
• OpenDSSDirect.py 0.8.0: https://github.com/dss-extensions/OpenDSSDirect.py/releases/tag/v0.8.0
• OpenDSSDirect.jl 0.9.0: https://github.com/dss-extensions/OpenDSSDirect.jl/releases/tag/v0.9.0

New packages for DSS_Sharp, DSS_MATLAB and dss.hpp remain to be released in the coming days.

[PMeira]

DSS_MATLAB version 0.13 has been released.

Along some fixes and usual updates ported from DSS-Python, the new AdvancedTypes feature is also available. With this, complex numbers and matrix shapes are used in a lot of properties and functions. An example is pasted below.

This feature is currently implemented in DSS-Python and DSS_MATLAB, while OpenDSSDirect.jl already returns matrices for a select subset of the API. In the future, OpenDSSDirect.py will have support.

>> DSSObj = DSS_MATLAB.IDSS;
>> DSSObj.Text.Command = 'redirect "..\electricdss-tst\Version8\Distrib\EPRITestCircuits\ckt5\Master_ckt5.dss"';
>> DSSObj.ActiveCircuit.TotalPower

ans =

   -0.0009    6.9789

% Note that the result is a 2-element array (of reals).

>> DSSObj.AdvancedTypes = true;

>> DSSObj.ActiveCircuit.TotalPower

ans =

  -0.0009 + 6.9789i

% We now get a complex number instead

>> DSSObj.ActiveCircuit.Lines.First;
>> DSSObj.ActiveCircuit.ActiveCktElement.NumConductors

ans =

     3

>> DSSObj.ActiveCircuit.ActiveCktElement.NumTerminals

ans =

     2

>> DSSObj.ActiveCircuit.ActiveCktElement.Currents

ans =

   0.1600 + 0.2770i  -0.1600 - 0.2770i
   0.1453 - 0.2518i  -0.1453 + 0.2518i
  -0.3129 - 0.0000i   0.3129 + 0.0000i

% The result is given in matrix form, as complex numbers, instead of an unshaped array of reals

[PMeira]

DSS_Sharp v0.13.1 has been released.

Of special note, DSS_Sharp now includes an option to disable the error-to-exception mapping, and the NuGet package should now
behave better with old apps that use .NET Framework. A simple example was added as a first step for more documentation: WinFormsAppSample.

The other packages were all updated to DSS C-API v0.13.1, which was also released in the past few days to address a minor concern.

[PMeira]

Forgot to say that dss.hpp should be updated by next week, including example usage.

[etherbrat]

Hi Paulo, Can you comment on the behaviour of switches in DSS-Python / DSS C-API? In my experience, this OpenDSS feature is unreliable at best, and leads to incorrect solutions when used in conjunction with transformers (and possibly in other cases). For example, if I have two transformers feeding a load in parallel, and I open the LV side of one of them, I would expect its LV current and power to go to zero and the other transformer to pick up all of the load. Also, I would expect the LV voltages on the unloaded transformer to be "no-load" values. This does not happen. Are DSS Python / DSS C-API structured in such a way as to not have this problem? Thanks in advance, Neil

[PMeira]

@etherbrat, if you have a minimal sample circuit we could take a look, since it depends on how/what you modeled as a switch. The behavior here should follow what the official OpenDSS does, but if it seems like a bug we can investigate (and potentially fix) here and report back to the official OpenDSS devs. If it's not a bug, we can consider adding some notes to our docs/examples.

Some thoughts:

• Remember that lines with switch=yes are still lines with tiny impedances, not ideal switches.
• If you're using SwtControl, it may have some unexpected (maybe buggy?) behavior per SwtControls.Action() has no effect after SwtControl is unlocked OpenDSSDirect.py#99 (not sure if the user ever reported to EPRI)
• I would expect that opening/closing one of the terminals of a line or transformer to work fine. From a quick test right now, it seems to be OK; two transformers in parallel, opening the second terminal of one leaves near zero currents and powers.

[etherbrat]

Hi Paolo, Yes, but the WINDING voltage of the off-line transformer, retrieved through the COM interface of OpenDSS, is wrong. It’s the same as the LV bus voltage. Also I think the WINDING current of the off-line transformer goes haywire – I’ll have to re-check that. I’ll put together a short demonstration as soon as I can. I’m doing this with Python and the win32com.client, so I need to pull out just the essentials. I reported this through the OpenDSS forum some time ago, but the reply I got was “it’s open source, so feel free to fix the problem yourself”. Nice sentiment, but I’m not much of a programmer. Neil From: Paulo Meira ***@***.***> Sent: Thursday, 13 April 2023 11:21 PM To: dss-extensions/dss-extensions ***@***.***> Cc: etherbrat ***@***.***>; Mention ***@***.***> Subject: Re: [dss-extensions/dss-extensions] DSS Extensions based on DSS C-API 0.13 (Discussion #21) @etherbrat <https://github.com/etherbrat> , if you have a minimal sample circuit we could take a look, since it depends on how/what you modeled as a switch. The behavior here should follow what the official OpenDSS does, but if it seems like a bug we can investigate (and potentially fix) here and report back to the official OpenDSS devs. If it's not a bug, we can consider adding some notes to our docs/examples. Some thoughts: * Remember that lines with switch=yes are still lines with tiny impedances, not ideal switches. * If you're using SwtControl, it may have some unexpected (maybe buggy?) behavior per dss-extensions/OpenDSSDirect.py#99 <dss-extensions/OpenDSSDirect.py#99> (not sure if the user ever reported to EPRI) * I would expect that opening/closing one of the terminals of a line or transformer to work fine. From a quick test right now, it seems to be OK; two transformers in parallel, opening <https://dss-extensions.org/dss_python/dss.html#dss.ICktElement.ICktElement.Open> the second terminal of one leaves near zero currents and powers. — Reply to this email directly, view it on GitHub <#21 (reply in thread)> , or unsubscribe <https://github.com/notifications/unsubscribe-auth/AKEPQNBENP4T2PVN22U6TVDXA74UJANCNFSM6AAAAAAWLJZZNE> . You are receiving this because you were mentioned. <https://github.com/notifications/beacon/AKEPQNDVQ4662NNA4KUASYLXA74UJA5CNFSM6AAAAAAWLJZZNGWGG33NNVSW45C7OR4XAZNRIRUXGY3VONZWS33OINXW23LFNZ2KUY3PNVWWK3TUL5UWJTQAKWCD6.gif> Message ID: ***@***.*** ***@***.***> >

[PMeira]

Hi, Neil,

Yes, but the WINDING voltage of the off-line transformer, retrieved through the COM interface of OpenDSS, is wrong. It’s the same as the LV bus voltage.

Yes, from your description the winding voltages/currents are just wrong. From a quick look into the code, the issue seems to be that no special handling is done when terminals are open, so the voltages are used as if the terminal is still connected/closed.

I'm not sure we can easily handle that for all situations, but the most common situations should be doable. And when not possible, returning an error instead of invalid values is always preferable, IMHO.

I reported this through the OpenDSS forum some time ago

I'll see if I can find it. Unfortunately lots of comments are lost to the void in the forum, only for someone to report the same or similar issue sometime later. A bug/issue tracker really helps. There's a constant influx of new users to OpenDSS and the forum gets flooded with "first steps" comments, drowning most potential bug reports.

I’ll put together a short demonstration as soon as I can. I’m doing this with Python and the win32com.client, so I need to pull out just the essentials.

Please do. We can use that as an example to illustrate the issue and add a modified version later in the test suite. If you prefer, feel free to email me at pmeira at ieee dot org

One potential workaround to opening the terminal could be setting the bus related that the terminal to a new, empty bus. This way, the powerflow solution and WdgVoltages/WdgCurrents should work as expected. Don't know what to do about AutoTrans though...

[etherbrat]

Many thanks. There is an old AppNote on switching, which doesn’t mention this problem, but suggests changing to an empty bus as a “safe” way of achieving most objectives. This is indeed a work-around in my view - changing the connectivity model in some arbitrary way to get around a bug - not very automatable. Anyway, I’ll prepare the example and send it as soon as I can. Regards, Neil

[etherbrat]

About as simple as I can make it. The .DSS file is for two transformers feeding a load. The .PY (python) file does a solution with both transformers feeding, then opens the LV side of the first transformer and does another solution. The transformers have different impedances and taps, so in the first solution there is a lot of circulating current. NOTES: 1. I had to change both file extensions to .TXT to post them. 2. Main program at bottom of .PY file; 3. You will have to adjust the path to the .DSS file in the OpenDSS "Compile" command. The WINDING quantities are retrieved from via the COM object as per the documentation and my Python functions. With the first transformer's LV disconnected, the winding voltage and current are both obviously incorrect.
TfmrSwitchingBugDemo-DyDy.TXT
TransformerSwitchingBugDemo.TXT

[etherbrat]

I didn't explain why WINDING quantities are important to me. For the voltage: In a substation it is common for the LV VT to be positioned between the transformer and the LV circuit breaker - i.e. it monitors the winding voltage, which is useful in several ways. So in a realistic co-simulation involving voltage regulation, it is the WINDING voltage that matters. For the current: It can occur that the tapchanger has a different (sometimes lower) rating than the winding it is in. So for a realistic co-simulation involving tapchanger overload protection, it is the WINDING current that matters.

[PMeira]

Thank you for the example, and you reasoning makes perfect sense for me.

I opened #24 to track this, including some initial notes from what I could observe from the code so far. I'll look at it with a bit more time later, before changing the code.

[etherbrat]

Thanks, Paulo. I'm sure there is an elegant solution. I just wish I knew what it is :-) Neil