IMP-dev January 2010

imp-dev@salilab.org

6 participants
16 discussions

Fwd: FixedZYZ fixed_zyz_from_rotation
by Javier Ángel Velázquez Muriel 01 Feb '10

01 Feb '10

2010/1/30 Daniel Russel <drussel(a)gmail.com>: > Check that the choice of Euler angles isn't singular near that point (each > choice of Euler angles has a place where it is singular, meaning very > different Euler angle values produce almost the same rotation). Yes, I think that is what is happening here, but I don't know how to repair it. How does the > instability manifest itself. When psi is 0, then sin(psi) = 0 and you're dividing by it. Needs a check, that is what I did. Does it help? > > I'll try to look more into it later. > > > On Jan 29, 2010, at 8:46 PM, Javier Ángel Velázquez Muriel > <javi(a)salilab.org> wrote: > >> That function enters into numerical instability when >> sin_tilt_sin_psi==0, which produces psi ==0. I've tried to fixe it, >> and i think is correct, but now the code throws the exception. The >> input and output are "apart". Can anybody help me to fix it? Anything >> that I missed? >> >> double psi= std::atan2(sin_tilt_sin_psi, cos_psi_sin_tilt); >> if(almost_equal(sin_tilt_sin_psi,0,1e-6)) { >> double sin_tilt= 0; >> double tilt= std::atan2(sin_tilt, cos_tilt); >> } else { >> double sin_tilt= sin_tilt_sin_psi/std::sin(psi); >> double tilt= std::atan2(sin_tilt, cos_tilt); >> } >> // double cos_rot= cos_rot_sin_tilt/sin_tilt; >> // double sin_rot= sin_rot_sin_tilt/sin_tilt; >> // double rot= std::atan2(sin_rot, cos_rot); >> double rot= std::atan2(sin_rot, cos_rot); >> _______________________________________________ >> IMP-dev mailing list >> IMP-dev(a)salilab.org >> https://salilab.org/mailman/listinfo/imp-dev > > _______________________________________________ > IMP-dev mailing list > IMP-dev(a)salilab.org > https://salilab.org/mailman/listinfo/imp-dev >

2 1

FixedZYZ fixed_zyz_from_rotation
by Javier Ángel Velázquez Muriel 30 Jan '10

30 Jan '10

That function enters into numerical instability when sin_tilt_sin_psi==0, which produces psi ==0. I've tried to fixe it, and i think is correct, but now the code throws the exception. The input and output are "apart". Can anybody help me to fix it? Anything that I missed? double psi= std::atan2(sin_tilt_sin_psi, cos_psi_sin_tilt); if(almost_equal(sin_tilt_sin_psi,0,1e-6)) { double sin_tilt= 0; double tilt= std::atan2(sin_tilt, cos_tilt); } else { double sin_tilt= sin_tilt_sin_psi/std::sin(psi); double tilt= std::atan2(sin_tilt, cos_tilt); } // double cos_rot= cos_rot_sin_tilt/sin_tilt; // double sin_rot= sin_rot_sin_tilt/sin_tilt; // double rot= std::atan2(sin_rot, cos_rot); double rot= std::atan2(sin_rot, cos_rot);

3 2

No imp-dev meeting today
by Daniel Russel 26 Jan '10

26 Jan '10

1 0

imppy.sh
by Javier Ángel Velázquez Muriel 26 Jan '10

26 Jan '10

I am not really sure why this script overrides the variable PYTHONPATH. I would suggest be nicer and add the line PYTHONPATH=$PYTHONPATH'/imp/blah/blah/' Is not a big deal, but a bit annoying when using other libraries.

3 2

RigidBody::.get_members
by Keren Lasker 26 Jan '10

26 Jan '10

To get the particles within a rigid body, it is better using IMP::core::get_leaves or get_members, i.e.: does get_members return the leaves or the children of the RigidBody ?

2 7

weight decorator
by Keren Lasker 25 Jan '10

25 Jan '10

hi, Currently we have a generic XYZR decorator. For mass we have atom::Mass, but when dealing with beads, it does not really make sense to use it. Do you think it makes sense to create a generic XYZRW decorator in core ? the default W key can be atom::Mass::get_mass_key() ?? Keren.

3 5

USAGE_AND_INTERNAL
by Keren Lasker 24 Jan '10

24 Jan '10

sometime the check requires more than a single command. do we have something like : IF_USAGE_AND_INTERNAL ?? thanks, Keren.

2 2

do we have a backbone selector ?
by Keren Lasker 23 Jan '10

23 Jan '10

i think we do not, but remember Ben saying something about it. so - should i write it or not ?

2 2

problem committing code ?
by Keren Lasker 22 Jan '10

22 Jan '10

hi - trying to commit a file and getting an error message: svn ci modules/domino/pyext/junction_tree_from_pair_list.py -m"allow of pairs to be strings and not numbers" Authentication realm: <https://svn.salilab.org:443> Private Sali Group pages Password for 'kerenl': Sending modules/domino/pyext/junction_tree_from_pair_list.py Transmitting file data .svn: Commit failed (details follow): svn: 'pre-commit' hook failed with error output: Traceback (most recent call last): File "/cowbell1/svn/imp/hooks/pre-commit", line 7, in ? import cpp_format File "/cowbell1/svn/imp/hooks/cpp_format.py", line 3, in ? from pygments import token ImportError: No module named pygments does it make sense ?? thanks, Keren.

2 1

opaqueness of RestraintSets
by Daniel Russel 19 Jan '10

19 Jan '10

Currently RestraintSets are opaque to the kernel, meaning that the kernel doesn't know anything about the restraints contained in them. This was fine for a while, but recently has been causing problems - Model::evaluate(restraints) called with restraints from a restraint set fails because the Model doesn't know about the dependencies of the restraint. - Restraint::evaluate() fails on restraints in restraint sets because it uses the above function - RestraintSets containing a mix of incremental and non-incremental restraints don't support incremental evaluation, making using restraint sets much slower than not using them in certain circumstances There are two solutions that I see: - move RestraintSet to the kernel and have the model traverse them internally so it is aware of the whole tree. This would slightly complicated the Model and would break some existing code (we could leave a deprecated core::RestraintSet with the above limitations) - directly address the above problems by having the Model compute the dependencies of unknown restraints on the fly and adding a mixed evaluation mode to restraints which do some of both incremental and non-incremental. This might complicate all restraints a bit and I worry that we would run into other problems later. Not too sure of all of the implications of this route. Thoughts?

4 4

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

IMP-dev January 2010