July 2013 - IMP-users

Atom not interpolated error when using do_global_fitting from multifit
by Dan Cohen 28 Jul '13

28 Jul '13

Hello, I have been using do_global_fitting function to fit a PDB into an EM map. I'm getting tons of warnings in the stdout such as : WARNING particle:Atom C of residue 52 is not interpolated WARNING particle:Atom O of residue 52 is not interpolated WARNING particle:Atom N of residue 53 is not interpolated WARNING particle:Atom C of residue 40 is not interpolated WARNING particle:Atom O of residue 40 is not interpolated WARNING particle:Atom N of residue 41 is not interpolated WARNING particle:Atom CA of residue 41 is not interpolated According to my understanding this means that the PDB is located outside the bounding box of the EM-file - is that true? Hows does the algorithm decide with which respective translations to test the fitting? Why doesn't the algorithm just move the the protein's center of mass to the center of the EM file, before starting the processing? Should I do that manually? Thank you, Dany

2 2

Re: [IMP-users] IMP-users Digest, Vol 30, Issue 6
by Barak Raveh 24 Jul '13

24 Jul '13

Hi Dany, We are considering removal of some of the Euler angle conversion functions, which are not frequently used by the IMP community and may not be numerically stable, while keeping only a few stable and well working ones that we will maintain. But before we do that - can you let us know which ones are important to you? We don't want to remove something that you're already using :) Best, Barak On Tue, Jul 16, 2013 at 12:00 PM, <imp-users-request(a)salilab.org> wrote: > Send IMP-users mailing list submissions to > imp-users(a)salilab.org > > To subscribe or unsubscribe via the World Wide Web, visit > https://salilab.org/mailman/listinfo/imp-users > or, via email, send a message with subject or body 'help' to > imp-users-request(a)salilab.org > > You can reach the person managing the list at > imp-users-owner(a)salilab.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of IMP-users digest..." > > > Today's Topics: > > 1. Re: Rotations and Euler angles - possibly wrong > documentation/function names (Dan Cohen) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Tue, 16 Jul 2013 15:56:08 +0300 > From: Dan Cohen <bojemoi(a)gmail.com> > To: Help and discussion for users of IMP <imp-users(a)salilab.org> > Subject: Re: [IMP-users] Rotations and Euler angles - possibly wrong > documentation/function names > Message-ID: > <CAECL089r0AkEwebki37Xg5k31+_ZkcwvsHZuWuDE6eCjVh= > xFQ(a)mail.gmail.com> > Content-Type: text/plain; charset="iso-8859-1" > > Thank you for your answer. > > I was able to pinpoint the problem - it is not a bug but it is a quite > confusing implementation so I would advise to change it. > Here goes : > > When using an zxz rotation (Implemented in FixedZXZ object) then : > A) When you print the object it will print the angles in this order : psi , > theta , phi > > Proof (From imp/modules/algebra/include/Rotation3D.h) > > FixedZXZ() {} > FixedZXZ(double psi, double theta, double phi) { > v_[0] = psi; > v_[1] = theta; > v_[2] = phi; > } > double get_psi() const { return v_[0]; } > double get_theta() const { return v_[1]; } > double get_phi() const { return v_[2]; } > IMP_SHOWABLE_INLINE(FixedZXZ, { > out << v_[0] << " " << v_[1] << " " << v_[2]; > }); > > ----- > > But when using the function get_rotation_from_fixed_zxz(double phi, double > theta, double psi) to create > such a rotation, you provide it with the Euler angles in a different order > : phi-theta-psi > > This causes in a situation in which writing the rotations to a file and > reading them back (while assuming > the same order of angles) caused me to get a different transform and > producing wrong results. > > Not a bug but quite confusing. BTW, When using the ZYZ variant the order IS > the same so there is no such problem. > > Could you confirm my understanding? > Thank you, > Dany > > > > > On 15 July 2013 21:22, Daniel Russel <drussel(a)gmail.com> wrote: > > > Sorry about the confusion. The Euler angle support has been added in a > > fairly ad hoc manner and is not extremely coherent or consistent. I think > > part of this is intrinsic to Euler angles as there are lots of > conventions > > used in different places. You can see some more discussion about what to > do > > with them at <https://github.com/salilab/imp/issues/303>. We didn't > > really come to any solid consensus on where to go. > > > > > > On Mon, Jul 15, 2013 at 6:59 AM, Dan Cohen <bojemoi(a)gmail.com> wrote: > > > >> Hello all, > >> > >> Please refer to Rotation3D.h > >> I add my remarks, all starting by XXXXXX : > >> > >> > >> /** \name Euler Angles > >> There are many conventions for how to define Euler angles, based on > >> choices > >> of which of the x,y,z axis to use in what order and whether the > >> rotation > >> axis is in the body frame (and hence affected by previous rotations) > >> or in > >> in a fixed frame. See > >> > >> > http://en.wikipedia.org/wiki/Conversion_between_quaternions_and_Euler_angles > >> for a general description. > >> > >> - All Euler angles are specified in radians. > >> - The names are all \c rotation_from_{fixed/body}_abc() where abc is > >> the > >> ordering of x,y,z. > >> @{ > >> */ > >> > >> *XXXXXX According to that, functions with the word "fixed" in their name > >> should > >> * > >> *XXXXXX Use the Lab fixed axis for rotations and NOT the new axis. > >> * > >> > >> //! Initialize a rotation in x-y-z order from three angles > >> /** \param[in] xr Rotation around the X axis in radians > >> \param[in] yr Rotation around the Y axis in radians > >> \param[in] zr Rotation around the Z axis in radians > >> \note The three rotations are represented in the original (fixed) > >> coordinate frame. > >> See Rotation3D > >> See FixedXYZ > >> */ > >> IMPALGEBRAEXPORT Rotation3D get_rotation_from_fixed_xyz(double xr, > double > >> yr, > >> double zr); > >> > >> *XXXXXX The above function complies with the above rule > >> * > >> //! Initialize a rotation from euler angles > >> /** > >> \param[in] phi Rotation around the Z axis in radians > >> \param[in] theta Rotation around the X axis in radians > >> \param[in] psi Rotation around the Z axis in radians > >> \note The first rotation is by an angle phi about the z-axis. > >> The second rotation is by an angle theta in [0,pi] about the > >> former x-axis , and the third rotation is by an angle psi > >> about the former z-axis. > >> See Rotation3D > >> */ > >> IMPALGEBRAEXPORT Rotation3D get_rotation_from_fixed_zxz(double phi, > >> double theta, > >> double psi); > >> > >> *XXXXXX I'm not sure what "former" means here, but probably this > >> function complies too. > >> XXXXXX Don't understand why angle parameter names are so different here > >> * > >> //! Generate a rotation object from Euler Angles > >> /** \note The first rotation is by an angle about the z-axis. > >> The second rotation is by an angle about the new y-axis. > >> The third rotation is by an angle about the new z-axis. > >> \param[in] Rot First Euler angle (radians) defining the rotation (Z > >> axis) > >> \param[in] Tilt Second Euler angle (radians) defining the rotation > (Y > >> axis) > >> \param[in] Psi Third Euler angle (radians) defining the rotation (Z > >> axis) > >> See Rotation3D > >> See FixedZYZ > >> */ > >> IMPALGEBRAEXPORT Rotation3D get_rotation_from_fixed_zyz(double Rot, > >> double Tilt, > >> double Psi); > >> > >> *XXXXXX This function is also called fixed but clearly says it is using > >> the NEW axis. > >> * > >> > >> I'm confused and add to that , the fact that the results of these > >> functions seem to be different than the ones produced by Chimera's > rotate > >> function so I'm in a problem here. > >> > >> Thank you, > >> Dany > >> > >> > >> _______________________________________________ > >> IMP-users mailing list > >> IMP-users(a)salilab.org > >> https://salilab.org/mailman/listinfo/imp-users > >> > >> > > > > _______________________________________________ > > IMP-users mailing list > > IMP-users(a)salilab.org > > https://salilab.org/mailman/listinfo/imp-users > > > > >

