Hi you all,
I was wondering if it is possible to make the command Linecode to leave untouched as introduced the impedance matrices.
For some reasons I want to keep each wire of the line with its own and different from others' impedance, but once I execute Linecode, the matrix is changed into another one which diagonal values are all the same, and similarly with non-diagonal elements (so at the end all wires will behave the same). You may say that I can achieve this if consider n lines of one-phase each instead of one single line of n-phases, but in that situation I would lose the mutual impedance elements.
So, is there any way to avoid this behaviour of the command?
Thanks in advance!
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
When I see that the values do not match, what it comes to my mind is that DSS is not using neither Rmatrix nor Xmatrix as I wrote them down, but as they appear later in the saved documents. So, my question is, how can I avoid this kind of behaviour within the Linecode command.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
As far as I know (I am user like you hence I am not an expert) there is not "command Linecode" that generates a linecode file. If I am wrong please post it such command.
However, exists something in OpenDSS that (among a lot of other things) produces what you see. It is a command that creates the positive sequence version of the circuit and, once you save such circuit, it produces the positive sequence version of the whole circuit (including linecode). The command is:
MakePosSeq
Save Circuit Dir=MyNewCircuitName
If you are using this command (as it looks like to me) I do believe it is normal opendss is providing you a changed linecode whose number are originated based on the definition of positve sequence and your initial data. If you want to know more on such sequences you can check any power system books (kersting is a good one) and also a recent technote published few weeks ago in cable modelling in which at the end this concept of sequence is briefly discussed.
Regards
Andrea
Post scriptum after Davis replay (below):
Yes, it is possible to create a linecode file (and others) only using the "save" command alone (i.e., without MakePosSeq) as detailed in the Opendss help (under Executive field). This might be useful to let OpenDSS organize the code (in case your original one was kind of messy) and also see what Opendss is actually considering as properties of the circuit I guess. This, in turn, as Fernando did, can be used as a kind of debugging material (as he spotted that the linecode was different from what he gave by COM).
"Save Circuit" saves the present enabled circuit elements to the specified subdirectory in standard DSS form with a Master.txt file and separate files for each class of data.
Last edit: Bandrea87 2016-03-30
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I got it. The problem is that you are sending the commands separately. One of the inconvenients of defining Linecodes using the COM interface is that if you send the entire string at once the COM interface could reject it because of its size on the buffer. I guess what you tried to do was to send each line separately one after the other, which is basically an error, The system is not going to accept your command. To confirm this, try the following: Send the following command using the COM interface and then save your circuit.
A confusing problem. I'm glad to see everyone giving an effort.
The actual syntax Fernando used is OK. The problem is this statement:
more C1=1.75225968562
This tell OpenDSS that the LineCode is being defined as symmetrical components rather than Rmatrix and Xmatrix. If the last thing you define is any of R1, X1, R0, X0, C1, C0, B1, B0, the program assumes you are using symmetrical components to define the line impedance. So it creates 8x8 R, X, and C matrices according to the rules for symmetrical components using the values for R1, etc., that is has on file -- in this case the default values.
You can see this using the command
FormEdit Linecode.catenaria
Define the linecode without setting the C1 property and look at the result in the Formedit. Then add the definition of the C1 property and again look at the FormEdit result.
Instead of defining C1, Fernando should have defined Cmatrix=[...]
Don't mix symmetrical component and matrix definitions.
From the help on the R1 property:
Positive-sequence Resistance, ohms per unit length. Setting any of R1, R0, X1, X0, C1, C0 forces the program to use the symmetrical component line definition. See also Rmatrix.
From the help on the Rmatrix property
Resistance matrix, lower triangle, ohms per unit length. Order of the matrix is the number of phases. May be used to specify the impedance of any line configuration. Using any of Rmatrix, Xmatrix, Cmatrix forces program to use the matrix values for line impedance definition. For balanced line models, you may use the standard symmetrical component data definition instead.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I just noticed that the Help on the R1 property in LineCode is not as complete as on the R1 property on the Line object. I'll update the Linecode help for the next release
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
In case you are interested, here is the actual code for creating the Z and Yc matrices from symmetrical component values in the LineCode.Pas module. Remember all circuit element impedances are converted into matrices before being used (in constructing the Yprim matrices) in OpenDSS. This routine got executed after the C1= statement was executed in Fernando's initial script.
Thanks everyone for helping, for real, DSS community is great!
The reason why I employed the two different ways is because some of the considered lines are in fact rails laying on the ground, so the P matrix has zero-elements hence the C has "inf" ones. As far as it doesn't happen with R and X, I can employ the matrix definition with them, but with C there's no other alternative from employing the direct sequence parameter.
As soon as I can I'll apply those changes and share the results!
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Thanks everyone for helping, for real, DSS community is great!
The reason why I employed the two different ways is because some of the considered lines are in fact rails laying on the ground, so the P matrix has zero-elements hence the C has "inf" ones. As far as it doesn't happen with R and X, I can employ the matrix definition with them, but with C there's no other alternative from employing the direct sequence parameter.
As soon as I can I'll apply those changes and share the results!
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
If you have the rails are physically grounded, the value you use for capacitance of the rail to ground probably doesn't make much difference. You should compute the capacitance between all the conductors. I would be tempted to assume the rails are a few inches above ground and let a standard line constants program estimate the C matrix.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi you all,
I was wondering if it is possible to make the command Linecode to leave untouched as introduced the impedance matrices.
For some reasons I want to keep each wire of the line with its own and different from others' impedance, but once I execute Linecode, the matrix is changed into another one which diagonal values are all the same, and similarly with non-diagonal elements (so at the end all wires will behave the same). You may say that I can achieve this if consider n lines of one-phase each instead of one single line of n-phases, but in that situation I would lose the mutual impedance elements.
So, is there any way to avoid this behaviour of the command?
Thanks in advance!
I don't understand. Please provide an example of the script where you are seeing this behavior.
Excuse me, Mr. Dugan, if I did not explain myself properly.
I write down this command within the script, using DSS as COM:
But when I save the circuit and have a look to the Linecode generated file, I find this instead:
When I see that the values do not match, what it comes to my mind is that DSS is not using neither Rmatrix nor Xmatrix as I wrote them down, but as they appear later in the saved documents. So, my question is, how can I avoid this kind of behaviour within the Linecode command.
Nothing?
Hi Fernando
As far as I know (I am user like you hence I am not an expert) there is not "command Linecode" that generates a linecode file. If I am wrong please post it such command.
However, exists something in OpenDSS that (among a lot of other things) produces what you see. It is a command that creates the positive sequence version of the circuit and, once you save such circuit, it produces the positive sequence version of the whole circuit (including linecode). The command is:
If you are using this command (as it looks like to me) I do believe it is normal opendss is providing you a changed linecode whose number are originated based on the definition of positve sequence and your initial data. If you want to know more on such sequences you can check any power system books (kersting is a good one) and also a recent technote published few weeks ago in cable modelling in which at the end this concept of sequence is briefly discussed.
Regards
Andrea
Post scriptum after Davis replay (below):
Yes, it is possible to create a linecode file (and others) only using the "save" command alone (i.e., without MakePosSeq) as detailed in the Opendss help (under Executive field). This might be useful to let OpenDSS organize the code (in case your original one was kind of messy) and also see what Opendss is actually considering as properties of the circuit I guess. This, in turn, as Fernando did, can be used as a kind of debugging material (as he spotted that the linecode was different from what he gave by COM).
Last edit: Bandrea87 2016-03-30
Hi Fernando,
I got it. The problem is that you are sending the commands separately. One of the inconvenients of defining Linecodes using the COM interface is that if you send the entire string at once the COM interface could reject it because of its size on the buffer. I guess what you tried to do was to send each line separately one after the other, which is basically an error, The system is not going to accept your command. To confirm this, try the following: Send the following command using the COM interface and then save your circuit.
New Linecode.Catenaria nphases=8 Rmatrix=[0.125228296369|0.0444225909912 0.241323539656|0.0447750468664 0.0445997973392 0.376491560811|0.0468828669958 0.0466761330875 0.0470581393757 0.0711234012812|0.0445714306186 0.04436040156 0.0446666015581 0.0468371788287 0.125228296369|0.04436040156 0.0441459057458 0.0444383635793 0.046608094565 0.0444225909912 0.241323539656|0.0446666015581 0.0444383635793 0.044709049062 0.0469395508745 0.0447750468664 0.0445997973392 0.376491560811|0.0468371788287 0.046608094565 0.0469395508745 0.0492950816834 0.0468828669958 0.0466761330875 0.0470581393757 0.0711234012812]
You will see that the script will be generated correctly. So, considering the constrains we have using COM I will suggest the following algorithm:
This way you will avoid the problems related with buffer size when using COM.
Andrea: yes you can define all elements using the text interface as if you were writing a script (with some limitations as the one we dicussed here)
Best regards
Davis
Last edit: Davis Montenegro 2016-03-30
Quite interesting. Thanks for sharing
A confusing problem. I'm glad to see everyone giving an effort.
The actual syntax Fernando used is OK. The problem is this statement:
This tell OpenDSS that the LineCode is being defined as symmetrical components rather than Rmatrix and Xmatrix. If the last thing you define is any of R1, X1, R0, X0, C1, C0, B1, B0, the program assumes you are using symmetrical components to define the line impedance. So it creates 8x8 R, X, and C matrices according to the rules for symmetrical components using the values for R1, etc., that is has on file -- in this case the default values.
You can see this using the command
Define the linecode without setting the C1 property and look at the result in the Formedit. Then add the definition of the C1 property and again look at the FormEdit result.
Instead of defining C1, Fernando should have defined Cmatrix=[...]
Don't mix symmetrical component and matrix definitions.
From the help on the R1 property:
From the help on the Rmatrix property
Resistance matrix, lower triangle, ohms per unit length. Order of the matrix is the number of phases. May be used to specify the impedance of any line configuration. Using any of Rmatrix, Xmatrix, Cmatrix forces program to use the matrix values for line impedance definition. For balanced line models, you may use the standard symmetrical component data definition instead.I just noticed that the Help on the R1 property in LineCode is not as complete as on the R1 property on the Line object. I'll update the Linecode help for the next release
In case you are interested, here is the actual code for creating the Z and Yc matrices from symmetrical component values in the LineCode.Pas module. Remember all circuit element impedances are converted into matrices before being used (in constructing the Yprim matrices) in OpenDSS. This routine got executed after the C1= statement was executed in Fernando's initial script.
Thanks everyone for helping, for real, DSS community is great!
The reason why I employed the two different ways is because some of the considered lines are in fact rails laying on the ground, so the P matrix has zero-elements hence the C has "inf" ones. As far as it doesn't happen with R and X, I can employ the matrix definition with them, but with C there's no other alternative from employing the direct sequence parameter.
As soon as I can I'll apply those changes and share the results!
Thanks everyone for helping, for real, DSS community is great!
The reason why I employed the two different ways is because some of the considered lines are in fact rails laying on the ground, so the P matrix has zero-elements hence the C has "inf" ones. As far as it doesn't happen with R and X, I can employ the matrix definition with them, but with C there's no other alternative from employing the direct sequence parameter.
As soon as I can I'll apply those changes and share the results!
If you have the rails are physically grounded, the value you use for capacitance of the rail to ground probably doesn't make much difference. You should compute the capacitance between all the conductors. I would be tempted to assume the rails are a few inches above ground and let a standard line constants program estimate the C matrix.