Re: [ccp4bb] conversion from pdb to cif format changes R factors ... why?

2018-10-03 Thread Martin Noble 
On observation is that I have a brand new pipeline for this that will be 
released as soon as the main distribution has
gemmi installed…this is based on far newer code developed by John Berrisford 
and Eugene Krissinel.  It does, however,
still rely on a zero cycle REFMAC run...

On 3 Oct 2018, at 12:16, Martin Noble 
mailto:martin.no...@newcastle.ac.uk>> wrote:

I will check that there is not a new keyword that needs to be set for TLS to be 
used as provided.
M.


On 3 Oct 2018, at 12:09, Christian Roth 
mailto:christianroth...@gmail.com>> wrote:

That was my thought exactly. Eleanor has been faster. Indeed if the TLS 
parameters get not passed to the refmac subjob it will not be taken into 
account. It did work previously, but there have been some changes recently and 
it might be that there is something broken now. It would be good to check this, 
because it should be fixed.

Christian

Am 03.10.2018 um 11:53 schrieb Eleanor Dodson:
That is a serious bug in the deposition task.
You can find the refmac command script if you search in the Job list 
directories. If it does not invoke TLS when there are TLS records provided that 
is a fixable bug..

Eleanor

On Wed, 3 Oct 2018 at 10:51, Antonio Ariza 
mailto:antonio.ar...@path.ox.ac.uk>> wrote:
Hi Christian,

Yes, I used TLS refinement for all the structures I deposited … but the TLS 
parameters were included in the deposition task, so I  assumed the programme 
would know that it needs to take these into account.

Anyway …  I guess that in order to correct the remarks in the headers of the 
curated coordinates in the PDB, I'll have to alter all the cif files manually 
and then resubmit them to the deposition server.


Cheers,


Tony

--

Dr. Antonio Ariza
University of Oxford
Sir William Dunn School of Pathology
South Parks Road
Oxford
OX1 3RE
e-mail: antonio.ar...@path.ox.ac.uk<mailto:antonio.ar...@path.ox.ac.uk>
Tel: 00 +44 1865 285655

Links to my public profiles:
ResearchGate<https://www.researchgate.net/profile/Antonio_Ariza>
LinkedIn<https://www.linkedin.com/in/antonioariza1>
GoogleScholar<https://scholar.google.co.uk/citations?user=9pAIKV0J=en>
Twitter<https://twitter.com/DrAntonioAriza?lang=en>

Check out my latest paper!!!
Structural insights into the function of ZRANB3 in replication stress 
response<http://www.nature.com/articles/ncomms15847>



From: Christian Roth 
mailto:christianroth...@gmail.com>>
Sent: 02 October 2018 20:52
To: Antonio Ariza; CCP4BB@JISCMAIL.AC.UK<mailto:CCP4BB@JISCMAIL.AC.UK>
Subject: Re: [ccp4bb] conversion from pdb to cif format changes R factors ... 
why?


Hi Tony,


is that for all structures or just some? I recall there was a problem when one 
has used TLS refinement. The deposition task runs a 0 cycle refmac job to 
recreate the statistics. If there is a difference, e.g no TLS included that 
might explain the difference.


Cheers


Christian

Am 02.10.2018 um 19:25 schrieb Antonio Ariza:
Hi all,

I'm wondering if anyone else has noticed this ... or is there something I am 
missing here?

One of the reviewers of my latest manuscript just pointed out that the R 
factors in my validation reports are significantly different (i.e. worse) than 
those I stated in the paper. So, I checked and indeed they are. I tracked the 
difference in the numbers down to the point where I used "Prepare files for 
deposition" in ccp4i2. This is the first time I used this programme to convert 
my pdb and mtz files into cif files, instead of trying to deposit the pdb and 
mtz files as I've always done. The conversion, however, changed the R factors 
... and seemingly nothing else as the coordinates of  both files are still the 
same.

Any idea why the programme does this? Is there another programme I can use that 
doesn't do this? It's annoying because now I have to redeposit the data for the 
10 structures I've submitted for this paper.

Here are the remarks of the pdb file and the remarks of the resulting cif file, 
as you can see they are the same except for the R factors.

