Menu
▾
▴
btk-developers — Developer planning list.
You can subscribe to this list here.
| 2002 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
(49) |
Jul
(60) |
Aug
(2) |
Sep
(2) |
Oct
(2) |
Nov
(8) |
Dec
|
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2003 |
Jan
|
Feb
(2) |
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Tim R. <timr@u.washington.edu> - 2003-02-20 03:01:32
|
neat! i've been working on weekends toward a fully-strategized polymer class (see MONOMER_POLYMER branch). parsing one of these would be a good strategy idea. -tim Eric Alm wrote: > Forget CHARMm and AMBER - these crystallography guys know how to make things > striaghtforward and easy to use! > > http://cns.csb.yale.edu/v1.0/tutorial/text.html > > Now who's going to parse these into the Molecule class... don't all volunteer > at once. > > -E > > > > ------------------------------------------------------- > This SF.net email is sponsored by: SlickEdit Inc. Develop an edge. > The most comprehensive and flexible code editor you can use. > Code faster. C/C++, C#, Java, HTML, XML, many more. FREE 30-Day Trial. > www.slickedit.com/sourceforge > _______________________________________________ > Btk-developers mailing list > Btk...@li... > https://lists.sourceforge.net/lists/listinfo/btk-developers |
|
From: Eric A. <ej...@lb...> - 2003-02-20 02:52:49
|
Forget CHARMm and AMBER - these crystallography guys know how to make things striaghtforward and easy to use! http://cns.csb.yale.edu/v1.0/tutorial/text.html Now who's going to parse these into the Molecule class... don't all volunteer at once. -E |
|
From: Chris S. <ctsa@u.washington.edu> - 2002-11-13 22:04:24
|
Guys,
Just wanted to put you on notice that I'm getting ready to check in some
major rearrangements in peptide as well as btk-wide atom storage, you'll
want to stay away from this stuff for a little bit if you can. Since sf
cvs is broken right now, I'll go ahead and give you the brief explanation
and the issues that have come up before I tag and ci.
The current atom storage system relies on an atom's type (topological
type, CB, CG, etc.) being determined by its place in the atom array of
each residue. I've changed atoms so that they store their own type and
only get thrown into the central atom array if you actually want them
there. This has lots of upside:
-Missing atoms can actually be missing
-Centroid mode works again w/o lots of hackery
-adding termini becomes trivial (I already threw on the N H's)
-tautomer states and water rotamers should be easier to code in.
-the default iterators for proteins and residues shouldn't require any
if's (assuming we assert that everything has built)
-Most important: all the peptide types can dissolve back into one peptide
(still as a monomer template) with very few if's thrown into the code, and
the user could recover the old modes something like this : (this is only
one possible design for the library interface)
//allh
Protein p("foo.pdb")
p.add_all_missing();
//basic
Protein p("foo.pdb")
p.remove_h();
p.add_all_heavy_missing();
//centroid
Protein p("foo.pdb")
p.remove_h();
p.remove_sidechains();
p.add_centroids();
Note that any of these type of functions could iterate over
monomer_begin() and monomer_end(), to customize the detail throughout
a large protein if desired.
The major downside is that I've trashed some of the pointer safety and
hidden implementations. specifically:
-The primary atom array is now a vector of pointers to atoms, this means
that all atom iterator functions require an ugly double deref,
and some safety issues come up. I'm using the pointers right now to be
able to look up atoms by type from the residue structure, and I was
planing to link them to the nodes of the topology graph later on.
Hopefuly these can be implemented in a cleaner way once more eyes look
at the code.
-Tetrad is back in atom, polluting the user interface. There are a couple
known ways to solve this problem.
-The details of this change are still being worked on and other major
architectural changes are required (monomer-polymer, the topology graph),
so I haven't spent a lot of time plinking on details, like
destructors, or fixing the torsion angle controls, which will be fixed
with the graph change.
I'll try to check in soon, If you guys know what's up with cvs right now,
lemme know.
-c
|
|
From: Tim R. <timr@u.washington.edu> - 2002-11-12 23:15:19
|
hi, between chris and myself, the makefiles have been changed pretty substantially in the past few days. in particular, now there are proper debug and optimized targets, and there is a makefile in the tests directory. the new targets in the top-level makefile are: opt -- (default) makes everything, including apps and tests, in fully-optimized mode debug -- makes everything in debug mode. lib -- make just the btk library, in fully-optimized mode debug_lib -- make just the btk library in debug mode clean -- removes .o files and library files realclean -- removes .o files, library files, core files and emacs temporary (*~) files. depending on how you make, you'll get different targets. libbtk.a is the optimized library, and libbtk_debug.a is the debug library. likewise, there are *_debug versions of the apps and tests. dependencies are managed sanely, as before, but with different dependencies for the different build modes (i.e., debug applications will only depend on libbtk_debug.o). As before, you can always build an individual application in apps or tests by doing make <appname> or make <appname_debug>, where <appname> is the name of the target (e.g. rmsd). finally, i moved test_main.cpp from the btk directory to tests/test_protein.cpp. this location is more appropriate, and i think the name better reflects what the program actually does (namely, testing the protein class). -tim |
|
From: Tim R. <timr@u.washington.edu> - 2002-11-08 00:57:36
|
Hi, I've integrated the Boost::uBLAS library into the BTK, and eliminated the homemade BTKVector and BTK*Matrix classes. To make things easier, I've checked in the version of Boost I used, and that I know works with the BTK. To get this, do a: cvs -z3 co boost before you do the usual cvs co btk routine. It's rather large, so you're going to want to be on a fast connection when you do this. Right now, the Makefiles have a BOOST_DIR variable that is set to look for Boost one directory above the btk directory. If you put Boost somewhere else, be sure to change this variable to reflect the correct locations. Otherwise, make should Just Work. -tim |
|
From: Tim R. <timr@u.washington.edu> - 2002-11-02 12:00:48
|
Hi, Just to let you all know: I'm creating a UBLAS_INTEGRATION branch for integrating uBLAS into the BTK. Thus, you can just keep working on the main branch in the meantime. Nothing should change for you. I'll join everything together once I get uBLAS working. -tim |
|
From: Tim R. <timr@u.washington.edu> - 2002-11-02 10:38:04
|
Hi, I'm sending this to the list because I'm proposing a "big" change, but it's a change that you'll have to work very hard to persuade me not to do. Remember that I wrote BTKMatrix to create something more comprehensive for use in the BTK, and to avoid committing to any particular linear algebra library implementation. At the time, this was because the various C++ linear algebra packages seemed risky for one reason or another. While some (e.g. Blitz++, MTL) provided very high performance, they worried me because the didn't seem well-maintained, or, in the case of MTL, just seemed ugly as sin. In other words, I liked them technically, but I worried about committing to them, only to find them unsupported down the road. Well, that's all over. Perhaps you're familiar with the Boost libraries. If not, let me introduce you. Go to: http://www.boost.org and take a look at all of the really excellent things provided by the package. Since Boost is a proving/stabilization ground for commonly-used C++ concepts that haven't yet made it into the standard library, it is extremely well-maintained, and provides all sorts of C++ goodness that would otherwise take a long time to write yourself. Boost is great. It's popular, it's well-known, reasonably well-supported, and it's free. Some of the very best C++ programmers in the world are contributing to it, and as far as I can tell, it's the closest thing you're going to find to "official" extensions of the C++ standard library. Now, more to the point, I just discovered this evening that a package named uBLAS has been added to Boost, and as you might guess from the name, uBLAS provides a good portion of BLAS (levels 1-3, to be exact). However, uBLAS does it in C++, using operator overloading so that the code is readable, and template metaprogramming to make it efficient. In short, it's everything we need in a linear algebra package: it's readable, it's efficient, it's (relatively) standard, and it's well-maintained. Go look at the documentation for it: http://www.boost.org/libs/numeric/ublas/doc/index.htm Especially interesting is the benchmark stuff at the bottom of this page: http://www.boost.org/libs/numeric/ublas/doc/overview.htm which shows that uBLAS is pretty darned fast. Probably as fast as we'll ever need. That said, there's one drawback: if we use it, we create an external dependency -- the first for the BTK. We'll have to tell people to go download some other package in order to use the BTK, and that could be annoying. However, if I had to pick an external package to require, Boost would be it. It's got so many great things in it that it's extremely multipurpose, and as I said before, it's popular and well-maintained. You couldn't ask for more. So there you go. My argument for dumping our home-brewed matrix code, and using something better. Like I said, if one of you has an objection, I'd be happy to hear it, but in the meantime I'm going to start the migration. Since I don't have to write anything new, I don't think it should take long. -tim |
|
From: Tim R. <timr@u.washington.edu> - 2002-11-01 22:13:44
|
By "cosmetic," I mean that the changes make output vectors, points and matrices more readable. -tim Tim Robertson wrote: > Hrmph. My fault. > > I changed the btk_vector output code to be more readable. Apparently I > used a bit of C++ that's *too* standard for g++ 2.96 (it compiles fine > with g++ 3). > > I'll look into it. In the meantime, just comment out the offending > lines in btk_vector's ostream operator. The differences are cosmetic. > > -tim > > Chris Saunders wrote: > >> Y'all, >> g++ 2.96 gives all the junk I pasted below. I briefly tried to debug but >> figured anyone who made recent changes can spot the problem much faster. >> >> -c >> >> ---------------------------------------------------------------------- >> SYSTEM SETUP >> CXX=g++ @ tao [i686] >> CXXFLAGS=-g -g -Wall -Wno-sign-compare -DVERBOSE >> BTKLIB=libbtk.a >> ---------------------------------------------------------------------- >> g++ -g -g -Wall -Wno-sign-compare -DVERBOSE -c -o .pdb_reader.o >> pdb_reader.cpp >> In file included from linear_algebra.h:33, >> from atoms.h:27, >> from pdb_reader.h:51, >> from pdb_reader.cpp:23: >> btk_vector.h: In function `ostream &BTK::operator<< (ostream &, const >> BTK::BTKPoint &)': >> btk_vector.h:58: `::ios_base' undeclared (first use here) >> btk_vector.h:58: parse error before `::' >> btk_vector.h:62: `::scientific' undeclared (first use here) >> btk_vector.h:62: `::left' undeclared (first use here) >> btk_vector.h:68: `old_streamopts' undeclared (first use this function) >> btk_vector.h:68: (Each undeclared identifier is reported only once for >> each function it appears in.) >> btk_vector.h: In function `ostream &BTK::operator<< (ostream &, const >> BTKVector &)': >> btk_vector.h:118: parse error before `::' >> make: *** [.pdb_reader.o] Error 1 >> >> >> >> >> ------------------------------------------------------- >> This sf.net email is sponsored by: See the NEW Palm Tungsten T >> handheld. Power & Color in a compact size! >> http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0001en >> _______________________________________________ >> Btk-developers mailing list >> Btk...@li... >> https://lists.sourceforge.net/lists/listinfo/btk-developers > > > > > > ------------------------------------------------------- > This sf.net email is sponsored by: See the NEW Palm Tungsten T handheld. > Power & Color in a compact size! > http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0001en > _______________________________________________ > Btk-developers mailing list > Btk...@li... > https://lists.sourceforge.net/lists/listinfo/btk-developers |
|
From: Tim R. <timr@u.washington.edu> - 2002-11-01 21:44:50
|
Hrmph. My fault. I changed the btk_vector output code to be more readable. Apparently I used a bit of C++ that's *too* standard for g++ 2.96 (it compiles fine with g++ 3). I'll look into it. In the meantime, just comment out the offending lines in btk_vector's ostream operator. The differences are cosmetic. -tim Chris Saunders wrote: > Y'all, > g++ 2.96 gives all the junk I pasted below. I briefly tried to debug but > figured anyone who made recent changes can spot the problem much faster. > > -c > > ---------------------------------------------------------------------- > SYSTEM SETUP > CXX=g++ @ tao [i686] > CXXFLAGS=-g -g -Wall -Wno-sign-compare -DVERBOSE > BTKLIB=libbtk.a > ---------------------------------------------------------------------- > g++ -g -g -Wall -Wno-sign-compare -DVERBOSE -c -o .pdb_reader.o > pdb_reader.cpp > In file included from linear_algebra.h:33, > from atoms.h:27, > from pdb_reader.h:51, > from pdb_reader.cpp:23: > btk_vector.h: In function `ostream &BTK::operator<< (ostream &, const > BTK::BTKPoint &)': > btk_vector.h:58: `::ios_base' undeclared (first use here) > btk_vector.h:58: parse error before `::' > btk_vector.h:62: `::scientific' undeclared (first use here) > btk_vector.h:62: `::left' undeclared (first use here) > btk_vector.h:68: `old_streamopts' undeclared (first use this function) > btk_vector.h:68: (Each undeclared identifier is reported only once for > each function it appears in.) > btk_vector.h: In function `ostream &BTK::operator<< (ostream &, const > BTKVector &)': > btk_vector.h:118: parse error before `::' > make: *** [.pdb_reader.o] Error 1 > > > > > ------------------------------------------------------- > This sf.net email is sponsored by: See the NEW Palm > Tungsten T handheld. Power & Color in a compact size! > http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0001en > _______________________________________________ > Btk-developers mailing list > Btk...@li... > https://lists.sourceforge.net/lists/listinfo/btk-developers |
|
From: Chris S. <ctsa@u.washington.edu> - 2002-11-01 19:35:34
|
Y'all,
g++ 2.96 gives all the junk I pasted below. I briefly tried to debug but
figured anyone who made recent changes can spot the problem much faster.
-c
----------------------------------------------------------------------
SYSTEM SETUP
CXX=g++ @ tao [i686]
CXXFLAGS=-g -g -Wall -Wno-sign-compare -DVERBOSE
BTKLIB=libbtk.a
----------------------------------------------------------------------
g++ -g -g -Wall -Wno-sign-compare -DVERBOSE -c -o .pdb_reader.o
pdb_reader.cpp
In file included from linear_algebra.h:33,
from atoms.h:27,
from pdb_reader.h:51,
from pdb_reader.cpp:23:
btk_vector.h: In function `ostream &BTK::operator<< (ostream &, const
BTK::BTKPoint &)':
btk_vector.h:58: `::ios_base' undeclared (first use here)
btk_vector.h:58: parse error before `::'
btk_vector.h:62: `::scientific' undeclared (first use here)
btk_vector.h:62: `::left' undeclared (first use here)
btk_vector.h:68: `old_streamopts' undeclared (first use this function)
btk_vector.h:68: (Each undeclared identifier is reported only once for
each function it appears in.)
btk_vector.h: In function `ostream &BTK::operator<< (ostream &, const
BTKVector &)':
btk_vector.h:118: parse error before `::'
make: *** [.pdb_reader.o] Error 1
|
|
From: Tim R. <timr@u.washington.edu> - 2002-10-23 22:17:06
|
Did you try removing the -o from the preprocessing command? -tim Eric Alm wrote: > I recently upgraded to RH8.0 which includes gcc version 3.2, and the BTK no > longer compiles. The problem is that the preprocessing step to generate > dependency files creates a .*.o file with some phony output. Then the real > object file never gets made. > > As a workaround (shameful hack), I just added "rm .*.o" to the end of the > preprocessing command, like this: > > g++ -M -o .area.o area.cpp > .area.d ; /bin/rm .*.o > > maybe someone has a better understanding of exactly what's going on. > > -E > > > ------------------------------------------------------- > This sf.net email is sponsored by: Influence the future > of Java(TM) technology. Join the Java Community > Process(SM) (JCP(SM)) program now. > http://ads.sourceforge.net/cgi-bin/redirect.pl?sunm0002en > > _______________________________________________ > Btk-developers mailing list > Btk...@li... > https://lists.sourceforge.net/lists/listinfo/btk-developers |
|
From: Eric A. <ej...@lb...> - 2002-10-23 21:25:21
|
I recently upgraded to RH8.0 which includes gcc version 3.2, and the BTK no longer compiles. The problem is that the preprocessing step to generate dependency files creates a .*.o file with some phony output. Then the real object file never gets made. As a workaround (shameful hack), I just added "rm .*.o" to the end of the preprocessing command, like this: g++ -M -o .area.o area.cpp > .area.d ; /bin/rm .*.o maybe someone has a better understanding of exactly what's going on. -E |
|
From: Tim R. <timr@u.washington.edu> - 2002-09-10 07:12:21
|
Hi, I added a tests directory to the btk. I think it would be wise to put all current/future code test drivers here, so that we have them in one place. Right now, I've added my test driver for the PredicateIterator class, but I haven't added a makefile yet. Maybe someday we'll even have some nifty automatic build-n-test perl script, too (assuming one of you writes it)! -tim |
|
From: Tim R. <timr@u.washington.edu> - 2002-09-10 06:12:18
|
Hi, This message is mainly for rich's benefit, but I thought that the rest of you might like to know, too. I renamed Peptide::atoms() to Peptide::atom(), and made it public. I also added a pair of operator[] to Peptide (const and non-const versions) which function the same way (they're nothing more than inline calls to atom()) -tim |
|
From: Tim R. <timr@u.washington.edu> - 2002-08-28 02:37:30
|
Uhh...if they're missing, it's an accident. Or a bug. That would be the only tricky part (chasing down the bug, that is). Should be easy to track down, though... Sort of related: Chris, could you add some comments to the tetrad parameter and build order tables (maybe just the first residue type or something) to tell which atoms correspond to which table elements? It always confuses me and takes me a few minutes to figure it out (mainly since I only look at the tables once in a while). -tim Eric Alm wrote: > Does anyone know when the centroid atoms stopped being built in > ProteinCentroids? Are there specific issues related to adding them back in? > > -E > > > ------------------------------------------------------- > This sf.net email is sponsored by: Jabber - The world's fastest growing > real-time communications platform! Don't just IM. Build it in! > http://www.jabber.com/osdn/xim > _______________________________________________ > Btk-developers mailing list > Btk...@li... > https://lists.sourceforge.net/lists/listinfo/btk-developers |
|
From: Eric A. <ej...@lb...> - 2002-08-28 01:04:10
|
Does anyone know when the centroid atoms stopped being built in ProteinCentroids? Are there specific issues related to adding them back in? -E |
|
From: <EJ...@lb...> - 2002-07-25 16:38:30
|
This sounds like a reasonable workaround. As long as we all agree never to use APPS. -E ----- Original Message ----- From: Timothy A Robertson <timr@u.washington.edu> Date: Wednesday, July 24, 2002 5:24 pm Subject: Re: [Btk-developers] dead folders > cvs update -P btk > > (-P = prune.) > > CVS sucks. This is the workaround for the dead directory problem. > As long as directories are empty, they won't be added when you do > an update. Same thing works for checkout, too, btw. > > Unfortunately, hacking the CVS archive is high-risk. There's a non- > zero chance that you'll trash the CVS tree, and then we'd have to > lose that context. Of course, if no one cares about that, we could > always do the *easiest* thing, and freeze the tree, backup the > current source code, wipe the sourceforge archive, and re-import > the code. > > -tim > > On Wed, 24 Jul 2002, Chris Saunders wrote: > > > you can blame we for those extra folders. I understand that > eliminating> any folder from a CVS tree is non-trivial. I'm sure > everyone agrees they > > should go, but how? > > > > On Wed, 24 Jul 2002 EJ...@lb... wrote: > > > > > Oh, in that case who cares about support for self-energies. If > the user wants it, > > > he/she can define it using some other rules like I mentioned > previously with > > > residue numbers. If they're really concerned about it, they > can download the > > > param files from some website, they have files for almost > anything you could > > > possibly imagine. > > > > > > On an unrelated note: > > > can we get rid of the APPS subdirectory? Apple OS X is case > preserving, but > > > case insensitive. This means when you check things out of CVS > it cant tell the > > > difference between apps and APPS, and everything gets chucked > into APPS. > > > Doesn't look like there's anything in there anyway. > > > > > > -E > > > > > > ----- Original Message ----- > > > From: Chris Saunders <ctsa@u.washington.edu> > > > Date: Wednesday, July 24, 2002 4:10 pm > > > Subject: Re: [Btk-developers] generic molecule self-energy > > > > > > > I think I see some confusion. Generic molecule exists to > define the > > > > operations that you can do without having to know or bother > with the > > > > molecule's topology. You can read any old thing in from a pdb, > > > > rotate it, > > > > write it back out etc.. When you say the generic molecule > energies> > > can be > > > > calculated "with a topology file", you aren't refering to the > generic> > > molecule class concept anymore, but the buildable > molecule concept. > > > > > > > > > > > > > > This might be tricky to implement. Unless, by > "undefined" you > > > > mean> > "energy function will spit out a value, but value > will be > > > > > > meaningless." > > > > > > Then it's not so hard. > > > > > > > > > > I think it's actually doable given a topology file, although > > > > either the Molecule > > > > > itself would have to carry extra topo info, or the e functions > > > > would need a topo > > > > > table passed in. The latter case is nice because it leaves > > > > things up to the user - > > > > > for example I might want to scale down interactions between > > > > backbone atoms of > > > > > adjacent residues which should work without any info about > topology.> > > > > > > > > > > > > > > > > > > > ------------------------------------------------------- > > > > This sf.net email is sponsored by: Jabber - The world's fastest > > > > growing > > > > real-time communications platform! Don't just IM. Build it in! > > > > http://www.jabber.com/osdn/xim > > > > _______________________________________________ > > > > Btk-developers mailing list > > > > Btk...@li... > > > > https://lists.sourceforge.net/lists/listinfo/btk-developers > > > > > > > > > > > > > > > > ------------------------------------------------------- > > > This sf.net email is sponsored by: Jabber - The world's fastest > growing> > real-time communications platform! Don't just IM. Build > it in! > > > http://www.jabber.com/osdn/xim > > > _______________________________________________ > > > Btk-developers mailing list > > > Btk...@li... > > > https://lists.sourceforge.net/lists/listinfo/btk-developers > > > > > > > > > > > ------------------------------------------------------- > > This sf.net email is sponsored by: Jabber - The world's fastest > growing > > real-time communications platform! Don't just IM. Build it in! > > http://www.jabber.com/osdn/xim > > _______________________________________________ > > Btk-developers mailing list > > Btk...@li... > > https://lists.sourceforge.net/lists/listinfo/btk-developers > > > > > > > ------------------------------------------------------- > This sf.net email is sponsored by: Jabber - The world's fastest > growing > real-time communications platform! Don't just IM. Build it in! > http://www.jabber.com/osdn/xim > _______________________________________________ > Btk-developers mailing list > Btk...@li... > https://lists.sourceforge.net/lists/listinfo/btk-developers > |
|
From: Timothy A R. <timr@u.washington.edu> - 2002-07-25 00:24:07
|
cvs update -P btk (-P = prune.) CVS sucks. This is the workaround for the dead directory problem. As long as directories are empty, they won't be added when you do an update. Same thing works for checkout, too, btw. Unfortunately, hacking the CVS archive is high-risk. There's a non-zero chance that you'll trash the CVS tree, and then we'd have to lose that context. Of course, if no one cares about that, we could always do the *easiest* thing, and freeze the tree, backup the current source code, wipe the sourceforge archive, and re-import the code. -tim On Wed, 24 Jul 2002, Chris Saunders wrote: > you can blame we for those extra folders. I understand that eliminating > any folder from a CVS tree is non-trivial. I'm sure everyone agrees they > should go, but how? > > On Wed, 24 Jul 2002 EJ...@lb... wrote: > > > Oh, in that case who cares about support for self-energies. If the user wants it, > > he/she can define it using some other rules like I mentioned previously with > > residue numbers. If they're really concerned about it, they can download the > > param files from some website, they have files for almost anything you could > > possibly imagine. > > > > On an unrelated note: > > can we get rid of the APPS subdirectory? Apple OS X is case preserving, but > > case insensitive. This means when you check things out of CVS it cant tell the > > difference between apps and APPS, and everything gets chucked into APPS. > > Doesn't look like there's anything in there anyway. > > > > -E > > > > ----- Original Message ----- > > From: Chris Saunders <ctsa@u.washington.edu> > > Date: Wednesday, July 24, 2002 4:10 pm > > Subject: Re: [Btk-developers] generic molecule self-energy > > > > > I think I see some confusion. Generic molecule exists to define the > > > operations that you can do without having to know or bother with the > > > molecule's topology. You can read any old thing in from a pdb, > > > rotate it, > > > write it back out etc.. When you say the generic molecule energies > > > can be > > > calculated "with a topology file", you aren't refering to the generic > > > molecule class concept anymore, but the buildable molecule concept. > > > > > > > > > > > This might be tricky to implement. Unless, by "undefined" you > > > mean> > "energy function will spit out a value, but value will be > > > > > meaningless." > > > > > Then it's not so hard. > > > > > > > > I think it's actually doable given a topology file, although > > > either the Molecule > > > > itself would have to carry extra topo info, or the e functions > > > would need a topo > > > > table passed in. The latter case is nice because it leaves > > > things up to the user - > > > > for example I might want to scale down interactions between > > > backbone atoms of > > > > adjacent residues which should work without any info about topology. > > > > > > > > > > > > > > > > ------------------------------------------------------- > > > This sf.net email is sponsored by: Jabber - The world's fastest > > > growing > > > real-time communications platform! Don't just IM. Build it in! > > > http://www.jabber.com/osdn/xim > > > _______________________________________________ > > > Btk-developers mailing list > > > Btk...@li... > > > https://lists.sourceforge.net/lists/listinfo/btk-developers > > > > > > > > > > > ------------------------------------------------------- > > This sf.net email is sponsored by: Jabber - The world's fastest growing > > real-time communications platform! Don't just IM. Build it in! > > http://www.jabber.com/osdn/xim > > _______________________________________________ > > Btk-developers mailing list > > Btk...@li... > > https://lists.sourceforge.net/lists/listinfo/btk-developers > > > > > > ------------------------------------------------------- > This sf.net email is sponsored by: Jabber - The world's fastest growing > real-time communications platform! Don't just IM. Build it in! > http://www.jabber.com/osdn/xim > _______________________________________________ > Btk-developers mailing list > Btk...@li... > https://lists.sourceforge.net/lists/listinfo/btk-developers > |
|
From: Chris S. <ctsa@u.washington.edu> - 2002-07-25 00:07:08
|
you can blame we for those extra folders. I understand that eliminating any folder from a CVS tree is non-trivial. I'm sure everyone agrees they should go, but how? On Wed, 24 Jul 2002 EJ...@lb... wrote: > Oh, in that case who cares about support for self-energies. If the user wants it, > he/she can define it using some other rules like I mentioned previously with > residue numbers. If they're really concerned about it, they can download the > param files from some website, they have files for almost anything you could > possibly imagine. > > On an unrelated note: > can we get rid of the APPS subdirectory? Apple OS X is case preserving, but > case insensitive. This means when you check things out of CVS it cant tell the > difference between apps and APPS, and everything gets chucked into APPS. > Doesn't look like there's anything in there anyway. > > -E > > ----- Original Message ----- > From: Chris Saunders <ctsa@u.washington.edu> > Date: Wednesday, July 24, 2002 4:10 pm > Subject: Re: [Btk-developers] generic molecule self-energy > > > I think I see some confusion. Generic molecule exists to define the > > operations that you can do without having to know or bother with the > > molecule's topology. You can read any old thing in from a pdb, > > rotate it, > > write it back out etc.. When you say the generic molecule energies > > can be > > calculated "with a topology file", you aren't refering to the generic > > molecule class concept anymore, but the buildable molecule concept. > > > > > > > > This might be tricky to implement. Unless, by "undefined" you > > mean> > "energy function will spit out a value, but value will be > > > > meaningless." > > > > Then it's not so hard. > > > > > > I think it's actually doable given a topology file, although > > either the Molecule > > > itself would have to carry extra topo info, or the e functions > > would need a topo > > > table passed in. The latter case is nice because it leaves > > things up to the user - > > > for example I might want to scale down interactions between > > backbone atoms of > > > adjacent residues which should work without any info about topology. > > > > > > > > > > > ------------------------------------------------------- > > This sf.net email is sponsored by: Jabber - The world's fastest > > growing > > real-time communications platform! Don't just IM. Build it in! > > http://www.jabber.com/osdn/xim > > _______________________________________________ > > Btk-developers mailing list > > Btk...@li... > > https://lists.sourceforge.net/lists/listinfo/btk-developers > > > > > > ------------------------------------------------------- > This sf.net email is sponsored by: Jabber - The world's fastest growing > real-time communications platform! Don't just IM. Build it in! > http://www.jabber.com/osdn/xim > _______________________________________________ > Btk-developers mailing list > Btk...@li... > https://lists.sourceforge.net/lists/listinfo/btk-developers > |
|
From: <EJ...@lb...> - 2002-07-24 23:34:15
|
Oh, in that case who cares about support for self-energies. If the user wants it, he/she can define it using some other rules like I mentioned previously with residue numbers. If they're really concerned about it, they can download the param files from some website, they have files for almost anything you could possibly imagine. On an unrelated note: can we get rid of the APPS subdirectory? Apple OS X is case preserving, but case insensitive. This means when you check things out of CVS it cant tell the difference between apps and APPS, and everything gets chucked into APPS. Doesn't look like there's anything in there anyway. -E ----- Original Message ----- From: Chris Saunders <ctsa@u.washington.edu> Date: Wednesday, July 24, 2002 4:10 pm Subject: Re: [Btk-developers] generic molecule self-energy > I think I see some confusion. Generic molecule exists to define the > operations that you can do without having to know or bother with the > molecule's topology. You can read any old thing in from a pdb, > rotate it, > write it back out etc.. When you say the generic molecule energies > can be > calculated "with a topology file", you aren't refering to the generic > molecule class concept anymore, but the buildable molecule concept. > > > > > This might be tricky to implement. Unless, by "undefined" you > mean> > "energy function will spit out a value, but value will be > > > meaningless." > > > Then it's not so hard. > > > > I think it's actually doable given a topology file, although > either the Molecule > > itself would have to carry extra topo info, or the e functions > would need a topo > > table passed in. The latter case is nice because it leaves > things up to the user - > > for example I might want to scale down interactions between > backbone atoms of > > adjacent residues which should work without any info about topology. > > > > > > ------------------------------------------------------- > This sf.net email is sponsored by: Jabber - The world's fastest > growing > real-time communications platform! Don't just IM. Build it in! > http://www.jabber.com/osdn/xim > _______________________________________________ > Btk-developers mailing list > Btk...@li... > https://lists.sourceforge.net/lists/listinfo/btk-developers > |
|
From: Chris S. <ctsa@u.washington.edu> - 2002-07-24 23:10:11
|
I think I see some confusion. Generic molecule exists to define the operations that you can do without having to know or bother with the molecule's topology. You can read any old thing in from a pdb, rotate it, write it back out etc.. When you say the generic molecule energies can be calculated "with a topology file", you aren't refering to the generic molecule class concept anymore, but the buildable molecule concept. > > This might be tricky to implement. Unless, by "undefined" you mean > > "energy function will spit out a value, but value will be > > meaningless." > > Then it's not so hard. > > I think it's actually doable given a topology file, although either the Molecule > itself would have to carry extra topo info, or the e functions would need a topo > table passed in. The latter case is nice because it leaves things up to the user - > for example I might want to scale down interactions between backbone atoms of > adjacent residues which should work without any info about topology. > |
|
From: Tim R. <timr@u.washington.edu> - 2002-07-24 22:59:20
|
Maybe I spoke too soon. I think your first suggestion is the correct way to do self energies (function taking BuildableMolecule class). The upshot, of course, is that we actually need a BuildableMolecule class, which wasn't clear before. so, double SelfEnergy(BuildableMolecule const & mol); (it *could* be a template, of course, if the need arose. We'd just need a way to query the molecule for it's connectivities. This might come up later with complexes. Bridge.cross(when_we_come_to_it) ) -tim Chris Saunders wrote: > for ques 1) > I don't know what the latest decision is on what actually gets passed to > the energy function to calc the self-energy of a molecule. If it were the > molecule itself, then undefined would mean that the self energy function > would take a "Buildable Molecule" class. If it's going to be some kind of > atom iterator, than craming the topology information into some > data-structure visible to the energy function is going to have to be > worked out before we really care about how to deal with the 'Generic > Molecule' exception. In general , by undefined, I mean that it shouldn't > even compile if you throw the wrong class at a self-energy function. > > > > On Wed, 24 Jul 2002, Tim Robertson wrote: > > >>This might be tricky to implement. Unless, by "undefined" you mean >>"energy function will spit out a value, but value will be meaningless." >> Then it's not so hard. >> >>Regarding topology files -- the plan is not to include anything charmm >>or amber specific in the molecule class itself, right? I'm thinking >>that you need functions like Molecule::define_connectivity() (or some >>such thing), that an outside method would call to set up the tetrads. >> >>Is this the plan (or something like it) ? >> >>-tim >> >>Chris Saunders wrote: >> >>>well what I mean is that atoms seperated by 1,2, or 3 covalent bonds will >>>have their vdw and electostatic interactions scaled down. This means that >>>the topology would have to be known or calculated for any molecule before >>>a self-energy could be found. Any molecule that has a topology file >>>available, as you suggest, is no longer generic -- so it sounds like what >>>we'll have to say is that for true generic molecules (3d positions and >>>atom types ONLY ) the self-energy is undefined. >>> >>>-c >>> >>>On Wed, 24 Jul 2002 EJ...@lb... wrote: >>> >>> >>> >>>>I'm not sure exactly what you mean by bonded scale-downs, but my plan was to >>>>use the topology/param files the same way the MD packages do. The files give >>>>a list of specific atom names and and connectivities and parameters that >>>>correspond to them. So to parameterize a generic molecule, you'd just pass the >>>>molecule and a param file to some function that would then assign the tetrads >>>>and radii and charge ... >>>> >>>>Does that answer the question? >>>> >>>>-E >>>> >>>>----- Original Message ----- >>>>From: Chris Saunders <ctsa@u.washington.edu> >>>>Date: Wednesday, July 24, 2002 2:27 pm >>>>Subject: [Btk-developers] generic molecule self-energy >>>> >>>> >>>> >>>>>Folks, >>>>>Is there a plan to deal with bonded scale-downs for generic >>>>>moleculesenergy calculations? For moledules with defined >>>>>topologies, we can either >>>>>use generic 1-2,1-3, and 1-4 bond energy scaling rules, or write >>>>>proteinand dna specific rules (as in the off-the-cuff ruleset in >>>>>rosetta). When >>>>>dealing with generic molecules, is the solution to just define bonds >>>>>automatically based on atom-pair distances, OR is there really no >>>>>need to >>>>>find the self-energy of a generic molecule? >>>>> >>>>>-c >>>>> >>>>> >>>>> >>>>>------------------------------------------------------- >>>>>This sf.net email is sponsored by:ThinkGeek >>>>>Welcome to geek heaven. >>>>>http://thinkgeek.com/sf >>>>>_______________________________________________ >>>>>Btk-developers mailing list >>>>>Btk...@li... >>>>>https://lists.sourceforge.net/lists/listinfo/btk-developers >>>>> >>>> >>>> >>>> >>>>------------------------------------------------------- >>>>This sf.net email is sponsored by:ThinkGeek >>>>Welcome to geek heaven. >>>>http://thinkgeek.com/sf >>>>_______________________________________________ >>>>Btk-developers mailing list >>>>Btk...@li... >>>>https://lists.sourceforge.net/lists/listinfo/btk-developers >>>> >>> >>> >>> >>> >>>------------------------------------------------------- >>>This sf.net email is sponsored by:ThinkGeek >>>Welcome to geek heaven. >>>http://thinkgeek.com/sf >>>_______________________________________________ >>>Btk-developers mailing list >>>Btk...@li... >>>https://lists.sourceforge.net/lists/listinfo/btk-developers >> >> >> >> >> >>------------------------------------------------------- >>This sf.net email is sponsored by:ThinkGeek >>Welcome to geek heaven. >>http://thinkgeek.com/sf >>_______________________________________________ >>Btk-developers mailing list >>Btk...@li... >>https://lists.sourceforge.net/lists/listinfo/btk-developers >> > > > > > ------------------------------------------------------- > This sf.net email is sponsored by:ThinkGeek > Welcome to geek heaven. > http://thinkgeek.com/sf > _______________________________________________ > Btk-developers mailing list > Btk...@li... > https://lists.sourceforge.net/lists/listinfo/btk-developers |
|
From: <EJ...@lb...> - 2002-07-24 22:53:43
|
----- Original Message ----- From: Tim Robertson <timr@u.washington.edu> Date: Wednesday, July 24, 2002 2:01 pm Subject: Re: [Btk-developers] generic molecule self-energy > This might be tricky to implement. Unless, by "undefined" you mean > "energy function will spit out a value, but value will be > meaningless." > Then it's not so hard. I think it's actually doable given a topology file, although either the Molecule itself would have to carry extra topo info, or the e functions would need a topo table passed in. The latter case is nice because it leaves things up to the user - for example I might want to scale down interactions between backbone atoms of adjacent residues which should work without any info about topology. > Regarding topology files -- the plan is not to include anything > charmm > or amber specific in the molecule class itself, right? I'm > thinking > that you need functions like Molecule::define_connectivity() (or > some > such thing), that an outside method would call to set up the tetrads. > > Is this the plan (or something like it) ? This was exactly my plan. It would be nice to include support (outside Molecule) for at least one of the standard formats, and if a user wanted to add support for OPLS or GROMOS or Gromacs, etc. later then they could easily do so. So we'll need some functions like Molecule::define_connectivity() that would probably interface with Tetrads directly. If we're talking about saving info about atoms connected by 2 or 3 bonds then we would obviously need to add some new data structure to Molecule. The latter case is something that I hadn't really thought about before Chris mentioned it. -E |
|
From: Chris S. <ctsa@u.washington.edu> - 2002-07-24 22:18:49
|
for ques 1) I don't know what the latest decision is on what actually gets passed to the energy function to calc the self-energy of a molecule. If it were the molecule itself, then undefined would mean that the self energy function would take a "Buildable Molecule" class. If it's going to be some kind of atom iterator, than craming the topology information into some data-structure visible to the energy function is going to have to be worked out before we really care about how to deal with the 'Generic Molecule' exception. In general , by undefined, I mean that it shouldn't even compile if you throw the wrong class at a self-energy function. On Wed, 24 Jul 2002, Tim Robertson wrote: > This might be tricky to implement. Unless, by "undefined" you mean > "energy function will spit out a value, but value will be meaningless." > Then it's not so hard. > > Regarding topology files -- the plan is not to include anything charmm > or amber specific in the molecule class itself, right? I'm thinking > that you need functions like Molecule::define_connectivity() (or some > such thing), that an outside method would call to set up the tetrads. > > Is this the plan (or something like it) ? > > -tim > > Chris Saunders wrote: > > well what I mean is that atoms seperated by 1,2, or 3 covalent bonds will > > have their vdw and electostatic interactions scaled down. This means that > > the topology would have to be known or calculated for any molecule before > > a self-energy could be found. Any molecule that has a topology file > > available, as you suggest, is no longer generic -- so it sounds like what > > we'll have to say is that for true generic molecules (3d positions and > > atom types ONLY ) the self-energy is undefined. > > > > -c > > > > On Wed, 24 Jul 2002 EJ...@lb... wrote: > > > > > >>I'm not sure exactly what you mean by bonded scale-downs, but my plan was to > >>use the topology/param files the same way the MD packages do. The files give > >>a list of specific atom names and and connectivities and parameters that > >>correspond to them. So to parameterize a generic molecule, you'd just pass the > >>molecule and a param file to some function that would then assign the tetrads > >>and radii and charge ... > >> > >>Does that answer the question? > >> > >>-E > >> > >>----- Original Message ----- > >>From: Chris Saunders <ctsa@u.washington.edu> > >>Date: Wednesday, July 24, 2002 2:27 pm > >>Subject: [Btk-developers] generic molecule self-energy > >> > >> > >>>Folks, > >>> Is there a plan to deal with bonded scale-downs for generic > >>>moleculesenergy calculations? For moledules with defined > >>>topologies, we can either > >>>use generic 1-2,1-3, and 1-4 bond energy scaling rules, or write > >>>proteinand dna specific rules (as in the off-the-cuff ruleset in > >>>rosetta). When > >>>dealing with generic molecules, is the solution to just define bonds > >>>automatically based on atom-pair distances, OR is there really no > >>>need to > >>>find the self-energy of a generic molecule? > >>> > >>>-c > >>> > >>> > >>> > >>>------------------------------------------------------- > >>>This sf.net email is sponsored by:ThinkGeek > >>>Welcome to geek heaven. > >>>http://thinkgeek.com/sf > >>>_______________________________________________ > >>>Btk-developers mailing list > >>>Btk...@li... > >>>https://lists.sourceforge.net/lists/listinfo/btk-developers > >>> > >> > >> > >> > >>------------------------------------------------------- > >>This sf.net email is sponsored by:ThinkGeek > >>Welcome to geek heaven. > >>http://thinkgeek.com/sf > >>_______________________________________________ > >>Btk-developers mailing list > >>Btk...@li... > >>https://lists.sourceforge.net/lists/listinfo/btk-developers > >> > > > > > > > > > > ------------------------------------------------------- > > This sf.net email is sponsored by:ThinkGeek > > Welcome to geek heaven. > > http://thinkgeek.com/sf > > _______________________________________________ > > Btk-developers mailing list > > Btk...@li... > > https://lists.sourceforge.net/lists/listinfo/btk-developers > > > > > > ------------------------------------------------------- > This sf.net email is sponsored by:ThinkGeek > Welcome to geek heaven. > http://thinkgeek.com/sf > _______________________________________________ > Btk-developers mailing list > Btk...@li... > https://lists.sourceforge.net/lists/listinfo/btk-developers > |
|
From: Tim R. <timr@u.washington.edu> - 2002-07-24 22:09:27
|
This might be tricky to implement. Unless, by "undefined" you mean "energy function will spit out a value, but value will be meaningless." Then it's not so hard. Regarding topology files -- the plan is not to include anything charmm or amber specific in the molecule class itself, right? I'm thinking that you need functions like Molecule::define_connectivity() (or some such thing), that an outside method would call to set up the tetrads. Is this the plan (or something like it) ? -tim Chris Saunders wrote: > well what I mean is that atoms seperated by 1,2, or 3 covalent bonds will > have their vdw and electostatic interactions scaled down. This means that > the topology would have to be known or calculated for any molecule before > a self-energy could be found. Any molecule that has a topology file > available, as you suggest, is no longer generic -- so it sounds like what > we'll have to say is that for true generic molecules (3d positions and > atom types ONLY ) the self-energy is undefined. > > -c > > On Wed, 24 Jul 2002 EJ...@lb... wrote: > > >>I'm not sure exactly what you mean by bonded scale-downs, but my plan was to >>use the topology/param files the same way the MD packages do. The files give >>a list of specific atom names and and connectivities and parameters that >>correspond to them. So to parameterize a generic molecule, you'd just pass the >>molecule and a param file to some function that would then assign the tetrads >>and radii and charge ... >> >>Does that answer the question? >> >>-E >> >>----- Original Message ----- >>From: Chris Saunders <ctsa@u.washington.edu> >>Date: Wednesday, July 24, 2002 2:27 pm >>Subject: [Btk-developers] generic molecule self-energy >> >> >>>Folks, >>> Is there a plan to deal with bonded scale-downs for generic >>>moleculesenergy calculations? For moledules with defined >>>topologies, we can either >>>use generic 1-2,1-3, and 1-4 bond energy scaling rules, or write >>>proteinand dna specific rules (as in the off-the-cuff ruleset in >>>rosetta). When >>>dealing with generic molecules, is the solution to just define bonds >>>automatically based on atom-pair distances, OR is there really no >>>need to >>>find the self-energy of a generic molecule? >>> >>>-c >>> >>> >>> >>>------------------------------------------------------- >>>This sf.net email is sponsored by:ThinkGeek >>>Welcome to geek heaven. >>>http://thinkgeek.com/sf >>>_______________________________________________ >>>Btk-developers mailing list >>>Btk...@li... >>>https://lists.sourceforge.net/lists/listinfo/btk-developers >>> >> >> >> >>------------------------------------------------------- >>This sf.net email is sponsored by:ThinkGeek >>Welcome to geek heaven. >>http://thinkgeek.com/sf >>_______________________________________________ >>Btk-developers mailing list >>Btk...@li... >>https://lists.sourceforge.net/lists/listinfo/btk-developers >> > > > > > ------------------------------------------------------- > This sf.net email is sponsored by:ThinkGeek > Welcome to geek heaven. > http://thinkgeek.com/sf > _______________________________________________ > Btk-developers mailing list > Btk...@li... > https://lists.sourceforge.net/lists/listinfo/btk-developers |
2 messages has been excluded from this view by a project administrator.
