[ccp4bb] Cryo-EM virology faculty position at UW-Madison

[Eric Montemayor]

Dear Colleagues:



The University of Wisconsin-Madison Institute for Molecular Virology (IMV),
in collaboration with the Department of Biochemistry or the Department of
Plant Pathology, seek to hire a tenure-track (junior) Assistant Professor
to develop a collaborative cutting-edge research program aimed at
understanding the structure, dynamic responses and function of viral
machinery, or virus-host interactions, using biochemical, biophysical, and
structural techniques, especially cryo-electron microscopy (cryo-EM).


This position is one of a three-part synergistic hiring initiative "The
Metastructures of Viral Infection" which will expand and complement the
Madison Virology Program (MVP). This faculty hire will develop a research
program in virology or virus-related cell biology that will take advantage
of the resources available in the new Cryo-EM Research Center. The Center
houses four new cryo-microscopes including Thermo-Fisher's 300 kV Titan
Krios, 200 kV Talos Arctica, 120 kV Talos L120C, an Aquilos cryo-FIB-SEM,
as well as other ancillary preparative equipment.



Please click Here

 for the direct link to the post and application process. The deadline for
receipt of applications is December 1, 2018. The position will remain open
until filled.



For more information, please contact Ann Palmenberg  or  Elizabeth Wright.



--

Eric J. Montemayor

Associate Scientist

Department of Biochemistry

University of Wisconsin Madison

433 Babcock Dr. Room 145

Madison, WI 53706



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

[ccp4bb] LAST CHANCE: DLS/CCP4 data analysis workshop 2018

[David Waterman]

Dear all,

The application period for this year's DLS/CCP4 workshop closes this
Sunday. Please get your applications in soon if you would like the
opportunity to collect data at the UK's national synchrotron light source,
and get help from leading experts on your own projects.

Best wishes
-- David


On Wed, 19 Sep 2018 at 14:17, David Waterman  wrote:

> PhD students, postdocs and early career scientists,
>
> Please consider applying for the fifth joint DLS/CCP4 workshop on MX data 
> collection
> and structure solution, to be held at Diamond Light Source, UK from the 2nd
> to the 9th December (with accommodation from the 1st).
>
> This course offers the opportunity for you to work alongside leaders in
> the field of MX on data from your own crystals. For more details please
> check here:
>
> http://www.ccp4.ac.uk/schools/DLS-2018/
>
> The application period is now open and will close on the *7th October*.
> Applicants will be required to submit a CV/resume, describe their projects
> and obtain a letter of support from a supervisor, so please do not wait
> until the last minute to apply! Those with crystals and/or data will be
> given priority.
>
> Best wishes on behalf of the organisers,
>
> David Waterman (CCP4)
>
>



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

Re: [ccp4bb] PDRA Position, Leicester, with Peter Moody

[Peter Moody]

PS closing date is October 27th, please only apply through the  link  at
https://www.jobs.ac.uk/job/BND638/postdoctoral-research-associate
Thanks, Peter

On Fri, 28 Sep 2018 at 18:17, Peter Moody  wrote:

> I have a BBSRC-funded PDRA position for someone to come and work with me
> at the Leicester Institute for Structural & Chemical Biology, and so  this
> is about to be posted on jobs.ac.uk.   Please contact me using my
> university email, and not through this account (as the message will
> probaly get lost).
> Vacancy Name: Postdoctoral Research Associate
> Vacancy ID: 474
> Vacancy Department: Leicester Institute of Structural and Chemical
> Biology/Molecular and Cell Biology
> Advertising Start Date: 28/09/2018 00:00:00
> Advertised Salary: Grade 7 £34,189 to £39,609 per annum
>
>
> We wish to recruit a Postdoctoral Researcher to the group of Prof Peter
> Moody to take a leading role in a programme of research to investigate the
> mechanism of heme peroxidases, using advanced and innovative structural
> and spectroscopic methods. Our work is summarised in Moody & Raven (2018) 
> *Acc.Chem.
> Res.* 51 (2), pp 427–435 *DOI: *10.1021/acs.accounts.7b00463, and in more
> detail in the papers listed on Peter Moody’s Departmental home page https
> ://www2.le.ac.uk/departments/molcellbiol/staff/moody
> 
>
> The research is funded by the BBSRC and is a collaboration with Professor
> Emma Raven of the Chemistry Department at Bristol University (http://www.
> bris.ac.uk/chemistry/people/emma-raven/index.html) and will involve
> expressing and purifying proteins from recombinant sources, gaining s
> tructural and mechanistic insights using X-ray (using home and
> synchrotron sources) and Neutron crystallography (using ILL Grenoble, FRM-II
> Munich and ONRL, USA). We have recently conducted experiments using the
> Free Electron Laser SACLA in Japan and hope to use other FEL sources such
> as EuXFEL soon. Leicester has recently acquired state of the art cryo-electron
> microscopes and we would like to explore the potential for micro electron
> diffraction. A wide range of biochemical and biophysical techniques
> (especially spectroscopy) will be used to explore enzyme intermediates.
>
> You will  develop your own original research projects, in line with the
> aims and objectives of the research programme and assist with the
> supervision of graduate and undergraduate students. You will write up your
> research findings for dissemination amongst the research team and the
> broader international community and make presentations at scientific
> meetings in the UK and overseas.
> About you
>
> The successful applicant should hold a PhD, have a strong background in
> biochemical or structural analysis of proteins and have a keen interest in
> experimental design and determining the direction of the research programme.
>
> Additional information
>
> LISCB comprises over 20 research groups drawn from several departments,
> including the Department of Molecular and Cell Biology, and brings together
> internationally renowned research using structural biology, chemical
> biology and single molecule methods to investigate major challenges in
> fundamental biological processes into a single world-leading unit.
>
> The University of Leicester is committed to international excellence,
> world-changing research and high quality, inspirational teaching. Recently,
> the MRC in partnership with the Universities of Leicester, Warwick,
> Nottingham and Birmingham has invested into a state-of-the-art CryoEM
> facility at the Leicester Institute for Structural and Chemical Biology (
> LISCB), one of four new, flagship Research Institutes of the University
> of Leicester. We are strongly committed to inclusivity, promoting
> equality and celebrating diversity among our staff and students. You will
> develop your career in a supportive and collaborative academic
> environment in one of the world’s leading research-intensive
> universities; elite in the excellence of our research, yet distinctive for
> the genuine synergy between our research and teaching.
> In return for your hard work, we offer a working environment that is
> committed to inclusivity, through promoting equality and valuing
> diversity. We offer a salary package with excellent pension scheme, a
> generous annual leave allowance and an online portal that offers a range of
> lifestyle benefits and discounts. Located close to Leicester city centre,
> our award winning campus benefits from a wide range of cafes, a fully
> equipped sports centre and nursery facilities. Further information
> regarding our extensive range of staff benefits is available here.
> 
>
>
> Informal enquiries and are welcome and should be made to Professor Peter
> Moody on Tel: +44 (0)116 229 7097 or email: peter.mo...@leicester.ac.uk
> 
>

[ccp4bb] Crystallography/drug development Post-doc opportunity

[Flaherty, Daniel P]

Hello All,

My name is Daniel Flaherty and I am an Assistant Professor at Purdue 
University. I am seeking a post-doc with experience in structural determination 
of protein targets and ligand-bound protein structures to support our drug 
development projects.  Please find the position announcement at this website: 
https://www.flahertylab.com/positions

Cheers,

Dan



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

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

[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
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



From: Christian Roth 
mailto:christianroth...@gmail.com>>
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   

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

[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
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



From: Christian Roth 
mailto:christianroth...@gmail.com>>
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   

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

[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

*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 



*From:* Christian Roth mailto:christianroth...@gmail.com>>
*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  

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

[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 
> LinkedIn 
> GoogleScholar
> 
> Twitter 
>
> *Check out my latest paper!!!*
> Structural insights into the function of ZRANB3 in replication stress
> response 
>
>
> --
> *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
> 

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

[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
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



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 BINS USED   :  20
REMARK   3   BIN