[ccp4bb] RNA Protease
Hi All, I figure after the discussion on reverse translatase (A+ for the name) that this question is fair game: Does anyone know of a bona fide RNA protease (a protease made exclusively from RNA)? James
[ccp4bb] Linker sequence for fusion protein
Dear CCP4 List Members, I am looking for a program that could help me to design the better sequence for a linker for a fusion protein. I found some references about the LINKER program, but the web server link didn't work. Is there a new link for this program or may be could you advise me on other programs or web servers to do this work. thanks a lot Julie Ménétrey -- julie.menet...@lebs.cnrs-gif.fr Team - Structural biology of molecular switches and motors http://www.lebs.cnrs-gif.fr/menetrey/menetrey_fr.html Laboratoire d'Enzymologie et Biochimie Structurales (LEBS) - UPR 3082 - CNRS Bât. 34 - 1 avenue de la terrasse 91198 Gif-sur-Yvette Cedex, FRANCE Tel: 33 - 1 69 82 42 45 - Fax 33 - 1 69 82 31 29
[ccp4bb] Postdoc Position at University Goettingen, Germany
Postdoc Position at University Goettingen The Department of Molecular Structural Biology at the University Goettingen (http://www.uni-goettingen.de/msb) seeks to recruit a postdoctoral scientist in structural biology with a research focus directed towards the structure and dynamics of protein-RNA complexes. The advertised position is suitable for candidates with strong expertise in macromolecular X-ray crystallography or computational structural biology. An initial contract of 2 years will be offered to the successful candidate. The University Goettingen strives to increase its proportion of female staff and specifically encourages qualified women to apply. Disabled persons with corresponding aptitude for the position will be favoured. Please send your application by Email to Prof. Dr. Ralf Ficner (rfic...@uni-goettingen.de), Department of Molecular Structural Biology, GZMB, University Goettingen, Germany. Closing date for applications: September 29, 2010.
Re: [ccp4bb] Deposition of riding H
Hello, a few points to balance the discussion: - if you refined your structure without H then it's obviously ok to deposit it without H; - if you refined your structure with H, then you should deposit it with H, as your refinement software outputs it (if your software uses H but removes it automatically for you - then it least it's not your responsibility). Any post-refinement manipulation on final refined model is bad since it tends to invalidate the reported statistics (R-factors, for instance), which is illustrated in this paper (section 3.1.5: J. Appl. Cryst. (2010). 43, 669-676). Indeed, let's not add more inconsistencies to the database because of a fear that insufficiently trained people may misinterpret it. - removing H, if really needed, is a matter of one trivial command, but adding them back the exact same way they were originally is less straightforward. - I agree that the X-H distances used in refinement and in validation are slightly different, although I'm not sure how much of difference that would make for validation. Pavel. On 9/14/10 10:38 PM, Ed Pozharski wrote: Mark, On Tue, 2010-09-14 at 13:34 -0400, Dr. Mark Mayer wrote: Where does the crystallographic community stand on deposition of coordinates with riding hydrogens? Surely community is divided on this. There could be arguments made both ways. Personally, I think that riding hydrogens can be calculated if necessary using the same algorithms/parameters employed upon refinement. It is true that different programs may use different parameter sets and reproducing exactly the same set of riding hydrogens may be difficult without exact knowledge of which version was used and ability to unearth that old version of the software. This may preclude one from getting exactly the same riding hydrogen positions (how large that difference would be I honestly don't know). But really, who cares? What is the benefit of knowing exactly where this or that riding hydrogen was? Maybe there is some benefit of such comparison in method development, but I would think its rather limited. I wholeheartedly agree with Ethan (even though that is not strictly what he said :) that some minor benefit here is completely negated by the danger of perception that somehow models tell us where hydrogens are. It is bad enough that, in my estimate, roughly 10% of atomic coordinates in the PDB are unwarranted as they come from disordered residues with exact spatial positions unsupported by electron density. Let's not add more things that PDB users may over-interpret. Cheers, Ed.
Re: [ccp4bb] Deposition of riding H
Dear Pavel, On Wed, Sep 15, 2010 at 07:57:09AM -0700, Pavel Afonine wrote: > Hello, > > a few points to balance the discussion: Your points sound more sound more like a summary than a contribution to the discussion which might confuse inexperienced readers of this thread, especially if they did not follow it completely. So here me counter-balance ;-) > > - if you refined your structure without H then it's obviously ok to > deposit it without H; I do not disagree but would like to add that I believe riding atoms usually improve the refinement even at poor resolution, so one should not refine without them at the final stage in the first place. > > - if you refined your structure with H, then you should deposit it with > H, as your refinement software outputs it (if your software uses H but > removes it automatically for you - then it least it's not your > responsibility). Any post-refinement manipulation on final refined model > is bad since it tends to invalidate the reported statistics (R-factors, > for instance), which is illustrated in this paper (section 3.1.5: J. > Appl. Cryst. (2010). 43, 669-676). Indeed, let's not add more > inconsistencies to the database because of a fear that insufficiently > trained people may misinterpret it. I disagree, because since the H-atom are (usually) in a riding position and used e.g. for anti-bumping restraints, they should be considered as (software dependent, as George pointed out) restraints rather than the actual model in terms of coordinates. > > - removing H, if really needed, is a matter of one trivial command, but > adding them back the exact same way they were originally is less > straightforward. I despise the word 'trivial' and as much as there is a 'useless use of cat' there is probably also an 'unnecessary use of trivial'. Cheers, Tim > > - I agree that the X-H distances used in refinement and in validation > are slightly different, although I'm not sure how much of difference > that would make for validation. > > Pavel. > > > On 9/14/10 10:38 PM, Ed Pozharski wrote: >> Mark, >> >> On Tue, 2010-09-14 at 13:34 -0400, Dr. Mark Mayer wrote: >>> Where does the crystallographic community stand >>> on deposition of coordinates with riding >>> hydrogens? >> Surely community is divided on this. There could be arguments made both >> ways. Personally, I think that riding hydrogens can be calculated if >> necessary using the same algorithms/parameters employed upon refinement. >> It is true that different programs may use different parameter sets and >> reproducing exactly the same set of riding hydrogens may be difficult >> without exact knowledge of which version was used and ability to unearth >> that old version of the software. This may preclude one from getting >> exactly the same riding hydrogen positions (how large that difference >> would be I honestly don't know). But really, who cares? What is the >> benefit of knowing exactly where this or that riding hydrogen was? >> Maybe there is some benefit of such comparison in method development, >> but I would think its rather limited. >> >> I wholeheartedly agree with Ethan (even though that is not strictly what >> he said :) that some minor benefit here is completely negated by the >> danger of perception that somehow models tell us where hydrogens are. >> It is bad enough that, in my estimate, roughly 10% of atomic coordinates >> in the PDB are unwarranted as they come from disordered residues with >> exact spatial positions unsupported by electron density. Let's not add >> more things that PDB users may over-interpret. >> >> Cheers, >> >> Ed. -- -- Tim Gruene Institut fuer anorganische Chemie Tammannstr. 4 D-37077 Goettingen GPG Key ID = A46BEE1A signature.asc Description: Digital signature
[ccp4bb] The input of CCP4-DM
Hi, If I have the model phase PHIC, exp Fo, and sigmaa-weighted FWT, is that more reasonable to use Fo/PHIC or FWT/PHIC as the input of CCP4-DM? Thanks! Best Regards, Hailiang
Re: [ccp4bb] The input of CCP4-DM
Hailiang Zhang wrote: If I have the model phase PHIC, exp Fo, and sigmaa-weighted FWT, is that more reasonable to use Fo/PHIC or FWT/PHIC as the input of CCP4-DM? You want Fo, sigFo, PHIC and the FOM from sigmaa or refmac. You might want to try parrot as well. If you feed it your MR model it will use this to get the NCS operators and do NCS averaging automatically (dm requires a load of matrices). Kevin -- EMAIL DISCLAIMER http://www.york.ac.uk/docs/disclaimer/email.htm
Re: [ccp4bb] Deposition of riding H
While I am sympathetic to Ethan's and George's arguments, what is missing in the world as it stands is a section in PDB files that encode the parameters and rules used to generate the riding hydrogen atoms for that particular model. George has his favorite hydrogen atoms to build, his favorite bond lengths for placing them (and good arguments for his selections) and one could, I suppose, look them up in the documentation for Shelxl, but they should be encoded in the PDB file to allow automatic regeneration of the hydrogen atoms. An explicit listing of the rules for generation is particularly needed since all these matters can, and often are, modified by the user. I know that in my refinements I manually move the hydrogen from one nitrogen to the other in a couple Histidine side chains, and have created my own rules for hydrogen generation in co-factors. CIF tags will have to be agreed upon (and that's always a fun job) that would allow the description of the details of the various hydrogen atom generation schemes that are in use, or may be used in the future. It would also be handy to have a reference implementation, available under some forgiving license, that would materialize the hydrogen atoms given the PDB header information, and would reproduce the exact model refined, for any of the refinement programs. This is a worthwhile goal, but a tall order. Until this infrastructure is in place I think the hydrogen atoms have to be included in the PDB file. Otherwise it's the same as saying that I've refined TLS ADP's but not saying what the TLS parameters were nor listing the atoms in each TLS group. Dale Tronrud P.S. George: Do you think hydrogen atoms generated by the "HFIX 137" command should be deposited? They are placed based on the electron density map with the dihedral angle of the methyl group becoming a parameter of the model -- a parameter not recorded anywhere other than in the hydrogen atom locations. On 09/14/10 12:41, George M. Sheldrick wrote: > > Even though SHELXL refinements often involve resolutions of 1.5A or > better, I discourage SHELXL users from depositing their hydrogen > coordinates. There are three reasons: > > 1. The C-H, N-H and O-H distances required to give the best fit to > the electron density are significantly shorter than those required > for molecular modeling and tests on non-bonded interactions (or > located by neutron diffraction). It is ESSENTIAL to recalculate > them hydrogens at longer distances before using MolProbity and other > validation software. > > 2. There is considerable confusion concerning the names to be assigned > to the hydrogens. This is not made easier by the application of a > chirality test to -CH2- groups! > > 3. O-H hydrogens are particularly difficult to 'see' and the geometrical > calculation of their positions is often ambiguous. The same applies > to the protonation states of histidines and carboxylic acids. In > addition such hydrogen positions are often disordered. > > For refinement I recommend including C-H and N-H but not O-H hydrogens. > For very high resolution structures this reduces Rfree by 0.5-1.0% and > clearly improves the model. At all resolutions the antibumping > restraints involving hydrogens are useful. > > George > > Prof. George M. Sheldrick FRS > Dept. Structural Chemistry, > University of Goettingen, > Tammannstr. 4, > D37077 Goettingen, Germany > Tel. +49-551-39-3021 or -3068 > Fax. +49-551-39-22582 > > > On Tue, 14 Sep 2010, Dr. Mark Mayer wrote: > >> Here's one for the community, which I'll post to both Phenix and CCP4 BBs. >> >> Where does the crystallographic community stand on deposition of coordinates >> with riding hydrogens? >> Explicit H are required for calculating all atom clash scores with >> Molprobity, >> and their use frequently gives better geometry (especially at low >> resolution). >> Phenix uses explicit riding H for refinement, and outputs these in the >> refined >> PDB. Refmac also uses riding H but does not output H coordinates. >> >> While depositing a series of structures refined at 1.4 - 2.75 A with Phenix >> got the following email from the RCSB, who asked I resupply coordinates >> without H for two of the structures. Since we can't see H even at 1.4 Å I >> don't understand why an arbitrary cut off of 1.5 Å was chosen, and also why >> explicit H atoms used in refinement and geometry validation should be >> stripped >> from the file. >> >> FROM RCSB >> >> We encourage depositors not to use hydrogens in the final PDB file for >> the low resolution structures (> 1.5 A). Please provide an updated PDB >> file. We request you to use processed PDB file as a starting point for >> making any corrections to the coordinates and/or re-refinement. >> -- >> >> Mark >>
Re: [ccp4bb] Deposition of riding H
On Wednesday 15 September 2010, Pavel Afonine wrote: > - if you refined your structure with H, then you should deposit it with > H, as your refinement software outputs it As I see it, "refining your structure in the presence of riding hydrogens" is not the same thing as "refining hydrogen positions in your structure". Let's exclude those rare cases of the latter from discussion. Tim Gruene wrote: > since the H-atom are (usually) in a riding position and used > e.g. for anti-bumping restraints, they should be considered as (software > dependent, as George pointed out) restraints rather than the actual model in > terms of coordinates. I agree. The use of a riding hydrogen model is better viewed as a refinement restraint than as a refinement of actual hydrogen positions. Ethan
Re: [ccp4bb] The input of CCP4-DM
Hi Kevin: Thanks! Could you explain why the DM (NCS concerned) input should be Fo/PHIC/WCMB instead of FWT/PHIC? I thought DM is just a real-space phase improvement method, and the latter (FWT/PHIC) suffers less from model bias... Best Regards, Hailiang > Hailiang Zhang wrote: >> If I have the model phase PHIC, exp Fo, and sigmaa-weighted FWT, is that >> more reasonable to use Fo/PHIC or FWT/PHIC as the input of CCP4-DM? > > You want Fo, sigFo, PHIC and the FOM from sigmaa or refmac. > > You might want to try parrot as well. If you feed it your MR model it > will use this to get the NCS operators and do NCS averaging > automatically (dm requires a load of matrices). > > Kevin > > -- > EMAIL DISCLAIMER http://www.york.ac.uk/docs/disclaimer/email.htm > >
Re: [ccp4bb] The input of CCP4-DM
zhan...@umbc.edu wrote: Hi Kevin: Thanks! Could you explain why the DM (NCS concerned) input should be Fo/PHIC/WCMB instead of FWT/PHIC? I thought DM is just a real-space phase improvement method, and the latter (FWT/PHIC) suffers less from model bias... No, DM does phase combination in reciprocal space (i.e. a sigmaa calculation. This is also a place where parrot does a better job - it uses MLHL instead of Rice-sigmaa). To do either a sigmaa or MLHL calculation, you need to know the Fo. You can optionally input FWT/PHWT to both parrot and dm in addition to the Fo, but you absolutely must give Fo as well. Internally, dm uses mFo maps on subsequent cycles, whereas parrot uses 2mFo-DFc maps. Kevin -- EMAIL DISCLAIMER http://www.york.ac.uk/docs/disclaimer/email.htm
Re: [ccp4bb] Deposition of riding H
Dear Dale, The PDB-format is, as far as I can see, incapable of containing all the information that you can store in an .ins-file used for shelxl refinement, so the only way one could recreate the model would be to also deposit the .ins-file anyhow, which solves the problem of the riding hydrogens altogether (and much more). The pdbe.org, for example allows to upload auxiliary files and in my opinion the uploading of the final .ins-file (not the .res-file!) should be made mandatory in the case of shelxl refinement. Since coot has now become utterly convenient even for shelxl refinement, there is no reason one should not deposit the .ins-file ([flame] and the PDB-file probably for legacy reasons [/flame]). Tim On Wed, Sep 15, 2010 at 09:14:51AM -0700, Dale Tronrud wrote: >While I am sympathetic to Ethan's and George's arguments, what > is missing in the world as it stands is a section in PDB files that > encode the parameters and rules used to generate the riding hydrogen > atoms for that particular model. George has his favorite hydrogen > atoms to build, his favorite bond lengths for placing them (and good > arguments for his selections) and one could, I suppose, look them > up in the documentation for Shelxl, but they should be encoded in > the PDB file to allow automatic regeneration of the hydrogen atoms. > >An explicit listing of the rules for generation is particularly > needed since all these matters can, and often are, modified by the > user. I know that in my refinements I manually move the hydrogen > from one nitrogen to the other in a couple Histidine side chains, > and have created my own rules for hydrogen generation in co-factors. > >CIF tags will have to be agreed upon (and that's always a fun > job) that would allow the description of the details of the various > hydrogen atom generation schemes that are in use, or may be used > in the future. It would also be handy to have a reference implementation, > available under some forgiving license, that would materialize the > hydrogen atoms given the PDB header information, and would reproduce > the exact model refined, for any of the refinement programs. > >This is a worthwhile goal, but a tall order. Until this > infrastructure is in place I think the hydrogen atoms have to be > included in the PDB file. Otherwise it's the same as saying that > I've refined TLS ADP's but not saying what the TLS parameters were > nor listing the atoms in each TLS group. > > Dale Tronrud > > P.S. George: Do you think hydrogen atoms generated by the "HFIX 137" > command should be deposited? They are placed based on the electron > density map with the dihedral angle of the methyl group becoming a > parameter of the model -- a parameter not recorded anywhere other > than in the hydrogen atom locations. > > > On 09/14/10 12:41, George M. Sheldrick wrote: > > > > Even though SHELXL refinements often involve resolutions of 1.5A or > > better, I discourage SHELXL users from depositing their hydrogen > > coordinates. There are three reasons: > > > > 1. The C-H, N-H and O-H distances required to give the best fit to > > the electron density are significantly shorter than those required > > for molecular modeling and tests on non-bonded interactions (or > > located by neutron diffraction). It is ESSENTIAL to recalculate > > them hydrogens at longer distances before using MolProbity and other > > validation software. > > > > 2. There is considerable confusion concerning the names to be assigned > > to the hydrogens. This is not made easier by the application of a > > chirality test to -CH2- groups! > > > > 3. O-H hydrogens are particularly difficult to 'see' and the geometrical > > calculation of their positions is often ambiguous. The same applies > > to the protonation states of histidines and carboxylic acids. In > > addition such hydrogen positions are often disordered. > > > > For refinement I recommend including C-H and N-H but not O-H hydrogens. > > For very high resolution structures this reduces Rfree by 0.5-1.0% and > > clearly improves the model. At all resolutions the antibumping > > restraints involving hydrogens are useful. > > > > George > > > > Prof. George M. Sheldrick FRS > > Dept. Structural Chemistry, > > University of Goettingen, > > Tammannstr. 4, > > D37077 Goettingen, Germany > > Tel. +49-551-39-3021 or -3068 > > Fax. +49-551-39-22582 > > > > > > On Tue, 14 Sep 2010, Dr. Mark Mayer wrote: > > > >> Here's one for the community, which I'll post to both Phenix and CCP4 BBs. > >> > >> Where does the crystallographic community stand on deposition of > >> coordinates > >> with riding hydrogens? > >> Explicit H are required for calculating all atom clash scores with > >> Molprobity, > >> and their use frequently gives better geometry (especially at low > >> resolution). > >> Phenix uses explicit riding H for refinement, and outputs these in the > >> refined > >> PDB. Refmac also uses riding H but d
Re: [ccp4bb] Deposition of riding H
On Wed, 2010-09-15 at 07:57 -0700, Pavel Afonine wrote: > if you refined your structure with H, then you should deposit it with > H sure. But the structure is not *refined with hydrogens* when they are in predicted positions. Following the same logic one could suggest that electron density should be deposited, since we can approximate it. I think it's useful to limit the information presented in a pdb-file to what was actually refined + specific instructions on how the refinement was done. > Any post-refinement manipulation on final refined model > is bad since it tends to invalidate the reported statistics ... > Indeed, let's not add more > inconsistencies to the database because of a fear that insufficiently > trained people may misinterpret it. I wouldn't call it a post-refinement manipulation, as nothing was really changed (afaiu, in most cases riding hydrogens are placed automatically by the program and not manipulated by user). On a digressing point, you might be underestimating the problem of "misinterpretation by insufficiently trained people". -- "I'd jump in myself, if I weren't so good at whistling." Julian, King of Lemurs
Re: [ccp4bb] Deposition of riding H
Hi Tim, The pdbe.org, for example allows to upload auxiliary files and in my opinion the uploading of the final .ins-file (not the .res-file!) should be made mandatory in the case of shelxl refinement. Since coot has now become utterly convenient even for shelxl refinement, there is no reason one should not deposit the .ins-file ([flame] and the PDB-file probably for legacy reasons [/flame]). I was always wondering but never had a good occasion to ask (my Shelxl knowledge is limited and may be outdated so I apology in advance if my questions are too dummy; also I realize that I'm asking a non-CCP4 question on CCP4bb for which I apology again): - how .ins file encodes the information about NCS groups used in refinement (atom selection for NCS groups, restraint weights for different groups, etc? - how .ins file encodes the information about TLS (again, atom selections for TLS groups, TLS matrices, etc)? Related, does it have a concept of having TLS and other components to the total atomic displacement parameter (ADP)? - If I recall it correctly, to fix (=not refine) a certain parameter (say occupancy or B-factor) in Shelxl you need to add a number 10 to it. Is it true? IMHO, this might lead to confusion if such a file gets deposited to PDB. All the best! Pavel.
Re: [ccp4bb] Deposition of riding H
Pavel, Shelxl is working in correct coordinates - fractional... Many things are easier in fractional coordinates. Are you sure that Phenix does not go orthogonal -> fractional -> orthogonal in internal calculations? When fixing of parameter is made in fractional coordinates it does not produce confusion. Shelxl also make fractional -> orthogonal (AKA PDB) which is also correct. Constrain is not transferred there. BTW Shelxl knows symmetry very well and will constrain atoms that occupying symmetry elements. Shortly Shelxl knows crystallography best. When you will see number of lines in Shelxl Fortran code ( do not kill Fortran to early) you will be surprised. There are not so many of them. No graphical user interface yet, but COOT is of great help. Dr Felix Frolow Professor of Structural Biology and Biotechnology Department of Molecular Microbiology and Biotechnology Tel Aviv University 69978, Israel Acta Crystallographica F, co-editor e-mail: mbfro...@post.tau.ac.il Tel: ++972-3640-8723 Fax: ++972-3640-9407 Cellular: 0547 459 608 On Sep 15, 2010, at 19:11 , Pavel Afonine wrote: > Hi Tim, > >> The pdbe.org, for example allows to upload auxiliary files and in my opinion >> the >> uploading of the final .ins-file (not the .res-file!) should be made >> mandatory >> in the case of shelxl refinement. >> >> Since coot has now become utterly convenient even for shelxl refinement, >> there >> is no reason one should not deposit the .ins-file ([flame] and the PDB-file >> probably for legacy reasons [/flame]). > > I was always wondering but never had a good occasion to ask (my Shelxl > knowledge is limited and may be outdated so I apology in advance if my > questions are too dummy; also I realize that I'm asking a non-CCP4 question > on CCP4bb for which I apology again): > > - how .ins file encodes the information about NCS groups used in refinement > (atom selection for NCS groups, restraint weights for different groups, etc? > > - how .ins file encodes the information about TLS (again, atom selections for > TLS groups, TLS matrices, etc)? Related, does it have a concept of having TLS > and other components to the total atomic displacement parameter (ADP)? > > - If I recall it correctly, to fix (=not refine) a certain parameter (say > occupancy or B-factor) in Shelxl you need to add a number 10 to it. Is it > true? IMHO, this might lead to confusion if such a file gets deposited to PDB. > > All the best! > Pavel.
Re: [ccp4bb] Deposition of riding H
On 15 Sep 2010, at 18:04, Ed Pozharski wrote: > On Wed, 2010-09-15 at 07:57 -0700, Pavel Afonine wrote: >> if you refined your structure with H, then you should deposit it with >> H > > sure. But the structure is not *refined with hydrogens* when they are > in predicted positions. Following the same logic one could suggest that > electron density should be deposited, since we can approximate it. And I notice that a fair number of groups do deposit electron density - at least, they deposit PHIC and sometimes even HL coefficients in the sf.cif file. HL coefficients in the sf.cif file can get badly corrupted in the deposition process, but they definitely show willing. > I think it's useful to limit the information presented in a pdb-file to > what was actually refined + specific instructions on how the refinement > was done. I suppose I come to this from a background where every deposition is a fresh new test-case for new refinement software; it's only lack of download bandwidth and CPU power that makes me not want to start from the images. I like the idea that what you deposit is the output of a well-defined refinement; which means that you need to deposit the instructions for doing the refinement, and the model you used as input. There's a perfectly good PDB protocol for multi-MODEL files. Nobody does such depositions, I think the PDB would complain if you tried, and there's the problem of endless regression. I would be very happy if every PDB deposition with 'METHOD: MOLECULAR REPLACEMENT' had an extra MODEL in it containing the input to the molrep tool, and some REMARK lines describing how molrep was used; I would not complain if this was made compulsory for depositions which nowadays say 'STARTING MODEL: NULL'. 26 of the 130 depositions with method MOLECULAR REPLACEMENT this week have starting model NULL, as well as seven depositions with method FOURIER SYNTHESIS and starting model NULL. (why do MAD and SAD depositions still have a STARTING MODEL field?) (while we're on the subject of riding hydrogens, I would invite people to admire the conformations of the hydrogens in such places as the C-alpha of residues A45 and A57 of deposition 2x5n - it's clearly a software bug rather than any mistake on the part of the authors, but nonetheless striking) Tom
Re: [ccp4bb] Deposition of riding H
Dear Felix, Shortly Shelxl knows crystallography best. I have no doubts about this. May questions were, though: - how .ins file encodes the information about NCS groups used in refinement (atom selection for NCS groups, restraint weights for different groups, etc? - how .ins file encodes the information about TLS (again, atom selections for TLS groups, TLS matrices, etc)? Related, does it have a concept of having TLS and other components to the total atomic displacement parameter (ADP)? - If I recall it correctly, to fix (=not refine) a certain parameter (say occupancy or B-factor) in Shelxl you need to add a number 10 to it. Is it true? IMHO, this might lead to confusion if such a file gets deposited to PDB. Best, Pavel.
Re: [ccp4bb] Deposition of riding H + what to deposit in addition to the pdb
On Wed, 2010-09-15 at 09:14 -0700, Dale Tronrud wrote: > I know that in my refinements I manually move the hydrogen > from one nitrogen to the other in a couple Histidine side chains, > and have created my own rules for hydrogen generation in co-factors. > Excellent point. And I believe in this case you are perfectly justified to either place a comment about this in the header or indeed deposit hydrogens. But I suspect that this is not what happens in most cases with, say, 2A refinement using refmac. The program is simply used to autogenerate the riding hydrogens, thus making the whole thing perfectly reproducible (with caveats). It may be seen as misleading when one deposits these hydrogens and they appear to have the same standing as other atoms which were actually refined. On a related issue, I believe it's long overdue policy change that all the input files, e.g. command scripts/cif-files for ligands/.ins files etc. should be attached to a PDB deposition. -- "I'd jump in myself, if I weren't so good at whistling." Julian, King of Lemurs
Re: [ccp4bb] Deposition of riding H
Dear Ed, Any post-refinement manipulation on final refined model is bad since it tends to invalidate the reported statistics ... Indeed, let's not add more inconsistencies to the database because of a fear that insufficiently trained people may misinterpret it. I wouldn't call it a post-refinement manipulation, as nothing was really changed (afaiu, in most cases riding hydrogens are placed automatically by the program and not manipulated by user). On a digressing point, you might be underestimating the problem of "misinterpretation by insufficiently trained people". ... This may preclude one from getting exactly the same riding hydrogen positions (how large that difference would be I honestly don't know). But really, who cares? I wouldn't dare calling a model manipulation that typically changes the R-factor by 0.5 ... ~2% as "nothing". Although, you are may be right - "who cares"? I think the "misinterpretation by insufficiently trained people" problem should not be propagated to the database affecting the quality of depositing material. This is what I meant. Pavel.
Re: [ccp4bb] Deposition of riding H + what to deposit in addition to the pdb
>The pdbe.org, for example allows to upload auxiliary files and in my opinion the >uploading of the final .ins-file (not the .res-file!) should be made mandatory >in the case of shelxl refinement. >all the input files, e.g. command scripts/cif-files for ligands/.ins files etc. >should be attached to a PDB deposition. Having access to all input files required to reproduce (modulo program/library version) the final/published refinement would be most helpful.
Re: [ccp4bb] Deposition of riding H
Dear Pavel, May I suggest that you take a look at the SHELX manual: http://shelx.uni-ac.gwdg.de/SHELX/shelx.pdf before sending your SHELX questions to CCP4bb? You might even find some good ideas for implementing in phenix_refine! For example, if you look up 'non-crystallographic symmetry' in the index you will discover that SHELXL applies NCS in the form of restraints, not constraints, which has the advantage that it can be applied locally and in combination with all other restraints and constraints involving the same atoms. However you will not find TLS in the index, because the credit for implementing this very useful concept should be given to Martin Winn, Garib and Ethan, long after the current version of SHELXL (and its manual) were released in 1997. And because SHELXL only reads one instruction file (*.ins) and one reflection file (*.hkl) but no other data files or libraries, and FORTRAN will always be FORTRAN, the deposition of these two files would be sufficient to define the refinement for posterity. Best wishes, George Prof. George M. Sheldrick FRS Dept. Structural Chemistry, University of Goettingen, Tammannstr. 4, D37077 Goettingen, Germany Tel. +49-551-39-3021 or -3068 Fax. +49-551-39-22582 On Wed, 15 Sep 2010, Pavel Afonine wrote: > Dear Felix, > > > Shortly Shelxl knows crystallography best. > > I have no doubts about this. May questions were, though: > > > > - how .ins file encodes the information about NCS groups used in > > > refinement (atom selection for NCS groups, restraint weights for different > > > groups, etc? > > > > > > - how .ins file encodes the information about TLS (again, atom selections > > > for TLS groups, TLS matrices, etc)? Related, does it have a concept of > > > having TLS and other components to the total atomic displacement parameter > > > (ADP)? > > > > > > - If I recall it correctly, to fix (=not refine) a certain parameter (say > > > occupancy or B-factor) in Shelxl you need to add a number 10 to it. Is it > > > true? IMHO, this might lead to confusion if such a file gets deposited to > > > PDB. > > Best, > Pavel. > >
Re: [ccp4bb] Deposition of riding H
Dear George, a small correction if I may: However you will not find TLS in the index, because the credit for implementing this very useful concept should be given to Martin Winn, Garib and Ethan, long after the current version of SHELXL (and its manual) were released in 1997. Acta Cryst. (*1985*). A41, 426-433 Restrained structure-factor least-squares refinement of protein structures using a vector processing computer I. Haneef, D. S. Moss, M. J. Stanford and N. Borkakoti *Abstract:* A least-squares refinement program /RESTRAIN/ has been developed, which is capable of refining macromolecular structures using structure amplitudes, phases from isomorphous replacement or anomalous scattering and pseudo-energy restraints. In addition to positional parameters and isotropic temperature factors, anisotropic mean-square displacements may be refined either as individual atomic *U* tensors or as *TLS* tensors applied to groups of atoms. Anharmonic effects may be handled by coupling together occupancies to enable the electron density of an atomic group to be distributed over more than one subsite. A novel way of restraining groups of atoms to be planar has been developed that does not require dummy atoms and does not restrain the plane to lie in its current orientation. One can find other, earlier programs, but they are small molecule specific. Regards, Pavel.
Re: [ccp4bb] Deposition of riding H: R-factor is overrated
On Wed, 2010-09-15 at 10:50 -0700, Pavel Afonine wrote: > I wouldn't dare calling a model manipulation that typically changes > the > R-factor by 0.5 ... ~2% as "nothing". Although, you are may be right > - > "who cares"? It's not a manipulation because no parameters were manipulated in the model. Don't you agree that using the riding model does not add additional refinable parameters? But your insistence has awakened my curiosity. So I looked at hydrogens as produced by phenix.refine for a 1.8A structure I randomly picked. Just as George has pointed out, the "covalent bonds" are too short. for instance, when hydrogens are added, the average N-H distance is 1.1(5), but upon refinement the value is down to 0.85998(4). I won't even begin discussing the fact that some of these hydrogens added to K,Y,S etc are placed in positions that are not justified by data (not in definitely wrong positions either, it's just that there is no evidence to support a particular torsion angle). And that it is unlikely that every histidine in the structure is fully protonated. Do you see the problem? I fully understand your desire to be able to reproduce the R-factors (although I don't necessarily share it), but if I decide to deposit this model with hydrogens, am I essentially stating that N-H bond is magically shortened to ~0.86A? Sure, it is driver's (PDB user's) responsibility to know the meaning of the red light (riding hydrogens), but wouldn't depositing riding hydrogens be equivalent to putting 70 mph sign at the ramp, just because all the cops know that it's not the actual safe speed? And then tell the accident victim that there was a fine print in the rule book? I think this situation is particularly problematic given that these days some enter the field the same way many people (at least so it seems here in Baltimore) get their driver's licenses, i.e. without ever learning the rules? Cheers, Ed. -- "I'd jump in myself, if I weren't so good at whistling." Julian, King of Lemurs
Re: [ccp4bb] Deposition of riding H: R-factor is overrated
Dear Ed, On 9/15/10 12:54 PM, Ed Pozharski wrote: On Wed, 2010-09-15 at 10:50 -0700, Pavel Afonine wrote: I wouldn't dare calling a model manipulation that typically changes the R-factor by 0.5 ... ~2% as "nothing". Although, you are may be right - "who cares"? It's not a manipulation because no parameters were manipulated in the model. I can't agree with this, sorry. A change to a model content (especially the one that changes Fcalc) is a model manipulation. Pavel.
Re: [ccp4bb] Deposition of riding H: R-factor is overrated
On 9/15/10 3:54 PM, Ed Pozharski wrote: Don't you agree that using the riding model does not add additional refinable parameters? (snip) instance, when hydrogens are added, the average N-H distance is 1.1(5), but upon refinement the value is down to 0.85998(4). I So the riding hydrogen model is imperfect. At least with phenix.refine you can measure it, unlike the default behavior of REFMAC. (But you can tell it to write hydrogens out, I believe). Obviously this question is not one amenable to a simple answer. In some sense (as per George) riding hydrogens are merely a restraint. In some other sense they are fundamentally a part of the model - they have very directional properties via bumping restraints that most certainly alter the atomic model for the heavy atoms in a very direct way via collision. Since the nature of these atoms - locationally specific - differs from the more amorphous "extended atom" restraints (CH3E for methyl in CNS etc) it could make sense to include them in the model at deposition. As far as I know we do not delete atoms from the final model that contribute to scattering and geometric restraints under any other circumstances, except perhaps in the nearly-as-contentious "how do I model my disordered side-chain" case. Also not amenable to a simple answer. Both approaches (REFMAC-esque and PHENIX-esque) have their merits. I doubt I'm the only person here conflicted over what to do about it. However this thread appears to have reached the point where not much new ground is being broken. Phil Jeffrey Princeton
Re: [ccp4bb] History of TLS [was: Deposition of riding H]
On Wednesday 15 September 2010 12:34:21 pm Pavel Afonine wrote: > Dear George, > > a small correction if I may: > > > However > > you will not find TLS in the index, because the credit for > > implementing this very useful concept should be given to > > Martin Winn, Garib and Ethan, long after the current version > > of SHELXL (and its manual) were released in 1997. > > Acta Cryst. (*1985*). A41, 426-433 > Restrained structure-factor least-squares refinement of protein > structures using a vector processing computer > I. Haneef, D. S. Moss, M. J. Stanford and N. Borkakoti > > One can find other, earlier programs, but they are small molecule specific. The full early history of TLS is deeper than that. It is reviewed at least briefly in Driessen et al (1989) J. Appl. Cryst (1989). 22, 510-516 As to applying TLS to macromolecules, RESTRAIN was pre-dated by CORELS Sussman et al (1977) Acta Cryst. A33, 800-804 although the treatment of TLS was added some time in the early 80s; I'm not sure exactly when. And there is nothing in the original theoretical formulation of TLS by Schomaker & Trueblood (1968) Acta Cryst B24, 63-76 "On the rigid-body motion of molecules in crystals" that is small-molecule specific. In fact we went back to this as the basis for TLSMD analysis (as distinct from refinement). Note that George is pointing to implementation rather than to theory. I think it's fair to say that the improvement of computer hardware and the introduction of FFT-based refinement coincided to make application of TLS to refining macromolecules really practical only after it was introduced in refmac. I can't find the exact quote at the moment, but I recall coming across an old meeting abstract announcing that recent computer advances allowed the use of TLS to analyze structures as large as 19 atoms!!! Computation had indeed advanced a bit by the time CORELS and RESTRAIN were written, but still the contemporary state of both hardware and software limited what could be done. Ethan -- Ethan A Merritt Biomolecular Structure Center, K-428 Health Sciences Bldg University of Washington, Seattle 98195-7742
Re: [ccp4bb] Deposition of riding H [was: Deposition of riding H]
Dear Pavel, Stressing Ethan's point about TLS refinement becoming practical with Refmac implementation, Winn et al. (2001) Acta D, 57, 122-133 (I know you like references) states: Derivatives of the residual with respect to the TLS parameters are expanded in terms of the derivatives with respect to individual anisotropic U values, which in turn are calculated using a fast Fourier transform technique. TLS refinement is therefore fast and can be used routinely. Best wishes Roberto On 15 Sep 2010, at 19:34, Pavel Afonine wrote: Dear George, a small correction if I may: However you will not find TLS in the index, because the credit for implementing this very useful concept should be given to Martin Winn, Garib and Ethan, long after the current version of SHELXL (and its manual) were released in 1997. Acta Cryst. (1985). A41, 426-433 Restrained structure-factor least-squares refinement of protein structures using a vector processing computer I. Haneef, D. S. Moss, M. J. Stanford and N. Borkakoti Abstract: A least-squares refinement program RESTRAIN has been developed, which is capable of refining macromolecular structures using structure amplitudes, phases from isomorphousreplacement or anomalous scattering and pseudo-energy restraints. In addition to positional parameters and isotropic temperature factors, anisotropic mean-square displacements may be refined either as individual atomic U tensors or as TLS tensors applied to groups of atoms. Anharmonic effects may be handled by coupling together occupancies to enable the electron density of an atomic group to be distributed over more than one subsite. A novel way of restraining groups of atoms to be planar has been developed that does not require dummy atoms and does not restrain the plane to lie in its current orientation. One can find other, earlier programs, but they are small molecule specific. Regards, Pavel. --- Dr. Roberto Steiner Randall Division of Cell and Molecular Biophysics New Hunt's House King's College London Guy's Campus London, SE1 1UL Phone +44 (0)20-7848-8216 Fax +44 (0)20-7848-6435 e-mail roberto.stei...@kcl.ac.uk
Re: [ccp4bb] Deposition of riding H
However this thread appears to have reached the point where not much new ground is being broken. As the person who started this thread I'll second Phil Jeffrey's comment. I chose to continue my depositions with riding H, and the rcsb agreed to accept the coordinates. Its been great hearing the experts weigh in on this. I've learned a lot, and clearly there is no consensus. As one of the vast majority of crystallographers dependent on all the hard work that program developers undertake to support structural biology, I'm happy to follow advice given by the developers of the various programs I use, and for Phenix the current advice is to deposit with riding H. -- Mark
Re: [ccp4bb] Deposition of riding H: R-factor is overrated
On Wed, 2010-09-15 at 13:13 -0700, Pavel Afonine wrote: > I can't agree with this, sorry. A change to a model content > (especially > the one that changes Fcalc) is a model manipulation. > That is not what I asked. Do you agree that using the riding model does not add additional refinable parameters? -- "I'd jump in myself, if I weren't so good at whistling." Julian, King of Lemurs
Re: [ccp4bb] Deposition of riding H: R-factor is overrated
I should just like to point out that the main source of the disagreement here seems to be that people have very different ideas about what a 'model' is or should be. Strictly a model is a purely mathematical construct, in this case it consists of the appropriate equation for the calculated structure factor and the best-fit values of the various parameters (scattering factors, atomic positions, occupancies, B factors, TLS parameters etc.) that appear in it. A mathematical model is inevitably going to be an imperfect representation of reality, but hopefully it's the best one we can come up with, in the sense of best explaining the data without significant overfitting. The problem arises because many users of the PDB, and I suspect many contributors to this BB, particularly non-crystallographers, don't see it like that, because they view a PDB file as a physical model, i.e. not as the best fit to the data (assuming that the non-crystallographers even know what the data are!), but the closest representation of reality. The difference between the N-H bond lengths that Ed referred to illustrates the distinction between the mathematical and the physical model. The mathematical model requires that the bond length is 0.86 Ang because that value gives the best fit of the assumed spherical scattering factor of H to the deformation density of the X-H covalent bond. The physical model requires that it be 1.00 Ang because that is the internuclear distance found by spectroscopic methods & predicted by QM calculations. The same goes for B factors and TLS: to a large extent they are a mathematical construct whose purpose is to provide an optimal fit to the data. The connection of Bs & TLS with reality is tenuous at best, nevertheless people obviously would like to have a physical interpretation such as rigid-body correlated motion. The fact that Bragg scattering provides no information about correlated motion (you need to measure the diffuse scattering for that) doesn't seem to deter them! I have no doubt in my mind that it is the mathematical model that should be published, because hopefully it's the best available interpretation of the data. Whether that involves publishing the riding H atoms explicitly, or alternatively the formulae and parameters that were used to calculate their positions I don't mind, as long as I can faithfully reproduce the Fcalcs to check the validity of the model. Then users of the PDB are free to *interpret* the mathematical models as physical models in a appropriate manner (e.g. by adjusting the bond lengths to H), and crystallographers have the untainted mathematical models needed to reproduce the Fcalcs. Cheers -- Ian On Wed, Sep 15, 2010 at 9:13 PM, Pavel Afonine wrote: > Dear Ed, > > On 9/15/10 12:54 PM, Ed Pozharski wrote: >> >> On Wed, 2010-09-15 at 10:50 -0700, Pavel Afonine wrote: >>> >>> I wouldn't dare calling a model manipulation that typically changes >>> the >>> R-factor by 0.5 ... ~2% as "nothing". Although, you are may be right >>> - >>> "who cares"? >> >> It's not a manipulation because no parameters were manipulated in the >> model. > > I can't agree with this, sorry. A change to a model content (especially the > one that changes Fcalc) is a model manipulation. > > Pavel. >
Re: [ccp4bb] Deposition of riding H: R-factor is overrated
On Wed, 2010-09-15 at 16:26 -0400, Phil Jeffrey wrote: > So the riding hydrogen model is imperfect. At least with > phenix.refine > you can measure it, unlike the default behavior of REFMAC. (But you > can > tell it to write hydrogens out, I believe). > My impression is that default behavior of phenix.refine is the same - I had to change parameters to include hydrogens in the output. Without breaking any new ground, there is really no conflict here. Is it a good idea to make a complete model description (including riding hydrogens, input files, cif-files, special case restraints etc) available for structures deposited in the PDB? Absolutely. But not in this form, when model is implying that we know the protonation states of all the atoms and has unreasonable geometry. For the example that I provided, the rmsd_bonds for that particular group is 0.14A, certainly unacceptable. Maybe one can use different record for these atoms, say RIDING instead of ATOM. Thus "complete model" can be recovered and at the same time the nature of these items is explicitly stated. In this way riding hydrogens are clearly distinguished from those that are actually refined at ultrahigh resolution. Cheers, Ed. -- "I'd jump in myself, if I weren't so good at whistling." Julian, King of Lemurs
Re: [ccp4bb] Deposition of riding H: R-factor is overrated
Dear Ed, On 9/15/10 2:47 PM, Ed Pozharski wrote: On Wed, 2010-09-15 at 16:26 -0400, Phil Jeffrey wrote: So the riding hydrogen model is imperfect. At least with phenix.refine you can measure it, unlike the default behavior of REFMAC. (But you can tell it to write hydrogens out, I believe). My impression is that default behavior of phenix.refine is the same - I had to change parameters to include hydrogens in the output. No, if your input file contains H atoms, the output file will contain them too (in phenix.refine). You don't have to change any parameters for this. Pavel.
Re: [ccp4bb] Deposition of riding H: R-factor is overrated
Sure. But if I start with model that has no hydrogens, they will be generated but not passed to the output, right. just like refmac. On Wed, 2010-09-15 at 14:52 -0700, Pavel Afonine wrote: > Dear Ed, > > On 9/15/10 2:47 PM, Ed Pozharski wrote: > > On Wed, 2010-09-15 at 16:26 -0400, Phil Jeffrey wrote: > >> So the riding hydrogen model is imperfect. At least with > >> phenix.refine > >> you can measure it, unlike the default behavior of REFMAC. (But you > >> can > >> tell it to write hydrogens out, I believe). > >> > > My impression is that default behavior of phenix.refine is the same - I > > had to change parameters to include hydrogens in the output. > > No, if your input file contains H atoms, the output file will contain > them too (in phenix.refine). You don't have to change any parameters for > this. > > Pavel. > -- "I'd jump in myself, if I weren't so good at whistling." Julian, King of Lemurs
Re: [ccp4bb] Deposition of riding H: R-factor is overrated
Dear Ed, no, if you start with model that has no hydrogens, they will not be generated internally. Pavel. On 9/15/10 2:58 PM, Ed Pozharski wrote: Sure. But if I start with model that has no hydrogens, they will be generated but not passed to the output, right. just like refmac. On Wed, 2010-09-15 at 14:52 -0700, Pavel Afonine wrote: Dear Ed, On 9/15/10 2:47 PM, Ed Pozharski wrote: On Wed, 2010-09-15 at 16:26 -0400, Phil Jeffrey wrote: So the riding hydrogen model is imperfect. At least with phenix.refine you can measure it, unlike the default behavior of REFMAC. (But you can tell it to write hydrogens out, I believe). My impression is that default behavior of phenix.refine is the same - I had to change parameters to include hydrogens in the output. No, if your input file contains H atoms, the output file will contain them too (in phenix.refine). You don't have to change any parameters for this. Pavel.
Re: [ccp4bb] Deposition of riding H
Pavel: In my original email I very carefully gave credit for IMPLEMENTING the TLS concept. Of course the ideas and some programs had been around long before, but it was the IMPLEMENTATION IN REFMAC that resulted in TLS becoming widely used. I had actually considered putting it into SHELXL but had not done so for two reasons (a) I was too lazy and (b) I missed an essential trick that REFMAC introduced, namely the combination of TLS with an additive isotropic B-value for each atom. Dale: You are quite correct that AFIX 137 breaks my argument about not depositing (SHELX) hydrogen atoms because they can be recalculated with no loss of experimental information. However to be fair, if you generate the first .ins file using SHELXPRO (the recommended procedure) you will get AFIX 33 that doesn't have this problem. For Pavel and others unfamiliar with SHELXL, AFIX 33 is a pure riding model with a staggered methyl group but AFIX 137 assumes local threefold symmetry, finds the initial torsion angle by a three-fold averaged fit to the difference density and then refines the torsion angle in the following cycles. Since this torsion angle is not given explicitly in the output files, if AFIX 137 hydrogens are not deposited, they cannot be regenerated except by a full refinement against the experimental data. George Prof. George M. Sheldrick FRS Dept. Structural Chemistry, University of Goettingen, Tammannstr. 4, D37077 Goettingen, Germany Tel. +49-551-39-3021 or -3068 Fax. +49-551-39-22582 On Wed, 15 Sep 2010, George M. Sheldrick wrote: > Dear Pavel, > > May I suggest that you take a look at the SHELX manual: > http://shelx.uni-ac.gwdg.de/SHELX/shelx.pdf > before sending your SHELX questions to CCP4bb? You might > even find some good ideas for implementing in phenix_refine! > > For example, > if you look up 'non-crystallographic symmetry' in the index > you will discover that SHELXL applies NCS in the form of > restraints, not constraints, which has the advantage that it > can be applied locally and in combination with all other > restraints and constraints involving the same atoms. However > you will not find TLS in the index, because the credit for > implementing this very useful concept should be given to > Martin Winn, Garib and Ethan, long after the current version > of SHELXL (and its manual) were released in 1997. And because > SHELXL only reads one instruction file (*.ins) and one > reflection file (*.hkl) but no other data files or libraries, > and FORTRAN will always be FORTRAN, the deposition of these > two files would be sufficient to define the refinement for > posterity. > > Best wishes, George > > Prof. George M. Sheldrick FRS > Dept. Structural Chemistry, > University of Goettingen, > Tammannstr. 4, > D37077 Goettingen, Germany > Tel. +49-551-39-3021 or -3068 > Fax. +49-551-39-22582 > > > On Wed, 15 Sep 2010, Pavel Afonine wrote: > > > Dear Felix, > > > > > Shortly Shelxl knows crystallography best. > > > > I have no doubts about this. May questions were, though: > > > > > > - how .ins file encodes the information about NCS groups used in > > > > refinement (atom selection for NCS groups, restraint weights for > > > > different > > > > groups, etc? > > > > > > > > - how .ins file encodes the information about TLS (again, atom > > > > selections > > > > for TLS groups, TLS matrices, etc)? Related, does it have a concept of > > > > having TLS and other components to the total atomic displacement > > > > parameter > > > > (ADP)? > > > > > > > > - If I recall it correctly, to fix (=not refine) a certain parameter > > > > (say > > > > occupancy or B-factor) in Shelxl you need to add a number 10 to it. Is > > > > it > > > > true? IMHO, this might lead to confusion if such a file gets deposited > > > > to > > > > PDB. > > > > Best, > > Pavel. > > > > > >
Re: [ccp4bb] Deposition of riding H
Hi All, I have not read all messages in the trace so my apologies if somebody already pointed out what I have to say. There is lot of talk about how this or that software treats the riding hydrogens. What to do with the fact that however these hydrogens are treated in calculations, they are, in most cases, still assumed? Meents et al http://scripts.iucr.org/cgi-bin/paper?xh0004 showed that proteins are stripped of hydrogens during X-ray data collection. So, IMHO it is a good argument against depositing the H coordinates in PDB. Cheers, N. Ruslan Sanishvili (Nukri), Ph.D. GM/CA-CAT Biosciences Division, ANL 9700 S. Cass Ave. Argonne, IL 60439 Tel: (630)252-0665 Fax: (630)252-0667 rsanishv...@anl.gov -Original Message- From: CCP4 bulletin board [mailto:ccp...@jiscmail.ac.uk] On Behalf Of George M. Sheldrick Sent: Wednesday, September 15, 2010 5:14 PM To: CCP4BB@JISCMAIL.AC.UK Subject: Re: [ccp4bb] Deposition of riding H Pavel: In my original email I very carefully gave credit for IMPLEMENTING the TLS concept. Of course the ideas and some programs had been around long before, but it was the IMPLEMENTATION IN REFMAC that resulted in TLS becoming widely used. I had actually considered putting it into SHELXL but had not done so for two reasons (a) I was too lazy and (b) I missed an essential trick that REFMAC introduced, namely the combination of TLS with an additive isotropic B-value for each atom. Dale: You are quite correct that AFIX 137 breaks my argument about not depositing (SHELX) hydrogen atoms because they can be recalculated with no loss of experimental information. However to be fair, if you generate the first .ins file using SHELXPRO (the recommended procedure) you will get AFIX 33 that doesn't have this problem. For Pavel and others unfamiliar with SHELXL, AFIX 33 is a pure riding model with a staggered methyl group but AFIX 137 assumes local threefold symmetry, finds the initial torsion angle by a three-fold averaged fit to the difference density and then refines the torsion angle in the following cycles. Since this torsion angle is not given explicitly in the output files, if AFIX 137 hydrogens are not deposited, they cannot be regenerated except by a full refinement against the experimental data. George Prof. George M. Sheldrick FRS Dept. Structural Chemistry, University of Goettingen, Tammannstr. 4, D37077 Goettingen, Germany Tel. +49-551-39-3021 or -3068 Fax. +49-551-39-22582 On Wed, 15 Sep 2010, George M. Sheldrick wrote: > Dear Pavel, > > May I suggest that you take a look at the SHELX manual: > http://shelx.uni-ac.gwdg.de/SHELX/shelx.pdf > before sending your SHELX questions to CCP4bb? You might > even find some good ideas for implementing in phenix_refine! > > For example, > if you look up 'non-crystallographic symmetry' in the index > you will discover that SHELXL applies NCS in the form of > restraints, not constraints, which has the advantage that it > can be applied locally and in combination with all other > restraints and constraints involving the same atoms. However > you will not find TLS in the index, because the credit for > implementing this very useful concept should be given to > Martin Winn, Garib and Ethan, long after the current version > of SHELXL (and its manual) were released in 1997. And because > SHELXL only reads one instruction file (*.ins) and one > reflection file (*.hkl) but no other data files or libraries, > and FORTRAN will always be FORTRAN, the deposition of these > two files would be sufficient to define the refinement for > posterity. > > Best wishes, George > > Prof. George M. Sheldrick FRS > Dept. Structural Chemistry, > University of Goettingen, > Tammannstr. 4, > D37077 Goettingen, Germany > Tel. +49-551-39-3021 or -3068 > Fax. +49-551-39-22582 > > > On Wed, 15 Sep 2010, Pavel Afonine wrote: > > > Dear Felix, > > > > > Shortly Shelxl knows crystallography best. > > > > I have no doubts about this. May questions were, though: > > > > > > - how .ins file encodes the information about NCS groups used in > > > > refinement (atom selection for NCS groups, restraint weights for different > > > > groups, etc? > > > > > > > > - how .ins file encodes the information about TLS (again, atom selections > > > > for TLS groups, TLS matrices, etc)? Related, does it have a concept of > > > > having TLS and other components to the total atomic displacement parameter > > > > (ADP)? > > > > > > > > - If I recall it correctly, to fix (=not refine) a certain parameter (say > > > > occupancy or B-factor) in Shelxl you need to add a number 10 to it. Is it > > > > true? IMHO, this might lead to confusion if such a file gets deposited to > > > > PDB. > > > > Best, > > Pavel. > > > > > >
