support for FeatureTrajectories (I think I had this almost figured out and ready). A clean way to generate Trajectory Files that only contain features besides existing trajectories. Analysis should then be able to work on both types of trajectories, feature and atom alike.
THE BIG UNIFICATION
A more on the grand (unifying) project if I would have more time. I guess that would be ultimate simulation machine. Let me lay out what I think would be enough to allow automatic parallel execution of most simulation needs (RepEx, AdaptiveMD, TIS and derivatives, MetaDynamics). What I propose is not about the way the resulting simulations are used or restart decisions but merely what features would be needed to cover all these cases.
Code for this mostly exists in adaptivemd or openpathsampling in some form. If possible I would like to guide OPS to use adaptivemd in a future version.
Simulation Engines / Generators like in adaptivemd
Trajectory Snippets We do not (necessarily) combine trajectories, but keep the simulated parts as trajectory parts (which can have feature trajectories as well). In OPS we have this already, but use trajectories of single frame size. This is extremely flexible, but has a large overhead that slows down analysis. A transition to Trajectory objects that consists of sub trajectories would be desirable.
Trajectory Files like in adaptivemd. We strictly separate the project metadata and trajectory files
Alterable Trajectories like in OPS. You can chop, extend and reverse trajectories to you liking.
Reversible Features like in OPS. Feature must support the concept of reversibility.
Trajectory Features like in upcoming OPS. A trajectory feature is a feature that is some value for the whole trajectory object. Example: the maximal phi angle. This will give in insane speed up for analysis.
Featurizer like in OPS. These are in OPS the connection between trajectories and rest of the framework. You cannot access atom coordinates unless you create a feature for these. You then access the values by feature(trajectory) like applying a function. A feature knows how it is computed (using PyEmma, etc...) and is cached. In adaptivemd it would be an abtraction of the FeatureTrajectory concept, so feature(trajectory) will automatically (1) use the constructed FeatureTrajectories and/or schedule computation of the features if necessary. Optionally we allow storage of certain features in the DB for later analysis (like in OPS)
Just a list of features we think are useful...
THE BIG UNIFICATION
A more on the grand (unifying) project if I would have more time. I guess that would be ultimate simulation machine. Let me lay out what I think would be enough to allow automatic parallel execution of most simulation needs (RepEx, AdaptiveMD, TIS and derivatives, MetaDynamics). What I propose is not about the way the resulting simulations are used or restart decisions but merely what features would be needed to cover all these cases.
Code for this mostly exists in
adaptivemdoropenpathsamplingin some form. If possible I would like to guide OPS to useadaptivemdin a future version.feature(trajectory)like applying a function. A feature knows how it is computed (using PyEmma, etc...) and is cached. In adaptivemd it would be an abtraction of the FeatureTrajectory concept, sofeature(trajectory)will automatically (1) use the constructed FeatureTrajectories and/or schedule computation of the features if necessary. Optionally we allow storage of certain features in the DB for later analysis (like in OPS)... more to come ...