2 2

e2pdb2mrc - how to get a map that is aligned to the PDB
by Dan Cohen 21 Jul '13

21 Jul '13

Hello all, I have been using e2pdb2mrc + e2proc3d to simulate maps in MRC format from a PDB. I have been feeding this simulated map into algorithms - for example the FFT fitting one in EMAN2 and then into my own algorithms. The problem is that the map I'm getting is not aligned with the PDB - It is moved to a different origin. It is easy to see if you just open the map and the pdb in Chimera - they are similar but translated in respect to one another. This means that any transform matrix I'm getting from my algorithms is also translated so It's harder to compare it to the map etc. I have been manually using "Fit to map" from chimera to align the PDB to the map but this is the wrong approach IMHO as there should be a way for me to get the MRC map in the same locations as the PDB from the beginning. I'm now writing an automated script that performs the mentioned process for many complexes so I can't start aligning manually each complex so would be very thankful for a solution for this issue. Thank you, Dany

1 0

Rotations and Euler angles - possibly wrong documentation/function names
by Dan Cohen 16 Jul '13

16 Jul '13

Hello all, Please refer to Rotation3D.h I add my remarks, all starting by XXXXXX : /** \name Euler Angles There are many conventions for how to define Euler angles, based on choices of which of the x,y,z axis to use in what order and whether the rotation axis is in the body frame (and hence affected by previous rotations) or in in a fixed frame. See http://en.wikipedia.org/wiki/Conversion_between_quaternions_and_Euler_angles for a general description. - All Euler angles are specified in radians. - The names are all \c rotation_from_{fixed/body}_abc() where abc is the ordering of x,y,z. @{ */ *XXXXXX According to that, functions with the word "fixed" in their name should * *XXXXXX Use the Lab fixed axis for rotations and NOT the new axis. * //! Initialize a rotation in x-y-z order from three angles /** \param[in] xr Rotation around the X axis in radians \param[in] yr Rotation around the Y axis in radians \param[in] zr Rotation around the Z axis in radians \note The three rotations are represented in the original (fixed) coordinate frame. See Rotation3D See FixedXYZ */ IMPALGEBRAEXPORT Rotation3D get_rotation_from_fixed_xyz(double xr, double yr, double zr); *XXXXXX The above function complies with the above rule * //! Initialize a rotation from euler angles /** \param[in] phi Rotation around the Z axis in radians \param[in] theta Rotation around the X axis in radians \param[in] psi Rotation around the Z axis in radians \note The first rotation is by an angle phi about the z-axis. The second rotation is by an angle theta in [0,pi] about the former x-axis , and the third rotation is by an angle psi about the former z-axis. See Rotation3D */ IMPALGEBRAEXPORT Rotation3D get_rotation_from_fixed_zxz(double phi, double theta, double psi); *XXXXXX I'm not sure what "former" means here, but probably this function complies too. XXXXXX Don't understand why angle parameter names are so different here * //! Generate a rotation object from Euler Angles /** \note The first rotation is by an angle about the z-axis. The second rotation is by an angle about the new y-axis. The third rotation is by an angle about the new z-axis. \param[in] Rot First Euler angle (radians) defining the rotation (Z axis) \param[in] Tilt Second Euler angle (radians) defining the rotation (Y axis) \param[in] Psi Third Euler angle (radians) defining the rotation (Z axis) See Rotation3D See FixedZYZ */ IMPALGEBRAEXPORT Rotation3D get_rotation_from_fixed_zyz(double Rot, double Tilt, double Psi); *XXXXXX This function is also called fixed but clearly says it is using the NEW axis. * I'm confused and add to that , the fact that the results of these functions seem to be different than the ones produced by Chimera's rotate function so I'm in a problem here. Thank you, Dany

