Re: [IMP-dev] Ordering among score_states (and other things)

[Ben Webb <>]

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
--
                      http://salilab.org/~ben/
"It is a capital mistake to theorize before one has data."
	- Sir Arthur Conan Doyle