Re: [ccp4bb] TLS parameters
Dear Pavel and Eleanor TLS records in mmCIF are standardised, so parameters from all refinement packages should be consistent with each other. Regards John From: CCP4 bulletin board On Behalf Of Pavel Afonine Sent: 19 November 2019 23:00 To: CCP4BB@JISCMAIL.AC.UK Subject: Re: [ccp4bb] TLS parameters Dear Eleanor, Phenix reads and writes TLS records, both PDB and mmCIF format. It can also read (but not write) TLS records in REFMAC and BUSTER format. In ATOM records Phenix outputs complete B factors, which includes both individual and TLS components (this is why they have ANISOU). Phenix won't re-define (or define from scratch) TLS groups automatically unless it is asked to do so. Pavel On Tue, Nov 19, 2019 at 7:36 AM Eleanor Dodson <176a9d5ebad7-dmarc-requ...@jiscmail.ac.uk <mailto:176a9d5ebad7-dmarc-requ...@jiscmail.ac.uk> > wrote: And what about PHENIX? E On Tue, 19 Nov 2019 at 15:33, Pierre Rizkallah mailto:rizkall...@cardiff.ac.uk> > wrote: I can vouch for TLS blocks being used by REFMAC and the PDB validation servers, after some frustration I had with a deposition recently: Towards the end of a refinement, I renamed some chains, to make oligomers in the a.u. contiguous in real space. Validation told me the centre of gravity as declared in the header is not the same as that produced from the coordinates. I edited the input TLS file, but it still produced the same outcome. I eventually realised that REFMAC reads the TLS blocks from the input PDB after reading all the other input instructions for the refinement run. This happening last, it overrides the declarations in the input TLS definitions file. In order to get the coordinates and the definitions to match, I had to remove the TLS blocks, produced by an earlier run of REFMAC, from the pdb input file, so that the new definitions can be followed, and appropriate TLS blocks produced. REFMAC would use pre-existing TLS blocks if they are in the PDB file. The mismatch notwithstanding, REFMAC still worked correctly, although the shifts from the group origins would have looked strange if one tries to analyse the TLS motions with TLSANL. I admit, I don't view them. Moral of the story is, be careful when you rename chains at the end of the refinement! Pierre Rizkallah *** Dr Pierre Rizkallah, Senior Lecturer Structural Biology Institute of Infection & Immunology, Sir Geraint Evans Building, School of Medicine, Heath Campus, Cardiff, CF14 4XN email: rizkall...@cardiff.ac.uk <mailto:rizkall...@cardiff.ac.uk> phone: +44 29 2074 2248 http://www.cardiff.ac.uk/people/view/126690-rizkallah-pierre -Original Message- From: CCP4 bulletin board mailto:CCP4BB@JISCMAIL.AC.UK> > On Behalf Of Robbie Joosten Sent: 19 November 2019 15:14 To: CCP4BB@JISCMAIL.AC.UK <mailto:CCP4BB@JISCMAIL.AC.UK> Subject: Re: [ccp4bb] TLS parameters Hi Eleanor, The blocks are reliably recorded in PDB entries but in some cases the renumbering of residues was not pushed through to TLS groups. Certain selections cannot be captured in the PDB format, for instance the split in main chain and side chain that Refmac allows. Fortunately that feature is hardly used. Parsing TLS records is not straightforward, particularly the sets from Buster suffered a lot from inconsistent manual editing in the early days of TLS refinement. PDB-REDO's extractor does a decent job in getting selections and changing those into Refmac format, but there are definitely cases that it cannot do. We also have a tool that does this for mmCIF files which is not written by me and (therefore) much more sophisticated in handling more complicated cases. Cheers, Robbie > -Original Message- > From: CCP4 bulletin board <mailto:CCP4BB@JISCMAIL.AC.UK> > On Behalf Of Eleanor > Dodson > Sent: Tuesday, November 19, 2019 3:59 PM > To: CCP4BB@JISCMAIL.AC.UK <mailto:CCP4BB@JISCMAIL.AC.UK> > Subject: [ccp4bb] TLS parameters > > Does anyone know how reliably the different programs record and use > these blocks from the PDB file? > > Eleanor > > > > > To unsubscribe from the CCP4BB list, click the following link: > https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww. > jiscmail.ac.uk <http://jiscmail.ac.uk> > %2Fcgi-bin%2Fwebadmin%3FSUBED1%3DCCP4BB%26A%3D1data > =01%7C01%7Crizkallahp%40CARDIFF.AC.UK <http://40CARDIFF.AC.UK> > %7Cf2a9834dd919481f28d508d76d030e > 63%7Cbdb74b3095684856bdbf06759778fcbc%7C1sdata=BMwtQsLcQzHTeZcKqC > Yg5W7MLDM7Phk0MUx8ohylApI%3Dreserved=0 To unsubscribe from the CCP4BB list, click the following link: https://eur03.safelinks.protection.outlook.com/?url=https%3A%2
Re: [ccp4bb] TLS parameters
Dear Eleanor, Phenix reads and writes TLS records, both PDB and mmCIF format. It can also read (but not write) TLS records in REFMAC and BUSTER format. In ATOM records Phenix outputs complete B factors, which includes both individual and TLS components (this is why they have ANISOU). Phenix won't re-define (or define from scratch) TLS groups automatically unless it is asked to do so. Pavel On Tue, Nov 19, 2019 at 7:36 AM Eleanor Dodson < 176a9d5ebad7-dmarc-requ...@jiscmail.ac.uk> wrote: > And what about PHENIX? > E > > On Tue, 19 Nov 2019 at 15:33, Pierre Rizkallah > wrote: > >> I can vouch for TLS blocks being used by REFMAC and the PDB validation >> servers, after some frustration I had with a deposition recently: >> Towards the end of a refinement, I renamed some chains, to make oligomers >> in the a.u. contiguous in real space. Validation told me the centre of >> gravity as declared in the header is not the same as that produced from the >> coordinates. I edited the input TLS file, but it still produced the same >> outcome. I eventually realised that REFMAC reads the TLS blocks from the >> input PDB after reading all the other input instructions for the refinement >> run. This happening last, it overrides the declarations in the input TLS >> definitions file. In order to get the coordinates and the definitions to >> match, I had to remove the TLS blocks, produced by an earlier run of >> REFMAC, from the pdb input file, so that the new definitions can be >> followed, and appropriate TLS blocks produced. REFMAC would use >> pre-existing TLS blocks if they are in the PDB file. >> >> The mismatch notwithstanding, REFMAC still worked correctly, although the >> shifts from the group origins would have looked strange if one tries to >> analyse the TLS motions with TLSANL. I admit, I don't view them. Moral of >> the story is, be careful when you rename chains at the end of the >> refinement! >> >> Pierre Rizkallah >> *** >> Dr Pierre Rizkallah, Senior Lecturer Structural Biology >> Institute of Infection & Immunology, Sir Geraint Evans Building, >> School of Medicine, Heath Campus, Cardiff, CF14 4XN >> email: rizkall...@cardiff.ac.ukphone: +44 29 2074 2248 >> http://www.cardiff.ac.uk/people/view/126690-rizkallah-pierre >> >> -Original Message- >> From: CCP4 bulletin board On Behalf Of Robbie >> Joosten >> Sent: 19 November 2019 15:14 >> To: CCP4BB@JISCMAIL.AC.UK >> Subject: Re: [ccp4bb] TLS parameters >> >> Hi Eleanor, >> >> The blocks are reliably recorded in PDB entries but in some cases the >> renumbering of residues was not pushed through to TLS groups. Certain >> selections cannot be captured in the PDB format, for instance the split in >> main chain and side chain that Refmac allows. Fortunately that feature is >> hardly used. >> Parsing TLS records is not straightforward, particularly the sets from >> Buster suffered a lot from inconsistent manual editing in the early days of >> TLS refinement. PDB-REDO's extractor does a decent job in getting >> selections and changing those into Refmac format, but there are definitely >> cases that it cannot do. We also have a tool that does this for mmCIF files >> which is not written by me and (therefore) much more sophisticated in >> handling more complicated cases. >> >> Cheers, >> Robbie >> >> > -Original Message- >> > From: CCP4 bulletin board On Behalf Of Eleanor >> > Dodson >> > Sent: Tuesday, November 19, 2019 3:59 PM >> > To: CCP4BB@JISCMAIL.AC.UK >> > Subject: [ccp4bb] TLS parameters >> > >> > Does anyone know how reliably the different programs record and use >> > these blocks from the PDB file? >> > >> > Eleanor >> > >> > >> > >> > >> > To unsubscribe from the CCP4BB list, click the following link: >> > https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww. >> > jiscmail.ac.uk%2Fcgi-bin%2Fwebadmin%3FSUBED1%3DCCP4BB%26A%3D1data >> > =01%7C01%7Crizkallahp%40CARDIFF.AC.UK%7Cf2a9834dd919481f28d508d76d030e >> > 63%7Cbdb74b3095684856bdbf06759778fcbc%7C1sdata=BMwtQsLcQzHTeZcKqC >> > Yg5W7MLDM7Phk0MUx8ohylApI%3Dreserved=0 >> >> >> >> >> To unsubscribe from the CCP4BB list, click the following link: >> >> https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.jiscmail
Re: [ccp4bb] TLS parameters
Purely from memory, I think TLS is refined in Phenix on the fly and the groups are updated in every run. It does split the B-Facs in isotropic and anisotropic part in the putput pdb file. I do not recall the tls groups to be recorded separately in a phenix pdb. But again distant memory. Christian On Tue, Nov 19, 2019 at 4:36 PM Eleanor Dodson < 176a9d5ebad7-dmarc-requ...@jiscmail.ac.uk> wrote: > And what about PHENIX? > E > > On Tue, 19 Nov 2019 at 15:33, Pierre Rizkallah > wrote: > >> I can vouch for TLS blocks being used by REFMAC and the PDB validation >> servers, after some frustration I had with a deposition recently: >> Towards the end of a refinement, I renamed some chains, to make oligomers >> in the a.u. contiguous in real space. Validation told me the centre of >> gravity as declared in the header is not the same as that produced from the >> coordinates. I edited the input TLS file, but it still produced the same >> outcome. I eventually realised that REFMAC reads the TLS blocks from the >> input PDB after reading all the other input instructions for the refinement >> run. This happening last, it overrides the declarations in the input TLS >> definitions file. In order to get the coordinates and the definitions to >> match, I had to remove the TLS blocks, produced by an earlier run of >> REFMAC, from the pdb input file, so that the new definitions can be >> followed, and appropriate TLS blocks produced. REFMAC would use >> pre-existing TLS blocks if they are in the PDB file. >> >> The mismatch notwithstanding, REFMAC still worked correctly, although the >> shifts from the group origins would have looked strange if one tries to >> analyse the TLS motions with TLSANL. I admit, I don't view them. Moral of >> the story is, be careful when you rename chains at the end of the >> refinement! >> >> Pierre Rizkallah >> *** >> Dr Pierre Rizkallah, Senior Lecturer Structural Biology >> Institute of Infection & Immunology, Sir Geraint Evans Building, >> School of Medicine, Heath Campus, Cardiff, CF14 4XN >> email: rizkall...@cardiff.ac.ukphone: +44 29 2074 2248 >> http://www.cardiff.ac.uk/people/view/126690-rizkallah-pierre >> >> -Original Message- >> From: CCP4 bulletin board On Behalf Of Robbie >> Joosten >> Sent: 19 November 2019 15:14 >> To: CCP4BB@JISCMAIL.AC.UK >> Subject: Re: [ccp4bb] TLS parameters >> >> Hi Eleanor, >> >> The blocks are reliably recorded in PDB entries but in some cases the >> renumbering of residues was not pushed through to TLS groups. Certain >> selections cannot be captured in the PDB format, for instance the split in >> main chain and side chain that Refmac allows. Fortunately that feature is >> hardly used. >> Parsing TLS records is not straightforward, particularly the sets from >> Buster suffered a lot from inconsistent manual editing in the early days of >> TLS refinement. PDB-REDO's extractor does a decent job in getting >> selections and changing those into Refmac format, but there are definitely >> cases that it cannot do. We also have a tool that does this for mmCIF files >> which is not written by me and (therefore) much more sophisticated in >> handling more complicated cases. >> >> Cheers, >> Robbie >> >> > -Original Message- >> > From: CCP4 bulletin board On Behalf Of Eleanor >> > Dodson >> > Sent: Tuesday, November 19, 2019 3:59 PM >> > To: CCP4BB@JISCMAIL.AC.UK >> > Subject: [ccp4bb] TLS parameters >> > >> > Does anyone know how reliably the different programs record and use >> > these blocks from the PDB file? >> > >> > Eleanor >> > >> > >> > >> > >> > To unsubscribe from the CCP4BB list, click the following link: >> > https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww. >> > jiscmail.ac.uk%2Fcgi-bin%2Fwebadmin%3FSUBED1%3DCCP4BB%26A%3D1data >> > =01%7C01%7Crizkallahp%40CARDIFF.AC.UK%7Cf2a9834dd919481f28d508d76d030e >> > 63%7Cbdb74b3095684856bdbf06759778fcbc%7C1sdata=BMwtQsLcQzHTeZcKqC >> > Yg5W7MLDM7Phk0MUx8ohylApI%3Dreserved=0 >> >> >> >> >> To unsubscribe from the CCP4BB list, click the following link: >> >> https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.jiscmail.ac.uk%2Fcgi-bin%2Fwebadm
Re: [ccp4bb] TLS parameters
And what about PHENIX? E On Tue, 19 Nov 2019 at 15:33, Pierre Rizkallah wrote: > I can vouch for TLS blocks being used by REFMAC and the PDB validation > servers, after some frustration I had with a deposition recently: > Towards the end of a refinement, I renamed some chains, to make oligomers > in the a.u. contiguous in real space. Validation told me the centre of > gravity as declared in the header is not the same as that produced from the > coordinates. I edited the input TLS file, but it still produced the same > outcome. I eventually realised that REFMAC reads the TLS blocks from the > input PDB after reading all the other input instructions for the refinement > run. This happening last, it overrides the declarations in the input TLS > definitions file. In order to get the coordinates and the definitions to > match, I had to remove the TLS blocks, produced by an earlier run of > REFMAC, from the pdb input file, so that the new definitions can be > followed, and appropriate TLS blocks produced. REFMAC would use > pre-existing TLS blocks if they are in the PDB file. > > The mismatch notwithstanding, REFMAC still worked correctly, although the > shifts from the group origins would have looked strange if one tries to > analyse the TLS motions with TLSANL. I admit, I don't view them. Moral of > the story is, be careful when you rename chains at the end of the > refinement! > > Pierre Rizkallah > *** > Dr Pierre Rizkallah, Senior Lecturer Structural Biology > Institute of Infection & Immunology, Sir Geraint Evans Building, > School of Medicine, Heath Campus, Cardiff, CF14 4XN > email: rizkall...@cardiff.ac.ukphone: +44 29 2074 2248 > http://www.cardiff.ac.uk/people/view/126690-rizkallah-pierre > > -Original Message- > From: CCP4 bulletin board On Behalf Of Robbie > Joosten > Sent: 19 November 2019 15:14 > To: CCP4BB@JISCMAIL.AC.UK > Subject: Re: [ccp4bb] TLS parameters > > Hi Eleanor, > > The blocks are reliably recorded in PDB entries but in some cases the > renumbering of residues was not pushed through to TLS groups. Certain > selections cannot be captured in the PDB format, for instance the split in > main chain and side chain that Refmac allows. Fortunately that feature is > hardly used. > Parsing TLS records is not straightforward, particularly the sets from > Buster suffered a lot from inconsistent manual editing in the early days of > TLS refinement. PDB-REDO's extractor does a decent job in getting > selections and changing those into Refmac format, but there are definitely > cases that it cannot do. We also have a tool that does this for mmCIF files > which is not written by me and (therefore) much more sophisticated in > handling more complicated cases. > > Cheers, > Robbie > > > -Original Message- > > From: CCP4 bulletin board On Behalf Of Eleanor > > Dodson > > Sent: Tuesday, November 19, 2019 3:59 PM > > To: CCP4BB@JISCMAIL.AC.UK > > Subject: [ccp4bb] TLS parameters > > > > Does anyone know how reliably the different programs record and use > > these blocks from the PDB file? > > > > Eleanor > > > > > > > > > > To unsubscribe from the CCP4BB list, click the following link: > > https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww. > > jiscmail.ac.uk%2Fcgi-bin%2Fwebadmin%3FSUBED1%3DCCP4BB%26A%3D1data > > =01%7C01%7Crizkallahp%40CARDIFF.AC.UK%7Cf2a9834dd919481f28d508d76d030e > > 63%7Cbdb74b3095684856bdbf06759778fcbc%7C1sdata=BMwtQsLcQzHTeZcKqC > > Yg5W7MLDM7Phk0MUx8ohylApI%3Dreserved=0 > > > > > To unsubscribe from the CCP4BB list, click the following link: > > https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.jiscmail.ac.uk%2Fcgi-bin%2Fwebadmin%3FSUBED1%3DCCP4BB%26A%3D1data=01%7C01%7Crizkallahp%40CARDIFF.AC.UK%7Cf2a9834dd919481f28d508d76d030e63%7Cbdb74b3095684856bdbf06759778fcbc%7C1sdata=BMwtQsLcQzHTeZcKqCYg5W7MLDM7Phk0MUx8ohylApI%3Dreserved=0 > > > > To unsubscribe from the CCP4BB list, click the following link: > https://www.jiscmail.ac.uk/cgi-bin/webadmin?SUBED1=CCP4BB=1 > To unsubscribe from the CCP4BB list, click the following link: https://www.jiscmail.ac.uk/cgi-bin/webadmin?SUBED1=CCP4BB=1
Re: [ccp4bb] TLS parameters
I can vouch for TLS blocks being used by REFMAC and the PDB validation servers, after some frustration I had with a deposition recently: Towards the end of a refinement, I renamed some chains, to make oligomers in the a.u. contiguous in real space. Validation told me the centre of gravity as declared in the header is not the same as that produced from the coordinates. I edited the input TLS file, but it still produced the same outcome. I eventually realised that REFMAC reads the TLS blocks from the input PDB after reading all the other input instructions for the refinement run. This happening last, it overrides the declarations in the input TLS definitions file. In order to get the coordinates and the definitions to match, I had to remove the TLS blocks, produced by an earlier run of REFMAC, from the pdb input file, so that the new definitions can be followed, and appropriate TLS blocks produced. REFMAC would use pre-existing TLS blocks if they are in the PDB file. The mismatch notwithstanding, REFMAC still worked correctly, although the shifts from the group origins would have looked strange if one tries to analyse the TLS motions with TLSANL. I admit, I don't view them. Moral of the story is, be careful when you rename chains at the end of the refinement! Pierre Rizkallah *** Dr Pierre Rizkallah, Senior Lecturer Structural Biology Institute of Infection & Immunology, Sir Geraint Evans Building, School of Medicine, Heath Campus, Cardiff, CF14 4XN email: rizkall...@cardiff.ac.uk phone: +44 29 2074 2248 http://www.cardiff.ac.uk/people/view/126690-rizkallah-pierre -Original Message- From: CCP4 bulletin board On Behalf Of Robbie Joosten Sent: 19 November 2019 15:14 To: CCP4BB@JISCMAIL.AC.UK Subject: Re: [ccp4bb] TLS parameters Hi Eleanor, The blocks are reliably recorded in PDB entries but in some cases the renumbering of residues was not pushed through to TLS groups. Certain selections cannot be captured in the PDB format, for instance the split in main chain and side chain that Refmac allows. Fortunately that feature is hardly used. Parsing TLS records is not straightforward, particularly the sets from Buster suffered a lot from inconsistent manual editing in the early days of TLS refinement. PDB-REDO's extractor does a decent job in getting selections and changing those into Refmac format, but there are definitely cases that it cannot do. We also have a tool that does this for mmCIF files which is not written by me and (therefore) much more sophisticated in handling more complicated cases. Cheers, Robbie > -Original Message- > From: CCP4 bulletin board On Behalf Of Eleanor > Dodson > Sent: Tuesday, November 19, 2019 3:59 PM > To: CCP4BB@JISCMAIL.AC.UK > Subject: [ccp4bb] TLS parameters > > Does anyone know how reliably the different programs record and use > these blocks from the PDB file? > > Eleanor > > > > > To unsubscribe from the CCP4BB list, click the following link: > https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww. > jiscmail.ac.uk%2Fcgi-bin%2Fwebadmin%3FSUBED1%3DCCP4BB%26A%3D1data > =01%7C01%7Crizkallahp%40CARDIFF.AC.UK%7Cf2a9834dd919481f28d508d76d030e > 63%7Cbdb74b3095684856bdbf06759778fcbc%7C1sdata=BMwtQsLcQzHTeZcKqC > Yg5W7MLDM7Phk0MUx8ohylApI%3Dreserved=0 To unsubscribe from the CCP4BB list, click the following link: https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.jiscmail.ac.uk%2Fcgi-bin%2Fwebadmin%3FSUBED1%3DCCP4BB%26A%3D1data=01%7C01%7Crizkallahp%40CARDIFF.AC.UK%7Cf2a9834dd919481f28d508d76d030e63%7Cbdb74b3095684856bdbf06759778fcbc%7C1sdata=BMwtQsLcQzHTeZcKqCYg5W7MLDM7Phk0MUx8ohylApI%3Dreserved=0 To unsubscribe from the CCP4BB list, click the following link: https://www.jiscmail.ac.uk/cgi-bin/webadmin?SUBED1=CCP4BB=1
Re: [ccp4bb] TLS parameters
Hi Eleanor, The blocks are reliably recorded in PDB entries but in some cases the renumbering of residues was not pushed through to TLS groups. Certain selections cannot be captured in the PDB format, for instance the split in main chain and side chain that Refmac allows. Fortunately that feature is hardly used. Parsing TLS records is not straightforward, particularly the sets from Buster suffered a lot from inconsistent manual editing in the early days of TLS refinement. PDB-REDO's extractor does a decent job in getting selections and changing those into Refmac format, but there are definitely cases that it cannot do. We also have a tool that does this for mmCIF files which is not written by me and (therefore) much more sophisticated in handling more complicated cases. Cheers, Robbie > -Original Message- > From: CCP4 bulletin board On Behalf Of Eleanor > Dodson > Sent: Tuesday, November 19, 2019 3:59 PM > To: CCP4BB@JISCMAIL.AC.UK > Subject: [ccp4bb] TLS parameters > > Does anyone know how reliably the different programs record and use these > blocks from the PDB file? > > Eleanor > > > > > To unsubscribe from the CCP4BB list, click the following link: > https://www.jiscmail.ac.uk/cgi-bin/webadmin?SUBED1=CCP4BB=1 To unsubscribe from the CCP4BB list, click the following link: https://www.jiscmail.ac.uk/cgi-bin/webadmin?SUBED1=CCP4BB=1
