modelica
M_OLine example
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 example is interesting, although has a major limitation due to a M_OLine limitation: it does not accept resistance in the off-diagonal elements of Z matrix.
However, the function LineZMatrix is able to compute all the elements of the Z matrix correctly (according to Carson's theory and only for a given frequency), so that it can be reused in case a new multi-conductor line component, removing the mentioned M_OLine limitation, is created, possibly in the Electrical-Polyphase or QuasiStatic-Polyphase sub-library.
Maybe I can propose such a component in the near future, if it is deemed useful. It would be rather straightforward for me, but using a different approach than M_OLine.
Important note There is a lot of theory and study of reference literature on the roots of LineCmatrix and especially LineZmatrix. If library officials want to discuss the roots of them in a ticket (Issues or Discussions), I can obviously open one and discuss every step I made to get to them.
Frankly, I don't understand what's wrong with the second check. Can someone help?
There a lots of HTML mistakes. You can see them when you click on the "Details" link and then on the red marked TidyHTML report. It tells you which line it for example found an unexpected <p> or something else that is missing.
There a lots of HTML mistakes. You can see them when you click on the "Details" link and then on the red marked TidyHTML report. It tells you which line it for example found an unexpected
<p>or something else that is missing.
Where do I find this "Details" link? I created comments using, either OpenModelica or Dymola (I don't remember which). One of them must have betrayed me...
@max-privato Have a look at the section "Some checks were not successful". Right from "CI / html_documentation_checks" you'll find "Details". I'm afraid you'll have to tidy the HTML manually ... Just a warning: It's dangerous to copy and paste code from text view to the documentation. Lots of unneccessary HTML is inserted.
Thank you @AHaumer for all your hints. I 've worked on the html and fixed all the errors due to my actions. Now there are remaining warnings regarding the <i> tag that apply to the file References.mo. For my row I closely followed the existing references pattern, and the checker complains also with the <i> that existed there before my addition.
Do you have any idea why this happens, and how to fix this?
<i> (and <b>) should no longer be used according to the HTML standard and one should use <em> (and <strong>) instead. That's what tidy is still complaining about.
<i>(and<b>) should no longer be used according to the HTML standard and one should use<em>(and<strong>) instead. That's what tidy is still complaining about.
Aha!
It is noticeable that I did find them already in References.mo (and probably continuing to use <i> instead of \em> would not harm in modelica context) I suppose that this file was last checked when <i> was still considered correct.
I consulted: https://stackoverflow.com/questions/21334380/what-is-the-benefit-of-em-vs-i and read: It's about semantics. Using <strong> or <em> means that the contents of the tag have more emphasis than the nearby copy. Bolding or italicizing stuff is just formatting. And formatting belongs in css, not html.
So, clear enough: for modelica embended html, as you say, we must use <em> instead of <i>, and <strong> instead of <b>. I understand that it is more a question of avoiding tidy to complain than actual code weakness.
I'll obey and change <i> with <em>, see if the appearance remains the same, and what tidy says about it.
This PR seems to be stale now. Should I do something to re-activate it?
I wonder what has happened on this PR. Why it is blocked?
This PR needs a review of 2 reviewers. Since MSL is a work of volunteers, this can take some time...
Can someone finalize this ticket? I worked a lot on it, and would be glad if it is evaluated, and possibly accepted. I think this adds a good example of M_Oline, as well as utility functions that create multiple conductor matrices, and can be used by users for other purposes.
In case something is unclear, please don't hesitate to ask, Thanks all.
@AHaumer and @christophclauss would you please review fix for this ticket? Please also let us know if additional info or summary would help you expedite the review.
@AHaumer , @kristinmajetta, @christophclauss would you please look into the fix for the ticket?
@kristinmajetta and @christophclauss haven't been online / active for quite a long time, I suppose you won't get a review. We have to look for other reviewers, one isn't enough (and I don't have too much time ...)
...but I am still alive. I started looking into the example but need some days.
...but I am still alive. I started looking into the example but need some days.
Glad to read from you, @christophclauss
I'm going to approve the PR. First I checked the new/changed files visually. Second I tested the example PowerLineWithFence using OpenModelica.
Question: Some of the line.c values are negative (line.c[2], and others). Violating constraints messages arise like this: Variable violating min constraint: 0.0 <= line.s_first.C[7].C, has value: -1.37911e-08 Can it be avoided? Or should we ignore these messages? I fear in a Standard Library example such messages could cause irritations.
Simulation with N=5 (5 lumped segments) the linear solver fails and falls back to a solver with total pivoting. It shows that the example is numerically critical. There could be a connection to negative capacitances. This should be investigates.
Question: Some of the line.c values are negative (line.c[2], and others)
AHA, thanks for reporting.
Here there is a mismatch on the meaning of C. In my code I created the C matrix, as in line theory, which has off-diagonal negative numbers (see for instance page 3-12 of EMTP Theory book available from https://www.academia.edu/38437649/EMTP_Theory_Book). This C matrix is used in the matrix equation I=YV, where I is the vector of transverse currents, V the vector of voltages between conductors and the reference, Y=jwC (w is the angular frequency, C is the matrix of capacitances)
The C vector to be used in M_Oline, instead, contains values corresponding to equivalent capacitors connecting lines, which must obviously be positive.
I've to make a change in the software to fix this, and update this PR. The change per see is simple, but I want to check all the examples, and the info, to make everything consistent with the change. I'll update the link to EMTP rule book, since the one I enclosed two years ago is not working anymore.
I'll try to do this soon.
I've spent some time in trying do amend my PR,. The issue with capacitances is simultaneously nasty and interesting.
The correspondence between the elements of C matrix (to be used as Y=jwC ), and the capacitances of physical capacitors across conductors and between concuctors and reference (in power lines usually the soil) is clear enough: che off diagonal elements of the C matrix, changed in sign, give the capacitors between conductors, while the capacitors towards ground are obtained summing all elements of the corresponding row of the C matrix.
This is written in page 3-11 of EMTP Theory book (https://www.academia.edu/38437649/EMTP_Theory_Book), and appears correct, since it corresponds to formulas used in the classical Power Systems theory.
I made the necessary changes, and created a tiny package which should confirm the correctness of formulas and implementation: TestCmatrix.mo.txt
Running CompareCmatrix3, one should find exactly the same current flowing in r1 and 4. Unfortunately these currents insofar are different:
For the time being I cannot understand why the they are not equal. I'll continue to investigate. Any suggestion is welcome.
Update over https://github.com/modelica/ModelicaStandardLibrary/pull/3846#issuecomment-1580258634
I found a trivial mistake. Now the correspondence between C-matrix approach and the use of physical capacitors between lines, is confirmed by theory and modelica models. I'm therefore able now to prepare (and soon submit) a revision of the PR that does important things:
- fixes the "negative capacitance" issue discussed in https://github.com/modelica/ModelicaStandardLibrary/pull/3846#issuecomment-1531174279
- contains software to make che conversion between C matrix and physical capacitors, that could be useful per se, not just for M_Oline, and to check compliance between the two approaches
- lays the ground for a possible future line component based on Z and C matrices, which is the approach used for lines in PowerSstems. That line component could be based on "cascaded-Pi" models or, better, a transient model such as the component "distributed parameter line" available in Matlab/Simscape.
So, I hope to update the PR within a couple of weeks!
Dear all, Yesterday, by mistake, I deleted the branch I'd created for this PR. Sorry for this.
However I have everything on my PC. I'm able to open a new PR, with the same content of the one deleted, including the fix mentioned in https://github.com/modelica/ModelicaStandardLibrary/pull/3846#issuecomment-1604274619. The new PR will be under my new Github name "ceraolo", since "max-privato" is being abandoned. As soon as I open it (I plan by tomorrow), I'll post here its number.
https://github.com/christophclauss, I created the new PR, which, among other things, takes into due consideration your comment https://github.com/modelica/ModelicaStandardLibrary/pull/3846#issuecomment-1531174279 I'm looking forward to hear any comments from you for this new PR. It follows an effort started two years ago, and I would like to have it finalised now! As you can see from the PR description, this new PR #4160 opens other possibilities for simulation of lines in Modelica. If (and when) PR 4160 is merged, I could try to find time to create multicondutor lines adequate for power system studies. What I miss with current MSL models is:
- the possibility to have Z-matrices with non-zero off diagonal resistances (needed to simulate ground return)
- the possibility to expand TLine behaviour to multiconductor lines, miming what already available in Matlab/Simscape (present also in the historical Power System Simulation program EMTP).
@ceraolo I believe you meant #4160 when you said new PR #4146,Would you please edit it?
@ceraolo I believe you meant #4160 when you said new PR #4146,Would you please edit it?
done, thank you.