Trees | Indices | Help |
|
---|
|
Functionalities to handle molecular topologies
Copyright Schrodinger, LLC. All rights reserved.
|
|||
DuckFrame A duck-type frame with limited interface. |
|
|||
|
|||
list of int
|
|
||
|
|||
|
|||
(new-cms-model, seletion-in-gid) |
|
||
|
|||
|
|||
structure.Structure |
|
||
|
|||
|
|||
structure.Structure |
|
||
msys.System |
|
||
list of int
|
|
||
list of int
|
|
||
|
|||
|
|||
|
|||
list
|
|
||
list
|
|
||
list
|
|
||
list
|
|
||
FFIOStructure
|
|
||
int or 3 if the water type cannot be identified.
|
|
||
|
|||
|
|||
structure.Structure |
|
||
structure.Structure |
|
||
structure.Structure |
|
||
structure.Structure |
|
|
|||
__package__ =
|
|
Returns an iterator through all atoms in a cms model. At each iteration, we can get a tuple of (fsys_atom, comp_atom, comp_ct, ct_index), where
|
|
This function will find the match between pseudoatoms and return it as a list of pseudoatom indices. match = pseudoatom_match(msys_model) j = match[i] where `j' is the matched pseudoatom's index in the ffio_pseudo block of the mutant CT, `i' is the pseudoatom's index in that of the reference CT. If `i'-th pseudoatom is not matched, `j's value is zero. `match[0]' is always junk and should be ignored. For non-alchemical-FEP systems, this function returns an empty list.
|
Read a .cms file from the given file name C{fname}, or from a string buffer. How does this differ from C{cms.Cms(fname)}? - Here, two models will be created for the given .cms file. So you will get 2-tuple return value: The first member is the msys model, and the second is the cms model. - The cms model returned by this function will give you correct gids, whereas the model returned by C{cms.Cms(fname)} might not do so when there are virtual sites. - The cms model returned by this function will have two extra attributes: - C{pseudoatoms} This is a map from the gid of a physical atom to that of its pseudoatom(s). - C{pseudomatch} This is pseudoatom match between the two alchemical molecules. (See the docstring of L{pseudoatom_match} for detail) Will we unite this with C{cms.Cms(fname)}? Maybe. But I don't see a strong motivation right now, and I don't want to overengineer. -YW (May 26, 2016) FIXME: C{msys.LoadMAE(...)} is unbelievably slow and may take up to 10 sec for typically-sized alchemical FEP systems. |
We need to clarify on what we call ``subsystem'' here. First, let's review the hierarchical structure of a chemical system in the cms model:
Despite of the fact that there are already a lot of concepts to grasp, it's still sometimes inadequate to describe a portion of the system. The problem arises mainly due to the fact that the cms model contains force field data: When we do atom selections, we have to keep that in mind, we won't be able to create a valid .cms file if we select a number of atoms that don't match the force field data. To address that problem, we introduce an extra concept that sits between the CT and the molecule levels in the hierarchy. We can call it ``instance'', and it refers to a single complete substructure that matches the ffio. For example, in a protein CT, the ffio describe the whole protein structure, and so the instance there is the whole protein, and the CT contains only 1 instance; whereas in a water CT, the ffio describes only a single water molecule, and thus the instance is a single water molecule, and the CT contains a number of instances. With that, we now define a subsystem as follows: A subsystem is a portion of the original system, containing 1 or more instances of any types as defined in the original system. By this definition, a subsystem should always be a valid cms model. We allow users to specify a subsystem using ASL, but how do we deal with cases where the ASL expression doesn't include a complete set of atoms in their respective instances? For now, we will simply automatically expand the selection to the whole instance. This is good enough for most cases, I think. Of course, in future we should have no problem to be more sophisticated in deciding to expand or shrink the selection.
|
A coroutine to iterate through all atoms in all component CTs of the
|
Given a C{ct}, set the following CT-level properties using the values from C{box}: "r_chorus_box_ax", "r_chorus_box_ay", "r_chorus_box_az", "r_chorus_box_bx", "r_chorus_box_by", "r_chorus_box_bz", "r_chorus_box_cx", "r_chorus_box_cy", "r_chorus_box_cz", @type box: Any type that supports double subscriptions like C{box[0][1]}, where both indices are zero-based. @rtype: L{structure.Structure} @return: The same input C{ct} object, whose "r_chorus_box_*" CT-level properties has been updated by this function. |
Updates coordinates and simulation-box-matrix of only the full-system CT with the given trajectory frame. N.B.: This function doesn't update the velocities.
|
This function will set the following atom properties: r_ffio_x_vel r_ffio_y_vel r_ffio_z_vel with C{vel[0]}, C{vel[1]}, and C{vel[2]}, respectively. @type atom: |
Update the physical data of a cms model. The physical data include all atom positions and velocities and also the box matrix.
|
Updates the given cms model N.B.: If you call this function for every frame of a long trajectory, you might find this function is quite slow. Also keep in mind that its performance has a strong dependency on the number of atoms in the system. If all that you want is a full-system CT with atom coordinates updated by the trajectory frame, consider using the update_fsys_ct function above, which is much faster than this function.
|
Updates the given msys model
|
Convert a list of atom IDs ( |
Evaluate an ASL expression, and return a list of gids of particles
selected by |
In MD simulation, molecules can be broken due to the periodic bound
condition, which makes some atoms be at one side of the simulation box
and the other atoms at the opposite side. This function will edit the
atom coordinates so to make broken molecules whole again for each frame
of the MD trajectory
|
First, make-whole all molecules in the simulation system, and then glue the selected molecules together.
|
This function will do what glue does, but it will do one more thing: It will translate the coordinates of all atoms so that the specified molecules will be placed at the center (origin) of the simulation box.
|
This function will do what center does, but in addition it will align and superimpose all the coordinates in the frame with respect to a reference coordinates (ref_pos). This operation will be applied to all frames in the trajectory.
|
Return the solvent CT in the system. In systems for life scienses,
typically the last CT, that is prepared by system_buidler, is a water
block. However, since this is may not be true for material sciences (and
mixed solvent) systems, we must validate the water block. Validation of
the water block is expensive, and should be used only the first time this
function is used. If the solvent CT is not pure water or is missing, a
|
Remove the unnecessary virtual sites from the solvent block. Should only be called for 4-pt and 5-pt waters. |
This function removes the majority of bulk waters, retaining a specified numbers of water molecules around a selected region. This function assumes that the system has already been centered, such that the only N-number of waters are retained around the origin. This function returns a list of water GIDs, for each frame, that are the closest to the origin. This approach has been tested on 3-pt and 4-pt waters with the systems that where set up with Desmond/Schrodinger tools. The assumptions being made are: 1) The water CT is the last idem of cms_model.comp_ct 2) The individual water molecules are organized in OHH order, where oxygen atom is folled by two hydrogen atoms. 3) If virtual site-containing water models are being used (like 4-pt), the virtual sites are ordered in the pseudo-block of ffio in same order as their corresponded water molecules. @param water_gids: the GIDs of water molecules. The default order atoms in a water molecule is OHH. May also include pseudo atoms for 4- and 5-pt water models. (See assumptions above) @type water_gids: C{list} of C{int} @param num_kept_water: total number of water molecules to retain @type num_kept_water: C{int} |
Similar to make_whole (see above), but on a cms model instead of a simulation trajectory. Both
|
Similar to glue (see above), but on a cms model instead of a simulation trajectory. Both
|
Similar to center (see above), but on a cms model instead of a simulation trajectory. Both
|
Similar to superimpose (see above), but on a cms model instead of a simulation trajectory. Both
|
Trees | Indices | Help |
|
---|
Generated by Epydoc 3.0.1 on Tue May 2 06:32:45 2017 | http://epydoc.sourceforge.net |