w_fork is broken

[synapticarbors]

I'm starting an issue here and copying some discussions I had with @mczwier a while back to aid in coming up with a reasonable solution:

 On Fri, Jan 3, 2014 at 3:58 PM, Joshua  wrote: 
It looks like there are several problems with how w_fork and WESTPA is currently put together: 

 • w_fork does not set the basis_state_id. I’m not sure if it is even appropriate to set this 
attribute for a initial state with itype ISTATE_TYPE_RESTART 

 • In the executable propagator there is an assert statement (line 316): 
  assert initial_state.istate_type in (InitialState.ISTATE_TYPE_BASIS, InitialState.ISTATE_TYPE_GENERATED) 
that would fail with the ISTATE_TYPE_RESTART itype. This part is trivial to fix. 

 • When the new forked simulation kicks off, the propagators self.basis_states dict is 
empty, so you can’t just pick some arbitrary basis state to grab since the data 
it inserts into the environmental variables isn’t used (I think). 

 • update_args_env_initial_state is also trying to access a basis state from 
self.basis_states if the inital state basis_state attribute isn’t set (which it isn’t) 

and

On May 20, 2014 Joshua wrote:

I'm finally sitting down to revisit this issue. I have a few days that I can devote to this 
so I want 
to re-write this in a robust way that isn't just patching things up enough to get it to run. 
Here's what I'm thinking as one possibility: 

- Restarts from a forked simulation are neither a basis or initial state, and 
instead are a separate classification, perhaps called RestartState. 

I think this is advisable to create a clear distinction from the role of initial and 
basis states in a recycling simulation. Presumably a user would not want to 
apply a transformation or modify the configurations of replicas from a forked 
simulation since the idea is to preserve the distribution within the pcoord space. 
So the RestartState would be minimal, following from the BasisState. 

- Add an `rstates` directory that sits alongside `bstates` and `istates`. 
This would entail adding a new entry under `data_refs` in the .cfg file called `restart_state`. 

Again this is to avoid co-mingling the process of restarting from a fork from 
the basis state machinery. 

- Add a separate code path for restarts under the condition in the 
executable propagator when `segment.initpoint_type == Segment.SEG_INITPOINT_RESTART` 
(adding the SEG_INITPOINT_RESTART enum). 

- Introduce a segment.restart_state_id to properly access into a propagator dict of restart states. 

My major concern is that this will require adding a code path for the restart states everywhere 
in the code that a basis and initial state is mentioned. This might be unavoidable if we don't 
want to dual-purpose an initial or basis state for restarts, although since the restart states are 
only used during the very first iteration, maybe there is a way to isolate any logic involving them. 
I guess an alternative would be to stay closer to the current implementation and use a mechanism 
that marks initial_states that are restarts for one time use, so that they would never be pulled 
into generating new replicas during recycling. 

[mczwier]

Is there a way to use the existing change-up mechanisms for initial and basis states for this? Initial and basis states can change on a per-iteration basis, so one possibility would be to use the restart states as basis (and initial) states for the first iteration of a forked simulation, then apply the "true" (going forward) basis states at the second iteration. A comment in a log file (or attribute in the h5 file, like "generated by w_fork from some_file_name.h5" ) might be sufficient to prevent any resulting confusion.