PDB:
REMARK   3  DATA USED IN REFINEMENT.
REMARK   3   RESOLUTION RANGE HIGH (ANGSTROMS) :   1.67
REMARK   3   RESOLUTION RANGE LOW  (ANGSTROMS) :  49.13
REMARK   3   DATA CUTOFF(SIGMA(F)) : NONE
REMARK   3   COMPLETENESS FOR RANGE(%) :  97.26
REMARK   3   NUMBER OF REFLECTIONS :   35463
REMARK   3
REMARK   3  FIT TO DATA USED IN REFINEMENT.
REMARK   3   CROSS-VALIDATION METHOD  : THROUGHOUT
REMARK   3   FREE R VALUE TEST SET SELECTION  : RANDOM
REMARK   3   R VALUE (WORKING + TEST SET) : 0.20233
REMARK   3   R VALUE(WORKING SET) :  0.20068
REMARK   3   FREE R VALUE :  0.23658
REMARK   3   FREE R VALUE TEST SET SIZE   (%) :  4.7
REMARK   3   FREE R VALUE TEST SET COUNT  :  1759
REMARK   3
REMARK   3  FIT IN THE HIGHEST RESOL

Re: [ccp4bb] conversion from pdb to cif format changes R factors ... why?

2018-10-03 Thread Martin Noble 
I will check that there is not a new keyword that needs to be set for TLS to be 
used as provided.
M.


On 3 Oct 2018, at 12:09, Christian Roth 
mailto:christianroth...@gmail.com>> wrote:

That was my thought exactly. Eleanor has been faster. Indeed if the TLS 
parameters get not passed to the refmac subjob it will not be taken into 
account. It did work previously, but there have been some changes recently and 
it might be that there is something broken now. It would be good to check this, 
because it should be fixed.

Christian

Am 03.10.2018 um 11:53 schrieb Eleanor Dodson:
That is a serious bug in the deposition task.
You can find the refmac command script if you search in the Job list 
directories. If it does not invoke TLS when there are TLS records provided that 
is a fixable bug..

Eleanor

On Wed, 3 Oct 2018 at 10:51, Antonio Ariza 
mailto:antonio.ar...@path.ox.ac.uk>> wrote:
Hi Christian,

Yes, I used TLS refinement for all the structures I deposited … but the TLS 
parameters were included in the deposition task, so I  assumed the programme 
would know that it needs to take these into account.

Anyway …  I guess that in order to correct the remarks in the headers of the 
curated coordinates in the PDB, I'll have to alter all the cif files manually 
and then resubmit them to the deposition server.


Cheers,


Tony

--

Dr. Antonio Ariza
University of Oxford
Sir William Dunn School of Pathology
South Parks Road
Oxford
OX1 3RE
e-mail: antonio.ar...@path.ox.ac.uk<mailto:antonio.ar...@path.ox.ac.uk>
Tel: 00 +44 1865 285655

Links to my public profiles:
ResearchGate<https://www.researchgate.net/profile/Antonio_Ariza>
LinkedIn<https://www.linkedin.com/in/antonioariza1>
GoogleScholar<https://scholar.google.co.uk/citations?user=9pAIKV0J=en>
Twitter<https://twitter.com/DrAntonioAriza?lang=en>

Check out my latest paper!!!
Structural insights into the function of ZRANB3 in replication stress 
response<http://www.nature.com/articles/ncomms15847>



From: Christian Roth 
mailto:christianroth...@gmail.com>>
Sent: 02 October 2018 20:52
To: Antonio Ariza; CCP4BB@JISCMAIL.AC.UK<mailto:CCP4BB@JISCMAIL.AC.UK>
Subject: Re: [ccp4bb] conversion from pdb to cif format changes R factors ... 
why?


Hi Tony,


is that for all structures or just some? I recall there was a problem when one 
has used TLS refinement. The deposition task runs a 0 cycle refmac job to 
recreate the statistics. If there is a difference, e.g no TLS included that 
might explain the difference.


Cheers


Christian

Am 02.10.2018 um 19:25 schrieb Antonio Ariza:
Hi all,

I'm wondering if anyone else has noticed this ... or is there something I am 
missing here?

One of the reviewers of my latest manuscript just pointed out that the R 
factors in my validation reports are significantly different (i.e. worse) than 
those I stated in the paper. So, I checked and indeed they are. I tracked the 
difference in the numbers down to the point where I used "Prepare files for 
deposition" in ccp4i2. This is the first time I used this programme to convert 
my pdb and mtz files into cif files, instead of trying to deposit the pdb and 
mtz files as I've always done. The conversion, however, changed the R factors 
... and seemingly nothing else as the coordinates of  both files are still the 
same.

Any idea why the programme does this? Is there another programme I can use that 
doesn't do this? It's annoying because now I have to redeposit the data for the 
10 structures I've submitted for this paper.

Here are the remarks of the pdb file and the remarks of the resulting cif file, 
as you can see they are the same except for the R factors.

