axsk / isokann.jl Goto Github PK

Currently we re-seed momentum on each (short) tractory, which leads to unphysical results.

This requires to decouple NN input/data from the underlying simulation data, as the former doesn't require the momentum.

Look at the work done in IsoMu.jl

So what do we want from this?

This seems to be the interface we are looking for to decouple data-generation from the actual ISOKANN loop

I can think of two stages, the raw burst-trajectory loader, which then in turn generates the data for the supervised training step.

The former should be fine for a first step.

We seem to have converged on the API now (assuming #14 turns out as expected).

We need a few alignment methods.
We have aligning 2 frames, aligning trajectories and aligning 3 points.

Maybe we can find "the most stable alignment along isokann"?

This would allow for simple minibatching using DataLoader #2 and be more in line with the general "batch dimension last" paradigm.

I am not sure how much this would brake and if it is wise to do ..

We have 2 reaction path files in ISOKANN and one more in VGV

Define an interface

keep an eye out for plotting and saving generically

Given that Iso2 now has a working autoplot and seems to be working with adapative sampling it is finally time to get rid of that monster IsoRun.

Since the OpenMM installation is not straigthforward with PyCall

I wanted to test the sensitivity wrt. to sampling procedure (chi-apapt/uniform) in the DoubleWell example (IsoForce) and test the performance by decreasing the integration timespan.

Turns out that the results for T=1 and T=1. differ vastly.

Something is wrong there.

Mainly because of the long precompilation due to Enzyme, but also since it somehow broke 1.10.2 precompilation

Almost done in src/molly.jl OverdampedLangevinGirsanov

We should have all these working, but the interface/usage is not quite clear.

I am thinking of examples/doublewell.jl and so on, demonstrating the according features

• Double Well (TransformShiftscale)
• Triple Well (TransformISA)
• Dialanine (Adaptive Sampling)
• VGV
• MOR (IsoMu)

They should double as tests.

supposedly there is some example code using reinterpret inside molly

This is nagging me for a long time and has caused a lot of headaches.

The main problem is that each of these can stand on their own, no clear hierarchy is obvious.

ISOKANN has its own trainings data, which however can differ from the full "coordinate" data.
For visualization however it needs access to the "coordinate" data.
Adaptive sampling complicates this further.

One way of patching them together is via a DataLoader which doubles as data provider for ISOKANN but also holds raw data, and is able to also contain a Simulation.

Where do we attach known reaction coordinates (for visualization) etc?

• load pdb into OpenMMSimulation
• get it working with adaptive sampling

Use multiple lag-times for the ys generation from trajectory data.