Re: [ccp4bb] nad woes
Hi Jan, at low occupancy (and I suppose a resolution that does not extend beyond 2.0 A), you have to rely on your restraints. I think the consensus is that the adenine ring should be planar. The pyridine ring of the nicotinamide should be flat if the ring is oxidized (NAD+), and can be distorted when reduced (NADH). Most NAD molecules in the PDB have strict planar restaints in the pyridine ring of the nicotinamide, even when the density clearly shows that they are puckered. Many NAD+ cofactors get converted to NADH during crystallization by the enzyme they bind. Especially PEG can contain a substrates to convert NAD+ into NADH in the crystal. Best regards, Rob Meijers Synchrotron Soleil --- On Thu, 3/19/09, Jan Abendroth jan.abendr...@gmail.com wrote: From: Jan Abendroth jan.abendr...@gmail.com Subject: [ccp4bb] nad woes To: CCP4BB@JISCMAIL.AC.UK Date: Thursday, March 19, 2009, 12:50 AM Hi all, is there any wisdom on NAD out there? I experience some strange behaviour of this common cofactor. With moderately convincing density, probably low occupancy of a cofactor that came along for the ride from E coli, Refmac5.5.0088 pulls the AN6 atom out of the adenine plane. With my own library that puts planar restraints on the adenine ring this seems to be fixed. Coot during real space refinement or regularisation using either the standard or my own dictionary handles the purine ring just fine, however, totally garbles up the nicotineamide. Btw, I use the * nomenclature. Cheers Jan -- Jan Abendroth deCODE biostructures Seattle / Bainbridge Island WA, USA work: JAbendroth_at_decode.is home: Jan.Abendroth_at_gmail.com
Re: [ccp4bb] Refmac5 on Windows
I can confirm this: I see the following running times for the exact same job under linux with no other work being done on the machine: ccp4.6.1.1 Refmac_5.5.0072: End of Refmac_5.5.0072 Times: User: 176.1s System: 78.2s Elapsed: 4:15 ccp4.6.0.2 Refmac_5.4.0062: End of Refmac_5.4.0062 Times: User: 71.0s System:5.5s Elapsed: 1:18 ccp4-6.1.1 installed 2 days ago from the automatic download page. i have not startet tracing the problem yet, a quick check on the ccp4 page did not show any known bugs. did i miss something ? it sure does make a big difference for the user. ingo Philip Leonard wrote: Have any other Windows users noticed that Refmac5 runs much slower on the same job when you upgrade from CCP4 6.0.2 to 6.1.1? Best regards, Phil Leonard. DISCLAIMER: This e-mail and any attachments are confidential. They may contain privileged information and are intended for the named addressee(s) only. If you are not the named addressee do not disseminate, distribute, copy or retain this e-mail, or any part of it, in any manner. Please notify the sender immediately if you have received this e-mail by mistake and delete it from your system. The sender does not accept any liability for any errors or omissions in the contents of this message, which arise as a result of e-mail transmission. Unless expressly stated, opinions in this e-mail are those of the individual sender, and not of Galapagos NV or any of its subsidiaries including BioFocus DPI. Galapagos NV and its subsidiaries including BioFocus DPI reserve the right to monitor all e-mail communications through its network. Although this e-mail has been scanned for all known viruses, the sender does not guarantee that this message is virus-free and disclaims any liability for viruses that may be transmitted with this message. -- CRELUX GmbH Dr. Ingo Korndoerfer Head of Crystallography Am Klopferspitz 19a 82152 München Germany Phone: +49 89 700760210 Fax: +49 89 700760222 korndoer...@crelux.com www.crelux.com Amtsgericht München HRB 165552 - Managing Directors: Dr. Michael Schäffer, Dr. Ismail Moarefi This e-mail contais confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and destroy this e-mail. Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden. Diese E-Mail enthält vertrauliche und/oder rechtlich geschützte Informationen. Wenn Sie nicht der richtige Adressat sind oder diese E-Mail irrtümlich erhalten haben, informieren Sie bitte sofort den Absender und vernichten Sie diese Mail. Das unerlaubte Kopieren sowie die unbefugte Weitergabe dieser Mail ist nicht gestattet. begin:vcard fn:Ingo Korndoerfer n:Korndoerfer;Ingo org:Grelux GmbH;Crystallography adr:;;Am Klopferspitz 19a;Martinsried;;82152;Germany email;internet:korndoer...@crelux.com title:Head of Crystallography tel;work:+49 89 700760210 tel;fax:+49 89 700760222 x-mozilla-html:FALSE url:www.crelux.com version:2.1 end:vcard
Re: [ccp4bb] nad woes
Even for NAD I think I would make my own new dictionary. If you go to the ebi site ( now pdbe) ask for Msdchem ( is it PDBeChem now?) Get the idealised NAD coordinates with the remediated nomenclature Submit the coordnates to the ProDrg server. Retrieve the REFMAC dictionary Use PDB and dictionary in Coot to fit the ligand.. Eleanor Get back an idealised dictionary Jan Abendroth wrote: Hi all, is there any wisdom on NAD out there? I experience some strange behaviour of this common cofactor. With moderately convincing density, probably low occupancy of a cofactor that came along for the ride from E coli, Refmac5.5.0088 pulls the AN6 atom out of the adenine plane. With my own library that puts planar restraints on the adenine ring this seems to be fixed. Coot during real space refinement or regularisation using either the standard or my own dictionary handles the purine ring just fine, however, totally garbles up the nicotineamide. Btw, I use the * nomenclature. Cheers Jan -- Jan Abendroth deCODE biostructures Seattle / Bainbridge Island WA, USA work: JAbendroth_at_decode.is home: Jan.Abendroth_at_gmail.com
Re: [ccp4bb] images
Jacob, Just for the fun, and for historical exactness... I would rather invoke Laplace for such an argumentation, whereas Poincaré should better be invoked for a very strong warning against it. Therefore, ignoring the warning and following Laplace, we could even readily extend your suggestion from back-calculating the images to solving the corresponding structures (and thus also writing the corresponding papers). And write The End (as nauseam, of course ::)) Philippe Dumas Jacob Keller a écrit : Perhaps we could use Poincare's argument(?), that knowing one cross section of the universe in all of its detail would allow forward and back-calculation of all previous states. Then the universe would be its own lab notebook/ archive, and we would not need to bother with all of these technicalities in the first place. The images, then, could be back-calculated from the current (or any) configuration of all the universe's atoms, and then we could work better on improving our crystallography software (and ferreting out fraud) from those... JPK *** Jacob Pearson Keller Northwestern University Medical Scientist Training Program Dallos Laboratory F. Searle 1-240 2240 Campus Drive Evanston IL 60208 lab: 847.491.2438 cel: 773.608.9185 email: j-kell...@northwestern.edu *** begin:vcard fn:Philippe Dumas n:Dumas;Philippe org:CNRS;Biophysique et Biologie Structurale adr;quoted-printable:15 rue Ren=C3=A9 Descartes;;IBMC;Strasbourg;;67084;France email;internet:p.du...@ibmc.u-strasbg.fr title:Directeur de Recherche tel;work:+33 (0)388 41 70 02 tel;fax:+33 (0)388 60 22 18 url:http://www-ibmc.u-strasbg.fr/arn/Dumas/index_dum_fr.html version:2.1 end:vcard
Re: [ccp4bb] imosflm STARTDIR
imosflm also takes the command line switch --startdir so you could try
an alias of
alias imosflm='imosflm --startdir $PWD'
Mark
-Original Message-
From: CCP4 bulletin board [mailto:ccp...@jiscmail.ac.uk] On Behalf Of
William G. Scott
Sent: 18 March 2009 17:17
To: CCP4BB@JISCMAIL.AC.UK
Subject: Re: [ccp4bb] imosflm STARTDIR
You could try something like this (bash/zsh/sh):
alias imosflm='MOSDIR=${PWD} imosflm'
The single quotes are required for it to do the right thing.
Bill
On Mar 18, 2009, at 6:49 AM, James Foadi wrote:
Dear MOSFLM/IMOSFLM people,
when I start the new version of imosflm I expect it to dump files and
to search all files starting from the current directory. This doesn't
seem to be the case. It appears it always starts from MOSDIR. I my
imosflm.tcl the line related to STARTDIR is:
set STARTDIR [pwd]
Perhaps somebody else has written about this, but if this is the case,
I have missed the thread.
Can somebody help me with this?
J
Dr James Foadi PhD
Membrane Protein Laboratory
Diamond Light Source Ltd.
Diamond House
Harwell Science and Innovation Campus
Didcot
Oxfordshire
OX11 0DE
United Kingdom
office email: james.fo...@diamond.ac.uk alternative email:
j.fo...@imperial.ac.uk
DIVFONT size=1 color=grayThis e-mail and any attachments may contain
confidential, copyright and or privileged material, and are for the use of the
intended addressee only. If you are not the intended addressee or an authorised
recipient of the addressee please notify us of receipt by returning the e-mail
and do not use, copy, retain, distribute or disclose the information in or
attached to the e-mail.
Any opinions expressed within this e-mail are those of the individual and not
necessarily of Diamond Light Source Ltd.
Diamond Light Source Ltd. cannot guarantee that this e-mail or any attachments
are free from viruses and we cannot accept liability for any damage which you
may sustain as a result of software viruses which may be transmitted in or with
the message.
Diamond Light Source Limited (company no. 4375679). Registered in England and
Wales with its registered office at Diamond House, Harwell Science and
Innovation Campus, Didcot, Oxfordshire, OX11 0DE, United Kingdom
/FONT/DIV
--
Scanned by iCritical.
Re: [ccp4bb] images
On Wed, 2009-03-18 at 18:19 +, Frank von Delft wrote: Maybe, but images without experimental context (sequence? ligands? purification? crystallization format? -- PURPOSE OF EXPERIMENT!?!! relationship to the other 15 similar datasets) are as good as no images. And as far as I know, there's no good discussion on the table for that. At least, no-one on the thread mentioned it, so they're probably not thinking about it either. I suppose efforts like PIMS or are a start, and maybe they can even have enough information (my feeling is they currently don't). But that's where the discussion should start: how to index (in sense of annotate) the datasets. The technicalities are just that: technicalities. Or even closer to home: does ANY detector/beamline write even timestamps into the image header...? Never mind ring current, intensity of the beam, size of beam, size of crystal, length of direct beam path, etc etc... As far as I know, most detectors write the current time into the image header. Certainly our in house MAR image plate systems do, as do the detectors at Diamond and ESRF (for those that I've looked at this morning).
Re: [ccp4bb] images
Hi Frank, I would have assumed that the purpose of the experiment would have been defined in the publication associated with the deposition - not to trivialize your point, which is very important, but to put it in context. I would also assume that the sequence and ligands are as per the associated PDB deposition. So so far we are quite a way towards being able to get something useful from this data with what we have already. The relationship to associated data sets - this is harder, certainly, but not impossible. In particular, how frequently is it the case that the measurements from these 15 similar data sets actually contribute directly to the structure solution? Obviously there is a process as defined in a lab book, but you could take the stance, at least in the first instance, that they do not directly contribute if the same conclusions would be reached in their absence. Obviously any repository must be more than an FTP site, and must allow the scientific links between structures and data to be made (for example including the model used for the successful molecular replacement.) It does seem clear to me though that we cannot set up the perfect repository in the first instance, but we do have to start somewhere. Perhaps we do not need the right answer, but one which is less wrong that not making available the data at all? Just my thoughts on this. Cheers, Graeme 2009/3/18 Frank von Delft frank.vonde...@sgc.ox.ac.uk: Maybe, but images without experimental context (sequence? ligands? purification? crystallization format? -- PURPOSE OF EXPERIMENT!?!! relationship to the other 15 similar datasets) are as good as no images. And as far as I know, there's no good discussion on the table for that. At least, no-one on the thread mentioned it, so they're probably not thinking about it either. I suppose efforts like PIMS or are a start, and maybe they can even have enough information (my feeling is they currently don't). But that's where the discussion should start: how to index (in sense of annotate) the datasets. The technicalities are just that: technicalities. Or even closer to home: does ANY detector/beamline write even timestamps into the image header...? Never mind ring current, intensity of the beam, size of beam, size of crystal, length of direct beam path, etc etc... phx Gerard Bricogne wrote: Dear Bernhard, I suppose you meant ad nauseam ;-) . In any case, what is the use of discussions and recommendations that are not followed by action, and only result in making their contributors themselves nauseated to the point of wanting to put this to rest? As Ethan has nicely stated in his reply to Garib's double-check of whether we do need images, this matter should NOT be put to rest: it should be dealt with. As was argued at the end of the paper by Joosten, Womack et al. (Acta Cryst. D65, 176-185), the main advantage of depositing images would be that it would enable and stimulate the further developement and testing of image integration and data processing software, to the same degree that the deposition of structure factors has stimulated progress and testing for structure refinement software. Far from a boring issue only capable of giving headaches to Standards Committee members, this is a vital issue: with each undeposited set of images that contributed in one way or another to the determination or refinement of a deposited structure, there disappears an opportunity to test improvements in methods and software that would be likely to improve that deposited entry (and most others) at a future stage. I think we need to take a long view on this, and abandon the picture of the PDB as a static archive of frozen results: instead, it should be seen as a repository of what is required not only to validate/authenticate the deposited models, but to feed the continued improvement of the methods used - and hence, at the next iteration, the constant revision and improvement of those very models. In what way can this topic be a source of nausea? With best wishes, Gerard. -- On Wed, Mar 18, 2009 at 10:16:42AM -0700, Bernhard Rupp wrote: As Herb will attest, the need for keeping images and the various reasons for it have been discussed ad nauseum and agreed upon in various imgCIF meetings - I am sure Herb or Andy Howard can provide links to the documents/recommendations, to put this to rest. Best, BR Past ACA Data Standards Committee serf -Original Message- From: CCP4 bulletin board [mailto:ccp...@jiscmail.ac.uk] On Behalf Of Kay Diederichs Sent: Wednesday, March 18, 2009 10:02 AM To: CCP4BB@JISCMAIL.AC.UK Subject: Re: [ccp4bb] images
[ccp4bb] TLS refinement in 6.1.1
Dear Martin, this should be fixed in the latest refmac version http://www.ysbl.york.ac.uk/~garib/refmac/latest_refmac.html Please let us know if it is not! Pavol. -- Sent from: Leiden ZH Netherlands.
Re: [ccp4bb] images
Dear Bernhard, Thank you for this suggestion. The question is: who outside the US can be in? I would be most happy to contribute to arguing the scientific case (in the broadest sense) for the benefits of such an initiative, and to play whatever role I can in getting (other people to put ...) the nuts and bolts in place. Could you broadcast the information about this kind of grant? With best wishes, Gerard. -- On Wed, Mar 18, 2009 at 04:24:18PM -0700, Bernhard Rupp wrote: All right: How about then putting in a NIH challenge grant (due April 27) for image archiving? Who is in? BR -Original Message- From: Gerard Bricogne [mailto:g...@globalphasing.com] Sent: Wednesday, March 18, 2009 4:12 PM To: Bernhard Rupp Cc: 'Gerard Bricogne'; CCP4BB@JISCMAIL.AC.UK Subject: Re: [ccp4bb] images Dear Bernhard, Re-reading your previous message, I can see that I did indeed misread it, and I apologise for that. Perhaps it was the expression put to rest in relation to a topic where so much action is needed that made me charge in the wrong direction. Although this thread is now attracting additional suggestions about what else it might be a good thing to archive, this should not result in a dilution of the urgency of this particular item. As for the argument that any new task can only be done if there is extra money, then isn't this the ideal time to argue that we need a PDB stimulus package? After all, the PDB is a bank ... . With best wishes, Gerard. -- On Wed, Mar 18, 2009 at 12:14:29PM -0700, Bernhard Rupp wrote: Maybe I was misunderstood. There is no doubt in my opinion and that of those that have put effort into image conservation issues years ago that keeping and archiving the images is more than desirable, for precisely the reasons mentioned. Nail my nauseating spell checker for the nausea that may have caused you. Cheers, BR -Original Message- From: CCP4 bulletin board [mailto:ccp...@jiscmail.ac.uk] On Behalf Of Gerard Bricogne Sent: Wednesday, March 18, 2009 11:03 AM To: CCP4BB@JISCMAIL.AC.UK Subject: Re: [ccp4bb] images Dear Bernhard, I suppose you meant ad nauseam ;-) . In any case, what is the use of discussions and recommendations that are not followed by action, and only result in making their contributors themselves nauseated to the point of wanting to put this to rest? As Ethan has nicely stated in his reply to Garib's double-check of whether we do need images, this matter should NOT be put to rest: it should be dealt with. As was argued at the end of the paper by Joosten, Womack et al. (Acta Cryst. D65, 176-185), the main advantage of depositing images would be that it would enable and stimulate the further developement and testing of image integration and data processing software, to the same degree that the deposition of structure factors has stimulated progress and testing for structure refinement software. Far from a boring issue only capable of giving headaches to Standards Committee members, this is a vital issue: with each undeposited set of images that contributed in one way or another to the determination or refinement of a deposited structure, there disappears an opportunity to test improvements in methods and software that would be likely to improve that deposited entry (and most others) at a future stage. I think we need to take a long view on this, and abandon the picture of the PDB as a static archive of frozen results: instead, it should be seen as a repository of what is required not only to validate/authenticate the deposited models, but to feed the continued improvement of the methods used - and hence, at the next iteration, the constant revision and improvement of those very models. In what way can this topic be a source of nausea? With best wishes, Gerard. -- On Wed, Mar 18, 2009 at 10:16:42AM -0700, Bernhard Rupp wrote: As Herb will attest, the need for keeping images and the various reasons for it have been discussed ad nauseum and agreed upon in various imgCIF meetings - I am sure Herb or Andy Howard can provide links to the documents/recommendations, to put this to rest. Best, BR Past ACA Data Standards Committee serf -Original Message- From: CCP4 bulletin board [mailto:ccp...@jiscmail.ac.uk] On Behalf Of Kay Diederichs Sent: Wednesday, March 18, 2009 10:02 AM To: CCP4BB@JISCMAIL.AC.UK Subject: Re: [ccp4bb] images -- === * * * Gerard Bricogne g...@globalphasing.com * * * * Global Phasing Ltd.
Re: [ccp4bb] imosflm STARTDIR
Hi folks
The real problem here is that the imosflm you run by default after
installing the latest CCP4 is a shell script in $CBIN (i.e. where all
the compiled programs are), which doesn't actually set things up
properly. This has been addressed by the guys in Daresbury and the fix
will appear in the next release (after which you should be able to
ignore the rest of this message).
If, on the other hand, you run the imosflm in the directory $CCP4/
ccp4i/imosflm/src, everything should be hunky-dory - you can do this
by setting your PATH environment variable so it finds this script
first, e.g. in tcsh -
setenv PATH $CCP4/ccp4i/imosflm/src:$PATH
_after_ doing the normal source'ing ccp4.setup; then imosflm on the
command line should work.
The other option would be to install imosflm from our web-pages and
run that, but since this is currently the one that ccp4 distribute
there's no obvious advantage to that, other than removing the ambiguity.
HTH
On 19 Mar 2009, at 10:03, Williams, MA (Mark) wrote:
imosflm also takes the command line switch --startdir so you could try
an alias of
alias imosflm='imosflm --startdir $PWD'
Mark
-Original Message-
From: CCP4 bulletin board [mailto:ccp...@jiscmail.ac.uk] On Behalf Of
William G. Scott
Sent: 18 March 2009 17:17
To: CCP4BB@JISCMAIL.AC.UK
Subject: Re: [ccp4bb] imosflm STARTDIR
You could try something like this (bash/zsh/sh):
alias imosflm='MOSDIR=${PWD} imosflm'
The single quotes are required for it to do the right thing.
Bill
On Mar 18, 2009, at 6:49 AM, James Foadi wrote:
Dear MOSFLM/IMOSFLM people,
when I start the new version of imosflm I expect it to dump files and
to search all files starting from the current directory. This doesn't
seem to be the case. It appears it always starts from MOSDIR. I my
imosflm.tcl the line related to STARTDIR is:
set STARTDIR [pwd]
Perhaps somebody else has written about this, but if this is the
case,
I have missed the thread.
Can somebody help me with this?
J
Dr James Foadi PhD
Membrane Protein Laboratory
Diamond Light Source Ltd.
Diamond House
Harwell Science and Innovation Campus
Didcot
Oxfordshire
OX11 0DE
United Kingdom
office email: james.fo...@diamond.ac.uk alternative email:
j.fo...@imperial.ac.uk
DIVFONT size=1 color=grayThis e-mail and any attachments may
contain confidential, copyright and or privileged material, and are
for the use of the intended addressee only. If you are not the
intended addressee or an authorised recipient of the addressee
please notify us of receipt by returning the e-mail and do not use,
copy, retain, distribute or disclose the information in or attached
to the e-mail.
Any opinions expressed within this e-mail are those of the
individual and not necessarily of Diamond Light Source Ltd.
Diamond Light Source Ltd. cannot guarantee that this e-mail or any
attachments are free from viruses and we cannot accept liability for
any damage which you may sustain as a result of software viruses
which may be transmitted in or with the message.
Diamond Light Source Limited (company no. 4375679). Registered in
England and Wales with its registered office at Diamond House,
Harwell Science and Innovation Campus, Didcot, Oxfordshire, OX11
0DE, United Kingdom
/FONT/DIV
--
Scanned by iCritical.
Harry
--
Dr Harry Powell, MRC Laboratory of Molecular Biology, MRC Centre,
Hills Road, Cambridge, CB2 0QH
[ccp4bb] Sample shipping question
For your amusement/outrage: A user of our synchrotron shipped samples in a deWar from overseas. The deWar was held up by U.S. Customs, and we received the following from a FedEx employee: --- This shipment is delayed with US Customs. We need to know the amount of salt in the shipment in kilograms. I have attached the commercial invoice. Can you provide this info? Thank you. (name redacted) Senior ECO Import Coordinator FedEx Trade Networks --- - === You can't possibly be a scientist if you mind people thinking that you're a fool. - Wonko the Sane === David J. Schuller modern man in a post-modern world MacCHESS, Cornell University schul...@cornell.edu
Re: [ccp4bb] nad woes
Rob, Thanks for the tips of wisdom. Is the 3 letter code for NADH something different, or is it NAD as well? Ditto for FMN and its reduced form.Thomas Edwards-CCP4 bulletin board CCP4BB@JISCMAIL.AC.UK wrote: -To: CCP4BB@JISCMAIL.AC.UKFrom: Rob Meijers ccp4spama...@yahoo.comSent by: CCP4 bulletin board CCP4BB@JISCMAIL.AC.UKDate: 03/19/2009 01:01AMSubject: Re: [ccp4bb] nad woesHi Jan, at low occupancy (and I suppose a resolution that does not extend beyond 2.0 A), you have to rely on your restraints. I think the consensus is that the adenine ring should be planar. The pyridine ring of the nicotinamide should be flat if the ring is oxidized (NAD+), and can be distorted when reduced (NADH). Most NAD molecules in the PDB have strict planar restaints in the pyridine ring of the nicotinamide, even when the density clearly shows that they are puckered. Many NAD+ cofactors get converted to NADH during crystallization by the enzyme they bind. Especially PEG can contain a substrates to convert NAD+ into NADH in the crystal. Best regards, Rob Meijers Synchrotron Soleil --- On Thu, 3/19/09, Jan Abendroth jan.abendr...@gmail.com wrote: From: Jan Abendroth jan.abendr...@gmail.com Subject: [ccp4bb] nad woes To: CCP4BB@JISCMAIL.AC.UK Date: Thursday, March 19, 2009, 12:50 AM Hi all,is there any wisdom on NAD out there? I experience some strange behaviour ofthis common cofactor.With moderately convincing density, probably low occupancy of a cofactor thatcame along for the ride from E coli, Refmac5.5.0088 pulls the AN6 atom out ofthe adenine plane. With my own library that puts planar restraints on theadenine ring this seems to be fixed.Coot during real space refinement or regularisation using either the standardor my own dictionary handles the purine ring just fine, however, totally garblesup the nicotineamide.Btw, I use the * nomenclature.CheersJan--Jan AbendrothdeCODE biostructuresSeattle /Bainbridge Island WA, USAwork: JAbendroth_at_decode.ishome: Jan.Abendroth_at_gmail.com
Re: [ccp4bb] nad woes - yet another question regarding ligand restraints
Is there a chance that ThDP (TDP or TPP in the ccp4 dictionary) is restrained differently in 6.1.x than it used to be in 6.02 or even earlier versions (e.g. 5.2) ? Boaz - Original Message - From: Eleanor Dodson c...@ysbl.york.ac.uk Date: Thursday, March 19, 2009 11:17 Subject: Re: [ccp4bb] nad woes To: CCP4BB@JISCMAIL.AC.UK Even for NAD I think I would make my own new dictionary. If you go to the ebi site ( now pdbe) ask for Msdchem ( is it PDBeChem now?) Get the idealised NAD coordinates with the remediated nomenclature Submit the coordnates to the ProDrg server. Retrieve the REFMAC dictionary Use PDB and dictionary in Coot to fit the ligand.. Eleanor Get back an idealised dictionary Jan Abendroth wrote: Hi all, is there any wisdom on NAD out there? I experience some strange behaviour of this common cofactor. With moderately convincing density, probably low occupancy of a cofactor that came along for the ride from E coli, Refmac5.5.0088 pulls the AN6 atom out of the adenine plane. With my own library that puts planar restraints on the adenine ring this seems to be fixed. Coot during real space refinement or regularisation using either the standard or my own dictionary handles the purine ring just fine, however, totally garbles up the nicotineamide. Btw, I use the * nomenclature. Cheers Jan -- Jan Abendroth deCODE biostructures Seattle / Bainbridge Island WA, USA work: JAbendroth_at_decode.is home: Jan.Abendroth_at_gmail.com Boaz Shaanan, Ph.D. Dept. of Life Sciences Ben-Gurion University of the Negev Beer-Sheva 84105 Israel Phone: 972-8-647-2220 ; Fax: 646-1710 Skype: boaz.shaanan
Re: [ccp4bb] nad woes
Eleanor Dodson wrote: Even for NAD I think I would make my own new dictionary. I must say that I would not (in the general case that is, there may be an argument for doing so for NAD). There will be a price to pay at deposition time. To address your particular problem (and Ignoring the problems of the hydrogens for now) the issue of the explosion in the nicotinamide is due to a mismatch between the dictionary name and the PDB name for the nitrogen atoms, NN1 and NN7. Coot has an algorithm to map the dictionary names to PDB file names, but the NN1 and NN7 are convolutedly (and erroneously) named (IMHO) that it does not match properly. You can get round this by editing the dictionary for NAD (I get mine from LIBCHECK [1]), changing occurrences of NN1 to 'NN1 ' (i.e. include a quoted space at the end of the 3 chars). Do the same for NN7 - 'NN7 '. Then read in that file to Coot: File - Import CIF dictionary and Coot will be happy. This is the current situation - things will change when Coot moves to PDB version 3.x-formatted dictionary. [1] note that for NAD, LIBCHECK will produce a dictionary that will idealise the riboses to flatness (but without a plane restraints, interestingly enough) Paul.
[ccp4bb] Computing and X-ray Scientist- Job opening
St. Jude Children's Research Hospital in Memphis, Tennessee has an opening for a Computing and X-ray Scientist in the Department of Structural Biology. The manager would be responsible for administering computing infrastructure within the department and maintaining the X-ray facilities. The ideal candidate would have expertise in LINUX/OSX systems administration and all aspects of macromolecular crystallography, in particular, the use and implementation of crystallographic software packages, data collection and processing, and structure determination and refinement. Experience in the maintenance of in-house X-ray equipment would be an advantage, but these skills can be acquired through courses that the candidate will be expected to attend. Expertise in programming and small molecule crystallography would also be viewed favorably. The department has a flexible array of LINUX/OSX workstations with access to a 10 Tbyte server and an institutional supercomputer, two Bruker rotating anodes and CCD detectors, and remote access to the SER-CAT beam-lines at the APS. The candidate should have excellent communication, organizational and interpersonal skills, and will be expected to interact productively with faculty, postdoctoral fellows and graduate students within the Department. Please contact Dr. Stephen White via e-mail (stephen.wh...@stjude.org) for further information. Qualifications: PhD or Masters in appropriate scientific field plus 5 years of relevant experience. Email Disclaimer: www.stjude.org/emaildisclaimer
[ccp4bb] purification
Hello everyone, I am expressing a 100 KDa eukaryotic membrane protein in E coli. The protein is fused to 6His-MBP in the N terminus and the resulting mass is ~ 150 KDa. However, the protein get severely degraded so after putting through a Ni-NTA column, the protein came out with a lot of contaminant bands. I did a western blot using antibody against his tag. The total cell lysate gave signals in many bands. The flow through did not give any signal and the eluted fraction again gave many band signals, indicating the protein got degraded copiously even before purification. I used Roche protease inhibitor tablet and still got a lot of degradation. Can anyone suggest a way to avoid the problem or a purification method so that I can purify the intact protein while keeping away the unwanted degraded fractions. Thanks heaps in advance. Kien
Re: [ccp4bb] purification
Put the His-tag at C-terminus. Remove rare codons Optimize sequence for translation You probably got truncations not degradations. Chun -Original Message- From: CCP4 bulletin board [mailto:ccp...@jiscmail.ac.uk] On Behalf Of Kn Ly Sent: Thursday, March 19, 2009 4:53 PM To: CCP4BB@JISCMAIL.AC.UK Subject: [ccp4bb] purification Hello everyone, I am expressing a 100 KDa eukaryotic membrane protein in E coli. The protein is fused to 6His-MBP in the N terminus and the resulting mass is ~ 150 KDa. However, the protein get severely degraded so after putting through a Ni-NTA column, the protein came out with a lot of contaminant bands. I did a western blot using antibody against his tag. The total cell lysate gave signals in many bands. The flow through did not give any signal and the eluted fraction again gave many band signals, indicating the protein got degraded copiously even before purification. I used Roche protease inhibitor tablet and still got a lot of degradation. Can anyone suggest a way to avoid the problem or a purification method so that I can purify the intact protein while keeping away the unwanted degraded fractions. Thanks heaps in advance. Kien
Re: [ccp4bb] purification
Hi, The details of the experiment are a bit sketchy. Is this a transmembrane protein or an associated one? What percentage of the structure is expected to associate with the lipid bilayer? Do you know the correct orientation of the protein with respect to the bilayer (i.e. what's inside and what's outside)? Membrane proteins can be extremely tricky. There are many types of problems that can be relevant here (like abortive translation brought up by Chun Luo), but my best guess is that your protein just isn't being folded correctly and therefore it activates the heat-shock like response (a.k.a. UPR) - causing the kind of proteolysis that you are observing. What this means is that you have to find a way for this protein to fold correctly, which may require you to insert it into the membrane or make sure that membrane approach is established (you did not mention the presence of any kind of membrane-targeting signal, so we have to assume you don't have any in the current construct). You are also facing a strong likelihood that this protein may not work out in E. coli and you have to switch to insect cells or yeast, or mammalian cells in the end. Artem --- When the Weasel comes to give New Year's greetings to the Chickens no good intentions are in his mind. -Original Message- From: CCP4 bulletin board [mailto:ccp...@jiscmail.ac.uk] On Behalf Of Kn Ly Sent: Thursday, March 19, 2009 7:53 PM To: CCP4BB@JISCMAIL.AC.UK Subject: [ccp4bb] purification Hello everyone, I am expressing a 100 KDa eukaryotic membrane protein in E coli. The protein is fused to 6His-MBP in the N terminus and the resulting mass is ~ 150 KDa. However, the protein get severely degraded so after putting through a Ni-NTA column, the protein came out with a lot of contaminant bands. I did a western blot using antibody against his tag. The total cell lysate gave signals in many bands. The flow through did not give any signal and the eluted fraction again gave many band signals, indicating the protein got degraded copiously even before purification. I used Roche protease inhibitor tablet and still got a lot of degradation. Can anyone suggest a way to avoid the problem or a purification method so that I can purify the intact protein while keeping away the unwanted degraded fractions. Thanks heaps in advance. Kien
Re: [ccp4bb] nad woes
I agree with Paul: use the standard dictionary if at all possible. It's strange: I've not had any trouble with NADPH (NDP) in refmac recently---as long as I had the correct atom names. Is there a typographical error in the standard NAD dictionary entry? Dave David Borhani, Ph.D. D. E. Shaw Research 120 West Forty-Fifth Street, 39th Floor New York, NY 10036 david.borh...@deshawresearch.com 212-478-0698 http://www.deshawresearch.com -Original Message- From: CCP4 bulletin board [mailto:ccp...@jiscmail.ac.uk] On Behalf Of Paul Emsley Sent: Thursday, March 19, 2009 1:04 PM To: CCP4BB@JISCMAIL.AC.UK Subject: Re: [ccp4bb] nad woes Eleanor Dodson wrote: Even for NAD I think I would make my own new dictionary. I must say that I would not (in the general case that is, there may be an argument for doing so for NAD). There will be a price to pay at deposition time. To address your particular problem (and Ignoring the problems of the hydrogens for now) the issue of the explosion in the nicotinamide is due to a mismatch between the dictionary name and the PDB name for the nitrogen atoms, NN1 and NN7. Coot has an algorithm to map the dictionary names to PDB file names, but the NN1 and NN7 are convolutedly (and erroneously) named (IMHO) that it does not match properly. You can get round this by editing the dictionary for NAD (I get mine from LIBCHECK [1]), changing occurrences of NN1 to 'NN1 ' (i.e. include a quoted space at the end of the 3 chars). Do the same for NN7 - 'NN7 '. Then read in that file to Coot: File - Import CIF dictionary and Coot will be happy. This is the current situation - things will change when Coot moves to PDB version 3.x-formatted dictionary. [1] note that for NAD, LIBCHECK will produce a dictionary that will idealise the riboses to flatness (but without a plane restraints, interestingly enough) Paul.
