I would like to ask how the creation of a new class affects the other objects and more precisely their operations inside the synchronization function. To be more specific if I want to create an object that calls its sync function too often for decision making purposes, the sync functions of all the other objects should be also called. If I want to delay the calculations that take place inside the sync function of some other objects untill the decision to be taken, is it possible to modify the returned timestamps of these sync functions (t2) or this will have cascading effects? Is there any other solution in that direction?
If for example I want to create a forecasting mechanism for congestion and if these mechanism needs more than one calls of its sync function in order to reach a conclusion, can I prevent a device object to ask for new demand while the sync functions of node objects for example still continue their execution in every cycle until the decision to be taken?
Thanks in advance.
Last edit: Rafik Fainti 2015-01-23
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I'm not sure I quite follow what you are trying to do, but maybe some explanations might help? Let me know if it doesn't and we can explore some more.
First, a couple definitions:
t0 is the time the simulation is coming from (i.e., the last synchronization).
t1 is the current time.
t2 is the future time (i.e., the next time the current object would require synchronization).
Every object returns a timestamp indicating what its t2 is - the time in which it has calculated that it will need to update its state and re-synchronize with the rest of the objects. This is done for each sync call (pre-sync, sync, and post-sync). The core gathers all of the t2 declarations from the objects, determines the minimum t2, then moves the simulation forward to the minimum t2 (which now becomes t1). At that point, all of the objects resynchronize.
If an object returns t2>t1, then it indicates that it is ready to move forward, assuming no values are changed by another object. Once all objects have a t2>t1, the simulator will move forward.
If an object returns t2==t1, it indicates that the object is not ready to move forward in time and forces a re-iteration. During the re-iteration, all sync functions are called again and all objects are resynchronized. So, effectively, you can "pause" the simulation in time by continuing to return t2==t1. The objects will continue to iterate through the sync functions until t2>t1 or you hit the iteration limit (100 by default, I believe - but it is adjustable).
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
What I am trying to do, is to create a congestion prediction mechanism distributed in every node in the sense that each node will collect an aggregated demand from a set of nodes (parent-child relationship) and checks whether this demand can be forwarded to the next node in the hierarchy (i.e the line connecting these two nodes can satisfy this demand). If the decision is that it can be done (i.e there is no congestion), the decision making process is forwarded to the next level until a generator is reached. Otherwise the devices should modify their demand. I think, please correct me if I am wrong, that this procedure (i.e the whole set of nodes to reach a verdict) will last more than one "sync cycles". In that direction I want the devices not to ask for new demand until this verdict is reached. A way to "pause their sync execution" for a little, if that term can be used, while the sync execution of other objects should continue unaffected in a sense that certain variables should change value - not the simulation time.
Thanks a lot
Last edit: Rafik Fainti 2015-01-26
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Should be relatively easy to do, but there will be some catches that have to do with the way GLD handles re-iterations.
If any object calls for a re-iteration (t2=t1) in any of the three sync functions, then all objects will re-iterate all of their sync functions. In some objects that we want to only calculate once per timestep (say, a control function of a regulator), we prevent this by using the timestep variables to determine that we are on the first iteration. Often seen as 'if t0<t1 then do this', as t0 is less than t1 on the first iteration, but equal to t1 on the second and later iterations. You can also use "valid_to", which basically says 'no matter who commands a re-iterate, I won't recalculate my state until valid_to', so that object gets ignored in the sync loop until that time.
That said, I think you are talking more about a sweep-like method, such as the forward-backsweep (FBS) method in powerflow used to calculate voltage and current. This relies on the ranking structure to make sure that calculations are performed "in order". The ranking structure forces the order of calculation of objects - pre-sync, it solves high to low rank objects, sync low to high, and post-sync high to low. So, in FBS we sweep up the system in sync to calculate currents, then down the system in post-sync to get voltages. If there is any dV too great, then that particular node commands a re-iteration, and we repeat the whole process.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hello,
I would like to ask how the creation of a new class affects the other objects and more precisely their operations inside the synchronization function. To be more specific if I want to create an object that calls its sync function too often for decision making purposes, the sync functions of all the other objects should be also called. If I want to delay the calculations that take place inside the sync function of some other objects untill the decision to be taken, is it possible to modify the returned timestamps of these sync functions (t2) or this will have cascading effects? Is there any other solution in that direction?
If for example I want to create a forecasting mechanism for congestion and if these mechanism needs more than one calls of its sync function in order to reach a conclusion, can I prevent a device object to ask for new demand while the sync functions of node objects for example still continue their execution in every cycle until the decision to be taken?
Thanks in advance.
Last edit: Rafik Fainti 2015-01-23
Rafik,
I'm not sure I quite follow what you are trying to do, but maybe some explanations might help? Let me know if it doesn't and we can explore some more.
First, a couple definitions:
t0 is the time the simulation is coming from (i.e., the last synchronization).
t1 is the current time.
t2 is the future time (i.e., the next time the current object would require synchronization).
Every object returns a timestamp indicating what its t2 is - the time in which it has calculated that it will need to update its state and re-synchronize with the rest of the objects. This is done for each sync call (pre-sync, sync, and post-sync). The core gathers all of the t2 declarations from the objects, determines the minimum t2, then moves the simulation forward to the minimum t2 (which now becomes t1). At that point, all of the objects resynchronize.
If an object returns t2>t1, then it indicates that it is ready to move forward, assuming no values are changed by another object. Once all objects have a t2>t1, the simulator will move forward.
If an object returns t2==t1, it indicates that the object is not ready to move forward in time and forces a re-iteration. During the re-iteration, all sync functions are called again and all objects are resynchronized. So, effectively, you can "pause" the simulation in time by continuing to return t2==t1. The objects will continue to iterate through the sync functions until t2>t1 or you hit the iteration limit (100 by default, I believe - but it is adjustable).
Mr Fuller,
What I am trying to do, is to create a congestion prediction mechanism distributed in every node in the sense that each node will collect an aggregated demand from a set of nodes (parent-child relationship) and checks whether this demand can be forwarded to the next node in the hierarchy (i.e the line connecting these two nodes can satisfy this demand). If the decision is that it can be done (i.e there is no congestion), the decision making process is forwarded to the next level until a generator is reached. Otherwise the devices should modify their demand. I think, please correct me if I am wrong, that this procedure (i.e the whole set of nodes to reach a verdict) will last more than one "sync cycles". In that direction I want the devices not to ask for new demand until this verdict is reached. A way to "pause their sync execution" for a little, if that term can be used, while the sync execution of other objects should continue unaffected in a sense that certain variables should change value - not the simulation time.
Thanks a lot
Last edit: Rafik Fainti 2015-01-26
Rafik,
Should be relatively easy to do, but there will be some catches that have to do with the way GLD handles re-iterations.
If any object calls for a re-iteration (t2=t1) in any of the three sync functions, then all objects will re-iterate all of their sync functions. In some objects that we want to only calculate once per timestep (say, a control function of a regulator), we prevent this by using the timestep variables to determine that we are on the first iteration. Often seen as 'if t0<t1 then do this', as t0 is less than t1 on the first iteration, but equal to t1 on the second and later iterations. You can also use "valid_to", which basically says 'no matter who commands a re-iterate, I won't recalculate my state until valid_to', so that object gets ignored in the sync loop until that time.
That said, I think you are talking more about a sweep-like method, such as the forward-backsweep (FBS) method in powerflow used to calculate voltage and current. This relies on the ranking structure to make sure that calculations are performed "in order". The ranking structure forces the order of calculation of objects - pre-sync, it solves high to low rank objects, sync low to high, and post-sync high to low. So, in FBS we sweep up the system in sync to calculate currents, then down the system in post-sync to get voltages. If there is any dV too great, then that particular node commands a re-iteration, and we repeat the whole process.
Thank you very much Mr Fuller. Your advice is very helpful.