M_Oline example (new version) and support functions for C and Z multiconductor line matrices

[ceraolo]

This PR logically follows PR #3819, since It takes advantage of the folder Modelica.Electrical.Analog.Examples.Lines created in that PR.

---

This PR contains an example of the usage of M_OLine to analyse the behaviour of a power line, including ground return.

To ease this usage, I created two utility functions LineZmatrix and LineCmatrix that compute Z and C matrices from the geometry of conductors.

The function LineZMatrix is able to compute all the elements of the Z matrix correctly (according to Carson's theory for ground return and only for a given frequency), with non-zero value of resistances of off-diagonal elements, even though M_Oline does not allow including off-diagonal resistances in simulations. Therefore, it can be used in future for further models able to consider these resistances. These further models may be possibly included in the Electrical-Polyphase or QuasiStatic-Polyphase sub-library. They could be based on cascaded-pi as M_OLine, or be a multiphase extension of MSL TLine model, e.g. similar to the one available in https://it.mathworks.com/help/sps/powersys/ref/distributedparametersline.html.

In M_OLine, capacitive couplings between conductors are simulated through physical capacitors to be put across them, instead of a capacitance matrix. Therefore, to use M_OLine the elements of the conductor C-matrix must be first converted into a set of capacitances for physical capacitors across conductors. This conversion is made inside LineCmatrix as well, and its effectiveness is demonstrated by the model CompareCmatrix, included in this PR.

The theory behind LineCMatrix and LineZmatrix is available in the Appendix of a paper of mine [M. Ceraolo, “Modelling and Simulation of AC Railway Electric Supply Lines Including Ground Return”, IEEE Transactions on Transportation Electrification Vol. 4, issue N. 1, pp. 202-210], which in turn is a compact version of a much larger work I did in past years. I can discuss details this theory in case it is requested.

Important note. This PR substitutes previous PR 3846 that I deleted by mistake! It takes into account everything already discussed under that PR, available in: https://github.com/modelica/ModelicaStandardLibrary/pull/3846

Summary by CodeRabbit

• New Features

  • Introduced new simulation examples illustrating capacitive coupling and impedance analysis in multi-conductor electrical systems, including an overhead power line model with fence interactions.
  • Added test cases that validate computed electrical matrices.

• Documentation

  • Updated visual annotations and reference materials with links to relevant theoretical literature.

• Enhancements

  • Standardized parameter types for improved clarity.
  • Reorganized simulation functions for a more streamlined structure.

[CLAassistant]

All committers have signed the CLA.

[TManikantan]

@christophclauss @AHaumer would you please the fix provided by @ceraolo , he has put efforts to work on it. Many thanks.

[ceraolo]

It seems that the evaluation process of this PR is now blocked. Is there something that I must or can do? Thanks.

[tobolar]

I've worked a lot on the technical content of the commit, but I'm unable to manage, without support, this phase of the revision.

@ceraolo I cannot review the technical content since not in my expertise area. I've concentrated on formal style mistakes which break MSL conventions. (I indeed highly appreciate a comprehensive documentation of your models and examples!)

I've added a review requiring changes now. So please go through my comments again - you should be able to commit/reject accordingly now. ("outdated" could be ignored; and note there could be hiden comments due to a long communication). Hope this works for you.

[ceraolo]

@tobolar , I've committed a lot of recommendations from you, considering that they referred just to html, and therefore did not interacti with functionality.

Now I pulled the result on Dymola and received a lot of error messages.

Therefore, I'm going to rever all these commits, and then I'll apply them again, one at a time.

[ceraolo]

@tobolar, I've gone through all your comments, suggestions and recommendations. Thank you for the huge work!

I've accepted and implemented 90% of them. In a few cases I did not, and explained why in responses to your comments. Can you please have a look?

I think we are nearly there!

[christiankral]

The acual implementation has some severe unit issues. Example Modelica/Electrical/Analog/Lines/Functions/lineZmatrix.mo:

  input Modelica.Units.SI.Resistivity rho=100 "Ground resistivity";
  input Modelica.Units.SI.Frequency f=50 "Frequency";
...
parameter Real a0=4*pi*sqrt(5)*1e-4*sqrt(f/rho)
    "multiplies D in a-pameter from EMTPs Theory Book";

@HansOlsson If we do not fix all the unit errors before merging, we have to fix them afterwards. The reqired changes may need some re-writing of equations and proper units of the used variables.

Then original implementation of the EMTP Theory Book may be

• based on empirical non-SI unit equations or
• hidden units applied in purely numeric scaling factors.

[ceraolo]

Then original implementation of the EMTP Theory Book may be

• based on empirical non-SI unit equations or
• hidden units applied in purely numeric scaling factors.

Ok, I wrote these lines a few years ago, and I forgot to revise them when preparing the PR. Obviously, these unit inconsistences must be removed. I'll do this personally very soon.

[HansOlsson]

The acual implementation has some severe unit issues. Example Modelica/Electrical/Analog/Lines/Functions/lineZmatrix.mo:

  input Modelica.Units.SI.Resistivity rho=100 "Ground resistivity";
  input Modelica.Units.SI.Frequency f=50 "Frequency";
...
parameter Real a0=4*pi*sqrt(5)*1e-4*sqrt(f/rho)
    "multiplies D in a-pameter from EMTPs Theory Book";

@HansOlsson If we do not fix all the unit errors before merging, we have to fix them afterwards. The reqired changes may need some re-writing of equations and proper units of the used variables.

I agree. Looking at equations like: Q := (-0.03860784) + 0.5*log(2/a) + sqrt(2)/6*a-pi/64*a*a; I don't see how they could make sense unless a.unit="1". Since a:=a0*2*y[i]; and a:=a0*D;, that only makes sense if a0.unit="m-1" - which isn't compatible with sqrt(f/rho).

[ceraolo]

The acual implementation has some severe unit issues. Example Modelica/Electrical/Analog/Lines/Functions/lineZmatrix.mo:

  input Modelica.Units.SI.Resistivity rho=100 "Ground resistivity";
  input Modelica.Units.SI.Frequency f=50 "Frequency";
...
parameter Real a0=4*pi*sqrt(5)*1e-4*sqrt(f/rho)
    "multiplies D in a-pameter from EMTPs Theory Book";

This can be fixed, obviously.

But I first try explain it, even though it is rather lengthy.

To implement line formulas, I could not resort to orignal Carson's formulas (published ub a paper from 1926 by Bell Technical Journal), because they are rather exhoteric , and use a language that nowadays appears clumsy.

Threrefore, I preferred to use a formulation near to that of EMTP theory book's, obviously after having checked its compliance to Carson's. In this way, any reader would have an authoritative source where to check formulas. To compare Carson theory book formulas I had the difficulty that Carson's contain infinite series, and therefore I had to stop the summation up to a maximum term in the series. However, by checking actual numbers and Power System Literature, I verified that the series can be stopped, for power system studies, rather early. I included in my routine a few more terms than what most commonly used version of Carson's formula, in a formulation near to EMTP theory book's. This guarantees good representation of ground upt to several hundred hertz,; if a larger than acceptable frequency is requested, given the line geometry, a warning is issued.

To show the dimension correctness of my formulas, consider that a0=sqrt(w*sigma*mu) where

• omega is the rotational frequency=2*pi*f
• sigma is the conductivity, the inverse of resistivity
• mu is the magnetic permeability (for empty space, in modelica mu_0)

It is easy to understand that omega*mu is an impedance per unit length, and that sigma is a conductance per unit length. Therefore a0 is the inverse of a length. (The fact that omega*mu is an impedance per unit length can be easily seen considering that omega*L is an impedance, where L is an inductance, and that mu is an inductance per unit length).

In the following screenshot we see that what I put in the code (= EMTP theory book formulation), i.e. ,a0=4*pi*sqrt(5)*1e-4*sqrt(f/rho) is equivalent to a0=sqrt(w*sigma*mu):

So, when I wrote the code I tried to stay as near as possible to Theory Book, that I chose as a "verifiable source".

I can change the formulation in a way that allows better verification of dimensions; this will have however the disadvantage that the formulation will depart from the Emtp theory book's. For instance, I could take inspiration from the one I used in Appendix A of my paper https://ieeexplore.ieee.org/document/8076707.

Or, as an alternative, I could just write a0=sqrt(w*sigma*mu). Maybe this is the right solution, since it reaches the purpose of dimension clarity, with minimal code change.

EDIT: Well, I've just updated lineZmatrix and used a0=sqrt(w*sigma*mu), The results, as obvious, are unchanged up to all the visible digits in the matrix output.

[HansOlsson]

It is easy to understand that omega*mu is an impedance per unit length, and that sigma is a conductance per unit length. Therefore a0 is the inverse of a length. (The fact that omega*mu is an impedance per unit length can be easily seen considering that omega*L is an impedance, where L is an inductance, and that mu is an inductance per unit length).

In the following screenshot we see that what I put in the code (= EMTP theory book formulation), i.e. ,a0=4*pi*sqrt(5)*1e-4*sqrt(f/rho) is equivalent to a0=sqrt(w*sigma*mu):

Ok, now it is making a bit more sense - I did consider that it was related to mu_0, but couldn't get it to work since I missed the other 2*pi. Note that since 2019 mu_0 isn't exactly 4*pi*1e-7.

[ceraolo]

Ok, now it is making a bit more sense - I did consider that it was related to mu_0, but couldn't get it to work since I missed the other 2*pi. Note that since 2019 mu_0 isn't exactly 4*pi*1e-7.

Yes, I learned this recently. The difference is however, very, very low: the ratio in MSL is 1.00000000055. But the principle is important: now that value is just a constant, which cannot be given by a mathematical expression.

So, last night's change has also the advantage of incorporating this. Thank you for prompting me for this change. In a comment, however, I left the old formula as well, just for people which knows that one, from their past studies.

[tobolar]

@ceraolo Yet another problem to be solved. For both examples (Examples.Lines.CompareCmatrix and Examples.Lines.PowerLineWithFence), Dymola reports missing initial conditions. It concerns initialization of a voltage drop between the pins of (nested) capacitors (e.g. c10.v or MTL_C.v). There is already a default start value set (v(start=0)) in capacitors but when used in examples, this shall be fixed (provided there is no other realization) additionally.

Please fix this and check simulation results if they are still fine.

[ceraolo]

@ceraolo Yet another problem to be solved. For both examples (Examples.Lines.CompareCmatrix and Examples.Lines.PowerLineWithFence), Dymola reports missing initial conditions. It concerns initialization of a voltage drop between the pins of (nested) capacitors (e.g. c10.v or MTL_C.v). There is already a default start value set (v(start=0)) in capacitors but when used in examples, this shall be fixed (provided there is no other realization) additionally.

Please fix this and check simulation results if they are still fine.

Regarding PowerLineWithFence: Model M_OLine does not provide in the input mask controls for setting initial conditions for internal inductances and capacitances. One would manually set all the internal values to zero, obviously, but this is a long and tedious process, and becomes totally unpractical for large numbers of segments. That's why I decided to accept the zero-valued defaults. As I mentioned in other comments I plan to create a new M_Oline, since the current one has limitations, so it is not good, for me, fix M_OLine for having a proper way to set initial coniditions from the mask.

Regarding CompareCmatrix I fixed as you suggested.

[tobolar]

Model M_OLine does not provide in the input mask controls for setting initial conditions for internal inductances and capacitances. One would manually set all the internal values to zero, obviously, but this is a long and tedious process, and becomes totally unpractical for large numbers of segments.

This PR is a good oppotrunity to modify M_OLine when such an input is useful. If not, simply add the initialization in the example manually. It is important that all examples initialize in an unambiguous way to assure comparable results acros various tools.

[ceraolo]

This PR is a good oppotrunity to modify M_OLine when such an input is useful. If not, simply add the initialization in the example manually. It is important that all examples initialize in an unambiguous way to assure comparable results acros various tools.

I solved this by changing row Modelica.Electrical.Analog.Basic.Capacitor C[dim_vector_lgc](C=Cl)); into Modelica.Electrical.Analog.Basic.Capacitor C[dim_vector_lgc](C=Cl, each v(fixed=true)); I chose this minimal change, to focus on the main objectives of this PR.

