IMP-dev

imp-dev@salilab.org

869 discussions

Samplers concept
by Daniel Russel 06 Jan '10

06 Jan '10

We count use a sampler-level concept. The idea is to provide something higher level that takes a Model and produces a set of good scoring models for analysis. Examples would include: - Domino - a MC/CG scheme for optimizing sets of spheres (a premature version is in helpers) Currently we have StructureSet which has the needed functionality and Domino which has some of it too. I propose I add a base class to kernel which provides a sample method which returns a structure set and provides support for the types of filtering that is currently in StructureSet (eg only keep solutions with low scores and where restraint r is < 10). This would also require moving StructureSet to the kernel. Something like: class Sampler { Sampler(Model *m); // find structures to fill virtual StructureSet* sample(); // filtering methods moved from structure set protected: // adds the model to the set if it satisfies the filters void add_model(); }; Adding the base class provides a place to put documentation for this level of interaction. It also would mean that Domino and the MC/CG protocols would automatically benefit from improvements in filtering and things as well as have more robust storage management (since handling changes to things other than optimized attributes can be tricky). Thoughts/Comments?

2 1

imp-dev meeting today at 1pm
by Daniel Russel 05 Jan '10

05 Jan '10

The email from before the holidays: Since we are trying to clean everything up for the release, I thought it might be good to have a meeting to get people's thoughts on - the IMP documentation: what needs improvement - coming up with a checklist set of standards for documentation to provide some a better starting point than "write some examples and fill in the doxygen docs" - what is a good balance between what I'll call "reference" documentation such as doxygen docs and general examples of using some component and "cookbook" examples which provide a solution to a scenario which is hopefully close to what the user wants (but, on the down side, tends to provide little information about how to solve other problems). Please think about how you use the IMP documentation and documentation of other libraries. What other libraries provide particularly good docs and what guidelines can we draw from those? What are cookbook examples that IMP should include? See you tomorrow.

1 0

quick Q about atom/data/top.lib
by Keren Lasker 02 Jan '10

02 Jan '10

hi, running IMP on a mac. trying to use add_radius , which requires reading force field parameters. however, IMP keeps compiling that it can not file top.lib. can someone please help ( guessing it has to do something with paths / install ) ? thanks, keren,

2 10

simple transformation test fails
by Keren Lasker 23 Dec '09

23 Dec '09

hey, can someone please help me figuring out what is the problem with the attached test. I am keep getting an error: UsageException: Attempt to use uninitialized vector. The error seem to come from VectorD, but I really think that all vector are initialized. If I initialize Rotation3D from 4 number everything is ok. ?? thanks keren.

2 1

Make ScoreStates more comprehensible
by Daniel Russel 15 Dec '09

15 Dec '09

A number of people have found score states confusing both because the name doesn't really suggest much useful as well as because it is not obvious that they are the place to look if you want to implement a constraint. To address this several of us came up with a few proposed changes: - rename ScoreState to ModelState. This rename would make the names consistent with OptimizerStates (XStates maintain state associated with X) and get rid of the idea that they have something direct to do with scoring. It also could be done trivially in all user code that uses ScoreStates via "sed -i.old 's#ScoreState#ModelState#g' **/*.h **/*.cpp **/*.py". - Create a new base class Constraint which inherits from ModelState. The new base class wouldn't (necessarily) add any functionality, but it would provide a place in the documentation to discuss "constraints" as defined by the Sali lab and label ModelStates that are constraints as such. We would have to decided whether to rename existing XScoreStates which are constraints to XConstraint. These renames should, I think, be accomplishable through sed and hence not too painful. - Continue with hiding ModelStates from the basic user experience. Currently, one should not have to know what they are and what they do unless you are implementing code for IMP. The documentation doesn't reflect this yet (as it was not originally the case). I'll work to further mark them as advanced. Comments? Thoughts? Opposition?

1 0

imp-dev meeting Tuesday at 1pm
by Daniel Russel 14 Dec '09

14 Dec '09

Since we are trying to clean everything up for the release, I thought it might be good to have a meeting to get people's thoughts on - the IMP documentation: what needs improvement - coming up with a checklist set of standards for documentation to provide some a better starting point than "write some examples and fill in the doxygen docs" - what is a good balance between what I'll call "reference" documentation such as doxygen docs and general examples of using some component and "cookbook" examples which provide a solution to a scenario which is hopefully close to what the user wants (but, on the down side, tends to provide little information about how to solve other problems). Please think about how you use the IMP documentation and documentation of other libraries. What other libraries provide particularly good docs and what guidelines can we draw from those? What are cookbook examples that IMP should include? See you tomorrow.

1 0

particlepair::first
by Daniel Russel 11 Dec '09

11 Dec '09

Is anyone in the habit of using first and second (as opposed to [0] and [1]) to access members of particle pairs?

1 0

Stubborn IMP with boost
by Javier Ángel Velázquez Muriel 02 Dec '09

02 Dec '09

Hi, I am receiving this error for the first time after just updating: Checking for Boost version >= 1.33... Boost version >= 1.33 is required to build IMP, but it could not be found on your system. Please see config.log for more details. In particular, if you have Boost installed in a non-standard location, please use the 'includepath' option to add this location to the search path. For example, a Mac using Boost installed with MacPorts will have the Boost headers in /opt/local/include, so edit (or create) config.py and add the line includepath='/opt/local/include' I'm trying to include it directly with this line in config.py, but no luck: includepath='/usr/include/boost' Help! ;)

2 5

Last week in IMP
by Daniel Russel 30 Nov '09

30 Nov '09

- imp.xcodeproj was moved into tools and updated accordingly - the bin directory finally went away - IMP::display::ChimeraWriter now supports the latest version of Chimera - IMP::display::CGOWriter was renamed to IMP::display::PymolWriter as it can do more than just CGO. - IMP::VectorOfRefCounted::operator[] can now be used for assignments just like a normal vector. No more need to use the IMP::VectorOfRefCounted::set() method. - the IMP::atom::Hierarchy constructor from an IMP::Particle* is now explicit (as were the ther decorator constructors)

1 0

No imp-dev meeting today
by Daniel Russel 10 Nov '09

10 Nov '09

Too many people away/busy and nothing too pressing. Sorry about the late notice. But everyone please make sure that they are progressing towards the various deadlines. Upcoming ones include: DOPE Examples and docs for IMP.domino Examples and docs for IMP.saxs Nup84-based example Multifit Addition of gmm code and cleanup of existing code to IMP.statistics A figure comparing rep and data for 26S and Nup84 Text on 26S ring ordering. Keren will resume with Domino next week. --Daniel

1 0

← Newer
1
...
33
34
35
36
37
38
39
...
87
Older →

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

IMP-dev