2 2

Failed to build IMP
by Dan Cohen 09 Jul '13

09 Jul '13

Hello all, I tried to build IMP on an ubuntu 12.04 by going over the directions in your site. These are the directions I used : *Building IMP from source is straightforward if the prerequisites<http://www.integrativemodeling.org/2.0.1/doc/html/installation.html#prereq>are already installed. We recommend you get IMP from git by git clone git://github.com/salilab/imp.git To build, create a directory to build IMP in (it is good practice not to build in the source directory and do) * * * *cmake ../imp -DCMAKE_BUILD_TYPE=Release make -j 4* The only change I did was to disable Doxygen. I did the git clone about 12 hours ago. The build runs OK until it fails on one of the swig creation phases : [ 70%] Built target _IMP_symmetry [ 70%] Built target imp_symmetry_python [ 71%] Built target _IMP_atom [ 72%] Built target imp_atom_python [ 72%] Built target _IMP_scratch [ 73%] Built target imp_scratch_python [ 73%] Built target _IMP_em [ 73%] Built target imp_em_python [ 73%] Built target _IMP_kinematics [ 74%] Built target imp_kinematics_python [ 75%] Built target _IMP_misc [ 75%] Built target imp_misc_python [ 75%] Running swig on rmf Traceback (most recent call last): File "/home/bojemoi/university/imp-source/tools/build/make_swig_wrapper.py", line 94, in <module> main() File "/home/bojemoi/university/imp-source/tools/build/make_swig_wrapper.py", line 87, in main run_swig(outputdir, options) File "/home/bojemoi/university/imp-source/tools/build/make_swig_wrapper.py", line 44, in run_swig ret = tools.run_subprocess(args, cwd=outputdir) File "/home/bojemoi/university/imp-source/tools/build/tools.py", line 465, in run_subprocess % (ret, " ".join(command))) OSError: subprocess failed with return code 1: swig -castmode -interface _IMP_rmf -DPySwigIterator=IMP_RMF_PySwigIterator -DSwigPyIterator=IMP_RMF_SwigPyIterator -python -c++ -naturalvar -fvirtual -Wextra -I../../include -I../../swig -oh wrap.h-in -o wrap.cpp-in -I/home/bojemoi/university/imp-release/include -I/usr/include /home/bojemoi/university/imp-release/swig/IMP_rmf.i make[2]: *** [src/rmf_swig/wrap.cpp] Error 1 make[1]: *** [modules/rmf/pyext/CMakeFiles/_IMP_rmf.dir/all] Error 2 make: *** [all] Error 2 When trying to execute the same command myself (the swig command that fails with error code 1) I get : bojemoi@linux:~/university/imp-release$ swig -castmode -interface _IMP_rmf -DPySwigIterator=IMP_RMF_PySwigIterator -DSwigPyIterator=IMP_RMF_SwigPyIterator -python -c++ -naturalvar -fvirtual -Wextra -I../../include -I../../swig -oh wrap.h-in -o wrap.cpp-in -I/home/bojemoi/university/imp-release/include -I/usr/include /home/bojemoi/university/imp-release/swig/IMP_rmf.i /home/bojemoi/university/imp-release/swig/IMP_rmf.impl.i:1: Error: Unable to find 'RMF.i' Many other modules that do not relate to RMF.i build correctly and I can import them from python , but I happen to need multfit that DOES require RMF... I tried to search for RMF.i in my release directory : bojemoi@linux:~/university/imp-release$ find | grep RMF ./include/IMP/rmf/RMFWriter.h ./data/build_info/RMF bojemoi@linux:~/university/imp-release$ cat data/build_info/RMF ok=True includepath="" swigpath="" libpath="" Swig version is 2.0.4 by the way. Thank you! Dany