PDB:
REMARK   3  DATA USED IN REFINEMENT.
REMARK   3   RESOLUTION RANGE HIGH (ANGSTROMS) :   1.67
REMARK   3   RESOLUTION RANGE LOW  (ANGSTROMS) :  49.13
REMARK   3   DATA CUTOFF(SIGMA(F)) : NONE
REMARK   3   COMPLETENESS FOR RANGE(%) :  97.26
REMARK   3   NUMBER OF REFLECTIONS :   35463
REMARK   3
REMARK   3  FIT TO DATA USED IN REFINEMENT.
REMARK   3   CROSS-VALIDATION METHOD  : THROUGHOUT
REMARK   3   FREE R VALUE TEST SET SELECTION  : RANDOM
REMARK   3   R VALUE (WORKING + TEST SET) : 0.20233
REMARK   3   R VALUE(WORKING SET) :  0.20068
REMARK   3   FREE R VALUE :  0.23658
REMARK   3   FREE R VALUE TEST SET SIZE   (%) :  4.7
REMARK   3   FREE R VALUE TEST SET COUNT  :  1759
REMARK   3
REMARK   3  FIT IN THE HIGHEST RESOLUTION BIN.
REMARK   3   TOTAL NUMBER OF BINS USED   :  20
REMARK   3   BIN RESOLUTION RANGE HIGH   :1.670
REMARK   3   BIN RESOLUTION RANGE LOW:1.714
REMARK   3   REFLECTION IN BIN (WORKING SET) : 2221
REMARK   3   BIN COMPLETENESS (WORKING+TEST) (%) :82.65
REMARK   3   BIN R VALUE   (WORKING SET) :0.392

Re: [ccp4bb] conversion from pdb to cif format changes R factors ... why?

2018-10-03 Thread Christian Roth 
That was my thought exactly. Eleanor has been faster. Indeed if the TLS 
parameters get not passed to the refmac subjob it will not be taken into 
account. It did work previously, but there have been some changes 
recently and it might be that there is something broken now. It would be 
good to check this, because it should be fixed.


Christian

Am 03.10.2018 um 11:53 schrieb Eleanor Dodson:

That is a serious bug in the deposition task.
You can find the refmac command script if you search in the Job list 
directories. If it does not invoke TLS when there are TLS records 
provided that is a fixable bug..


Eleanor

On Wed, 3 Oct 2018 at 10:51, Antonio Ariza 
mailto:antonio.ar...@path.ox.ac.uk>> wrote:


Hi Christian,


Yes, I used TLS refinement for all the structures I deposited …
but the TLS parameters were included in the deposition task, so I 
assumed the programme would know that it needs to take these into
account.


Anyway …  I guess that in order to correct the remarks in the
headers of the curated coordinates in the PDB, I'll have to alter
all the cif files manually and then resubmit them to the
deposition server.


Cheers,


Tony


--
*
Dr. Antonio Ariza
University of Oxford
Sir William Dunn School of Pathology
South Parks Road
Oxford
OX1 3RE*
*e-mail: *antonio.ar...@path.ox.ac.uk
<mailto:antonio.ar...@path.ox.ac.uk>
*Tel: 00 +44 1865 285655*
**
*Links to my public profiles:*
ResearchGate <https://www.researchgate.net/profile/Antonio_Ariza>
LinkedIn <https://www.linkedin.com/in/antonioariza1>
GoogleScholar
<https://scholar.google.co.uk/citations?user=9pAIKV0J=en>
Twitter <https://twitter.com/DrAntonioAriza?lang=en>
*Check out my latest paper!!!*
Structural insights into the function of ZRANB3 in replication
stress response <http://www.nature.com/articles/ncomms15847>



*From:* Christian Roth mailto:christianroth...@gmail.com>>
*Sent:* 02 October 2018 20:52
*To:* Antonio Ariza; CCP4BB@JISCMAIL.AC.UK
<mailto:CCP4BB@JISCMAIL.AC.UK>
    *Subject:* Re: [ccp4bb] conversion from pdb to cif format changes
R factors ... why?

Hi Tony,


is that for all structures or just some? I recall there was a
problem when one has used TLS refinement. The deposition task runs
a 0 cycle refmac job to recreate the statistics. If there is a
difference, e.g no TLS included that might explain the difference.


Cheers


Christian


Am 02.10.2018 um 19:25 schrieb Antonio Ariza:


Hi all,


I'm wondering if anyone else has noticed this ... or is there
something I am missing here?


One of the reviewers of my latest manuscript just pointed out
that the R factors in my validation reports are significantly
different (i.e. worse) than those I stated in the paper. So, I
checked and indeed they are. I tracked the difference in the
numbers down to the point where I used "Prepare files for
deposition" in ccp4i2. This is the first time I used this
programme to convert my pdb and mtz files into cif files, instead
of trying to deposit the pdb and mtz files as I've always done.
The conversion, however, changed the R factors ... and seemingly
nothing else as the coordinates of  both files are still the same.


Any idea why the programme does this? Is there another programme
I can use that doesn't do this? It's annoying because now I have
to redeposit the data for the 10 structures I've submitted for
this paper.


