how can you retrieve the atom index from AtomDecorator ?
It is not currently stored since the atom indices are not meaningful and would have to be recomputed each time you add or remove an atom from the model.
On Feb 2, 2009, at 12:41 AM, Keren Lasker wrote:
> > _______________________________________________ > IMP-dev mailing list > IMP-dev@salilab.org > https://salilab.org/mailman/listinfo/imp-dev
I see your point, but when you write a pdb file after reading it - sometime you want to keep the same atom indexes for analysis - can it be an option when reading a pdb file to store the indexes as well ? ( like in modeller) On Feb 2, 2009, at 1:21 AM, Daniel Russel wrote:
> It is not currently stored since the atom indices are not meaningful > and would have to be recomputed each time you add or remove an atom > from the model. > > On Feb 2, 2009, at 12:41 AM, Keren Lasker wrote: > >> >> _______________________________________________ >> IMP-dev mailing list >> IMP-dev@salilab.org >> https://salilab.org/mailman/listinfo/imp-dev > > _______________________________________________ > IMP-dev mailing list > IMP-dev@salilab.org > https://salilab.org/mailman/listinfo/imp-dev
On Feb 2, 2009, at 1:23 AM, Keren Lasker wrote:
> I see your point, but when you write a pdb file after reading it - > sometime you want to keep the same atom indexes for analysis - can > it be an option when reading a pdb file to store the indexes as > well ? ( like in modeller) Easy enough to add although it might be good enough to ensure that the hierarchy is traversed for writing in the same order in which it is read from the file.
Then the numbers will be the same and you don't have the issue of what to do with invalid indexes.
> > On Feb 2, 2009, at 1:21 AM, Daniel Russel wrote: > >> It is not currently stored since the atom indices are not >> meaningful and would have to be recomputed each time you add or >> remove an atom from the model. >> >> On Feb 2, 2009, at 12:41 AM, Keren Lasker wrote: >> >>> >>> _______________________________________________ >>> IMP-dev mailing list >>> IMP-dev@salilab.org >>> https://salilab.org/mailman/listinfo/imp-dev >> >> _______________________________________________ >> IMP-dev mailing list >> IMP-dev@salilab.org >> https://salilab.org/mailman/listinfo/imp-dev > > _______________________________________________ > IMP-dev mailing list > IMP-dev@salilab.org > https://salilab.org/mailman/listinfo/imp-dev
On Feb 2, 2009, at 1:39 AM, Daniel Russel wrote:
> > On Feb 2, 2009, at 1:23 AM, Keren Lasker wrote: > >> I see your point, but when you write a pdb file after reading it - >> sometime you want to keep the same atom indexes for analysis - can >> it be an option when reading a pdb file to store the indexes as >> well ? ( like in modeller) > Easy enough to add although it might be good enough to ensure that > the hierarchy is traversed for writing in the same order in which it > is read from the file. > > Then the numbers will be the same and you don't have the issue of > what to do with invalid indexes. This is true if you do not read two pdbs separately to the same model and ask for the indexes of the second one. > > >> >> On Feb 2, 2009, at 1:21 AM, Daniel Russel wrote: >> >>> It is not currently stored since the atom indices are not >>> meaningful and would have to be recomputed each time you add or >>> remove an atom from the model. >>> >>> On Feb 2, 2009, at 12:41 AM, Keren Lasker wrote: >>> >>>> >>>> _______________________________________________ >>>> IMP-dev mailing list >>>> IMP-dev@salilab.org >>>> https://salilab.org/mailman/listinfo/imp-dev >>> >>> _______________________________________________ >>> IMP-dev mailing list >>> IMP-dev@salilab.org >>> https://salilab.org/mailman/listinfo/imp-dev >> >> _______________________________________________ >> IMP-dev mailing list >> IMP-dev@salilab.org >> https://salilab.org/mailman/listinfo/imp-dev > > _______________________________________________ > IMP-dev mailing list > IMP-dev@salilab.org > https://salilab.org/mailman/listinfo/imp-dev
On Feb 2, 2009, at 1:40 AM, Keren Lasker wrote:
> > On Feb 2, 2009, at 1:39 AM, Daniel Russel wrote: > >> >> On Feb 2, 2009, at 1:23 AM, Keren Lasker wrote: >> >>> I see your point, but when you write a pdb file after reading it - >>> sometime you want to keep the same atom indexes for analysis - can >>> it be an option when reading a pdb file to store the indexes as >>> well ? ( like in modeller) >> Easy enough to add although it might be good enough to ensure that >> the hierarchy is traversed for writing in the same order in which >> it is read from the file. >> >> Then the numbers will be the same and you don't have the issue of >> what to do with invalid indexes. > This is true if you do not read two pdbs separately to the same > model and ask for the indexes of the second one. True, but this will get screwed up on writing anyway as all the atoms need to have distinct ids in the written pdb. Or am I misunderstanding your scenario?
I guess I would propose having a "source_pdb_index" attribute (or something similar) in atoms, but that it always gets ignored on writing (since either it is already correct, in which case you might as well ignore it, or it is incorrect, in which case you have to ignore it).
On Feb 2, 2009, at 1:43 AM, Daniel Russel wrote:
> > On Feb 2, 2009, at 1:40 AM, Keren Lasker wrote: > >> >> On Feb 2, 2009, at 1:39 AM, Daniel Russel wrote: >> >>> >>> On Feb 2, 2009, at 1:23 AM, Keren Lasker wrote: >>> >>>> I see your point, but when you write a pdb file after reading it >>>> - sometime you want to keep the same atom indexes for analysis - >>>> can it be an option when reading a pdb file to store the indexes >>>> as well ? ( like in modeller) >>> Easy enough to add although it might be good enough to ensure that >>> the hierarchy is traversed for writing in the same order in which >>> it is read from the file. >>> >>> Then the numbers will be the same and you don't have the issue of >>> what to do with invalid indexes. >> This is true if you do not read two pdbs separately to the same >> model and ask for the indexes of the second one. > True, but this will get screwed up on writing anyway as all the > atoms need to have distinct ids in the written pdb. Or am I > misunderstanding your scenario? yes - I was thinking of writing only mol2, by giving the Particle that represents mol2 ( regardless to mol1) - so the ids should be ok. > > > I guess I would propose having a "source_pdb_index" attribute (or > something similar) in atoms, but that it always gets ignored on > writing (since either it is already correct, in which case you might > as well ignore it, or it is incorrect, in which case you have to > ignore it). would be useful for the scenario above I think. > _______________________________________________ > IMP-dev mailing list > IMP-dev@salilab.org > https://salilab.org/mailman/listinfo/imp-dev
>>> >> True, but this will get screwed up on writing anyway as all the >> atoms need to have distinct ids in the written pdb. Or am I >> misunderstanding your scenario? > yes - I was thinking of writing only mol2, by giving the Particle > that represents mol2 ( regardless to mol1) - so the ids should be ok. >> >> >> I guess I would propose having a "source_pdb_index" attribute (or >> something similar) in atoms, but that it always gets ignored on >> writing (since either it is already correct, in which case you >> might as well ignore it, or it is incorrect, in which case you have >> to ignore it). > would be useful for the scenario above I think SVN now contains a version which does this (AtomDecorator::get_input_index()). Not really tested (other than it compiles and the tests pass).
Hi, I got a following error message, when I try to use a double precision. (I'm using "typedef double Float;" in base_types.h)
modules/core/src/internal/ParticleGrid.cpp: In member function 'void IMP::core::internal::ParticleGrid::build_grid(const IMP::Particles&)': modules/core/src/internal/ParticleGrid.cpp:57: error: ISO C++ says that these are ambiguous, even though the worst conversion for the first is better than the worst conversion for the second: /usr/include/architecture/i386/math.h:352: note: candidate 1: double pow(double, double) /usr/include/c++/4.0.0/cmath:344: note: candidate 2: float std::pow(float, float) scons: *** [modules/core/src/internal/ParticleGrid.os] Error 1 build/include/IMP/SingletonContainer.h:59: Warning(473): Returning a pointer or reference in a director method is not recommended.
Could you take a look at it?
participants (3)
-
Daniel Russel -
Keren Lasker -
Seung Joong Kim