-
Notifications
You must be signed in to change notification settings - Fork 13
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Lines.RMatrix and Lines.XMatrix scale input before setting #36
Comments
I don't know, I posted something related on the forums and got no comments. I also did search the forums but couldn't find anything near the date of the commit. SourceForge's search is not great though, I could have missed something. https://sourceforge.net/p/electricdss/discussion/experts/thread/459afcb4/ It was changed in 2017 and it's inconsistent for those two properties (R1 and X1) even today in the official distribution -- dss-extensions/electricdss-src@c081ae2 Before that, there was no relevant changes in the Lines interface code. After, there was a fix in |
Oh, and to clarify, they scale in the getter, not in the setter. |
I see.
This is the linecode that is attached to that specific Line. And the units is
And the conversion is correctly applied to return the value with the correct units in the getter. However, in the setter we assume that the unit is what is defined original line code. I think it makes sense to multiply the I think this because a user is going to use the |
@kdheepak Something like that (there seems to be some missing side-effects besides the unit convertion), as we usually expect that a call like The COM PDF docs don't mention anything about units, but the Direct DLL mentions the same thing from the COM helpstrings that we have imported:
So it seems it was intended to use the same units, the missing factor on write is probably an oversight. I'll review the related code better this weekend. I think there are also issues with the capacitance values/matrices, maybe both in the parser side and in the DLL API side. I also noticed that in the parser there are some conditions that I didn't see in the API code. For reading: // From Line.pas
12:
for i := 1 to FNconds do // R matrix
begin
for j := 1 to i do
begin // report in per unit Length in length units
if GeometrySpecified or SpacingSpecified then
Result := Result + Format('%-.7g', [Z.GetElement(i, j).re / len]) + ' '
else
Result := Result + Format('%-.7g', [Z.GetElement(i, j).re / FUnitsConvert]) + ' ';
end;
if i < FNconds then
Result := Result + '|';
end; For writing, there is no extra unit handling, but it changes other things:
Looks like we really need that better handling of side-effects. I spent a couple minutes searching the repositories that use OpenDSS here on GitHub and on SourceForge. I didn't find any that reads or writes (R/X)Matrix through the API, only saw code that uses the parser. Maybe some people found this bug/strange behavior and just used the parser instead. Either way, it doesn't look like we would break too much code.
No, not directly. I think it's a good idea to expose some of the utility functions used for this kind of thing (e.g. |
Yes, I don't expect people are changing the RMatrix of a line / linecode using the setter functionality. We could even request a call with EPRI folks and see if they can help us answer questions and sort out any issues we have. Thanks again for looking into this! If you want to open issues and assign them to me, I'm willing to get my hands dirty as well. I can submit PRs here for the necessary changes. I feel a little bad just opening all these issues and making you look into them ;) |
@PMeira I noticed that RMatrix and XMatrix functions scale the input when setting values
What is the reason behind this behavior?
The text was updated successfully, but these errors were encountered: