230328 Meeting ideas

[ehhartmann]

Rates and Barriers

Problem statement

Kinetic Monte Carlo (KMC) needs reaction rates as input to draw a reaction rate with is then performed. There are certain constraints to the input reaction rates, especially for the set of rates that is used for one individual KMC step. Reaction rates that will be compared because they are in the same set should therefore share some properties. We should settle on properties for kimmdy reaction rates.

Microscopic Barrier Interpretation

Macroscopic Barrier Interpretation

-> the barrier at a certain KMC step should represent the effective barrier to cross from the current state to a neighboring state

• predicted barriers should approximate the barrier determined by methods that search for the lowest first-order saddle point on the PES
  • many KMC simulations, eg. in surface chemistry use this interpretation for their KMC rates (ref)
  • the hybrid MD/MC approach of Benoit Roux uses macroscopic rates based on energetic differences of protonated and unprotonated sites as described in the Henderson-Hasselbalch equation
• we could get macroscopic rates by predicting microscopic rates of specific conformations along the trajectory; rates from this boltzmann weighted ensemble can then be coarse grained into macroscopic rates in a similar fashion to the way it is done in markov state models
  • I currently don't know a physically reasonable way to coarse grain microscopic rates into macroscopic rates
• these rates would be comparable to the homolysis rates from the bell model as used in kimmdy v1
• implementations of other reactions which derive their rates from mathematical models would also use macroscopic/effective rates

Other

• scale attempt frequency of reactions with different time scales if state of one reaction has no impact on the rate of the other reaction
  • is this the case for HAT/homolysis?
• rejection KMC: determine number of reactions or simulations? Remove tasks from queue?
• lincs on h-bond during HAT reaction MD?? timestep changes

[KRiedmiller]

Reaction plugin interface

For efficiency, we do not query the reactions every time step. Therefor, we get trajectories and need then to decide, at what points we want to ask the reactions for rates.

• Interval, in which we want to query the reactions?
• Most likely, this interval is not the same as we perform MD in, therefore:
• How should we 'roll back' the simulation?
  • Query at some points in traj, apply changes to last frame, continue from there?
    • easiest, but not very clean
    • Query at some points in traj, apply changes at first accepted point, discard rest of traj? Most flexibility
    • Only query and apply reaction at end of traj, so reaction and MD timeframes are synced. Less flexible, easy to implement.
• How should interface look exactly for reaction?
  • Reaction has already access to everything (last traj)
  • Reaction should know in what intervals it should check (or it should get called multiple times with exact frames as input) -> from config
  • Either ReactionResult should contain a list with frame ids or
  • Conversion Recipe should contain a single frame id

Misc:

• Kimmdy should accept arbitrary input from reactions for logging. Logging should be done in one place.
• e.g. uncertainty from ensemble, but other reactions could want to log other things.
• ReactionResult probably the best interface for this?

[ehhartmann]

Summary

• Calculating the attempt frequency is a important
  • Approaches: 1. unbiased QM/MM 2. biased QM/MM 3. from vibration modes
  • Assignee: Eric
• It remains unclear which properties the rates of reactions should have
  • Generally, robust, pooled rates are seen as positive
  • it is unclear how to obtain them, clustering could be an option
  • Kai will check how strong current HAT rates fluctuate
• We will keep using h-bond lincs
• Validating the reaction rates is important
  • Toy systems with experimental rates could be: RNR, System from Sergi Garcia-Manyes (Vinculin?), peptides with radical starters

[ehhartmann]

Implementation Discussion

• Reaction interface
  • in: Trajectory
  • out: Rates for a single MC step, final structure
  • limitations: computationally inefficient, reactions could be hard to conduct if the final structure is not favoring that reaction anymore
• Conversion Recipe returning frame id
  • how often MD stops would be part of the actual attempt frequency
  • thus changing MD timescales between MC steps (as caused by not returning the final structure) is hard to justify
  • I could see it as feasible if the only task of the MD is to calculate the reaction rates and it would not be part of the time evolution
• Logging
  • could you explain the advantages and disadvantages of logging in one place?

[jmbuhr]

I think what Kai means by logging in one place is not that everything should be written to the same file but rather that it is configured in one place and re-used, right?
A reaction can already just import logging and write to our logfile, but I was also wondering if we could use the logging module to collect different outputs.

[KRiedmiller]

I really just meant writing things down, so different reactions may produce some more information besides the pure reaction, like in the HAT case the uncertainty. A way for the reaction to return arbitrary information per reaction step would be nice I think.

[ehhartmann]

Dev Meeting 30.03

• try more expensive methods for TS search
• Reaction interface
  • Runmanager reads trj (trr + tpr) to MDA Universe
  • trj is split into sampling intervals
  • from a first-in-first-out queue, the runmanager calls a reaction modules with a MDA Universe that contains only the current timestep
  • the reaction module calculates rates for exactly this configuration and returns them to the runmanager
  • the runmanager starts a MC step (rejection free KMC)
  • if a move gets accepted, the queue gets flushed and the reaction is conducted from the current configuration
  • if a move gets rejected, the next sampling interval will be evaluated from the queue
    • if the queue is empty a new MD simulation will be conducted (crr_task queue)
• an overall attempt frequency has to be supplied for a kimmdy run per reaction type
• the attempt frequency of a MC step is scaled by the sampling interval (AF_general [1/s] = AF_step * sampling frequency )
• sampling frequency is a hyperparameter that should correspond to the time during which the fastest changing reaction barrier is constant
• MD runtime > sampling interval is necessary, ideally sampling interval = n* write frequency and MD runtime = n* sampling interval