-
Notifications
You must be signed in to change notification settings - Fork 33
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
Implementation of feature 720 asym_line #762
base: main
Are you sure you want to change the base?
Conversation
Hi @leovsch, thanks for the draft PR. I have put the check list in the description of the PR to track where we are. |
Hi @leovsch, Herewith I come back with some suggestions on the implementation of Class memberI suggest having the following two class members for the parameters. The double i_n_;
double base_i_;
ComplexTensor<asymmetric_t> y_series_;
ComplexTensor<asymmetric_t> y_shunt_; ConstructionThe construction of For the construction of if (is_nan(r_na)) {
// if r_na is nan, it means user already does the kron reduction
// we just assign the 3*3 z_series by fill-in with (r + x * imaginary_unit) for each entry
// also fill-in the upper triangle based on symmetry.
}
else {
// if r_na is not nan, the user specifies the neutral conductor parameters, we need to do kron reduction
// in a way that
// z_kl_reduced = z_kl - z_nk * z_nl / z_nn
// k, l = a, b, c
// note: z_nk = z_kn, etc.
// fill-in all the values of 3*3 z_series, also the symmetry
}
y_series_ = inverse(z_series); We do the similar for Calculation parametersSymmetric parameterTo implement y_s = average of diagonal of y_series_;
y_m = average of off-diagonal of y_series_;
y1_series = y_s - y_m You put the Asymmetric parameterTo implement Please learn the function power-grid-model/power_grid_model_c/power_grid_model/include/power_grid_model/component/branch.hpp Lines 205 to 235 in 677c078
|
First implementation version is here some general remarks and questions:
I like working on the project, hope my questions are clear otherwise reach out 👍 |
Hi @leovsch , I will most likely spend some time tomorrow to review this, but at first glance, you've made the right decisions and followed the correct path. Without digging more into it, here's some initial response on your questions.
we try to follow the paradigm "If it looks like a duck, swims like a duck, and quacks like a duck, then it probably is a duck", especially on the things in
we do have something similar for transformers. That functionality resides in
I put it as a topic on the agenda for tomorrow with the rest of the team.
If you like, we can have a call about this. We do have some guidelines, but also a lot of heuristics, so it might be easier to talk to you directly. You can send an email to me (martijn.govers@alliander.com) if that is alright with you, and we can schedule a meeting.
That's great to hear! It's very nice to see external contributors working on the project, and we're happy to help you out at any time. Any feedback you have is also highly valued. Again, thank you for your input so far! Martijn |
Thanks again for the contribution! |
power_grid_model_c/power_grid_model/include/power_grid_model/component/asym_line.hpp
Outdated
Show resolved
Hide resolved
power_grid_model_c/power_grid_model/include/power_grid_model/component/asym_line.hpp
Outdated
Show resolved
Hide resolved
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
like I said: you're definitely on the right track. a couple ideas.
power_grid_model_c/power_grid_model/include/power_grid_model/common/common.hpp
Outdated
Show resolved
Hide resolved
power_grid_model_c/power_grid_model/include/power_grid_model/common/exception.hpp
Outdated
Show resolved
Hide resolved
power_grid_model_c/power_grid_model/include/power_grid_model/common/three_phase_tensor.hpp
Outdated
Show resolved
Hide resolved
power_grid_model_c/power_grid_model/include/power_grid_model/common/three_phase_tensor.hpp
Outdated
Show resolved
Hide resolved
power_grid_model_c/power_grid_model/include/power_grid_model/component/asym_line.hpp
Outdated
Show resolved
Hide resolved
} | ||
else { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
formatting can be automatically solved using pre-commit
(see https://power-grid-model.readthedocs.io/en/stable/contribution/CONTRIBUTING.html#pre-commit-hooks ; you can apply the format changes retroactively using pre-commit run --all-files
and run it before committing using pre-commit install
)
} | |
else { | |
} else { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I will try this once I've completely finished the implementation
return param; | ||
} | ||
}; | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
code convention: newline at end of file (EOF)
} | |
} | |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
guess this will be fixed if I use the pre-commit?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
yes indeed, but you might need to run pre-commit run --all-files
just to be sure, as it will by default only run on checked-in files during the commit phase.
power_grid_model_c/power_grid_model/include/power_grid_model/component/asym_line.hpp
Outdated
Show resolved
Hide resolved
} | ||
} | ||
|
||
} // namespace power_grid_model |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
newline at EOF
} // namespace power_grid_model | |
} // namespace power_grid_model | |
power_grid_model_c/power_grid_model/include/power_grid_model/component/asym_line.hpp
Outdated
Show resolved
Hide resolved
@leovsch I have compared with OpenDSS and I could not find the different you mentioned. Maybe can you elaborate a bit more about what exactly are we still missing? Then we can make a choice. |
power_grid_model_c/power_grid_model/include/power_grid_model/component/asym_line.hpp
Outdated
Show resolved
Hide resolved
Hi Tony, In OpenDSS you can per parameter (R, X, C) decide if you want to supply the full matrix or just the 0th and 1st order values. Example 1: Example 2: And all posible other permutations of the input format. For now I've implemented only the possibility that would support example 1. I can imagine that you would want to generalize such functionality to all possible permutations of the input format just as in OpenDSS. Hope this clarifies it a bit for you. |
@leovsch This is a valid point. Thanks for clarification. We need to discuss this and come back to you later. |
Hi @leovsch, Comeback to your point, we have thoroughly considered different options and decide to go with the attributes you have already defined in this PR. Concretely means: R = always full r matrix (no r1, r0 possible) From practical applications, if the user want to specify a r1/r0, they will almost certain specify x1/x0 instead of full x matrix, verse versa is also true. In that case, the user can just use normal We allow C to be specified in both c0/c1 or full c matrix way because this could be a use-case for the user. |
Thanks for the clarifification. I will leave it as is. |
Hi @leovsch , I see that this branch hasn't been updated with |
power_grid_model_c/power_grid_model/include/power_grid_model/common/matrix_utils.hpp
Outdated
Show resolved
Hide resolved
power_grid_model_c/power_grid_model/include/power_grid_model/component/asym_line.hpp
Outdated
Show resolved
Hide resolved
power_grid_model_c/power_grid_model/include/power_grid_model/component/asym_line.hpp
Outdated
Show resolved
Hide resolved
power_grid_model_c/power_grid_model/include/power_grid_model/component/asym_line.hpp
Outdated
Show resolved
Hide resolved
power_grid_model_c/power_grid_model/include/power_grid_model/component/asym_line.hpp
Outdated
Show resolved
Hide resolved
I did a rebase of my fork last week monday, I did not have any merge conflicts, does that typically not show up here? Or do you mean that since last monday a lot has changed? |
ohhh that's great. I did not realize that you only did it last monday. Great that you did not have merge conflicts. Usually, the amount of merge conflicts is small for things like a new component, but you never know 😬 |
power_grid_model_c/power_grid_model/include/power_grid_model/component/asym_line.hpp
Outdated
Show resolved
Hide resolved
power_grid_model_c/power_grid_model/include/power_grid_model/component/asym_line.hpp
Outdated
Show resolved
Hide resolved
power_grid_model_c/power_grid_model/include/power_grid_model/component/asym_line.hpp
Outdated
Show resolved
Hide resolved
power_grid_model_c/power_grid_model/include/power_grid_model/component/asym_line.hpp
Outdated
Show resolved
Hide resolved
power_grid_model_c/power_grid_model/include/power_grid_model/component/asym_line.hpp
Outdated
Show resolved
Hide resolved
power_grid_model_c/power_grid_model/include/power_grid_model/component/asym_line.hpp
Outdated
Show resolved
Hide resolved
power_grid_model_c/power_grid_model/include/power_grid_model/component/asym_line.hpp
Outdated
Show resolved
Hide resolved
While using this function for the new asym_line input validation function I ran into a potential issue (or my misterpretation of this function). Consider the following input data for aym_line: asym_line = initialize_array(DatasetType.input, ComponentType.asym_line, 2)
asym_line["id"] = [55, 56]
asym_line["from_node"] = [0, 1]
asym_line["to_node"] = [1, 2]
asym_line["from_status"] = [1, 1]
asym_line["to_status"] = [1, 1]
asym_line["r_aa"] = [-1, 2]
asym_line["r_ba"] = [-1, 2]
asym_line["r_bb"] = [-1, 2]
asym_line["r_ca"] = [-1, 2]
asym_line["r_cb"] = [-1, 2]
asym_line["r_cc"] = [-1, 2]
asym_line["r_na"] = [-1, 2]
asym_line["r_nb"] = [-1, 2]
asym_line["r_nc"] = [-1, 2]
asym_line["r_nn"] = [-1, 2]
asym_line["x_aa"] = [-1, 2]
asym_line["x_ba"] = [-1, 2]
asym_line["x_bb"] = [-1, 2]
asym_line["x_ca"] = [-1, 2]
asym_line["x_cb"] = [-1, 2]
asym_line["x_cc"] = [-1, 2]
asym_line["x_na"] = [-1, 2]
asym_line["x_nb"] = [-1, 2]
asym_line["x_nc"] = [-1, 2]
asym_line["x_nn"] = [-1, 2]
asym_line["c_aa"] = [-1, np.nan]
asym_line["c_ba"] = [-1, np.nan]
asym_line["c_bb"] = [-1, np.nan]
asym_line["c_ca"] = [-1, np.nan]
asym_line["c_cb"] = [-1, np.nan]
asym_line["c_cc"] = [-1, np.nan]
asym_line["c_na"] = [-1, np.nan]
asym_line["c_nb"] = [-1, np.nan]
asym_line["c_nc"] = [-1, np.nan]
asym_line["c_nn"] = [-1, np.nan]
asym_line["c0"] = [-1, np.nan]
asym_line["c1"] = [-1, np.nan]
asym_line["i_n"] = [50, 50] by calling the none_missing(data, ComponentType.asym_line, ["c_aa", "c_ba"], 1) I would expect the function to return two `MissingValueError' instances that look like this: MissingValueError(component=ComponentType.asym_line, field="c_aa", ids=[56])
MissingValueError(component=ComponentType.asym_line, field="c_ba", ids=[56]) Because this is the component at index 1 with id 56 and has missing values for the fields MissingValueError(component=ComponentType.asym_line, field="c_aa", ids=[55, 56])
MissingValueError(component=ComponentType.asym_line, field="c_ba", ids=[55, 56]) This is unexpected as id |
Hi @leovsch , I can confirm that this is a bug in the EDIT: I created #902 to this end. |
In the meantime, I recommend you add the check for required |
Hi @mgovers , Thanks for creating the issue. I've looked into your suggestion and I think the values that are always required are already in there. For the other ones I think this is kind of a special case. As some values might be optional depending on other values. For example, When a user supplied the C1 and C0, all the values for the full c matrix are not required anymore but either one should be supllied i.e. C1 and C0 or the full C_matrix. Looking at the What are your thoughts on this? |
Hi @leovsch , I see what you mean. We do have something similar for power sensors: either
However, I have found a bug in the latter (closely related to the bug in I have already found and implemented a sustainable solution including tests for the |
Implement feature:
# 720
Changes proposed in this PR include:
Implementation of feature 720.
Add a new component to support asym_line specification with R, X and C matrix values
Could you please pay extra attention to the points below when reviewing the PR:
I'm a new contributor so pay attention to the coding standards applicable to this project along with achitectural rules etc.
Check list
power-grid-model/power_grid_model_c/power_grid_model/include/power_grid_model/auxiliary/
input.hpp
/update.hpp
/output.hpp
or in the documentation directly)code_generation/data/attribute_classes/
input.json
/update.json
/output.json
+ runcode_generation/code_gen.py
power-grid-model/power_grid_model_c/power_grid_model/include/power_grid_model/component/[component].hpp
file that at least inherits from Base, but in this caseGenericBranch
should inherit fromBranch
power-grid-model/tests/cpp_unit_tests/test_[component].cpp
test_[component].cpp
topower-grid-model/tests/cpp_unit_tests/CMakeLists.txt
power_grid_model_c/power_grid_model/include/power_grid_model/all_components.hpp
main_core/topology.hpp
/input.hpp
/output.hpp
/update.hpp
)code_generation/data/dataset_class_maps/dataset_definitions.json
+ re-runcode_generation/code_gen.py
tests/data
src/power_grid_model/validation/validation.py
+ add corresponding tests