[tobolar]

I solved this by changing row Modelica.Electrical.Analog.Basic.Capacitor C[dim_vector_lgc](C=Cl)); into Modelica.Electrical.Analog.Basic.Capacitor C[dim_vector_lgc](C=Cl, each v(fixed=true)); I chose this minimal change, to focus on the main objectives of this PR.

This solution has a disadvantage that it could brake user's models which use M_OLine and already are clearly initialized. Imagine a user set another variable a fixed start value. Then the default M_OLine.C.v(fixed=true) would lead to too much initial conditions and the user would be forced to resolve this. Possibly in several models/examples which would be annoying.

[ceraolo]

This solution has a disadvantage that it could brake user's models which use M_OLine and already are clearly initialized

After years of tampering with lines models in MSL I got convinced that M_OLine is either not used or used very basically, and therefore the case you mention should not occur. But yes, if we must not create any possible cause of non-backwards compatibility, even if very unlikely, that change is unacceptable.

I could not find any other way to initialise to zero that voltage from the outside, i.e. without putting my hands inside M_OLine. Do you have a way? If not, I think it is better to revert my change and leave the warning in PowerLineWithFence.

Consider that M_OLine has significant weaknesses, and after this PR is merged (if ever will be) I plan to propose to make it obsolete and introduce an enhanced version of it (possibly two, one which is based on lumped components, another which reproduces also travelling waves), which overcomes the majority of its weaknesses.

