I am trying to clarify to my self some issues related with the execution order of nodes. I am using the IEEE 13-bus test feeder as you can see below:
I have add a printf inside the presync and postsync function in order to print the name of the object that is executed each time and more precisely to clarify to my self the execution order of each node.
When the solver method used is the FBS, the execution order is as follows: network_node, node 650, 632, 671, 684, 645, 692, 652, 675, 611, 646, 633, 680, 634.
When the solver method used is the NR, the execution order is as follows: network_node, node 692, 671, 630, 633, 675, 652, 646, 680, 645, 650, 611, 684, 634
I would like to know if I can somehow force the execution order of nodes using the NR method to be the same as the execution order of nodes with the FBS method
Of course the general question is if there is a way to force the nodes to be executed in a strictly top-down order; imagine the feeder as a tree (the children should be executed after their father's execution)
Thanks in advance
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I would say that except for the most trivial systems the answer is no you cannot use the same update order for the two solvers. They are necessarily different because of how the solvers work.
It is possible to force the order of update using "rank" specifications in your objects but the solver you choose will alter your specs in order to make the system solvable. What you should end up with is something that is consistent with both your specification and the solver's needs, provided they are not mutually exclusive (e.g., you specify A before B and the solver wants B before A, although I confess not knowing what will happen if you try to force something that is not solvable.)
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The rank order, to a certain degree, is set by the topology of the system, otherwise the solvers won't work. For FBS, which requires a radial system, the rank is driven by "how far" (object-wise, not distance) it is from the swing node. There is some very minimal adjustment you can make there - you can raise the rank of a node and all the nodes and links above them.
For NR, there are no adjustments that can be made. There are only two ranks, the swing node and all the others - the swing node contains the solver, which requires that all other nodes solve ahead of it.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
First of all thank you for our previous conversation. Your advice was very helpful.
I would like to ask something more. How the NR solver decides the execution order of the nodes? Is there any specific criterion? Could you suggest me any reference for further information?
Sincerely
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
For the NR method, there are only two classes of nodes - the SWING node and everything else. So, the execution order only has those two choices. Since all of the non-swing nodes will be forced into the same rank, there is no way to pre-determine the execution order (execution order within a given rank is random).
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Dear all,
I am trying to clarify to my self some issues related with the execution order of nodes. I am using the IEEE 13-bus test feeder as you can see below:
I have add a printf inside the presync and postsync function in order to print the name of the object that is executed each time and more precisely to clarify to my self the execution order of each node.
When the solver method used is the FBS, the execution order is as follows: network_node, node 650, 632, 671, 684, 645, 692, 652, 675, 611, 646, 633, 680, 634.
When the solver method used is the NR, the execution order is as follows: network_node, node 692, 671, 630, 633, 675, 652, 646, 680, 645, 650, 611, 684, 634
I would like to know if I can somehow force the execution order of nodes using the NR method to be the same as the execution order of nodes with the FBS method
Of course the general question is if there is a way to force the nodes to be executed in a strictly top-down order; imagine the feeder as a tree (the children should be executed after their father's execution)
Thanks in advance
I would say that except for the most trivial systems the answer is no you cannot use the same update order for the two solvers. They are necessarily different because of how the solvers work.
It is possible to force the order of update using "rank" specifications in your objects but the solver you choose will alter your specs in order to make the system solvable. What you should end up with is something that is consistent with both your specification and the solver's needs, provided they are not mutually exclusive (e.g., you specify A before B and the solver wants B before A, although I confess not knowing what will happen if you try to force something that is not solvable.)
Rafik,
The rank order, to a certain degree, is set by the topology of the system, otherwise the solvers won't work. For FBS, which requires a radial system, the rank is driven by "how far" (object-wise, not distance) it is from the swing node. There is some very minimal adjustment you can make there - you can raise the rank of a node and all the nodes and links above them.
For NR, there are no adjustments that can be made. There are only two ranks, the swing node and all the others - the swing node contains the solver, which requires that all other nodes solve ahead of it.
Thank you very much.
Mr Chassin, Mr Fuller,
First of all thank you for our previous conversation. Your advice was very helpful.
I would like to ask something more. How the NR solver decides the execution order of the nodes? Is there any specific criterion? Could you suggest me any reference for further information?
Sincerely
Rafik,
For the NR method, there are only two classes of nodes - the SWING node and everything else. So, the execution order only has those two choices. Since all of the non-swing nodes will be forced into the same rank, there is no way to pre-determine the execution order (execution order within a given rank is random).