Here are the remarks of the pdb file and the remarks of the
resulting cif file, as you can see they are the same except for
the R factors.


PDB:

REMARK   3  DATA USED IN REFINEMENT.
REMARK   3   RESOLUTION RANGE HIGH (ANGSTROMS) :   1.67
REMARK   3   RESOLUTION RANGE LOW  (ANGSTROMS) :  49.13
REMARK   3   DATA CUTOFF    (SIGMA(F)) : NONE
REMARK   3   COMPLETENESS FOR RANGE    (%) :  97.26
REMARK   3   NUMBER OF REFLECTIONS :   35463
REMARK   3
REMARK   3  FIT TO DATA USED IN REFINEMENT.
REMARK   3   CROSS-VALIDATION METHOD  : THROUGHOUT
REMARK   3   FREE R VALUE TEST SET SELECTION  : RANDOM
REMARK   3   R VALUE (WORKING + TEST SET) : 0.20233
REMARK   3   R VALUE    (WORKING SET) : 0.20068
REMARK   3   FREE R VALUE : 0.23658
REMARK   3   FREE R VALUE TEST SET SIZE   (%) : 4.7
REMARK   3   FREE R VALUE TEST SET COUNT  : 1759
REMARK   3
REMARK   3  FIT IN THE HIGHEST RESOLUTION BIN.
REMARK   3   TOTAL NUMBER OF BINS USED :  20
REMARK   3   BIN RESOLUTION RANGE HIGH :    1.670
REMARK   3   BIN RESOLUTION RANGE LOW :    1.714
REMARK   3

Re: [ccp4bb] conversion from pdb to cif format changes R factors ... why?

2018-10-03 Thread Eleanor Dodson 
That is a serious bug in the deposition task.
You can find the refmac command script if you search in the Job list
directories. If it does not invoke TLS when there are TLS records provided
that is a fixable bug..

Eleanor

On Wed, 3 Oct 2018 at 10:51, Antonio Ariza 
wrote:

> Hi Christian,
>
>
> Yes, I used TLS refinement for all the structures I deposited … but the
> TLS parameters were included in the deposition task, so I  assumed the
> programme would know that it needs to take these into account.
>
>
> Anyway …  I guess that in order to correct the remarks in the headers of
> the curated coordinates in the PDB, I'll have to alter all the cif files
> manually and then resubmit them to the deposition server.
>
>
> Cheers,
>
>
> Tony
>
>
> --
>
>
>
>
>
>
> * Dr. Antonio Ariza University of Oxford Sir William Dunn School of
> Pathology South Parks Road Oxford OX1 3RE*
> *e-mail: *antonio.ar...@path.ox.ac.uk
> *Tel: 00 +44 1865 285655*
>
> *Links to my public profiles:*
> ResearchGate <https://www.researchgate.net/profile/Antonio_Ariza>
> LinkedIn <https://www.linkedin.com/in/antonioariza1>
> GoogleScholar
> <https://scholar.google.co.uk/citations?user=9pAIKV0J=en>
> Twitter <https://twitter.com/DrAntonioAriza?lang=en>
>
> *Check out my latest paper!!!*
> Structural insights into the function of ZRANB3 in replication stress
> response <http://www.nature.com/articles/ncomms15847>
>
>
> ----------
> *From:* Christian Roth 
> *Sent:* 02 October 2018 20:52
> *To:* Antonio Ariza; CCP4BB@JISCMAIL.AC.UK
> *Subject:* Re: [ccp4bb] conversion from pdb to cif format changes R
> factors ... why?
>
>
> Hi Tony,
>
>
> is that for all structures or just some? I recall there was a problem when
> one has used TLS refinement. The deposition task runs a 0 cycle refmac job
> to recreate the statistics. If there is a difference, e.g no TLS included
> that might explain the difference.
>
>
> Cheers
>
>
> Christian
>
> Am 02.10.2018 um 19:25 schrieb Antonio Ariza:
>
> Hi all,
>
>
> I'm wondering if anyone else has noticed this ... or is there something I
> am missing here?
>
>
> One of the reviewers of my latest manuscript just pointed out that the R
> factors in my validation reports are significantly different (i.e. worse)
> than those I stated in the paper. So, I checked and indeed they are. I
> tracked the difference in the numbers down to the point where I used
> "Prepare files for deposition" in ccp4i2. This is the first time I used
> this programme to convert my pdb and mtz files into cif files, instead of
> trying to deposit the pdb and mtz files as I've always done. The
> conversion, however, changed the R factors ... and seemingly nothing else
> as the coordinates of  both files are still the same.
>
>
> Any idea why the programme does this? Is there another programme I can use
> that doesn't do this? It's annoying because now I have to redeposit the
> data for the 10 structures I've submitted for this paper.
>
>
> Here are the remarks of the pdb file and the remarks of the resulting cif
> file, as you can see they are the same except for the R factors.
>
>
> PDB:
> REMARK   3  DATA USED IN REFINEMENT.
> REMARK   3   RESOLUTION RANGE HIGH (ANGSTROMS) :   1.67
> REMARK   3   RESOLUTION RANGE LOW  (ANGSTROMS) :  49.13
> REMARK   3   DATA CUTOFF(SIGMA(F)) : NONE
> REMARK   3   COMPLETENESS FOR RANGE(%) :  97.26
> REMARK   3   NUMBER OF REFLECTIONS :   35463
> REMARK   3
> REMARK   3  FIT TO DATA USED IN REFINEMENT.
> REMARK   3   CROSS-VALIDATION METHOD  : THROUGHOUT
> REMARK   3   FREE R VALUE TEST SET SELECTION  : RANDOM
> REMARK   3   R VALUE (WORKING + TEST SET) : 0.20233
> REMARK   3   R VALUE(WORKING SET) :  0.20068
> REMARK   3   FREE R VALUE :  0.23658
> REMARK   3   FREE R VALUE TEST SET SIZE   (%) :  4.7
> REMARK   3   FREE R VALUE TEST SET COUNT  :  1759
> REMARK   3
> REMARK   3  FIT IN THE HIGHEST RESOLUTION BIN.
> REMARK   3   TOTAL NUMBER OF BINS USED   :  20
> REMARK   3   BIN RESOLUTION RANGE HIGH   :1.670
> REMARK   3   BIN RESOLUTION RANGE LOW:1.714
> REMARK   3   REFLECTION IN BIN (WORKING SET) : 2221
> REMARK   3   BIN COMPLETENESS (WORKING+TEST) (%) :82.65
> REMARK   3   BIN R VALUE   (WORKING SET) :0.392
> REMARK   3   BIN FREE R VALUE SET COUNT  :  113
> REMARK   3   BIN FREE R VALUE:0.390
>
>
>
> CIF:
> REMARK   3  DATA USED IN REFIN

