Setting up TPS calculations starting from transition paths generated by TIS fails

[gyorgy-hantal]

Hello,

I ran a bunch of TIS calculations for my system and now I need to run TPS for the same system starting from some of the transition paths generated earlier by TIS. I redefine my network and move scheme accordingly, however when OPS reads my initial path it complains about bad initial conditions, in particular, about missing Sequential Ensemble. I know that my initial path is physical, intact, and connects my stable states. Since I make OPS output the value of my order parameter when it reads the initial path, I am sure that the path is read correctly. I tried with several paths and the result was always the same. I wonder if I set up something wrong.. Have you every seen this problem before?

Thank you in advance! Gyorgy

[dwhswenson]

Thanks for the report. I'm traveling right now, so it may be a few days before I can look in detail. (On mobile now.) As a first step, could you try with debugging enabled for ensembles? If you use the engine debugging file, but replace engines with ensemble (note difference in plural), that might provide useful information.

To use the logging config file, do something like this:

import logging.config
logging.config.fileConfig("logging.conf")

Details can be found in Python logging pages, linked to on the OPS website.

If you can upload the resulting output file here (might need to make the extension txt instead of log for GitHub to allow drag/drop uploads), that might provide some more insight.

[gyorgy-hantal]

Thank you, David, for the suggestion. I uploaded here the resulting log file containing information on the ensembles. I am also traveling, so haven't had time to check it...

[dwhswenson]

I took a little time to look at this today. For context, OPS sees a TPS ensemble as:

1. One frame in state A
2. Optionally an arbtrary number of frames not in either state A or state B
3. One frame in state B.

It looks like it is having trouble assigning frames to the second of those ensembles. Could you try the following (after creating your TPS scheme with the name scheme and your transition trajectory with name traj)?

ensemble = scheme.network.sampling_ensembles[0]
in_A, out, in_B = ensemble.ensembles
assert in_A(traj[:1]), "in_A failed"
assert out(traj[1:-1]), "out failed"
assert in_B(traj[-1:]), "in_B failed"

[gyorgy-hantal]

Indeed, the second assertion fails:

File "/gpfs/work1/0/transit/ghantal1/TPS/S1/run0.py", line 93, in <module> assert out(trajectory[1:-1]), "out failed" AssertionError: out failed

[dwhswenson]

Good -- that's the error I expected. Could you try the following (continuing from the above, which defined in_A, out, and in_B):

[idx for idx, snap in enumerate(traj) if out.volume(snap)]
# this should give you 2 numbers: index of first and last frames (so 0 and something)

[idx for idx, snap in enumerate(traj) if in_A(paths.Trajectory([snap]))]
# this should give you [0]

[idx for idx, snap in enumerate(traj) if in_B(paths.Trajectory([snap]))]
# this should give you only the last frame

Given the errors, you'll most likely get 3 numbers in the first one, and then the question is which specific state one gives more than one.

[gyorgy-hantal]

I got the following lists (I have 697 snapshots in the path):

[0, 621, 696] [0] [621, 696]

I checked snapshot 621. In fact, what happens is that when OPS reads my trajectory now, it does not exactly obtain the same order parameter values as when the path was generated, and it finds that we already reach state B in snapshot 621. Indeed, my order parameter fluctuates a lot and it can be that due to some round-off error we don't always obtain the same values... I observed this before but apparently this inconsistency is more prevalent than I thought. Reading only the first 622 snapshots solves the problem. Thank you very much for the help in solving this issue!!