2 3

Compilation error of develop-version due to problem with shell?
by Pia Unverdorben 09 Jul '13

09 Jul '13

Dear all, I have problems compiling the develop-version of IMP, while the master is fine. Running: "cmake ../imp -DCMAKE_BUILD_TYPE=Debug -DIMP_DISABLED_MODULES=cgal:membrane -DIMP_PER_CPP_COMPILATION=core" works, but "make -j 8" crashes after about 20% with the following message: " Scanning dependencies of target imp_benchmark /bin/sh: 1: Syntax error: Bad fd number make[2]: *** [doxygen/base/tags] Error 2 make[1]: *** [modules/base/CMakeFiles/IMP.base-doc.dir/all] Error 2 make[1]: *** Waiting for unfinished jobs.... " A similar error occurs when calling "git imp update": Fetching changes from origin tools/git/gitflow/git-imp: 125: tools/git/gitflow/git-imp: Syntax error: Bad fd number I found, that "Bad fd number" is often related to the shell used in the makefiles. For our system sh points to dash, not bash. Might that be the reason why I run into problems? Which shell are you using? When I change in tools/git/gitflow/git-imp "#!/bin/sh" to "#!/bin/bash" git imp update works again. Is there a way, that I don't have to search and replace every single "#! bin/sh"? Or do you have any other ideas or hints, what I could try? Could doxygen cause part of the problem? Thank you very much in advance! Pia Pia Unverdorben (Dipl. Math.) Max-Planck Institut für Biochemie Am Klopferspitz 18 D-82152 Martinsried unverdor(a)biochem.mpg.de

2 3

ConnectivityRestraint evaluation fails
by Pia Unverdorben 01 Jul '13

01 Jul '13

Dear all, after some time, I updated IMP. Now the way I set up ConnectivityRestraints fails. I combine several particles to a pseudo-particle and the connectivity restraint gets a list of this pseudo-particles. The problem occurs in the moment, I try to evaluate the restraint. Attached is an example script, based on the connectivity example. That works still fine in an older IMP version, but now it gives me an error message "_IMP_base.InternalException: Not in input list. Violating object: "Model 0". Attribute x of particle "P3" with id 3" even though P3 has a x-value. What is wrong in my approach? Or what did change in the implementation? Is it related to the issue, that in my case particle.show() now only displays the name, but no attributes anymore? Furthermore, there is a "WARNING You should pass the model to the Restraint constructor. Constructing ConnectivityRestraint %1%", directly when I call IMP.core.ConnectivityRetraint. Is there a possibility to add the Model already at this point, which is not described in the documentation? I use set_model in the next line... Thanks in advance! Pia Pia Unverdorben (Dipl. Math.) Max-Planck Institut für Biochemie Am Klopferspitz 18 D-82152 Martinsried unverdor(a)biochem.mpg.de

2 2