Re: [ccp4bb] conversion from pdb to cif format changes R factors ... why?

2018-10-03 Thread Antonio Ariza 
Hi Christian,


Yes, I used TLS refinement for all the structures I deposited … but the TLS 
parameters were included in the deposition task, so I  assumed the programme 
would know that it needs to take these into account.


Anyway …  I guess that in order to correct the remarks in the headers of the 
curated coordinates in the PDB, I'll have to alter all the cif files manually 
and then resubmit them to the deposition server.


Cheers,


Tony


--

Dr. Antonio Ariza
University of Oxford
Sir William Dunn School of Pathology
South Parks Road
Oxford
OX1 3RE
e-mail: antonio.ar...@path.ox.ac.uk<mailto:antonio.ar...@path.ox.ac.uk>
Tel: 00 +44 1865 285655

Links to my public profiles:
ResearchGate<https://www.researchgate.net/profile/Antonio_Ariza>
LinkedIn<https://www.linkedin.com/in/antonioariza1>
GoogleScholar<https://scholar.google.co.uk/citations?user=9pAIKV0J=en>
Twitter<https://twitter.com/DrAntonioAriza?lang=en>

Check out my latest paper!!!
Structural insights into the function of ZRANB3 in replication stress 
response<http://www.nature.com/articles/ncomms15847>



From: Christian Roth 
Sent: 02 October 2018 20:52
To: Antonio Ariza; CCP4BB@JISCMAIL.AC.UK
Subject: Re: [ccp4bb] conversion from pdb to cif format changes R factors ... 
why?


Hi Tony,


is that for all structures or just some? I recall there was a problem when one 
has used TLS refinement. The deposition task runs a 0 cycle refmac job to 
recreate the statistics. If there is a difference, e.g no TLS included that 
might explain the difference.


Cheers


Christian

Am 02.10.2018 um 19:25 schrieb Antonio Ariza:

Hi all,


I'm wondering if anyone else has noticed this ... or is there something I am 
missing here?


One of the reviewers of my latest manuscript just pointed out that the R 
factors in my validation reports are significantly different (i.e. worse) than 
those I stated in the paper. So, I checked and indeed they are. I tracked the 
difference in the numbers down to the point where I used "Prepare files for 
deposition" in ccp4i2. This is the first time I used this programme to convert 
my pdb and mtz files into cif files, instead of trying to deposit the pdb and 
mtz files as I've always done. The conversion, however, changed the R factors 
... and seemingly nothing else as the coordinates of  both files are still the 
same.


