Daniel Russel wrote: > I am ending up with various score states which have to be updated in > the right order. Currently this requires that the user add them to the > model in the right order and non-obvious things happen if this is not > the case. I think adding an iteration counter to the update call > would make this simpler (and the change could be implemented without > changing individual score states much). > > Model maintains a counter which is incremented each time evaluate is > called. It then calls ScoreState::update(int) for each score state > passing the counter. This update is a method in the ScoreState base > class which simply compares the passed counter to the stored counter > and calls the existing update method if the counters are different. > ScoreStates which depend on other score states can simply call update > on their dependencies with the counter. Each ScoreState is updated > exactly once and, unless there are circular dependencies, everything > is updated before it is used. The same thing can be used for > after_evaluate, although there is currently no need. With slightly > more logic we could catch circular dependencies too.
I don't really follow what you're proposing. Which 'evaluate' method are you talking about? And what is the 'stored counter'? Are you proposing that ScoreStates contain a container of their own dependencies? Perhaps an example would be instructive.
Here is an example of a state which would benefit from ordering: Keren asked about GravityCenters which contain other GravityCenters, e.g. given particles P1 through P4, we could create two new particles P5 and P6 which are gravity centers of P1,P2 and P3,P4 respectively, i.e P5=G(P1,P2) and P6=G(P3,P4). The two GravityCenterScoreStates set the xyz coordinates of P5 and P6 from their 'child' particles *before* evaluating the score function, and map the derivatives on P5 and P6 back onto the child particles *after* evaluation. The problem now is if we add a new GravityCenter P7=G(P5,P6). In order for this to work properly the before-update has to happen after that for P5 and P6, but the after-update has to happen before P5 and P6. So ordering could help here, but would need to happen in reverse order for update() and after_evaluate(). (The alternative is to prohibit gravity centers from containing other gravity centers, in which case we would simply define P7=G(P1,P2,P3,P4).)
Ben