Element order different compared to PowerWorld internal order
Closed this issue · 10 comments
@blthayer Hey Brandon, I wonder have you observed that the Simauto element order is sometimes different compared to PowerWorld internal order? For example, the branch order we could get from ListofDevices function is different compared to what shows in Model Explorer or in LODF analysis. Do you have any comments or suggestions on how to get the exact same order that is used by PW internally? Thanks!
I observed this problem in RTS 96 bus case as well as the 2000 case, so I would assume it is a common issue.
Hey @mzy2240 , long time! I hope you're doing well!
Unfortunately, I'm not sure hot to solve this one. Sounds like PowerWorld is being inconsistent between it's internal Model Explorer and SimAuto.
I suppose you could try to figure out what sort of ordering scheme is being used internally and then implement the sorting in ESA... but that sounds a bit hacky 😉
Haha that is definitely a hacky but smart solution. One thing I just observed is calling GetParametersMultipleElement function with key fields and without key fields will tend to have different orders. When key fields are not included in the paramlist, the order will be the same as internal order used in PW simulator. So to at least make the Simauto output consistent, I am thinking of adding key fields mandatorily to all the GetParametersMultipleElement calls. What do you think?
Ok I find the problem. We did sort the table when outputting the dataframe. For example, the ListOfDevices result is different compared to the raw SimAuto function. We could either modify the order to be the same as shown in simulator, or adding the key fields for every GetParametersMultipleElement calls to at least makes our order to be constant.
I suppose I should have led off with "What's the use case for making the output order match the PowerWorld order?" It seems to me like that should never be necessary, as the point of ESA is to enable the user to mostly avoid working the the PowerWorld GUI.
ESA doesn't claim to be just a wrapper around SimAuto. It purports to do more high-level and useful things for the user. For example, we output Pandas DataFrames instead of nested lists. Ordering by BusNum seems like a sane and maybe useful feature of ESA (we did it for a reason initially, I'm sure! Though that was a while ago so I don't remember the reason now without digging through lots of code and commit history haha).
I would be careful about making fields that were previously not mandatory, mandatory. Presumably folks are using ESA (at least I hope so!), so it's important to preserve backwards compatibility. Nobody likes it when they go create a new environment which includes updated packages and now their code is broken.
If you must have the ability to change sorting, add a new, optional argument (I'm not sure where: it's been so long and I don't really remember this code very well) that defaults to the old behavior. For example (I am not saying this is the right way to do this, just an example. It would take me a lot of time to get refreshed on the code and better understand the problem in order to give a proposal that I think is "right"), __init__ could take in a sort_by_bus flag that defaults to True.
Yes I totally agree, as long as the order from ESA is consistent. However in reality, sometime it is not. For example, calling GetParametersMultipleElement with key fields and without key fields will return elements in different orders (at least for branch objecttype). If you have IEEE RTS 96 bus case, you could very easily verify that by running the code below:
# obtain key fields for branch
key_field = sa.get_key_field_list('branch')
# you could observe different orders from the same function call
statement = "CalculateLODF(Branch %s %s %s)" % (108, 109, 1)
sa.RunScriptCommand(statement)
result1 = sa.GetParametersMultipleElement(ObjectType='branch', ParamList=['LineLODF'])
result2 = sa.GetParametersMultipleElement(ObjectType='branch',
ParamList=key_field + ['LineLODF'])
# You could find difference in the first 15 elements.
To avoid breaking the backward compatibility, maybe what I could do now is to mention this problem in the document (like Q&A or common issues).
Agreed - multiple calls to the same function should return the same sorting, so that certainly isn't ideal.
I also agree on your approach: if "fixing" the problem would cause a backwards compatibility problem, then documenting it rather than "fixing" it is the right approach.
I'm not sure if you have any long-term plans for ESA, but you could work toward a version 2.0 where things that would break backwards compatibility get addressed. Then, you could tag issues/tickets with a 2.0 "milestone." Only if you think it's worth building out a version 2.0, of course 😄
Judging by the increased number of "stars" since I last looked at this repository, it looks like a good number of folks are using ESA! That's great! You came up with a great idea, and I'm glad I was able to help build out version 1.0 with you!
It is for sure a great choice & great experience to work with you on ESA. I'm really happy that many people are using it and love it. I would keep adding useful functions to ESA, though jumping to version 2.0 I would very likely leave this great honor to the next successor : )