Any idea why the programme does this? Is there another programme I can use that 
doesn't do this? It's annoying because now I have to redeposit the data for the 
10 structures I've submitted for this paper.


Here are the remarks of the pdb file and the remarks of the resulting cif file, 
as you can see they are the same except for the R factors.


PDB:

REMARK   3  DATA USED IN REFINEMENT.
REMARK   3   RESOLUTION RANGE HIGH (ANGSTROMS) :   1.67
REMARK   3   RESOLUTION RANGE LOW  (ANGSTROMS) :  49.13
REMARK   3   DATA CUTOFF(SIGMA(F)) : NONE
REMARK   3   COMPLETENESS FOR RANGE(%) :  97.26
REMARK   3   NUMBER OF REFLECTIONS :   35463
REMARK   3
REMARK   3  FIT TO DATA USED IN REFINEMENT.
REMARK   3   CROSS-VALIDATION METHOD  : THROUGHOUT
REMARK   3   FREE R VALUE TEST SET SELECTION  : RANDOM
REMARK   3   R VALUE (WORKING + TEST SET) : 0.20233
REMARK   3   R VALUE(WORKING SET) :  0.20068
REMARK   3   FREE R VALUE :  0.23658
REMARK   3   FREE R VALUE TEST SET SIZE   (%) :  4.7
REMARK   3   FREE R VALUE TEST SET COUNT  :  1759
REMARK   3
REMARK   3  FIT IN THE HIGHEST RESOLUTION BIN.
REMARK   3   TOTAL NUMBER OF BINS USED   :  20
REMARK   3   BIN RESOLUTION RANGE HIGH   :1.670
REMARK   3   BIN RESOLUTION RANGE LOW:1.714
REMARK   3   REFLECTION IN BIN (WORKING SET) : 2221
REMARK   3   BIN COMPLETENESS (WORKING+TEST) (%) :82.65
REMARK   3   BIN R VALUE   (WORKING SET) :0.392
REMARK   3   BIN FREE R VALUE SET COUNT  :  113
REMARK   3   BIN FREE R VALUE:0.390



CIF:

REMARK   3  DATA USED IN REFINEMENT.
REMARK   3   RESOLUTION RANGE HIGH (ANGSTROMS) :   1.67
REMARK   3   RESOLUTION RANGE LOW  (ANGSTROMS) :  49.13
REMARK   3   DATA CUTOFF(SIGMA(F)) : NONE
REMARK   3   COMPLETENESS FOR RANGE(%) :  97.26
REMARK   3   NUMBER OF REFLECTIONS :   35463
REMARK   3
REMARK   3  FIT TO DATA USED IN REFINEMENT.
REMARK   3   CROSS-VALIDATION METHOD  : THROUGHOUT
REMARK   3   FREE R VALUE TEST SET SELECTION  : RANDOM
REMARK   3   R VALUE (WORKING + TEST SET) : 0.24316
REMARK   3   R VALUE(WORKING SET) :  0.24133
REMARK   3   FREE R VALUE :  0.28140
REMARK   3   FREE R VALUE TEST SET SIZE   (%) :  4.7
REMARK   3   FREE R VALUE TEST SET COUNT  :  1759
REMARK   3
REMARK   3  FIT IN THE HIGHEST RESOLUTION BIN.
REMARK   3   TOTAL NUMBER OF

Re: [ccp4bb] conversion from pdb to cif format changes R factors ... why?

2018-10-02 Thread Christian Roth 

Hi Tony,


is that for all structures or just some? I recall there was a problem 
when one has used TLS refinement. The deposition task runs a 0 cycle 
refmac job to recreate the statistics. If there is a difference, e.g no 
TLS included that might explain the difference.



Cheers


Christian


Am 02.10.2018 um 19:25 schrieb Antonio Ariza:


Hi all,


I'm wondering if anyone else has noticed this ... or is there 
something I am missing here?



One of the reviewers of my latest manuscript just pointed out that the 
R factors in my validation reports are significantly different (i.e. 
worse) than those I stated in the paper. So, I checked and indeed they 
are. I tracked the difference in the numbers down to the point where I 
used "Prepare files for deposition" in ccp4i2. This is the first time 
I used this programme to convert my pdb and mtz files into cif files, 
instead of trying to deposit the pdb and mtz files as I've always 
done. The conversion, however, changed the R factors ... and seemingly 
nothing else as the coordinates of  both files are still the same.



Any idea why the programme does this? Is there another programme I can 
use that doesn't do this? It's annoying because now I have to 
redeposit the data for the 10 structures I've submitted for this paper.



Here are the remarks of the pdb file and the remarks of the 
resulting cif file, as you can see they are the same except for the R 
factors.



PDB:

