Difference between revisions of "Optimising a path"
import>Mp466 |
import>Mp466 |
||
| Line 1: | Line 1: | ||
Under construction... |
Under construction... |
||
| − | Once a |
+ | Once a connection has been thought to be made, it is best to verify that there is indeed a |
connection. Run another PATHSAMPLE calculation with DIJKSTRA 0 and CYCLES 0. A common gotcha |
connection. Run another PATHSAMPLE calculation with DIJKSTRA 0 and CYCLES 0. A common gotcha |
||
is a too high of a MAXTSENERGY value can make an apparent connection disappear! The aim is to |
is a too high of a MAXTSENERGY value can make an apparent connection disappear! The aim is to |
||
| Line 7: | Line 7: | ||
number of local minima. A plateau of around an order of magnitude is usually accurate enough. |
number of local minima. A plateau of around an order of magnitude is usually accurate enough. |
||
| − | The |
+ | The goal is to optimise the mean first passage time, by building a larger database |
that has more direct connections between the starting and ending minima. In pathdata, |
that has more direct connections between the starting and ending minima. In pathdata, |
||
COMMENT DIJINITCONTFLY 0 and add SHORTCUT <n>, where n is perhaps a quarter of the |
COMMENT DIJINITCONTFLY 0 and add SHORTCUT <n>, where n is perhaps a quarter of the |
||
| Line 21: | Line 21: | ||
The primary keywords to use when improving the rate constants are SHORTCUT, SHORTCUT BARRIER, and |
The primary keywords to use when improving the rate constants are SHORTCUT, SHORTCUT BARRIER, and |
||
FREEPAIRS. Aggressive shortcutting of either variety may be required, but one should be careful |
FREEPAIRS. Aggressive shortcutting of either variety may be required, but one should be careful |
||
| − | about it introducing |
+ | about it introducing artificial traps, which can be alleviated with FREEPAIRS. |
Three bits of data should be tracked when performing this calculation. |
Three bits of data should be tracked when performing this calculation. |
||
| − | 1. Also periodically make a |
+ | 1. Also periodically make a disconnectivity graph from the database (with or without grouping as necessary) |
| − | introduced traps. |
+ | to check for introduced traps. |
| − | 2. The pathsample |
+ | 2. The pathsample output lines starting with Dijkstra> will provide the most information about the |
rates of the existing database. |
rates of the existing database. |
||
Revision as of 00:18, 20 September 2008
Under construction...
Once a connection has been thought to be made, it is best to verify that there is indeed a connection. Run another PATHSAMPLE calculation with DIJKSTRA 0 and CYCLES 0. A common gotcha is a too high of a MAXTSENERGY value can make an apparent connection disappear! The aim is to grow the database until one sees a plateau in the GT (grouped) rate constant as a function of number of local minima. A plateau of around an order of magnitude is usually accurate enough.
The goal is to optimise the mean first passage time, by building a larger database that has more direct connections between the starting and ending minima. In pathdata, COMMENT DIJINITCONTFLY 0 and add SHORTCUT <n>, where n is perhaps a quarter of the path length, or less if the path is huge. Using DUMMYRUN in pathdata can help in setting the value for <n> because a list of pairs to connect will be created etc. but no actual OPTIM jobs will be submitted. Setting too large or too small <n> will be inefficient with respect to improving the rate constants. To begin with one rate constant is likely to be much smaller than the other one. You want to optimise the rate constant as far as possible, by keeping track of the rate constants as function of the number of minima in the databases. Eventually additions of new connections to the database will no longer reduce the rate constant.
The primary keywords to use when improving the rate constants are SHORTCUT, SHORTCUT BARRIER, and FREEPAIRS. Aggressive shortcutting of either variety may be required, but one should be careful about it introducing artificial traps, which can be alleviated with FREEPAIRS.
Three bits of data should be tracked when performing this calculation.
1. Also periodically make a disconnectivity graph from the database (with or without grouping as necessary) to check for introduced traps.
2. The pathsample output lines starting with Dijkstra> will provide the most information about the rates of the existing database.
3. Check the GT rate every n cycles with a "GT 0 <n>" line. Might be useful if n is chosen to be large; otherwise check the rate with a separate pathsample job e.g. when you're making a tree.