[MartinOtter]

This solution has a disadvantage that it could brake user's models which use M_OLine and already are clearly initialized

After years of tampering with lines models in MSL I got convinced that M_OLine is either not used or used very basically, and therefore the case you mention should not occur. But yes, if we must not create any possible cause of non-backwards compatibility, even if very unlikely, that change is unacceptable.

I could not find any other way to initialise to zero that voltage from the outside, i.e. without putting my hands inside M_OLine. Do you have a way? If not, I think it is better to revert my change and leave the warning in PowerLineWithFence.

Consider that M_OLine has significant weaknesses, and after this PR is merged (if ever will be) I plan to propose to make it obsolete and introduce an enhanced version of it (possibly two, one which is based on lumped components, another which reproduces also travelling waves), which overcomes the majority of its weaknesses

As you proposed, introduce a new element with a new name. I do not know anything about M_OLine, so I cannot judge. I would mark this component as "obsolete" only, if other people with know-how about this component agree. Otherwise, I would just keep it as it is and maybe add a comment in M_OLine that it is recommended to use the new component and list reasons for it.

Note, it is planned to have a feature freeze on July 14, and then start the process for a new MSL version. In case you would like to have your new component in the next MSL version, try to make a pull request soon (or give some indication, when you think you could provide the component).

[ceraolo]

