Thread: [Apbs-users] Using PyMOL with APBS
Biomolecular electrostatics software
Brought to you by:
sobolevnrm
From: Michael G. L. <ml...@um...> - 2004-01-08 21:45:23
|
Hi, I've written some code that lets you use PyMOL ( <http://pymol.sourceforge.net> ) to run some simple electrostatics calculations with APBS and look at the results. You can find the code, etc. at http://www.umich.edu/~mlerner/Pymol/ if you're interested. It's not quite ready for prime-time, though, as you have to recompile PyMOL to get it to work (I think/hope this won't be true for long). I'll probably post about this again when it becomes easier to use (my guess is that that'll be with the next release of PyMOL). I have a few comments and questions: - I haven't used APBS much .. I've attached a typical .in file at the end of this email .. could someone tell me if it seems reasonable? - psize.py doesn't let you specify FADD on the command line. Is this on purpose? Even if I add in code to make it a valid command line option, it doesn't do what I want. Later on, I want to draw a surface 10A from the protein. I need to make sure that the grid is big enough for that. Can I do that with psize? (I was in a bit of a hurry, so I added a CADD option (analogous to FADD) and called psize.py with --FADD=20 and --CADD=20 .. is that the right thing to do?) I'd really like to know the answer to this question .. I haven't used APBS much, so I have no intuition for what the grid spacing, etc. should be, and I hope I can just trust my hacked version of psize.py. - psize.py can't parse the output of the pqr files that I get from http://nbcr.sdsc.edu/pdb2pqr/ (the web-based PDB2PQR service). psize.py expects different column alignments (in particular, it wants the x,y,z coordinates to be in the same positions as they are in PDB files). I have a really simple Python function that rewrites the pqr files, but it seems like this should be fixed. My stupid Python function just does this: linetype,num,aname,res,resn,x,y,z,charge,radius,atype = line.split() goodLine = '%-6s%5s%5s%4s%6s %8s%8s%8s %6s %4s%12s'%(linetype,num,aname,res,resn,x,y,z,charge,radius,atype) but it seems to work for me. - All of the example input files I found use mg-manual, but the APBS users guide makes it look like mg-auto is the way to go, so my code uses mg-auto. mg-auto seems to require 'srfm' even though the users guide (http://agave.wustl.edu/apbs/doc/api/html/#mg-auto) doesn't mention it. - I have been using AMBER parameters for my electrostatics calculations. Is this a particularly bad idea? Also, does anyone have a little script to AMBER parameter files + a PDB file into a PQR file, or should I write it myself? - I was using MOE for my electrostatics calculations before .. man is APBS faster! - I don't really understand licensing issues, so I have some questions about GPL vs. the PyMOL license (which looks basically like a BSD license to me). Anyway, here are my licensing questions: - I stole some of my comments for the input files from one of the apbs.in files that comes with APBS .. is that a problem? - I think I was looking at some of the APBS source when I wrote my code that parses dx files .. probably vgrid.c I didn't directly copy any code (that would be hard, since my stuff is in Python). Can I still release my code under a less restrictive license (i.e. the PyMOL license), or do I need to rewrite that part first? - Right now, my code generates a .in file, calls apbs from the command line and parses the resulting dx file. It would be cool if I could plug directly into APBS with the stuff in tools/python. Is there any way to do that without forcing my code to be GPL'd? Normally, I don't care about licenses. In this case, though, I'd really like it if any C code I write could be folded into PyMOL. This means that 1) I don't have to maintain it and 2) lots of people can use it (I doubt that very many people want to recompile PyMOL themselves). My guess is that the PyMOL folks might want to fold at least the dx parsing stuff into PyMOL too. It was pretty easy to write, and I'm sure the PyMOL folks could rewrite it pretty quickly, but it'd be nice if I could just give it away. Thanks, -michael lerner Here's a typical input file for a short poly-peptide: read mol pqr /home/mlerner/small.pqr # read molecule 1 end elec mg-auto dime = 33 33 33 # number of find grid points # calculated by psize.py cglen = 26.416000 18.674000 19.356000 # coarse mesh lengths (A) fglen = 26.416000 18.674000 19.356000 # fine mesh lengths (A) grid = 0.825509 0.583578 0.604881 # fine mesh spacings # calculated by psize.py cgcent mol 1 # (could also give (x,y,z) form psize.py) fgcent mol 1 # (could also give (x,y,z) form psize.py) npbe # solve the full nonlinear PBE with npbe #lpbe # wimp out and solve the linear PBE with lpbe bcfl 2 # Boundary condition flag # 0 => Zero # 1 => Single DH sphere # 2 => Multiple DH spheres # 4 => Focusing # READ THE MANUAL for this one. You may want a few # sections here .. the first with bcfl=2 and the others # with bcfl=4, for instance. # #ion 1 0.000 2.0 # Counterion declaration: ion 1 0.000000 2.000000 # Counterion declaration: ion -1 0.000000 2.000000 # ion <charge> <conc (M)> <radius> ion 2 0.000000 2.000000 # ion <charge> <conc (M)> <radius> # TODO: make this a sub-menu pdie 20.000000 # Solute dielectric sdie 80.000000 # Solvent dielectric chgm 1 # Charge disc method # read the manual .. 1 is cubic b-splines mol 1 # which molecule to use srfm 1 # Surface calculation method # 0 => Mol surface for epsilon; # inflated VdW for kappa; no # smoothing # 1 => As 0 with harmoic average # smoothing # 2 => Cubic spline srad 1.400000 # Solvent radius (1.4 for water) # TODO: put this in a sub-menu swin 0.3 # Surface cubic spline window .. default 0.3 temp 310.000000 # System temperature (298.15 default) # TODO: put this in a sub-menu gamma 0.105 # Surface tension parameter for apolar forces (in kJ/mol/A^2) # only used for force calculations, so we don't care, but # it's always required, and 0.105 is the default calcenergy 0 # Energy I/O to stdout # 0 => don't write out energy # 1 => write out total energy # 2 => write out total energy and all # components calcforce 0 # Atomic forces I/O (to stdout) # 0 => don't write out forces # 1 => write out net forces on molecule # 2 => write out atom-level forces write pot dx /home/mlerner/small.pqr # What to write .. this says write the potential in dx # format to a file. end quit -- This isn't a democracy;| _ |Michael Lerner it's a cheer-ocracy. | ASCII ribbon campaign ( ) | Michigan -Torrence, Bring It On| - against HTML email X | Biophysics | / \ | mlerner@umich |
From: Nathan A. B. <ba...@ch...> - 2004-01-09 14:23:09
|
Dear Michael -- >I've written some code that lets you use PyMOL ( ><http://pymol.sourceforge.net> ) to run some simple electrostatics >calculations with APBS and look at the results. You can find the >code, etc. at http://www.umich.edu/~mlerner/Pymol/ if you're >interested. It's not quite ready for prime-time, though, as you have >to recompile PyMOL to get it to work (I think/hope this won't be true >for long). I'll probably post about this again when it becomes >easier to use (my guess is that that'll be with the next release of >PyMOL). I have a few comments and questions: This looks great! I'd like to centralize plugins (as much as possible) with APBS. Is there any chance you'd be willing to let us either place this on our web server and/or package it with APBS (with full acknowledgements to you, of course). If not, are you planning to have this included with PyMOL? I'm just interested in making sure this gets distributed and maintained. > - I haven't used APBS much .. I've attached a typical .in file at the end >of this email .. could someone tell me if it seems reasonable? It looks more-or-less OK; there are some "=" characters that shouldn't be there. You might look at apbs/examples/misc for a good potential calculation example. > - psize.py doesn't let you specify FADD on the command line. Is this on >purpose? Even if I add in code to make it a valid command line option, it >doesn't do what I want. Later on, I want to draw a surface 10A from the >protein. I need to make sure that the grid is big enough for that. Can I >do that with psize? (I was in a bit of a hurry, so I added a CADD option >(analogous to FADD) and called psize.py with --FADD=20 and --CADD=20 .. is >that the right thing to do?) I'd really like to know the answer to this >question .. I haven't used APBS much, so I have no intuition for what the >grid spacing, etc. should be, and I hope I can just trust my hacked >version of psize.py. Thanks for letting us know. I'm Cc'ing our programmer, Todd Dolinsky, who will take care of this. > - psize.py can't parse the output of the pqr files that I get from >http://nbcr.sdsc.edu/pdb2pqr/ (the web-based PDB2PQR service). psize.py >expects different column alignments (in particular, it wants the x,y,z >coordinates to be in the same positions as they are in PDB files). I have >a really simple Python function that rewrites the pqr files, but it seems >like this should be fixed. My stupid Python function just does this: > >linetype,num,aname,res,resn,x,y,z,charge,radius,atype = line.split() >goodLine = '%-6s%5s%5s%4s%6s %8s%8s%8s %6s %4s%12s'%(linetype,num,aname,res,resn,x,y,z,charge,radius,atype) > >but it seems to work for me. Again thanks; I'll pass this along to Todd. > - All of the example input files I found use mg-manual, but the APBS >users guide makes it look like mg-auto is the way to go, so my code uses >mg-auto. mg-auto seems to require 'srfm' even though the users guide >(http://agave.wustl.edu/apbs/doc/api/html/#mg-auto) doesn't mention it. That omission has been fixed in a more recent version of APBS (about to be released) > - I have been using AMBER parameters for my electrostatics calculations. >Is this a particularly bad idea? This isn't a bad idea; lots of folks use AMBER parameters for PB calculations. AMBER has some of their own radii they suggest for MM/PBSA calculations. It might be worthwhile looking at these >Also, does anyone have a little script to AMBER parameter files + a >PDB file into a PQR file, or should I write it myself? Actually, we have a whole server dedicated to this; however, it's currently off-line for upgrades. The new version of APBS will include support for this in the main program. In the meantime, I'd suggest using the various scripts in the apbs/tools/ directory for PDB -> PQR. > - I don't really understand licensing issues, so I have some questions >about GPL vs. the PyMOL license (which looks basically like a BSD license >to me). Anyway, here are my licensing questions: > > - I stole some of my comments for the input files from one of the > apbs.in files that comes with APBS .. is that a problem? No; you might acknowledge the original source. > - I think I was looking at some of the APBS source when I wrote my code > that parses dx files .. probably vgrid.c I didn't directly copy any > code (that would be hard, since my stuff is in Python). Can I still > release my code under a less restrictive license (i.e. the PyMOL license), > or do I need to rewrite that part first? As far as I'm concerned, you can include the code under the PyMOL license provided you acknowledge the original code and note that it was covered under GPL. > - Right now, my code generates a .in file, calls apbs from the command > line and parses the resulting dx file. It would be cool if I could > plug directly into APBS with the stuff in tools/python. Is there any > way to do that without forcing my code to be GPL'd? Sure! You can use the Python wrappers independently as modules (more coming in the new release) without having to actually tinker with them. That should avoid any licensing issues. >Normally, I don't care about licenses. In this case, though, I'd >really like it if any C code I write could be folded into PyMOL. >This means that 1) I don't have to maintain it and 2) lots of people >can use it (I doubt that very many people want to recompile PyMOL >themselves). My guess is that the PyMOL folks might want to fold at >least the dx parsing stuff into PyMOL too. It was pretty easy to >write, and I'm sure the PyMOL folks could rewrite it pretty quickly, >but it'd be nice if I could just give it away. Agreed. As far as I'm concerned, the APBS GPL license is there only for protection and should be interpreted in the most liberal way possible. Thanks, Nathan >Here's a typical input file for a short poly-peptide: > >read > mol pqr /home/mlerner/small.pqr # read molecule 1 >end >elec > mg-auto > dime = 33 33 33 # number of find grid points > # calculated by psize.py > cglen = 26.416000 18.674000 19.356000 # coarse mesh lengths (A) > fglen = 26.416000 18.674000 19.356000 # fine mesh lengths (A) > grid = 0.825509 0.583578 0.604881 # fine mesh spacings > # calculated by psize.py > cgcent mol 1 # (could also give (x,y,z) form psize.py) > fgcent mol 1 # (could also give (x,y,z) form psize.py) > npbe # solve the full nonlinear PBE with npbe > #lpbe # wimp out and solve the linear PBE with lpbe > bcfl 2 # Boundary condition flag > # 0 => Zero > # 1 => Single DH sphere > # 2 => Multiple DH spheres > # 4 => Focusing > # READ THE MANUAL for this one. You may want a few > # sections here .. the first with bcfl=2 and the others > # with bcfl=4, for instance. > # > #ion 1 0.000 2.0 # Counterion declaration: > ion 1 0.000000 2.000000 # Counterion declaration: > ion -1 0.000000 2.000000 # ion <charge> <conc (M)> <radius> > ion 2 0.000000 2.000000 # ion <charge> <conc (M)> <radius> > # TODO: make this a sub-menu > pdie 20.000000 # Solute dielectric > sdie 80.000000 # Solvent dielectric > chgm 1 # Charge disc method > # read the manual .. 1 is cubic b-splines > mol 1 # which molecule to use > srfm 1 # Surface calculation method > # 0 => Mol surface for epsilon; > # inflated VdW for kappa; no > # smoothing > # 1 => As 0 with harmoic average > # smoothing > # 2 => Cubic spline > srad 1.400000 # Solvent radius (1.4 for water) > # TODO: put this in a sub-menu > swin 0.3 # Surface cubic spline window .. default 0.3 > temp 310.000000 # System temperature (298.15 default) > # TODO: put this in a sub-menu > gamma 0.105 # Surface tension parameter for apolar forces (in kJ/mol/A^2) > # only used for force calculations, so we don't care, but > # it's always required, and 0.105 is the default > calcenergy 0 # Energy I/O to stdout > # 0 => don't write out energy > # 1 => write out total energy > # 2 => write out total energy and all > # components > calcforce 0 # Atomic forces I/O (to stdout) > # 0 => don't write out forces > # 1 => write out net forces on molecule > # 2 => write out atom-level forces > write pot dx /home/mlerner/small.pqr # What to write .. this says write the potential in dx > # format to a file. >end >quit > >-- >This isn't a democracy;| _ |Michael Lerner > it's a cheer-ocracy. | ASCII ribbon campaign ( ) | Michigan >-Torrence, Bring It On| - against HTML email X | Biophysics > | / \ | mlerner@umich >_______________________________________________ >apbs-users mailing list >apb...@ch... >http://cholla.wustl.edu/mailman/listinfo/apbs-users End of message from Michael George Lerner. -- Nathan A. Baker, Assistant Professor Washington University in St. Louis School of Medicine Dept. of Biochemistry and Molecular Biophysics Center for Computational Biology 700 S. Euclid Ave., Campus Box 8036, St. Louis, MO 63110 Phone: (314) 362-2040, Fax: (314) 362-0234 URL: http://www.biochem.wustl.edu/~baker PGP key: http://cholla.wustl.edu/~baker/pubkey.asc |
From: Michael G. L. <ml...@um...> - 2004-01-09 20:02:25
|
Hi, > This looks great! I'd like to centralize plugins (as much as > possible) with APBS. Is there any chance you'd be willing to let us > either place this on our web server and/or package it with APBS (with > full acknowledgements to you, of course). If not, are you planning to > have this included with PyMOL? I'm just interested in making sure > this gets distributed and maintained. I'm hoping the C code gets integrated into PyMOL .. after that, it's easy to just drop the Python code into a working PyMOL installation. I don't know whether Warren (the PyMOL developer) wants to include this with PyMOL, but I'd certainly let him if he wants to. Having other people use (and maybe maintain! :)) this would be great. I'd be glad to let you put it on your web server, package it up with APBS, etc., but you probably want to wait until it's had a bit more testing. It works well for my systems, but I haven't tested it on a lot of other systems. Also, like I said, I haven't done much work with APBS. You should let me know if there are any features you'd like me to add to the GUI. There should always be a current version on my website .. I don't know how much the current version will change, but it'll probably be a good idea to at least link to http://www-personal.umich.edu/~mlerner/Pymol. We can sort the details out after a few more people have tested this :). > > - I haven't used APBS much .. I've attached a typical .in file at the end > >of this email .. could someone tell me if it seems reasonable? > > It looks more-or-less OK; there are some "=" characters that shouldn't > be there. You might look at apbs/examples/misc for a good potential > calculation example. Thanks. I got rid of the spurious "=" characters (APBS seemed to ignore them and do the right thing, luckily enough for me, but they're gone now), changed bcfl from 2 to 1, and changed chgm from 1 to 0. The only other differences I noticed were pdie (I use 20, the example file uses 1), the size of the grid (hopefully, psize.py gets this right for me automagically) and the types of output (I can easily add in options for writing different output). > > - I have been using AMBER parameters for my electrostatics calculations. > >Is this a particularly bad idea? > > This isn't a bad idea; lots of folks use AMBER parameters for PB > calculations. AMBER has some of their own radii they suggest for > MM/PBSA calculations. It might be worthwhile looking at these Thanks. > >Also, does anyone have a little script to AMBER parameter files + a > >PDB file into a PQR file, or should I write it myself? > > Actually, we have a whole server dedicated to this; however, it's > currently off-line for upgrades. The new version of APBS will include > support for this in the main program. In the meantime, I'd suggest > using the various scripts in the apbs/tools/ directory for PDB -> PQR. Cool. I also noticed that AMBER's ambpdb comes with a -pqr option to generate PQR files from prmtop and prmcrd files. > > - I don't really understand licensing issues, so I have some questions > >about GPL vs. the PyMOL license (which looks basically like a BSD license > >to me). Anyway, here are my licensing questions: > > > > - I stole some of my comments for the input files from one of the > > apbs.in files that comes with APBS .. is that a problem? > > No; you might acknowledge the original source. Oops! I'm pretty embarrassed that I forgot to do that in the first place. Sorry about that. Done. > > - I think I was looking at some of the APBS source when I wrote my code > > that parses dx files .. probably vgrid.c I didn't directly copy any > > code (that would be hard, since my stuff is in Python). Can I still > > release my code under a less restrictive license (i.e. the PyMOL license), > > or do I need to rewrite that part first? > > As far as I'm concerned, you can include the code under the PyMOL > license provided you acknowledge the original code and note that it > was covered under GPL. Thanks! > > - Right now, my code generates a .in file, calls apbs from the command > > line and parses the resulting dx file. It would be cool if I could > > plug directly into APBS with the stuff in tools/python. Is there any > > way to do that without forcing my code to be GPL'd? > > Sure! You can use the Python wrappers independently as modules (more > coming in the new release) without having to actually tinker with > them. That should avoid any licensing issues. Cool. Like I said, I don't really understand licensing issues (LGPL vs. GPL, etc.), so I'm glad that I won't have to :). > >Normally, I don't care about licenses. In this case, though, I'd > >really like it if any C code I write could be folded into PyMOL. > >This means that 1) I don't have to maintain it and 2) lots of people > >can use it (I doubt that very many people want to recompile PyMOL > >themselves). My guess is that the PyMOL folks might want to fold at > >least the dx parsing stuff into PyMOL too. It was pretty easy to > >write, and I'm sure the PyMOL folks could rewrite it pretty quickly, > >but it'd be nice if I could just give it away. > > Agreed. As far as I'm concerned, the APBS GPL license is there only > for protection and should be interpreted in the most liberal way > possible. Great, and thanks again. -michael P.S. I'm in Heather Carlson's lab .. she says hi. |
From: Nathan A. B. <ba...@ch...> - 2004-01-12 14:10:41
|
Sounds great -- thanks! I'm looking forward to trying it out. Would you be willing to post to the mailing list when you have the code working without recompiling PyMOL? I'm sure there are others who would like to try it as well. Thanks again and say "hi" to Heather for me. -- Nathan Michael George Lerner <ml...@um...> (01-09-2004 13:02:24-0500): > >Hi, > >> This looks great! I'd like to centralize plugins (as much as >> possible) with APBS. Is there any chance you'd be willing to let us >> either place this on our web server and/or package it with APBS (with >> full acknowledgements to you, of course). If not, are you planning to >> have this included with PyMOL? I'm just interested in making sure >> this gets distributed and maintained. > >I'm hoping the C code gets integrated into PyMOL .. after that, it's easy >to just drop the Python code into a working PyMOL installation. I don't >know whether Warren (the PyMOL developer) wants to include this with >PyMOL, but I'd certainly let him if he wants to. Having other people use >(and maybe maintain! :)) this would be great. I'd be glad to let you put >it on your web server, package it up with APBS, etc., but you probably >want to wait until it's had a bit more testing. It works well for my >systems, but I haven't tested it on a lot of other systems. Also, like I >said, I haven't done much work with APBS. You should let me know if there >are any features you'd like me to add to the GUI. > >There should always be a current version on my website .. I don't know how >much the current version will change, but it'll probably be a good idea to >at least link to http://www-personal.umich.edu/~mlerner/Pymol. We can >sort the details out after a few more people have tested this :). > >> > - I haven't used APBS much .. I've attached a typical .in file at the end >> >of this email .. could someone tell me if it seems reasonable? >> >> It looks more-or-less OK; there are some "=" characters that shouldn't >> be there. You might look at apbs/examples/misc for a good potential >> calculation example. > >Thanks. I got rid of the spurious "=" characters (APBS seemed to ignore >them and do the right thing, luckily enough for me, but they're gone now), >changed bcfl from 2 to 1, and changed chgm from 1 to 0. The only other >differences I noticed were pdie (I use 20, the example file uses 1), the >size of the grid (hopefully, psize.py gets this right for me >automagically) and the types of output (I can easily add in options for >writing different output). > >> > - I have been using AMBER parameters for my electrostatics calculations. >> >Is this a particularly bad idea? >> >> This isn't a bad idea; lots of folks use AMBER parameters for PB >> calculations. AMBER has some of their own radii they suggest for >> MM/PBSA calculations. It might be worthwhile looking at these > >Thanks. > >> >Also, does anyone have a little script to AMBER parameter files + a >> >PDB file into a PQR file, or should I write it myself? >> >> Actually, we have a whole server dedicated to this; however, it's >> currently off-line for upgrades. The new version of APBS will include >> support for this in the main program. In the meantime, I'd suggest >> using the various scripts in the apbs/tools/ directory for PDB -> PQR. > >Cool. I also noticed that AMBER's ambpdb comes with a -pqr option to >generate PQR files from prmtop and prmcrd files. > >> > - I don't really understand licensing issues, so I have some questions >> >about GPL vs. the PyMOL license (which looks basically like a BSD license >> >to me). Anyway, here are my licensing questions: >> > >> > - I stole some of my comments for the input files from one of the >> > apbs.in files that comes with APBS .. is that a problem? >> >> No; you might acknowledge the original source. > >Oops! I'm pretty embarrassed that I forgot to do that in the first place. >Sorry about that. Done. > >> > - I think I was looking at some of the APBS source when I wrote my code >> > that parses dx files .. probably vgrid.c I didn't directly copy any >> > code (that would be hard, since my stuff is in Python). Can I still >> > release my code under a less restrictive license (i.e. the PyMOL license), >> > or do I need to rewrite that part first? >> >> As far as I'm concerned, you can include the code under the PyMOL >> license provided you acknowledge the original code and note that it >> was covered under GPL. > >Thanks! > >> > - Right now, my code generates a .in file, calls apbs from the command >> > line and parses the resulting dx file. It would be cool if I could >> > plug directly into APBS with the stuff in tools/python. Is there any >> > way to do that without forcing my code to be GPL'd? >> >> Sure! You can use the Python wrappers independently as modules (more >> coming in the new release) without having to actually tinker with >> them. That should avoid any licensing issues. > >Cool. Like I said, I don't really understand licensing issues (LGPL vs. >GPL, etc.), so I'm glad that I won't have to :). > >> >Normally, I don't care about licenses. In this case, though, I'd >> >really like it if any C code I write could be folded into PyMOL. >> >This means that 1) I don't have to maintain it and 2) lots of people >> >can use it (I doubt that very many people want to recompile PyMOL >> >themselves). My guess is that the PyMOL folks might want to fold at >> >least the dx parsing stuff into PyMOL too. It was pretty easy to >> >write, and I'm sure the PyMOL folks could rewrite it pretty quickly, >> >but it'd be nice if I could just give it away. >> >> Agreed. As far as I'm concerned, the APBS GPL license is there only >> for protection and should be interpreted in the most liberal way >> possible. > >Great, and thanks again. > >-michael > >P.S. I'm in Heather Carlson's lab .. she says hi. >_______________________________________________ >apbs-users mailing list >apb...@ch... >http://cholla.wustl.edu/mailman/listinfo/apbs-users End of message from Michael George Lerner. -- Nathan A. Baker, Assistant Professor Washington University in St. Louis School of Medicine Dept. of Biochemistry and Molecular Biophysics Center for Computational Biology 700 S. Euclid Ave., Campus Box 8036, St. Louis, MO 63110 Phone: (314) 362-2040, Fax: (314) 362-0234 URL: http://www.biochem.wustl.edu/~baker PGP key: http://cholla.wustl.edu/~baker/pubkey.asc |
From: Michael G. L. <ml...@um...> - 2004-06-11 00:26:59
|
Hi, I'm trying to get a picture the electrostatics of a protein's active site. Usually, I look at things without explicit waters, set sdie to 80 and set pdie to 20. In this case, there are some waters near the active site that are particularly important, so I want to include them in the calculation. How does one usually set up the dielectric constants for situations like this? Please feel free to just point me at a good reference. The closest thing I've found so far is a Biophys J paper (Bridging Implicit and Explicit Solvent Approaches for Membrane Electrostatics, Lin, Baker and McCammon, 2002, Vol. 83, p. 1374-1479). There, they set the dielectric for explicit waters and lipids to 1 and 78.54 for everything else. Is this the right thing for me to do? I also found some text at http://mccammon.ucsd.edu/~jswanson/apbsDoc/command_doc2.html that implies that this is the right thing, but it didn't point me at any references. Thanks, -michael -- This isn't a democracy;| _ |Michael Lerner it's a cheer-ocracy. | ASCII ribbon campaign ( ) | Michigan -Torrence, Bring It On| - against HTML email X | Biophysics | / \ | mlerner@umich On Fri, 9 Jan 2004, Nathan A. Baker wrote: > Dear Michael -- > > >I've written some code that lets you use PyMOL ( > ><http://pymol.sourceforge.net> ) to run some simple electrostatics > >calculations with APBS and look at the results. You can find the > >code, etc. at http://www.umich.edu/~mlerner/Pymol/ if you're > >interested. It's not quite ready for prime-time, though, as you have > >to recompile PyMOL to get it to work (I think/hope this won't be true > >for long). I'll probably post about this again when it becomes > >easier to use (my guess is that that'll be with the next release of > >PyMOL). I have a few comments and questions: > > This looks great! I'd like to centralize plugins (as much as > possible) with APBS. Is there any chance you'd be willing to let us > either place this on our web server and/or package it with APBS (with > full acknowledgements to you, of course). If not, are you planning to > have this included with PyMOL? I'm just interested in making sure > this gets distributed and maintained. > > > - I haven't used APBS much .. I've attached a typical .in file at the end > >of this email .. could someone tell me if it seems reasonable? > > It looks more-or-less OK; there are some "=" characters that shouldn't > be there. You might look at apbs/examples/misc for a good potential > calculation example. > > > - psize.py doesn't let you specify FADD on the command line. Is this on > >purpose? Even if I add in code to make it a valid command line option, it > >doesn't do what I want. Later on, I want to draw a surface 10A from the > >protein. I need to make sure that the grid is big enough for that. Can I > >do that with psize? (I was in a bit of a hurry, so I added a CADD option > >(analogous to FADD) and called psize.py with --FADD=20 and --CADD=20 .. is > >that the right thing to do?) I'd really like to know the answer to this > >question .. I haven't used APBS much, so I have no intuition for what the > >grid spacing, etc. should be, and I hope I can just trust my hacked > >version of psize.py. > > Thanks for letting us know. I'm Cc'ing our programmer, Todd Dolinsky, who > will take care of this. > > > - psize.py can't parse the output of the pqr files that I get from > >http://nbcr.sdsc.edu/pdb2pqr/ (the web-based PDB2PQR service). psize.py > >expects different column alignments (in particular, it wants the x,y,z > >coordinates to be in the same positions as they are in PDB files). I have > >a really simple Python function that rewrites the pqr files, but it seems > >like this should be fixed. My stupid Python function just does this: > > > >linetype,num,aname,res,resn,x,y,z,charge,radius,atype = line.split() > >goodLine = '%-6s%5s%5s%4s%6s %8s%8s%8s %6s %4s%12s'%(linetype,num,aname,res,resn,x,y,z,charge,radius,atype) > > > >but it seems to work for me. > > Again thanks; I'll pass this along to Todd. > > > - All of the example input files I found use mg-manual, but the APBS > >users guide makes it look like mg-auto is the way to go, so my code uses > >mg-auto. mg-auto seems to require 'srfm' even though the users guide > >(http://agave.wustl.edu/apbs/doc/api/html/#mg-auto) doesn't mention it. > > That omission has been fixed in a more recent version of APBS (about > to be released) > > > - I have been using AMBER parameters for my electrostatics calculations. > >Is this a particularly bad idea? > > This isn't a bad idea; lots of folks use AMBER parameters for PB > calculations. AMBER has some of their own radii they suggest for > MM/PBSA calculations. It might be worthwhile looking at these > > >Also, does anyone have a little script to AMBER parameter files + a > >PDB file into a PQR file, or should I write it myself? > > Actually, we have a whole server dedicated to this; however, it's > currently off-line for upgrades. The new version of APBS will include > support for this in the main program. In the meantime, I'd suggest > using the various scripts in the apbs/tools/ directory for PDB -> PQR. > > > - I don't really understand licensing issues, so I have some questions > >about GPL vs. the PyMOL license (which looks basically like a BSD license > >to me). Anyway, here are my licensing questions: > > > > - I stole some of my comments for the input files from one of the > > apbs.in files that comes with APBS .. is that a problem? > > No; you might acknowledge the original source. > > > - I think I was looking at some of the APBS source when I wrote my code > > that parses dx files .. probably vgrid.c I didn't directly copy any > > code (that would be hard, since my stuff is in Python). Can I still > > release my code under a less restrictive license (i.e. the PyMOL license), > > or do I need to rewrite that part first? > > As far as I'm concerned, you can include the code under the PyMOL > license provided you acknowledge the original code and note that it > was covered under GPL. > > > - Right now, my code generates a .in file, calls apbs from the command > > line and parses the resulting dx file. It would be cool if I could > > plug directly into APBS with the stuff in tools/python. Is there any > > way to do that without forcing my code to be GPL'd? > > Sure! You can use the Python wrappers independently as modules (more > coming in the new release) without having to actually tinker with > them. That should avoid any licensing issues. > > >Normally, I don't care about licenses. In this case, though, I'd > >really like it if any C code I write could be folded into PyMOL. > >This means that 1) I don't have to maintain it and 2) lots of people > >can use it (I doubt that very many people want to recompile PyMOL > >themselves). My guess is that the PyMOL folks might want to fold at > >least the dx parsing stuff into PyMOL too. It was pretty easy to > >write, and I'm sure the PyMOL folks could rewrite it pretty quickly, > >but it'd be nice if I could just give it away. > > Agreed. As far as I'm concerned, the APBS GPL license is there only > for protection and should be interpreted in the most liberal way > possible. > > Thanks, > > Nathan > > >Here's a typical input file for a short poly-peptide: > > > >read > > mol pqr /home/mlerner/small.pqr # read molecule 1 > >end > >elec > > mg-auto > > dime = 33 33 33 # number of find grid points > > # calculated by psize.py > > cglen = 26.416000 18.674000 19.356000 # coarse mesh lengths (A) > > fglen = 26.416000 18.674000 19.356000 # fine mesh lengths (A) > > grid = 0.825509 0.583578 0.604881 # fine mesh spacings > > # calculated by psize.py > > cgcent mol 1 # (could also give (x,y,z) form psize.py) > > fgcent mol 1 # (could also give (x,y,z) form psize.py) > > npbe # solve the full nonlinear PBE with npbe > > #lpbe # wimp out and solve the linear PBE with lpbe > > bcfl 2 # Boundary condition flag > > # 0 => Zero > > # 1 => Single DH sphere > > # 2 => Multiple DH spheres > > # 4 => Focusing > > # READ THE MANUAL for this one. You may want a few > > # sections here .. the first with bcfl=2 and the others > > # with bcfl=4, for instance. > > # > > #ion 1 0.000 2.0 # Counterion declaration: > > ion 1 0.000000 2.000000 # Counterion declaration: > > ion -1 0.000000 2.000000 # ion <charge> <conc (M)> <radius> > > ion 2 0.000000 2.000000 # ion <charge> <conc (M)> <radius> > > # TODO: make this a sub-menu > > pdie 20.000000 # Solute dielectric > > sdie 80.000000 # Solvent dielectric > > chgm 1 # Charge disc method > > # read the manual .. 1 is cubic b-splines > > mol 1 # which molecule to use > > srfm 1 # Surface calculation method > > # 0 => Mol surface for epsilon; > > # inflated VdW for kappa; no > > # smoothing > > # 1 => As 0 with harmoic average > > # smoothing > > # 2 => Cubic spline > > srad 1.400000 # Solvent radius (1.4 for water) > > # TODO: put this in a sub-menu > > swin 0.3 # Surface cubic spline window .. default 0.3 > > temp 310.000000 # System temperature (298.15 default) > > # TODO: put this in a sub-menu > > gamma 0.105 # Surface tension parameter for apolar forces (in kJ/mol/A^2) > > # only used for force calculations, so we don't care, but > > # it's always required, and 0.105 is the default > > calcenergy 0 # Energy I/O to stdout > > # 0 => don't write out energy > > # 1 => write out total energy > > # 2 => write out total energy and all > > # components > > calcforce 0 # Atomic forces I/O (to stdout) > > # 0 => don't write out forces > > # 1 => write out net forces on molecule > > # 2 => write out atom-level forces > > write pot dx /home/mlerner/small.pqr # What to write .. this says write the potential in dx > > # format to a file. > >end > >quit > > > >-- > >This isn't a democracy;| _ |Michael Lerner > > it's a cheer-ocracy. | ASCII ribbon campaign ( ) | Michigan > >-Torrence, Bring It On| - against HTML email X | Biophysics > > | / \ | mlerner@umich > >_______________________________________________ > >apbs-users mailing list > >apb...@ch... > >http://cholla.wustl.edu/mailman/listinfo/apbs-users > End of message from Michael George Lerner. > > -- > Nathan A. Baker, Assistant Professor > Washington University in St. Louis School of Medicine > Dept. of Biochemistry and Molecular Biophysics > Center for Computational Biology > 700 S. Euclid Ave., Campus Box 8036, St. Louis, MO 63110 > Phone: (314) 362-2040, Fax: (314) 362-0234 > URL: http://www.biochem.wustl.edu/~baker > PGP key: http://cholla.wustl.edu/~baker/pubkey.asc > |
From: Nathan B. <ba...@bi...> - 2004-06-11 14:19:04
|
Hi Michael -- The use of higher dielectric values inside the protein is not necessarily aimed at capturing the effects of buried waters; higher values describe a variety of internal relaxation modes (libration, side chain reorientation, etc.) of the protein that are not explicitly included in the calculation. Additionally, atomic polarizability alone gives a dielectric constant of 2-3 in a solid. However, figuring out how to deconvolve the contribution from internal motion, waters, atomic polarizability, etc. is not straightforward. If you are including the motion of the protein explicitly (snapshots from MD, etc.), you should use a lower value (2-3). Otherwise, I'd stick with higher values, perhaps closer to 10 or 15 for your calculations. Good luck, Nathan Michael George Lerner wrote: > Hi, > > I'm trying to get a picture the electrostatics of a protein's active site. > Usually, I look at things without explicit waters, set sdie to 80 and set > pdie to 20. In this case, there are some waters near the active site that > are particularly important, so I want to include them in the calculation. > How does one usually set up the dielectric constants for situations like > this? > > Please feel free to just point me at a good reference. The closest thing > I've found so far is a Biophys J paper (Bridging Implicit and Explicit > Solvent Approaches for Membrane Electrostatics, Lin, Baker and McCammon, > 2002, Vol. 83, p. 1374-1479). There, they set the dielectric for explicit > waters and lipids to 1 and 78.54 for everything else. Is this the right > thing for me to do? > > I also found some text at > http://mccammon.ucsd.edu/~jswanson/apbsDoc/command_doc2.html that implies > that this is the right thing, but it didn't point me at any references. > > Thanks, > > -michael > > -- > This isn't a democracy;| _ |Michael Lerner > it's a cheer-ocracy. | ASCII ribbon campaign ( ) | Michigan > -Torrence, Bring It On| - against HTML email X | Biophysics > | / \ | mlerner@umich > > On Fri, 9 Jan 2004, Nathan A. Baker wrote: > > >>Dear Michael -- >> >> >>>I've written some code that lets you use PyMOL ( >>><http://pymol.sourceforge.net> ) to run some simple electrostatics >>>calculations with APBS and look at the results. You can find the >>>code, etc. at http://www.umich.edu/~mlerner/Pymol/ if you're >>>interested. It's not quite ready for prime-time, though, as you have >>>to recompile PyMOL to get it to work (I think/hope this won't be true >>>for long). I'll probably post about this again when it becomes >>>easier to use (my guess is that that'll be with the next release of >>>PyMOL). I have a few comments and questions: >> >>This looks great! I'd like to centralize plugins (as much as >>possible) with APBS. Is there any chance you'd be willing to let us >>either place this on our web server and/or package it with APBS (with >>full acknowledgements to you, of course). If not, are you planning to >>have this included with PyMOL? I'm just interested in making sure >>this gets distributed and maintained. >> >> >>>- I haven't used APBS much .. I've attached a typical .in file at the end >>>of this email .. could someone tell me if it seems reasonable? >> >>It looks more-or-less OK; there are some "=" characters that shouldn't >>be there. You might look at apbs/examples/misc for a good potential >>calculation example. >> >> >>>- psize.py doesn't let you specify FADD on the command line. Is this on >>>purpose? Even if I add in code to make it a valid command line option, it >>>doesn't do what I want. Later on, I want to draw a surface 10A from the >>>protein. I need to make sure that the grid is big enough for that. Can I >>>do that with psize? (I was in a bit of a hurry, so I added a CADD option >>>(analogous to FADD) and called psize.py with --FADD=20 and --CADD=20 .. is >>>that the right thing to do?) I'd really like to know the answer to this >>>question .. I haven't used APBS much, so I have no intuition for what the >>>grid spacing, etc. should be, and I hope I can just trust my hacked >>>version of psize.py. >> >>Thanks for letting us know. I'm Cc'ing our programmer, Todd Dolinsky, who >>will take care of this. >> >> >>>- psize.py can't parse the output of the pqr files that I get from >>>http://nbcr.sdsc.edu/pdb2pqr/ (the web-based PDB2PQR service). psize.py >>>expects different column alignments (in particular, it wants the x,y,z >>>coordinates to be in the same positions as they are in PDB files). I have >>>a really simple Python function that rewrites the pqr files, but it seems >>>like this should be fixed. My stupid Python function just does this: >>> >>>linetype,num,aname,res,resn,x,y,z,charge,radius,atype = line.split() >>>goodLine = '%-6s%5s%5s%4s%6s %8s%8s%8s %6s %4s%12s'%(linetype,num,aname,res,resn,x,y,z,charge,radius,atype) >>> >>>but it seems to work for me. >> >>Again thanks; I'll pass this along to Todd. >> >> >>>- All of the example input files I found use mg-manual, but the APBS >>>users guide makes it look like mg-auto is the way to go, so my code uses >>>mg-auto. mg-auto seems to require 'srfm' even though the users guide >>>(http://agave.wustl.edu/apbs/doc/api/html/#mg-auto) doesn't mention it. >> >>That omission has been fixed in a more recent version of APBS (about >>to be released) >> >> >>>- I have been using AMBER parameters for my electrostatics calculations. >>>Is this a particularly bad idea? >> >>This isn't a bad idea; lots of folks use AMBER parameters for PB >>calculations. AMBER has some of their own radii they suggest for >>MM/PBSA calculations. It might be worthwhile looking at these >> >> >>>Also, does anyone have a little script to AMBER parameter files + a >>>PDB file into a PQR file, or should I write it myself? >> >>Actually, we have a whole server dedicated to this; however, it's >>currently off-line for upgrades. The new version of APBS will include >>support for this in the main program. In the meantime, I'd suggest >>using the various scripts in the apbs/tools/ directory for PDB -> PQR. >> >> >>>- I don't really understand licensing issues, so I have some questions >>>about GPL vs. the PyMOL license (which looks basically like a BSD license >>>to me). Anyway, here are my licensing questions: >>> >>> - I stole some of my comments for the input files from one of the >>> apbs.in files that comes with APBS .. is that a problem? >> >>No; you might acknowledge the original source. >> >> >>> - I think I was looking at some of the APBS source when I wrote my code >>> that parses dx files .. probably vgrid.c I didn't directly copy any >>> code (that would be hard, since my stuff is in Python). Can I still >>> release my code under a less restrictive license (i.e. the PyMOL license), >>> or do I need to rewrite that part first? >> >>As far as I'm concerned, you can include the code under the PyMOL >>license provided you acknowledge the original code and note that it >>was covered under GPL. >> >> >>> - Right now, my code generates a .in file, calls apbs from the command >>> line and parses the resulting dx file. It would be cool if I could >>> plug directly into APBS with the stuff in tools/python. Is there any >>> way to do that without forcing my code to be GPL'd? >> >>Sure! You can use the Python wrappers independently as modules (more >>coming in the new release) without having to actually tinker with >>them. That should avoid any licensing issues. >> >> >>>Normally, I don't care about licenses. In this case, though, I'd >>>really like it if any C code I write could be folded into PyMOL. >>>This means that 1) I don't have to maintain it and 2) lots of people >>>can use it (I doubt that very many people want to recompile PyMOL >>>themselves). My guess is that the PyMOL folks might want to fold at >>>least the dx parsing stuff into PyMOL too. It was pretty easy to >>>write, and I'm sure the PyMOL folks could rewrite it pretty quickly, >>>but it'd be nice if I could just give it away. >> >>Agreed. As far as I'm concerned, the APBS GPL license is there only >>for protection and should be interpreted in the most liberal way >>possible. >> >>Thanks, >> >>Nathan >> >> >>>Here's a typical input file for a short poly-peptide: >>> >>>read >>> mol pqr /home/mlerner/small.pqr # read molecule 1 >>>end >>>elec >>> mg-auto >>> dime = 33 33 33 # number of find grid points >>> # calculated by psize.py >>> cglen = 26.416000 18.674000 19.356000 # coarse mesh lengths (A) >>> fglen = 26.416000 18.674000 19.356000 # fine mesh lengths (A) >>> grid = 0.825509 0.583578 0.604881 # fine mesh spacings >>> # calculated by psize.py >>> cgcent mol 1 # (could also give (x,y,z) form psize.py) >>> fgcent mol 1 # (could also give (x,y,z) form psize.py) >>> npbe # solve the full nonlinear PBE with npbe >>> #lpbe # wimp out and solve the linear PBE with lpbe >>> bcfl 2 # Boundary condition flag >>> # 0 => Zero >>> # 1 => Single DH sphere >>> # 2 => Multiple DH spheres >>> # 4 => Focusing >>> # READ THE MANUAL for this one. You may want a few >>> # sections here .. the first with bcfl=2 and the others >>> # with bcfl=4, for instance. >>> # >>> #ion 1 0.000 2.0 # Counterion declaration: >>> ion 1 0.000000 2.000000 # Counterion declaration: >>> ion -1 0.000000 2.000000 # ion <charge> <conc (M)> <radius> >>> ion 2 0.000000 2.000000 # ion <charge> <conc (M)> <radius> >>> # TODO: make this a sub-menu >>> pdie 20.000000 # Solute dielectric >>> sdie 80.000000 # Solvent dielectric >>> chgm 1 # Charge disc method >>> # read the manual .. 1 is cubic b-splines >>> mol 1 # which molecule to use >>> srfm 1 # Surface calculation method >>> # 0 => Mol surface for epsilon; >>> # inflated VdW for kappa; no >>> # smoothing >>> # 1 => As 0 with harmoic average >>> # smoothing >>> # 2 => Cubic spline >>> srad 1.400000 # Solvent radius (1.4 for water) >>> # TODO: put this in a sub-menu >>> swin 0.3 # Surface cubic spline window .. default 0.3 >>> temp 310.000000 # System temperature (298.15 default) >>> # TODO: put this in a sub-menu >>> gamma 0.105 # Surface tension parameter for apolar forces (in kJ/mol/A^2) >>> # only used for force calculations, so we don't care, but >>> # it's always required, and 0.105 is the default >>> calcenergy 0 # Energy I/O to stdout >>> # 0 => don't write out energy >>> # 1 => write out total energy >>> # 2 => write out total energy and all >>> # components >>> calcforce 0 # Atomic forces I/O (to stdout) >>> # 0 => don't write out forces >>> # 1 => write out net forces on molecule >>> # 2 => write out atom-level forces >>> write pot dx /home/mlerner/small.pqr # What to write .. this says write the potential in dx >>> # format to a file. >>>end >>>quit >>> >>>-- >>>This isn't a democracy;| _ |Michael Lerner >>>it's a cheer-ocracy. | ASCII ribbon campaign ( ) | Michigan >>>-Torrence, Bring It On| - against HTML email X | Biophysics >>> | / \ | mlerner@umich >>>_______________________________________________ >>>apbs-users mailing list >>>apb...@ch... >>>http://cholla.wustl.edu/mailman/listinfo/apbs-users >> >>End of message from Michael George Lerner. >> >>-- >>Nathan A. Baker, Assistant Professor >>Washington University in St. Louis School of Medicine >>Dept. of Biochemistry and Molecular Biophysics >>Center for Computational Biology >>700 S. Euclid Ave., Campus Box 8036, St. Louis, MO 63110 >>Phone: (314) 362-2040, Fax: (314) 362-0234 >>URL: http://www.biochem.wustl.edu/~baker >>PGP key: http://cholla.wustl.edu/~baker/pubkey.asc >> > > _______________________________________________ > apbs-users mailing list > apb...@ch... > http://cholla.wustl.edu/mailman/listinfo/apbs-users -- Nathan A. Baker, Assistant Professor Washington University in St. Louis School of Medicine Dept. of Biochemistry and Molecular Biophysics Center for Computational Biology 700 S. Euclid Ave., Campus Box 8036, St. Louis, MO 63110 Phone: (314) 362-2040, Fax: (314) 362-0234 URL: http://www.biochem.wustl.edu/~baker |
From: Michael G. L. <ml...@um...> - 2004-06-11 23:10:42
|
Hi Nathan, Thanks for the detailed reply. In this case, I'm not including any protein motion, so I'll probably take your recommendation of 10-15. That's still a big range, though. I'd like to know how to answer this question myself. I'm kind of embarrassed to admit it, but I've look in all of the standard references that I can think of, and I haven't found a whole lot of relevant information. Can you recommend a good reference or two? Thanks, -michael On Fri, 11 Jun 2004, Nathan Baker wrote: > Hi Michael -- > > The use of higher dielectric values inside the protein is not > necessarily aimed at capturing the effects of buried waters; higher > values describe a variety of internal relaxation modes (libration, side > chain reorientation, etc.) of the protein that are not explicitly > included in the calculation. Additionally, atomic polarizability alone > gives a dielectric constant of 2-3 in a solid. > > However, figuring out how to deconvolve the contribution from internal > motion, waters, atomic polarizability, etc. is not straightforward. If > you are including the motion of the protein explicitly (snapshots from > MD, etc.), you should use a lower value (2-3). Otherwise, I'd stick > with higher values, perhaps closer to 10 or 15 for your calculations. > > Good luck, > > Nathan > > Michael George Lerner wrote: > > > Hi, > > > > I'm trying to get a picture the electrostatics of a protein's active site. > > Usually, I look at things without explicit waters, set sdie to 80 and set > > pdie to 20. In this case, there are some waters near the active site that > > are particularly important, so I want to include them in the calculation. > > How does one usually set up the dielectric constants for situations like > > this? > > > > Please feel free to just point me at a good reference. The closest thing > > I've found so far is a Biophys J paper (Bridging Implicit and Explicit > > Solvent Approaches for Membrane Electrostatics, Lin, Baker and McCammon, > > 2002, Vol. 83, p. 1374-1479). There, they set the dielectric for explicit > > waters and lipids to 1 and 78.54 for everything else. Is this the right > > thing for me to do? > > > > I also found some text at > > http://mccammon.ucsd.edu/~jswanson/apbsDoc/command_doc2.html that implies > > that this is the right thing, but it didn't point me at any references. > > > > Thanks, > > > > -michael > > > > -- > > This isn't a democracy;| _ |Michael Lerner > > it's a cheer-ocracy. | ASCII ribbon campaign ( ) | Michigan > > -Torrence, Bring It On| - against HTML email X | Biophysics > > | / \ | mlerner@umich > > > > On Fri, 9 Jan 2004, Nathan A. Baker wrote: > > > > > >>Dear Michael -- > >> > >> > >>>I've written some code that lets you use PyMOL ( > >>><http://pymol.sourceforge.net> ) to run some simple electrostatics > >>>calculations with APBS and look at the results. You can find the > >>>code, etc. at http://www.umich.edu/~mlerner/Pymol/ if you're > >>>interested. It's not quite ready for prime-time, though, as you have > >>>to recompile PyMOL to get it to work (I think/hope this won't be true > >>>for long). I'll probably post about this again when it becomes > >>>easier to use (my guess is that that'll be with the next release of > >>>PyMOL). I have a few comments and questions: > >> > >>This looks great! I'd like to centralize plugins (as much as > >>possible) with APBS. Is there any chance you'd be willing to let us > >>either place this on our web server and/or package it with APBS (with > >>full acknowledgements to you, of course). If not, are you planning to > >>have this included with PyMOL? I'm just interested in making sure > >>this gets distributed and maintained. > >> > >> > >>>- I haven't used APBS much .. I've attached a typical .in file at the end > >>>of this email .. could someone tell me if it seems reasonable? > >> > >>It looks more-or-less OK; there are some "=" characters that shouldn't > >>be there. You might look at apbs/examples/misc for a good potential > >>calculation example. > >> > >> > >>>- psize.py doesn't let you specify FADD on the command line. Is this on > >>>purpose? Even if I add in code to make it a valid command line option, it > >>>doesn't do what I want. Later on, I want to draw a surface 10A from the > >>>protein. I need to make sure that the grid is big enough for that. Can I > >>>do that with psize? (I was in a bit of a hurry, so I added a CADD option > >>>(analogous to FADD) and called psize.py with --FADD=20 and --CADD=20 .. is > >>>that the right thing to do?) I'd really like to know the answer to this > >>>question .. I haven't used APBS much, so I have no intuition for what the > >>>grid spacing, etc. should be, and I hope I can just trust my hacked > >>>version of psize.py. > >> > >>Thanks for letting us know. I'm Cc'ing our programmer, Todd Dolinsky, who > >>will take care of this. > >> > >> > >>>- psize.py can't parse the output of the pqr files that I get from > >>>http://nbcr.sdsc.edu/pdb2pqr/ (the web-based PDB2PQR service). psize.py > >>>expects different column alignments (in particular, it wants the x,y,z > >>>coordinates to be in the same positions as they are in PDB files). I have > >>>a really simple Python function that rewrites the pqr files, but it seems > >>>like this should be fixed. My stupid Python function just does this: > >>> > >>>linetype,num,aname,res,resn,x,y,z,charge,radius,atype = line.split() > >>>goodLine = '%-6s%5s%5s%4s%6s %8s%8s%8s %6s %4s%12s'%(linetype,num,aname,res,resn,x,y,z,charge,radius,atype) > >>> > >>>but it seems to work for me. > >> > >>Again thanks; I'll pass this along to Todd. > >> > >> > >>>- All of the example input files I found use mg-manual, but the APBS > >>>users guide makes it look like mg-auto is the way to go, so my code uses > >>>mg-auto. mg-auto seems to require 'srfm' even though the users guide > >>>(http://agave.wustl.edu/apbs/doc/api/html/#mg-auto) doesn't mention it. > >> > >>That omission has been fixed in a more recent version of APBS (about > >>to be released) > >> > >> > >>>- I have been using AMBER parameters for my electrostatics calculations. > >>>Is this a particularly bad idea? > >> > >>This isn't a bad idea; lots of folks use AMBER parameters for PB > >>calculations. AMBER has some of their own radii they suggest for > >>MM/PBSA calculations. It might be worthwhile looking at these > >> > >> > >>>Also, does anyone have a little script to AMBER parameter files + a > >>>PDB file into a PQR file, or should I write it myself? > >> > >>Actually, we have a whole server dedicated to this; however, it's > >>currently off-line for upgrades. The new version of APBS will include > >>support for this in the main program. In the meantime, I'd suggest > >>using the various scripts in the apbs/tools/ directory for PDB -> PQR. > >> > >> > >>>- I don't really understand licensing issues, so I have some questions > >>>about GPL vs. the PyMOL license (which looks basically like a BSD license > >>>to me). Anyway, here are my licensing questions: > >>> > >>> - I stole some of my comments for the input files from one of the > >>> apbs.in files that comes with APBS .. is that a problem? > >> > >>No; you might acknowledge the original source. > >> > >> > >>> - I think I was looking at some of the APBS source when I wrote my code > >>> that parses dx files .. probably vgrid.c I didn't directly copy any > >>> code (that would be hard, since my stuff is in Python). Can I still > >>> release my code under a less restrictive license (i.e. the PyMOL license), > >>> or do I need to rewrite that part first? > >> > >>As far as I'm concerned, you can include the code under the PyMOL > >>license provided you acknowledge the original code and note that it > >>was covered under GPL. > >> > >> > >>> - Right now, my code generates a .in file, calls apbs from the command > >>> line and parses the resulting dx file. It would be cool if I could > >>> plug directly into APBS with the stuff in tools/python. Is there any > >>> way to do that without forcing my code to be GPL'd? > >> > >>Sure! You can use the Python wrappers independently as modules (more > >>coming in the new release) without having to actually tinker with > >>them. That should avoid any licensing issues. > >> > >> > >>>Normally, I don't care about licenses. In this case, though, I'd > >>>really like it if any C code I write could be folded into PyMOL. > >>>This means that 1) I don't have to maintain it and 2) lots of people > >>>can use it (I doubt that very many people want to recompile PyMOL > >>>themselves). My guess is that the PyMOL folks might want to fold at > >>>least the dx parsing stuff into PyMOL too. It was pretty easy to > >>>write, and I'm sure the PyMOL folks could rewrite it pretty quickly, > >>>but it'd be nice if I could just give it away. > >> > >>Agreed. As far as I'm concerned, the APBS GPL license is there only > >>for protection and should be interpreted in the most liberal way > >>possible. > >> > >>Thanks, > >> > >>Nathan > >> > >> > >>>Here's a typical input file for a short poly-peptide: > >>> > >>>read > >>> mol pqr /home/mlerner/small.pqr # read molecule 1 > >>>end > >>>elec > >>> mg-auto > >>> dime = 33 33 33 # number of find grid points > >>> # calculated by psize.py > >>> cglen = 26.416000 18.674000 19.356000 # coarse mesh lengths (A) > >>> fglen = 26.416000 18.674000 19.356000 # fine mesh lengths (A) > >>> grid = 0.825509 0.583578 0.604881 # fine mesh spacings > >>> # calculated by psize.py > >>> cgcent mol 1 # (could also give (x,y,z) form psize.py) > >>> fgcent mol 1 # (could also give (x,y,z) form psize.py) > >>> npbe # solve the full nonlinear PBE with npbe > >>> #lpbe # wimp out and solve the linear PBE with lpbe > >>> bcfl 2 # Boundary condition flag > >>> # 0 => Zero > >>> # 1 => Single DH sphere > >>> # 2 => Multiple DH spheres > >>> # 4 => Focusing > >>> # READ THE MANUAL for this one. You may want a few > >>> # sections here .. the first with bcfl=2 and the others > >>> # with bcfl=4, for instance. > >>> # > >>> #ion 1 0.000 2.0 # Counterion declaration: > >>> ion 1 0.000000 2.000000 # Counterion declaration: > >>> ion -1 0.000000 2.000000 # ion <charge> <conc (M)> <radius> > >>> ion 2 0.000000 2.000000 # ion <charge> <conc (M)> <radius> > >>> # TODO: make this a sub-menu > >>> pdie 20.000000 # Solute dielectric > >>> sdie 80.000000 # Solvent dielectric > >>> chgm 1 # Charge disc method > >>> # read the manual .. 1 is cubic b-splines > >>> mol 1 # which molecule to use > >>> srfm 1 # Surface calculation method > >>> # 0 => Mol surface for epsilon; > >>> # inflated VdW for kappa; no > >>> # smoothing > >>> # 1 => As 0 with harmoic average > >>> # smoothing > >>> # 2 => Cubic spline > >>> srad 1.400000 # Solvent radius (1.4 for water) > >>> # TODO: put this in a sub-menu > >>> swin 0.3 # Surface cubic spline window .. default 0.3 > >>> temp 310.000000 # System temperature (298.15 default) > >>> # TODO: put this in a sub-menu > >>> gamma 0.105 # Surface tension parameter for apolar forces (in kJ/mol/A^2) > >>> # only used for force calculations, so we don't care, but > >>> # it's always required, and 0.105 is the default > >>> calcenergy 0 # Energy I/O to stdout > >>> # 0 => don't write out energy > >>> # 1 => write out total energy > >>> # 2 => write out total energy and all > >>> # components > >>> calcforce 0 # Atomic forces I/O (to stdout) > >>> # 0 => don't write out forces > >>> # 1 => write out net forces on molecule > >>> # 2 => write out atom-level forces > >>> write pot dx /home/mlerner/small.pqr # What to write .. this says write the potential in dx > >>> # format to a file. > >>>end > >>>quit > >>> > >>>-- > >>>This isn't a democracy;| _ |Michael Lerner > >>>it's a cheer-ocracy. | ASCII ribbon campaign ( ) | Michigan > >>>-Torrence, Bring It On| - against HTML email X | Biophysics > >>> | / \ | mlerner@umich > >>>_______________________________________________ > >>>apbs-users mailing list > >>>apb...@ch... > >>>http://cholla.wustl.edu/mailman/listinfo/apbs-users > >> > >>End of message from Michael George Lerner. > >> > >>-- > >>Nathan A. Baker, Assistant Professor > >>Washington University in St. Louis School of Medicine > >>Dept. of Biochemistry and Molecular Biophysics > >>Center for Computational Biology > >>700 S. Euclid Ave., Campus Box 8036, St. Louis, MO 63110 > >>Phone: (314) 362-2040, Fax: (314) 362-0234 > >>URL: http://www.biochem.wustl.edu/~baker > >>PGP key: http://cholla.wustl.edu/~baker/pubkey.asc > >> > > > > _______________________________________________ > > apbs-users mailing list > > apb...@ch... > > http://cholla.wustl.edu/mailman/listinfo/apbs-users > > -- > Nathan A. Baker, Assistant Professor > Washington University in St. Louis School of Medicine > Dept. of Biochemistry and Molecular Biophysics > Center for Computational Biology > 700 S. Euclid Ave., Campus Box 8036, St. Louis, MO 63110 > Phone: (314) 362-2040, Fax: (314) 362-0234 > URL: http://www.biochem.wustl.edu/~baker > > |
From: Nathan B. <ba...@bi...> - 2004-06-14 13:27:42
|
Hi Michael -- Hopefully other folks on the list will have good references as well; my list is not particularly comprehensive. In addition to work by Bertrand Garcia-Moreno and Arieh Warshel, I'd look at the following references as a entrez into the broader literature: Pack GR, Garrett GA, Wong L and Lamm G. (1993) The effect of a variable dielectric coefficient and finite ion size on Poisson-Boltzmann calculations of DNA-electrolyte systems. Biophys J, 65 (4), 1363-1370. <http://www.ncbi.nlm.nih.gov/entrez/query.fcgi?cmd=Retrieve&db=PubMed&dopt=Citation&list_uids=8274630> Simonson T. (1999) Dielectric relaxation in proteins: Microscopic and macroscopic models. Int J Quantum Chem, 75 (1), 45-57. <http://www3.interscience.wiley.com/cgi-bin/abstract/55001580/ABSTRACT> Roux B and Simonson T. (1999) Implicit solvent models. Biophys Chem, 78 (1-2), 1-20. <http://dx.doi.org/10.1016/S0301-4622(98)00226-9> Gilson M, Rashin A, Fine R and Honig B. (1985) On the calculation of electrostatic interactions in proteins. J Mol Biol, 183, 503-516. <http://www.ncbi.nlm.nih.gov/entrez/query.fcgi?cmd=Retrieve&db=PubMed&dopt=Citation&list_uids=4046024> Gilson M. (2000) Introduction to continuum electrostatics. In Beard, D. A. (ed.), Biophysics Textbook Online. Biophysical Society, Bethesda, MD, Vol. Computational Biology. <http://www.biophysics.org/btol> Georgescu RE, Alexov EG and Gunner MR. (2002) Combining Conformational Flexibility and Continuum Electrostatics for Calculating pKas in Proteins. Biophys J, 83 (4), 1731-1748. <http://www.biophysj.org/cgi/content/abstract/83/4/1731> Michael George Lerner wrote: > Hi Nathan, > > Thanks for the detailed reply. In this case, I'm not including any > protein motion, so I'll probably take your recommendation of 10-15. > That's still a big range, though. > > I'd like to know how to answer this question myself. I'm kind of > embarrassed to admit it, but I've look in all of the standard references > that I can think of, and I haven't found a whole lot of relevant > information. Can you recommend a good reference or two? > > Thanks, > > -michael > > On Fri, 11 Jun 2004, Nathan Baker wrote: > > >>Hi Michael -- >> >>The use of higher dielectric values inside the protein is not >>necessarily aimed at capturing the effects of buried waters; higher >>values describe a variety of internal relaxation modes (libration, side >>chain reorientation, etc.) of the protein that are not explicitly >>included in the calculation. Additionally, atomic polarizability alone >>gives a dielectric constant of 2-3 in a solid. >> >>However, figuring out how to deconvolve the contribution from internal >>motion, waters, atomic polarizability, etc. is not straightforward. If >>you are including the motion of the protein explicitly (snapshots from >>MD, etc.), you should use a lower value (2-3). Otherwise, I'd stick >>with higher values, perhaps closer to 10 or 15 for your calculations. >> >>Good luck, >> >>Nathan >> >>Michael George Lerner wrote: >> >> >>>Hi, >>> >>>I'm trying to get a picture the electrostatics of a protein's active site. >>>Usually, I look at things without explicit waters, set sdie to 80 and set >>>pdie to 20. In this case, there are some waters near the active site that >>>are particularly important, so I want to include them in the calculation. >>>How does one usually set up the dielectric constants for situations like >>>this? >>> >>>Please feel free to just point me at a good reference. The closest thing >>>I've found so far is a Biophys J paper (Bridging Implicit and Explicit >>>Solvent Approaches for Membrane Electrostatics, Lin, Baker and McCammon, >>>2002, Vol. 83, p. 1374-1479). There, they set the dielectric for explicit >>>waters and lipids to 1 and 78.54 for everything else. Is this the right >>>thing for me to do? >>> >>>I also found some text at >>>http://mccammon.ucsd.edu/~jswanson/apbsDoc/command_doc2.html that implies >>>that this is the right thing, but it didn't point me at any references. >>> >>>Thanks, >>> >>>-michael >>> >>>-- >>>This isn't a democracy;| _ |Michael Lerner >>> it's a cheer-ocracy. | ASCII ribbon campaign ( ) | Michigan >>>-Torrence, Bring It On| - against HTML email X | Biophysics >>> | / \ | mlerner@umich >>> >>>On Fri, 9 Jan 2004, Nathan A. Baker wrote: >>> >>> >>> >>>>Dear Michael -- >>>> >>>> >>>> >>>>>I've written some code that lets you use PyMOL ( >>>>><http://pymol.sourceforge.net> ) to run some simple electrostatics >>>>>calculations with APBS and look at the results. You can find the >>>>>code, etc. at http://www.umich.edu/~mlerner/Pymol/ if you're >>>>>interested. It's not quite ready for prime-time, though, as you have >>>>>to recompile PyMOL to get it to work (I think/hope this won't be true >>>>>for long). I'll probably post about this again when it becomes >>>>>easier to use (my guess is that that'll be with the next release of >>>>>PyMOL). I have a few comments and questions: >>>> >>>>This looks great! I'd like to centralize plugins (as much as >>>>possible) with APBS. Is there any chance you'd be willing to let us >>>>either place this on our web server and/or package it with APBS (with >>>>full acknowledgements to you, of course). If not, are you planning to >>>>have this included with PyMOL? I'm just interested in making sure >>>>this gets distributed and maintained. >>>> >>>> >>>> >>>>>- I haven't used APBS much .. I've attached a typical .in file at the end >>>>>of this email .. could someone tell me if it seems reasonable? >>>> >>>>It looks more-or-less OK; there are some "=" characters that shouldn't >>>>be there. You might look at apbs/examples/misc for a good potential >>>>calculation example. >>>> >>>> >>>> >>>>>- psize.py doesn't let you specify FADD on the command line. Is this on >>>>>purpose? Even if I add in code to make it a valid command line option, it >>>>>doesn't do what I want. Later on, I want to draw a surface 10A from the >>>>>protein. I need to make sure that the grid is big enough for that. Can I >>>>>do that with psize? (I was in a bit of a hurry, so I added a CADD option >>>>>(analogous to FADD) and called psize.py with --FADD=20 and --CADD=20 .. is >>>>>that the right thing to do?) I'd really like to know the answer to this >>>>>question .. I haven't used APBS much, so I have no intuition for what the >>>>>grid spacing, etc. should be, and I hope I can just trust my hacked >>>>>version of psize.py. >>>> >>>>Thanks for letting us know. I'm Cc'ing our programmer, Todd Dolinsky, who >>>>will take care of this. >>>> >>>> >>>> >>>>>- psize.py can't parse the output of the pqr files that I get from >>>>>http://nbcr.sdsc.edu/pdb2pqr/ (the web-based PDB2PQR service). psize.py >>>>>expects different column alignments (in particular, it wants the x,y,z >>>>>coordinates to be in the same positions as they are in PDB files). I have >>>>>a really simple Python function that rewrites the pqr files, but it seems >>>>>like this should be fixed. My stupid Python function just does this: >>>>> >>>>>linetype,num,aname,res,resn,x,y,z,charge,radius,atype = line.split() >>>>>goodLine = '%-6s%5s%5s%4s%6s %8s%8s%8s %6s %4s%12s'%(linetype,num,aname,res,resn,x,y,z,charge,radius,atype) >>>>> >>>>>but it seems to work for me. >>>> >>>>Again thanks; I'll pass this along to Todd. >>>> >>>> >>>> >>>>>- All of the example input files I found use mg-manual, but the APBS >>>>>users guide makes it look like mg-auto is the way to go, so my code uses >>>>>mg-auto. mg-auto seems to require 'srfm' even though the users guide >>>>>(http://agave.wustl.edu/apbs/doc/api/html/#mg-auto) doesn't mention it. >>>> >>>>That omission has been fixed in a more recent version of APBS (about >>>>to be released) >>>> >>>> >>>> >>>>>- I have been using AMBER parameters for my electrostatics calculations. >>>>>Is this a particularly bad idea? >>>> >>>>This isn't a bad idea; lots of folks use AMBER parameters for PB >>>>calculations. AMBER has some of their own radii they suggest for >>>>MM/PBSA calculations. It might be worthwhile looking at these >>>> >>>> >>>> >>>>>Also, does anyone have a little script to AMBER parameter files + a >>>>>PDB file into a PQR file, or should I write it myself? >>>> >>>>Actually, we have a whole server dedicated to this; however, it's >>>>currently off-line for upgrades. The new version of APBS will include >>>>support for this in the main program. In the meantime, I'd suggest >>>>using the various scripts in the apbs/tools/ directory for PDB -> PQR. >>>> >>>> >>>> >>>>>- I don't really understand licensing issues, so I have some questions >>>>>about GPL vs. the PyMOL license (which looks basically like a BSD license >>>>>to me). Anyway, here are my licensing questions: >>>>> >>>>> - I stole some of my comments for the input files from one of the >>>>> apbs.in files that comes with APBS .. is that a problem? >>>> >>>>No; you might acknowledge the original source. >>>> >>>> >>>> >>>>> - I think I was looking at some of the APBS source when I wrote my code >>>>> that parses dx files .. probably vgrid.c I didn't directly copy any >>>>> code (that would be hard, since my stuff is in Python). Can I still >>>>> release my code under a less restrictive license (i.e. the PyMOL license), >>>>> or do I need to rewrite that part first? >>>> >>>>As far as I'm concerned, you can include the code under the PyMOL >>>>license provided you acknowledge the original code and note that it >>>>was covered under GPL. >>>> >>>> >>>> >>>>> - Right now, my code generates a .in file, calls apbs from the command >>>>> line and parses the resulting dx file. It would be cool if I could >>>>> plug directly into APBS with the stuff in tools/python. Is there any >>>>> way to do that without forcing my code to be GPL'd? >>>> >>>>Sure! You can use the Python wrappers independently as modules (more >>>>coming in the new release) without having to actually tinker with >>>>them. That should avoid any licensing issues. >>>> >>>> >>>> >>>>>Normally, I don't care about licenses. In this case, though, I'd >>>>>really like it if any C code I write could be folded into PyMOL. >>>>>This means that 1) I don't have to maintain it and 2) lots of people >>>>>can use it (I doubt that very many people want to recompile PyMOL >>>>>themselves). My guess is that the PyMOL folks might want to fold at >>>>>least the dx parsing stuff into PyMOL too. It was pretty easy to >>>>>write, and I'm sure the PyMOL folks could rewrite it pretty quickly, >>>>>but it'd be nice if I could just give it away. >>>> >>>>Agreed. As far as I'm concerned, the APBS GPL license is there only >>>>for protection and should be interpreted in the most liberal way >>>>possible. >>>> >>>>Thanks, >>>> >>>>Nathan >>>> >>>> >>>> >>>>>Here's a typical input file for a short poly-peptide: >>>>> >>>>>read >>>>> mol pqr /home/mlerner/small.pqr # read molecule 1 >>>>>end >>>>>elec >>>>> mg-auto >>>>> dime = 33 33 33 # number of find grid points >>>>> # calculated by psize.py >>>>> cglen = 26.416000 18.674000 19.356000 # coarse mesh lengths (A) >>>>> fglen = 26.416000 18.674000 19.356000 # fine mesh lengths (A) >>>>> grid = 0.825509 0.583578 0.604881 # fine mesh spacings >>>>> # calculated by psize.py >>>>> cgcent mol 1 # (could also give (x,y,z) form psize.py) >>>>> fgcent mol 1 # (could also give (x,y,z) form psize.py) >>>>> npbe # solve the full nonlinear PBE with npbe >>>>> #lpbe # wimp out and solve the linear PBE with lpbe >>>>> bcfl 2 # Boundary condition flag >>>>> # 0 => Zero >>>>> # 1 => Single DH sphere >>>>> # 2 => Multiple DH spheres >>>>> # 4 => Focusing >>>>> # READ THE MANUAL for this one. You may want a few >>>>> # sections here .. the first with bcfl=2 and the others >>>>> # with bcfl=4, for instance. >>>>> # >>>>> #ion 1 0.000 2.0 # Counterion declaration: >>>>> ion 1 0.000000 2.000000 # Counterion declaration: >>>>> ion -1 0.000000 2.000000 # ion <charge> <conc (M)> <radius> >>>>> ion 2 0.000000 2.000000 # ion <charge> <conc (M)> <radius> >>>>> # TODO: make this a sub-menu >>>>> pdie 20.000000 # Solute dielectric >>>>> sdie 80.000000 # Solvent dielectric >>>>> chgm 1 # Charge disc method >>>>> # read the manual .. 1 is cubic b-splines >>>>> mol 1 # which molecule to use >>>>> srfm 1 # Surface calculation method >>>>> # 0 => Mol surface for epsilon; >>>>> # inflated VdW for kappa; no >>>>> # smoothing >>>>> # 1 => As 0 with harmoic average >>>>> # smoothing >>>>> # 2 => Cubic spline >>>>> srad 1.400000 # Solvent radius (1.4 for water) >>>>> # TODO: put this in a sub-menu >>>>> swin 0.3 # Surface cubic spline window .. default 0.3 >>>>> temp 310.000000 # System temperature (298.15 default) >>>>> # TODO: put this in a sub-menu >>>>> gamma 0.105 # Surface tension parameter for apolar forces (in kJ/mol/A^2) >>>>> # only used for force calculations, so we don't care, but >>>>> # it's always required, and 0.105 is the default >>>>> calcenergy 0 # Energy I/O to stdout >>>>> # 0 => don't write out energy >>>>> # 1 => write out total energy >>>>> # 2 => write out total energy and all >>>>> # components >>>>> calcforce 0 # Atomic forces I/O (to stdout) >>>>> # 0 => don't write out forces >>>>> # 1 => write out net forces on molecule >>>>> # 2 => write out atom-level forces >>>>> write pot dx /home/mlerner/small.pqr # What to write .. this says write the potential in dx >>>>> # format to a file. >>>>>end >>>>>quit >>>>> >>>>>-- >>>>>This isn't a democracy;| _ |Michael Lerner >>>>>it's a cheer-ocracy. | ASCII ribbon campaign ( ) | Michigan >>>>>-Torrence, Bring It On| - against HTML email X | Biophysics >>>>> | / \ | mlerner@umich >>>>>_______________________________________________ >>>>>apbs-users mailing list >>>>>apb...@ch... >>>>>http://cholla.wustl.edu/mailman/listinfo/apbs-users >>>> >>>>End of message from Michael George Lerner. >>>> >>>>-- >>>>Nathan A. Baker, Assistant Professor >>>>Washington University in St. Louis School of Medicine >>>>Dept. of Biochemistry and Molecular Biophysics >>>>Center for Computational Biology >>>>700 S. Euclid Ave., Campus Box 8036, St. Louis, MO 63110 >>>>Phone: (314) 362-2040, Fax: (314) 362-0234 >>>>URL: http://www.biochem.wustl.edu/~baker >>>>PGP key: http://cholla.wustl.edu/~baker/pubkey.asc >>>> >>> >>>_______________________________________________ >>>apbs-users mailing list >>>apb...@ch... >>>http://cholla.wustl.edu/mailman/listinfo/apbs-users >> >>-- >>Nathan A. Baker, Assistant Professor >>Washington University in St. Louis School of Medicine >>Dept. of Biochemistry and Molecular Biophysics >>Center for Computational Biology >>700 S. Euclid Ave., Campus Box 8036, St. Louis, MO 63110 >>Phone: (314) 362-2040, Fax: (314) 362-0234 >>URL: http://www.biochem.wustl.edu/~baker >> >> -- Nathan A. Baker, Assistant Professor Washington University in St. Louis School of Medicine Dept. of Biochemistry and Molecular Biophysics Center for Computational Biology 700 S. Euclid Ave., Campus Box 8036, St. Louis, MO 63110 Phone: (314) 362-2040, Fax: (314) 362-0234 URL: http://www.biochem.wustl.edu/~baker |