- IMP-dev - salilab.org

Re: [IMP-dev] Towards the IMP release
by Daniel Russel 09 Apr '09

09 Apr '09

On Apr 9, 2009, at 10:41 AM, Ben Webb wrote: > Dina Schneidman wrote: >> regarding "complicated projects", I think what we mean is having a >> "black box" program or a script, that can be used by any user. >> The input data should come from the user. We can have some sample >> input data as an example. >> I have a couple of programs for saxs data and we should put there >> more >> for other data types. >> it could be nice to combine them. I think for this purpose we should >> have some common >> mechanism for reading user input parameters. > > Sounds reasonable, although we should be careful to avoid too many > special-purpose applications - the principal aim of IMP after all is > to > allow things to be easily mixed and matched. I think the key thing here is that the applications be made from IMP components and the code in the applications only do things like selecting the correct restraints and optimization protocols and managing data. Then they can both be useful and show off the rest of the IMP code.

1 0

Re: [IMP-dev] Towards the IMP release
by Daniel Russel 08 Apr '09

08 Apr '09

2009/4/8 Ben Webb <ben(a)salilab.org>: > That sounds reasonable to me, although I guess it depends on what you > mean by a "complicated project" and how much data that project might > have. For example, our experience with the 26S has certainly been that > experimental data lives elsewhere (typically it has rather a rather > different distribution, and if nothing else, it's big). I only have a vague idea what I meant by it :-) We have had the general idea floating around all along of having some code that takes a certain restricted set of data is some nice human-readable file format (csv or yaml or something simple) or standard experimental data types (pdb, em maps etc) and produces structures without someone having mess about with more complicated things like python code, restraints, particles, or xml. That was the sort of the thing I meant. The only data in svn would be sample data.

1 0

This week in IMP
by Daniel Russel 27 Mar '09

27 Mar '09

- create_* functions (helper functions for rigid bodies and covers) now require you to add the score state to the model yourself. Whether the rigid body is enforced or not can be controlled by adding or removing the returned score state. - All previously deprecated code has been removed. Removed functionality includes indexes in particles, the no-argument constructor for particles and the functionality that was moved from core to atom. - The rigid body decorators have been simplified by removing the traits classes. There is now only one type of rigid body and it stores the list of member particles internally. - NameDecorator has been deprecated as Particles have built in names. - a ChainDecorator added to IMP.atom to store the chain id

1 0

Problem when reading a Spider EM map in Python
by Javier Ángel Velázquez Muriel 27 Mar '09

27 Mar '09

Hi everybody. I've written a class to read and write EM maps in Spider format in IMP. Runs perfect in C++ when combined with DensityMap and MRCReaderWriter from EMbed: #include "IMP/em/SpiderReaderWriter.h" #include "DensityMap.h" #include "MRCReaderWriter.h" int main() { // Constructor IMP::em::SpiderMapReaderWriter rw("media_mon_iter3.xmp",false,false,true); MRCReaderWriter rw2; DensityMap m; m.Read("media_mon_iter3.xmp",rw); m.Write("test.xmp",rw); m.Write("test.mrc",rw2); } When wrapped in Python, after modifying modules/em/pyext/em.i with this: %import "MapReaderWriter.h" %include "IMP/em/SpiderReaderWriter.h" And trying to do exactly the same thing: def test_em_maps(self): """Check volume reading and writing""" rw1=em.SpiderMapReaderWriter("media_mon_iter3.xmp",False,False,True) rw2=EM.MRCReaderWriter() m=EM.DensityMap() m.Read("media_mon_iter3.xmp",rw1) m.Write("test.mrc",rw2) m.Write("test.xmp",rw1) I obtain this error: ====================================================================== ERROR: Check volume reading and writing ---------------------------------------------------------------------- Traceback (most recent call last): File "test_volumes_and_images.py", line 74, in test_em_maps m.Read("media_mon_iter3.xmp",rw1) File "/diva1/home/modeller/SVN/modlib/EM.py", line 698, in Read def Read(*args): return _EM.DensityMap_Read(*args) TypeError: in method 'DensityMap_Read', argument 3 of type 'MapReaderWriter &' ---------------------------------------------------------------------- Seems that SWIG is not wrapping properly MapReaderWriter or is getting confused by passing a IMP object like SpiderMapReaderWriter to the EMbed class DensityMap. Any help? Thanks

2 1

Be very careful with floating point numbers
by Daniel Russel 27 Mar '09

27 Mar '09

Since it keeps coming up, I'll say again, never depend on floating point equality checks (or transitivity). As an example, I just ran into a problem with domino caused by C++ code which looked like: float min=big_number; loop over things: if (thing.get_value() < min) min= thing.get_value() loop over things again: if (thing.get_value() == min) return thing; Code like this can fail if: - the type of thing.get_value() is not exactly the same as the type of min - or thing.get_value() performs some computations and the compiler decides to inline them - or for whatever other reason, thing.get_value() is never written to main memory The reason is that on intel chips, floating point values are stored as 32 bit, 64 bit or 80 bit values depending on what the compiler feels like doing. They are only truncated into the specified 32 bit (float) or 64 bit (double) values when stored as the appropriate value type in cache or memory or when copied to a different type of register. If one copy of a value is truncated to a 32 bits or 64 bits by being moved, then it is no longer equal to its old value. In this case the fix is trivial: just combine the two loops and keep track of the min element as you go along. Other times you will have to jump through more hoops.

2 2

Necessity of comprehensive documentation
by Javier Ángel Velázquez Muriel 26 Mar '09

26 Mar '09

Hi everybody, This days, as I use more and more the IMP API documentation and get more familiar with it, I feel that is extremely simple, rather useless if you don't know about the class you're using and the internal mechanisms, or somebody introduce you to it. Probably it also applies to my small contributions to the package, but I would like to raise my hand as one that would enjoy some effort (and I am willing to take the advice too) from the rest of the developers when documenting. Thanks Javi

3 3

minor but important API change
by Daniel Russel 25 Mar '09

25 Mar '09

The create_* helper functions (such as those for rigid body) now do not add the score state to the model, you must do it yourself. The ScoreState will warn you (a bit cryptically) if it is not added to a model before it is destroyed. Note that it is possible to miss the message if you use C++ and never destroy the object, I'll figure out a way to warn in this case too.

1 0

Wrapping of the use of read_pdb in EM module
by Javier Ángel Velázquez Muriel 25 Mar '09

25 Mar '09

Hi, In addition to my previous mail, now I'm trying to read a PDB inside a simple test program in the em module. It is called prueba.h (attached file). When I prepare the file modules/em/pyext/em.i (attached) to deal with prueba.h, surprisingly, I obtain this error from python: ImportError: /chime1/home/javi/imp/trunk/build/lib/_IMP_em.so: undefined symbol: _ZTVN3IMP4atom8SelectorE Shouldn't this atom::Selector be wrapped, as I add these lines to the em.i file ? #include "IMP/core.h" #include "IMP/atom.h" %import "modules/core/pyext/core.i" %import "modules/atom/pyext/atom.i" Thanks

2 1

endian treatment in algebra module
by Javier Ángel Velázquez Muriel 24 Mar '09

24 Mar '09

Hi everybody I've moved the files dealing with endian treatment from EM module to algebra, as I needed MultiArrray to read and write taking into account that. Admittedly, it is probably not the proper module. Perhaps kernel or core should contain endian.h and endian.cpp. Thanks

2 1

This week in IMP
by Daniel Russel 20 Mar '09

20 Mar '09

Changes this week: * A new writer, ChimeraWriter has been added which exports geometry to native Chimera constructs. It probably should be used instead of bild and cmm for most purposes as it combines the best of both types. * compose for transformation is now a free function so compose(rotation, vector) will work. * the geometry classes have been cleaned up and are now more consistent with IMP standards (and more likely to do what their names/comments suggest) * ParticleRefiner has been renamed to Refiner since the Particle was long and unnecessary.

1 0