IMP Manual
for IMP version 2.16.0
|
The short answer is: "because no one knows how to do it safely". The complication is that the attributes of various particles may have relationships to one another that would be violated by the cloning process. For example, a Particle attribute in a Particle could be part of a bond, in which case the bond particle must also be cloned and the attribute in the new particle must point to the new bond, or it could be a pointer to a particle which keeps track of all of the atoms in the system, in which case the attribute value should be copied unchanged. A clone function would have no way of knowing which should be done.
We suggest that you either
protein_0= create_protein("my_protein_name") protein_1= create_protein("my_protein_name")
IMP.atom.create_clone()
function to clone a molecular hierarchy.Restraints are not allowed to add/remove/change attributes during restraint evaluation. The reason for this is that the order of evaluation of restraints is not defined and if restraints could change attributes, the score could depend on what order they were evaluated in. However, in certain cases it makes sense to cache computations in the particle so as to avoid having to recompute it next time (or in a different restraint). The (undocumented) method add_cache_attribute() provides a means to do that. The assumptions made are that
One usage of it currently is for the collision detection hierarchies used with rigid bodies. This hierarchy is computed on demand (for example when trying to evaluate a distance pair score on a pair of rigid bodies). Any time the rigid body is changed (eg the internal coordinates of a member are changed), the hierarchy gets cleared out and must be recomputed the next time.
In IMP we only export selected functions and classes from the dynamically linked libraries. This is required for things to work on Windows; while it is not strictly necessary on other platforms it gives slightly faster code. As a result, each class/function that is used outside of the library needs to be marked with IMPMODULENAMEEXPORT
. The rules for doing this are as follows:
class IMPMODULENAMEEXPORT ClassName: public BaseClass{};
IMPMODULENAMEEXPORT ReturnType function_name(ArgumentType arg_name);
IMPMODULENAMEEXPORT
IMPMODULENAMEEXPORT
tagsNote that the pickiest compiler about this is the Visual Studio compiler, so the fact that your code works with gcc does not guarantee it is correct.
cppcheck --enable=all . -I../debug/build/include --template="{file}:{line}:{severity},{id},{message}"
You are trying to decorate a particle before setting it up as an instance of the decorator. Use MyDecorator.setup_particle(blah) and now you can decorate: MyDecorator(blah)
The swig.i-in
file that you will find under mymodule/pyext
.
The order of the includes in the swig.i-in
matters. If a class uses code that is in another file, then you should put the latter first (note also that SWIG does not recursively follow #include
s inside the .h
files you include
). For example, if your class EnergyTermsRestraint requires EnergyTerms these lines in the swig.i-in
must appear in this order:
%include "IMP/mymodule/EnergyTerms.h" %include "IMP/mymodule/EnergyTermsRestraint.h"
One of its strengths is that there are excellent references, and Google will find you good answers to almost any question you have (many on Stack Overflow). Some good overviews that IMP users have liked can be found at:
In addition, help for any git command can be found by doing git help <command>
.
Show the branches in the log git log --graph --all --decorate
Show which words change in the diff git diff --word-diff
Clean out unknown files from repository git clean -f -d -x
Use a nice interface when there are merge conflicts git mergetool