| Trees | Indices | Help |
|
|---|
|
|
Functionalities to handle molecular topologies
Copyright Schrodinger, LLC. All rights reserved.
|
|||
|
DuckFrame A duck-type frame with limited interface. |
|||
|
|||
|
|||
|
|||
|
|||
| (new-cms-model, seletion-in-gid) |
|
||
|
|||
|
|||
|
|||
| msys.System |
|
||
list of int
|
|
||
list of int
|
|
||
|
|||
|
|||
|
|||
list
|
|
||
list
|
|
||
list
|
|
||
| structure.Structure |
|
||
| structure.Structure |
|
||
| structure.Structure |
|
||
|
|||
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
|
Read a .cms file from the given file name C{fname}.
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 an extra attribute:
C{pseudoatoms}, which is a map from the gid of a physical atom to that
of its pseudoatom(s).
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)
|
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 the given cms model C{cms_model} with the atom coordinates and
the simulation box matrix from a simulation frame C{frame}.
FIXME: Currently, this function doesn't update the velocities.
FIXME: Currently, if the system is alchemical FEP system where there are
matched pseudoatoms, this code doesn't update the pseudoatoms'
coordinates properly.
@type cms_model: L{structure.Structure}
@type frame: Duck type (see L{DuckFrame} for the interface requirements).
@rtype: L{structure.Structure}
@return: The same input C{cms_model} object, which has been updated on the
atom coordinates and the simulation box matrix.
|
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.
|
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
|
| Trees | Indices | Help |
|
|---|
| Generated by Epydoc 3.0.1 on Wed Aug 3 07:59:06 2016 | http://epydoc.sourceforge.net |