Fix short-circuit source impedance scaling

[shin4141]

Fixes #1352

Changes proposed in this PR include

• Keep sk based on the connected node's rated voltage and carry an SC-only per-source admittance factor of 1/c from short-circuit input preparation.
• Apply the scaled source admittance consistently to the Norton matrix/RHS and source-current post-processing, without changing power flow, state estimation, or generic cached-YBus semantics.
• Add a solid source-bus regression for c=0.95, c=1.0, and c=1.1, and update the 13 directly affected short-circuit golden files. Their JSON structure and non-numeric content are unchanged; the semantic changes are numeric SC results only.

Local verification: focused property 6/6 assertions; all single/batch short-circuit validation 16,239/16,239 assertions; power-flow/state-estimation single/batch counterchecks 12,385/12,385 assertions; full configured CTest 198/198 tests; clang-format and git diff --check pass.

Not run locally: Python pytest/coverage, Linux/Windows compiler matrices, sanitizers, full clang-tidy, or upstream CI.

Could you please pay extra attention to the points below when reviewing the PR

• The same scaled source admittance is used for matrix assembly, the Norton RHS, and source-current output.
• Low-voltage minimum scaling (c=0.95) is handled per source, while existing internal solver inputs can retain a neutral scaling of 1.0.
• The broad golden movement is confined to short-circuit outputs.

Checks

• If changes are related to CI/CD, are they verified via a manual run on this branch? (Not applicable; no CI/CD changes.)
• Do you wish to discuss this PR in the bi monthly community meeting? (No.)

Assisted-by: OpenAI Codex (repository analysis, implementation, test design, and local verification).

[nitbharambe]

Thanks @shin4141 We shall review the implementation and the modified tests soon.

[nitbharambe]

Rest looks good!

[figueroa1395]

Hello @shin4141,

We reviewed the implementation and noticed only minor changes to be made. Do you wish to continue and finalize your contribution? We are happy to help if needed.

[shin4141]

Thanks for following up. Yes, I would like to continue and finalize the contribution.

I have addressed the three review comments:

• moved the scaling explanation to ShortCircuitSolver::source_admittance();
• removed the dedicated source_admittance_scaling vector and now derive 1/c directly as
  1.0 / cabs(input.source[source_number]); and
• made the complex source value explicit in the focused regression test.

I also updated the existing short-circuit unit-test expectations to use Z(c) = c * Z.
After integrating the current main branch, I preserved its newer link/fault changes and
regenerated the overlapping dummy-test-line-into-itself golden from the combined tree.
I also updated the numeric-only golden for the newer multiple-infinite-faults
maximum-scaling fixture.

I independently checked all 14 affected/adjacent SC expected files with the unmodified
current-main solver using the equivalent input transformation sk' = sk / c, derived from
Z(c) = c * Z. I retained the four high-voltage minimum goldens unchanged because all of
their source factors are c = 1; the final diff changes only the ten semantically affected
goldens.

The code-identical integrated tree passed the focused regression (6/6 assertions), math
solver (47/47 cases, 2,363/2,363 assertions), main core (9/9 cases, 452/452 assertions),
full configured CTest (205/205), and Python validation (383 passed with 7 expected
xfails). clang-format and git diff --check also passed. The final pruning step changed no
production or unit-test code; it restored four c = 1 expected-output files to current-main
values, and focused validation of those cases passed (5 tests, 385 deselected). I did not
rerun the full suite after this expected-data-only prune.

The independent reference covered 632 scenarios and 74,138 expected numeric values.
The updated head still needs the upstream CI matrix to run.

[shin4141]

Hello,

After your September 10 invitation to finalize this contribution, I addressed all three review comments and completed the additional verification described above. I noticed that the do-not-merge label was subsequently added, but I could not find an explanation in the discussion.

Could you clarify what is blocking the PR and whether any further action is needed from me, or whether it is waiting on an internal review or CI step?

I understand that completing requested changes does not guarantee a merge. However, after being asked to resume the work and investing time in the revisions and validation, a brief explanation of the hold would help me understand the next step and plan my time.

Thank you.

[nitbharambe]

Hi @shin4141 , the do-not-merge is sort of an inter-maintainer communication label. In this specific case, The label was added to communicate pending review despite of passing CI.
We definitely intend to merge this. The bugfix is a valuable contribution. Apologies if there was any miscommunication.

I am done with that review now.