Note, it is planned to have a feature freeze on July 14, and then start the process for a new MSL version. In case you would like to have your new component in the next MSL version, try to make a pull request soon (or give some indication, when you think you could provide the component).

Let me explain. I started this PR on 2021, when I found that the "lines" part of MSL was not adequate for Power Engineering, and supplied examples for the existing line models. These examples have been incorporated in the examples.lines folder (which I proposed to create as subfolder of Electrical.Analog.Examples, and was approved).

With this PR, originally, I just wanted to supply an example also for M_OLine, and therefore created the PowerLineWithFence model, which is validated against a consolidated and very valuable source for Power Engineers (EMTP Theory Book).

Unfortunately this PR remained stuck for years (I don't know why), and only in recent weeks got awakened again, even though the process of it revision remained very slow, because the reviewers (this is not a criticisms) decided to object to any tiny details of code, even those subject to personal opinions, and for this implied long discussions. As regards myself, I tried to answer always reviewers' comments within one working day.

Over these two years, the PR has evolved: from having just the purpose of supplying an example for M_OLine, it has become a way to give users the two functions lineZmatrix() and lineCmatrix(), that can be useful for any interested power engineer which is also a Modelica user, independently of the example PowerLineWithFence. Because of their importance, I also added example models for these two functions (now, since several days ago, discussion is ongoing on where these examples must appear on MSL)

These two functions, therefore, are more general than just being functional to the M_OLine example. In addition to be useful per se, they also form the basis for other power line-related models:

• a model similar to M_OLine, but able to model also the resistivity of soil. This is not allowed by the current version of M_OLine. When this model is built, I intend to eliminate the internal ground (that I consider wrong, and I can explain why, if I'm given enough space for this). I intend also to improve the way internal state variables are initialised (currently initialization is tricky, if ever possible).
• another model, able to consider also travelling waves for multi-conductor lines. Currently TLine is present in MSL that allows modelling travelling waves, but works only for single-line lines (so the new model could become MTLine). Obviously, this new model will be complemented with a significant example.

Given this scenario, expecially the extreme slowness of the acceptance of this PR (not yet concluded), I think is unrealistic to think now, July 12, of a new PR in preparation of feature-freese of the July 14.

I'm, instead, worred about this very PR #4160: can we include this PR in the next MSL version? Based on the acceptance of this PR, I will start working on the next models. I could propose them in scientific papers, waiting for the next opportunity to include them in MSL.

To summarise:

• I really would like to see this PR merged in the next MSL version, not just for the PowerLineWithFence example, but also for the two functions lineZMatrix and LineCmatrix, which are useful per se
• after this PR is merged I'll work on an improved version of M_OLine, (making the current one obsolete), and, if I have enough time, on a new model (and example) able to model travelling waves on multi-conductor lines (Simulink/Simscape has such a model already).

Thanks.

[ceraolo]

For M_OLine iniitial conditions in PowerLineWith Fence there are the following options:

1. leave M_OLine as it is and accept a warning on initial conditions, that should not harm (even if this is not totally guaranteed for all tools), since the initial states are all assumed to be zero
2. use the technique I proposed in https://github.com/modelica/ModelicaStandardLibrary/pull/4160#issuecomment-1623506044, that eliminates the warning and should not harm as well (even if this is not totally guaranteed for all existing models using M_OLine, as you mentioned in your comment https://github.com/modelica/ModelicaStandardLibrary/pull/4160#issuecomment-1630370684)
3. use another solution that avoids the warning without touching M_OLine (but I could not find one; proposals are welcome)

Personally I'm in favour of option 1, that does not change the behaviour of any existing model. The probability that PowerLineWithFence gives different results on different tools is very, very small, since, AFAIK, most tools start using zero for all state variables and this is acceptable for this model.

@tobolar what's your opinion?

Consider that we have also to be conclusive with this ticket: MSL evolves rapidly and we risk to become stuck. Conclusion 1 does not have any impact on existing user models, just has a very, very low probability that it does not give the expected solution with some tool. But it is an example, not a model that users will incorporate in their own models, so even this possibility will not produce significant harm.

[tobolar]

@tobolar what's your opinion?

My personal opinion:

1. Shall be omitted due to regression issues. Optionally, the following could work for that particular example (being of the less implementation effort):

   initial equation
     line.s[1].C[1].v=0;
     line.s[1].C[5].v=0;
     line.s[1].C[8].v=0;
     line.s[1].C[10].v=0;
     line.s_first.C[1].v=0;
     line.s_first.C[5].v=0;
     line.s_first.C[8].v=0;
     line.s_first.C[10].v=0;
   

2. This could be possible but generates redundant initial conditions. It could (even if unlikely) also break initialization of user's models. So I would omit this.

3. Dymola suggests the following initialization:

   line.s[1].C[1].v(start = 0)
   line.s[1].C[5].v(start = 0)
   line.s[1].C[8].v(start = 0)
   line.s[1].C[10].v(start = 0)
   line.s_first.C[1].v(start = 0)
   line.s_first.C[5].v(start = 0)
   line.s_first.C[8].v(start = 0)
   line.s_first.C[10].v(start = 0)
   

   So there is obviously a logic behind which could be used to initialize only concerned variables in M_Oline. This could be even done conditionally depending on something like

   parameter Boolean initializeSegmentVoltage = false;
   

But again, there are more colleagues here having far more experience regarding both Modelica and electrical systems. I hope they could contribute es well.

[ceraolo]

Unfortunately, I could not make your suggestion work.

Therefore I reverted previous change on M_OLine, so now it is the same as has been for years, and no regression can occur. The PowerLineExample looks good enough even though it produces a warning.

@tobolar, I've received today at 12.34 a mail stating that you've approved this pull request. Can you, please tell me if there is something that I must still do to have this PR merged, or do I have just to wait?

Thank you in advance.

[tobolar]

I've received today at 12.34 a mail stating that you've approved this pull request.

I retrieved my approval since I'm convinced the library officers have to review.

[ceraolo]

I've received today at 12.34 a mail stating that you've approved this pull request.

I retrieved my approval since I'm convinced the library officers have to review.

sure. Can you, please let me know what is now mandatory for you to approve it? I'm a bit confused so far.

[tobolar]

Can you, please let me know what is now mandatory for you to approve it?

I have reviewed to my best regarding coding style, documentation, library structure. But not an expert in this field of application. I understand you did your best and wish to merge this as soon as possible, but this PR concerns a particular technical topic and so - similarly to many other PRs - the library officers shall approve.

[christiankral]

I would like to make a rather controversial comment here. I do remember that @dietmarw argued quite often that we cause a lot of additional difficulties and troubles when we add very sophisticated models and examples to the MSL.

1. Sophisticated models and examples may be beyond the understanding of most users.
2. Who will be able to maintain and review the added models and examples? Do we have sufficient ressources for that?

Pro: I understand the intention to imporve the line models and examples. I also appreciate the work that @ceraolo put into his proposal.

Yet there are some cons related to review and maintenance:

• If I had to serve as reviewer for the proposed changes it would take me hours, if I don't look to close into the proposed code.
• And it would take me days if I carefully investigage the entire code (so far we have 71 commits and 44 file changes).

If we add a Functions package and a new model, we also have to maintain it. In this case we have to make sure that we do not introduce unit or euqation flaws.

I thus recommend two alternative implentation scenarios:

1. Move the new functions, models and examples to an external open source library. In this case you, @ceraolo, are free to apply whatever changes you want at any time. This adds a lot of freedom to possible changes and improvements in applications and simulaton examples.
2. Move the Functions package and the new model to the Examples package. In this case we are not caught in any compatiblity issues. The additionally added models and examples may then be changed in a non-backwards compatible way at any time if it turns out that a flaw was introduced. Yet, we keep the review and mainenance effort high, which I consider to be a drawback.

So my personal opinion here is to go for option 1. It is easy to implement and to maintain and it can be developed step by step.

[ceraolo]

@christiankral, Received.

My work started with the intention to supply an example for M_OLine model.

A second target, for me, was to create some background activity to make MSL more useful for Power Engineers. I remember that, around 10 years ago, I got to know MSL, and found it very useful, sound, and rich of models. Only, my colleagues and I, noted that the part related to power lines was a bit clumsy.

In my opinion, power lines are a component of the power system just as machines and converters are; so, I tried to contribute to this. Now I realise very well that, while power converters and machines are in the library, sometimes more than once (for instance machines in Electrical.Machines and in Magnetic.FundamentalWave), lines are instead considered too complex or "sophisticated" to quote your words.

I worked a lot to select the "right" complexity for my PR to be inserted in MSL. As you can see, the two functions contain just a few lines, exactly because I did not want to introduce too complex models and code.

I must just add that this PR has 71 commits and 44 file changes just because I made very tiny modifications at a time, often back and forth in the effort to be compliant with @tobolar inputs. This prolonged the list of changes, made the code cleaner but did not increase (it reduced, instead) its complexity. In practice the PR contains just two functions. The rest are examples (two models to test the functions, and a model to test M_OLine.).

To summarise:

• the PR contains just two general purpose tiny functions an three examples
• because of this it is totally inadequate to be the content of an independent library
• these functions will just make more useful the already existing M_OLine MSL model, possibly modestly modified by another PR by muself to overcome a couple of its weakness
• because of the fact that this PR contains just to tiny functions, it should not be subject to maintenance. Just in case, I'll ve happy to contribute to this.

[coderabbitai[bot]]

Walkthrough

This update introduces several new models, functions, and records in the Modelica Electrical Analog library. New examples, such as those for capacitor matrix comparisons and overhead power lines with fences, have been added. A dedicated Functions package now provides support for capacitance and impedance calculations via new functions (lineCmatrix and lineZmatrix) and a LineGeometry record. Parameter types in existing models (e.g., M_OLine) have also been updated for clarity. Additionally, documentation files and package order lists have been revised and a signal comparison data file has been added.

Changes

File(s)	Change Summary
Modelica/Electrical/Analog/Examples/Lines/CompareCmatrix.mo	Added new models CompareCmatrix and MTL_Cmatrix to demonstrate capacitive coupling via Y-matrix formulations.
Modelica/Electrical/Analog/Examples/Lines/PowerLineWithFence.mo	Introduced an example model for an overhead power line with a fence, including circuit connections and initial computations.
Modelica/Electrical/Analog/Examples/Lines/package.order	Appended entries for CompareCmatrix and PowerLineWithFence.
Modelica/Resources/Reference/.../comparisonSignals.txt	Added a new file containing signal comparison data (time, r1n.i, r1.i).
Modelica/Electrical/Analog/Lines/Functions/*	New Functions package added, including: - LineGeometry.mo (record for line geometry parameters) - TestLineCmatrix.mo and TestLineZmatrix.mo (test models) - lineCmatrix.mo and lineZmatrix.mo (functions for matrix computations) - package.mo and package.order for Functions.
Modelica/Electrical/Analog/Lines/M_OLine.mo	Updated parameter types (e.g., using SI types for resistance, inductance, etc.) and adjusted capacitor annotations.
Modelica/Electrical/Analog/Lines/package.order (root)	Added a new entry for the Functions package.
Modelica/Electrical/Analog/UsersGuide/References.mo	Added new literature references and made minor textual corrections.

Sequence Diagram(s)

sequenceDiagram
    participant T as TestLineCmatrix
    participant F as lineCmatrix Function
    participant C as Computation Engine
    participant O as Output Printer

    T->>F: Call lineCmatrix(g, parameters)
    F->>C: Compute full & compact capacitance matrices
    C-->>F: Return computed matrices
    F-->>T: Deliver results
    T->>O: Print capacitance data

sequenceDiagram
    participant T as TestLineZmatrix
    participant F as lineZmatrix Function
    participant C as Computation Engine
    participant O as Output Printer

    T->>F: Call lineZmatrix(g, parameters)
    F->>C: Compute Rcomp, Xcomp, and Lcomp matrices
    C-->>F: Return computed values
    F-->>T: Deliver results
    T->>O: Print impedance data

Poem

Oh, what a hop this update brings,
New models and functions make my circuits sing.
Capacitor matrices and power lines in a dance,
Each parameter update gives a coder’s glance.
I, CodeRabbit, leap with glee and delight,
Nibbling through code under digital moonlight!
🐇✨

---

🪧 Tips

Chat

There are 3 ways to chat with CodeRabbit:

• Review comments: Directly reply to a review comment made by CodeRabbit. Example:
  • I pushed a fix in commit <commit_id>, please review it.
  • Generate unit testing code for this file.
  • Open a follow-up GitHub issue for this discussion.
• Files and specific lines of code (under the "Files changed" tab): Tag @coderabbitai in a new review comment at the desired location with your query. Examples:
  • @coderabbitai generate unit testing code for this file.
  • @coderabbitai modularize this function.
• PR comments: Tag @coderabbitai in a new PR comment to ask questions about the PR branch. For the best results, please provide a very specific query, as very limited context is provided in this mode. Examples:
  • @coderabbitai gather interesting stats about this repository and render them as a table. Additionally, render a pie chart showing the language distribution in the codebase.
  • @coderabbitai read src/utils.ts and generate unit testing code.
  • @coderabbitai read the files in the src/scheduler package and generate a class diagram using mermaid and a README in the markdown format.
  • @coderabbitai help me debug CodeRabbit configuration file.

Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments.

CodeRabbit Commands (Invoked using PR comments)

• @coderabbitai pause to pause the reviews on a PR.
• @coderabbitai resume to resume the paused reviews.
• @coderabbitai review to trigger an incremental review. This is useful when automatic reviews are disabled for the repository.
• @coderabbitai full review to do a full review from scratch and review all the files again.
• @coderabbitai summary to regenerate the summary of the PR.
• @coderabbitai generate docstrings to generate docstrings for this PR.
• @coderabbitai resolve resolve all the CodeRabbit review comments.
• @coderabbitai plan to trigger planning for file edits and PR creation.
• @coderabbitai configuration to show the current CodeRabbit configuration for the repository.
• @coderabbitai help to get help.

Other keywords and placeholders

• Add @coderabbitai ignore anywhere in the PR description to prevent this PR from being reviewed.
• Add @coderabbitai summary to generate the high-level summary at a specific location in the PR description.
• Add @coderabbitai anywhere in the PR title to generate the title automatically.

CodeRabbit Configuration File (.coderabbit.yaml)

• You can programmatically configure CodeRabbit by adding a .coderabbit.yaml file to the root of your repository.
• Please see the configuration documentation for more information.
• If your editor has YAML language server enabled, you can add the path at the top of this file to enable auto-completion and validation: # yaml-language-server: $schema=https://coderabbit.ai/integrations/schema.v2.json

Documentation and Community

• Visit our Documentation for detailed information on how to use CodeRabbit.
• Join our Discord Community to get help, request features, and share feedback.
• Follow us on X/Twitter for updates and announcements.