REMARK   3  DATA USED IN REFINEMENT.
REMARK   3   RESOLUTION RANGE HIGH (ANGSTROMS) :   1.67
REMARK   3   RESOLUTION RANGE LOW  (ANGSTROMS) :  49.13
REMARK   3   DATA CUTOFF    (SIGMA(F)) : NONE
REMARK   3   COMPLETENESS FOR RANGE    (%) :  97.26
REMARK   3   NUMBER OF REFLECTIONS :   35463
REMARK   3
REMARK   3  FIT TO DATA USED IN REFINEMENT.
REMARK   3   CROSS-VALIDATION METHOD  : THROUGHOUT
REMARK   3   FREE R VALUE TEST SET SELECTION  : RANDOM
REMARK   3   R VALUE (WORKING + TEST SET) : 0.20233
REMARK   3   R VALUE    (WORKING SET) :  0.20068
REMARK   3   FREE R VALUE :  0.23658
REMARK   3   FREE R VALUE TEST SET SIZE   (%) :  4.7
REMARK   3   FREE R VALUE TEST SET COUNT  :  1759
REMARK   3
REMARK   3  FIT IN THE HIGHEST RESOLUTION BIN.
REMARK   3   TOTAL NUMBER OF BINS USED   :  20
REMARK   3   BIN RESOLUTION RANGE HIGH   :    1.670
REMARK   3   BIN RESOLUTION RANGE LOW    :    1.714
REMARK   3   REFLECTION IN BIN (WORKING SET) : 2221
REMARK   3   BIN COMPLETENESS (WORKING+TEST) (%) :    82.65
REMARK   3   BIN R VALUE   (WORKING SET) :    0.392
REMARK   3   BIN FREE R VALUE SET COUNT  :  113
REMARK   3   BIN FREE R VALUE    :    0.390



CIF:

REMARK   3  DATA USED IN REFINEMENT.
REMARK   3   RESOLUTION RANGE HIGH (ANGSTROMS) :   1.67
REMARK   3   RESOLUTION RANGE LOW  (ANGSTROMS) :  49.13
REMARK   3   DATA CUTOFF    (SIGMA(F)) : NONE
REMARK   3   COMPLETENESS FOR RANGE    (%) :  97.26
REMARK   3   NUMBER OF REFLECTIONS :   35463
REMARK   3
REMARK   3  FIT TO DATA USED IN REFINEMENT.
REMARK   3   CROSS-VALIDATION METHOD  : THROUGHOUT
REMARK   3   FREE R VALUE TEST SET SELECTION  : RANDOM
REMARK   3   R VALUE (WORKING + TEST SET) : 0.24316
REMARK   3   R VALUE    (WORKING SET) :  0.24133
REMARK   3   FREE R VALUE :  0.28140
REMARK   3   FREE R VALUE TEST SET SIZE   (%) :  4.7
REMARK   3   FREE R VALUE TEST SET COUNT  :  1759
REMARK   3
REMARK   3  FIT IN THE HIGHEST RESOLUTION BIN.
REMARK   3   TOTAL NUMBER OF BINS USED   :  20
REMARK   3   BIN RESOLUTION RANGE HIGH   :    1.670
REMARK   3   BIN RESOLUTION RANGE LOW    :    1.714
REMARK   3   REFLECTION IN BIN (WORKING SET) : 2221
REMARK   3   BIN COMPLETENESS (WORKING+TEST) (%) :    82.65
REMARK   3   BIN R VALUE   (WORKING SET) :    0.426
REMARK   3   BIN FREE R VALUE SET COUNT  :  113
REMARK   3   BIN FREE R VALUE    :    0.429



Cheers,


Tony


--
*
Dr. Antonio Ariza
University of Oxford
Sir William Dunn School of Pathology
South Parks Road
Oxford
OX1 3RE*
*e-mail: *antonio.ar...@path.ox.ac.uk 
*Tel: 00 +44 1865 285655*
**
*Links to my public profiles:*
ResearchGate 
LinkedIn 
GoogleScholar 


Twitter 
*Check out my latest paper!!!*
Structural insights into the function of ZRANB3 in replication stress 
response 




To unsubscribe from the CCP4BB list, click the following link:
https://www.jiscmail.ac.uk/cgi-bin/webadmin?SUBED1=CCP4BB=1

[ccp4bb] conversion from pdb to cif format changes R factors ... why?

2018-10-02 Thread Antonio Ariza 
Hi all,


I'm wondering if anyone else has noticed this ... or is there something I am 
missing here?


One of the reviewers of my latest manuscript just pointed out that the R 
factors in my validation reports are significantly different (i.e. worse) than 
those I stated in the paper. So, I checked and indeed they are. I tracked the 
difference in the numbers down to the point where I used "Prepare files for 
deposition" in ccp4i2. This is the first time I used this programme to convert 
my pdb and mtz files into cif files, instead of trying to deposit the pdb and 
mtz files as I've always done. The conversion, however, changed the R factors 
... and seemingly nothing else as the coordinates of  both files are still the 
same.


Any idea why the programme does this? Is there another programme I can use that 
doesn't do this? It's annoying because now I have to redeposit the data for the 
10 structures I've submitted for this paper.


Here are the remarks of the pdb file and the remarks of the resulting cif file, 
as you can see they are the same except for the R factors.


PDB:

REMARK   3  DATA USED IN REFINEMENT.
REMARK   3   RESOLUTION RANGE HIGH (ANGSTROMS) :   1.67
REMARK   3   RESOLUTION RANGE LOW  (ANGSTROMS) :  49.13
REMARK   3   DATA CUTOFF(SIGMA(F)) : NONE
REMARK   3   COMPLETENESS FOR RANGE(%) :  97.26
REMARK   3   NUMBER OF REFLECTIONS :   35463
REMARK   3
REMARK   3  FIT TO DATA USED IN REFINEMENT.
REMARK   3   CROSS-VALIDATION METHOD  : THROUGHOUT
REMARK   3   FREE R VALUE TEST SET SELECTION  : RANDOM
REMARK   3   R VALUE (WORKING + TEST SET) : 0.20233
REMARK   3   R VALUE(WORKING SET) :  0.20068
REMARK   3   FREE R VALUE :  0.23658
REMARK   3   FREE R VALUE TEST SET SIZE   (%) :  4.7
REMARK   3   FREE R VALUE TEST SET COUNT  :  1759
REMARK   3
REMARK   3  FIT IN THE HIGHEST RESOLUTION BIN.
REMARK   3   TOTAL NUMBER OF BINS USED   :  20
REMARK   3   BIN RESOLUTION RANGE HIGH   :1.670
REMARK   3   BIN RESOLUTION RANGE LOW:1.714
REMARK   3   REFLECTION IN BIN (WORKING SET) : 2221
REMARK   3   BIN COMPLETENESS (WORKING+TEST) (%) :82.65
REMARK   3   BIN R VALUE   (WORKING SET) :0.392
REMARK   3   BIN FREE R VALUE SET COUNT  :  113
REMARK   3   BIN FREE R VALUE:0.390



CIF:

REMARK   3  DATA USED IN REFINEMENT.
REMARK   3   RESOLUTION RANGE HIGH (ANGSTROMS) :   1.67
REMARK   3   RESOLUTION RANGE LOW  (ANGSTROMS) :  49.13
REMARK   3   DATA CUTOFF(SIGMA(F)) : NONE
REMARK   3   COMPLETENESS FOR RANGE(%) :  97.26
REMARK   3   NUMBER OF REFLECTIONS :   35463
REMARK   3
REMARK   3  FIT TO DATA USED IN REFINEMENT.
REMARK   3   CROSS-VALIDATION METHOD  : THROUGHOUT
REMARK   3   FREE R VALUE TEST SET SELECTION  : RANDOM
REMARK   3   R VALUE (WORKING + TEST SET) : 0.24316
REMARK   3   R VALUE(WORKING SET) :  0.24133
REMARK   3   FREE R VALUE :  0.28140
REMARK   3   FREE R VALUE TEST SET SIZE   (%) :  4.7
REMARK   3   FREE R VALUE TEST SET COUNT  :  1759
REMARK   3
REMARK   3  FIT IN THE HIGHEST RESOLUTION BIN.
REMARK   3   TOTAL NUMBER OF BINS USED   :  20
REMARK   3   BIN RESOLUTION RANGE HIGH   :1.670
REMARK   3   BIN RESOLUTION RANGE LOW:1.714
REMARK   3   REFLECTION IN BIN (WORKING SET) : 2221
REMARK   3   BIN COMPLETENESS (WORKING+TEST) (%) :82.65
REMARK   3   BIN R VALUE   (WORKING SET) :0.426
REMARK   3   BIN FREE R VALUE SET COUNT  :  113
REMARK   3   BIN FREE R VALUE:0.429



Cheers,


Tony


--

Dr. Antonio Ariza
University of Oxford
Sir William Dunn School of Pathology
South Parks Road
Oxford
OX1 3RE
e-mail: antonio.ar...@path.ox.ac.uk
Tel: 00 +44 1865 285655

Links to my public profiles:
ResearchGate
LinkedIn
GoogleScholar
Twitter

Check out my latest paper!!!
Structural insights into the function of ZRANB3 in replication stress 
response



To unsubscribe from the CCP4BB list, click the following link:
https://www.jiscmail.ac.uk/cgi-bin/webadmin?SUBED1=CCP4BB=1