Re: [ccp4bb] Semet derivative dying almost immediately in beam

[graeme.win...@diamond.ac.uk]

Their web page indicates they’re running a 315, so there are limits on useful 
low dose data collection. If you can get to a beamline with a pixel array 
detector and mount your samples carefully you’ll probably get more from low 
dose methods.

The key thing with this is minimising background from loop, drop etc so the 
photons you measure are as far as possible from the sample under study. You’ll 
probably benefit from combining data from multiple samples if they are 
isomorphous.

Obviously your ultimate resolution will be limited by the number of photons 
your sample can scatter before suffering measurable damage... but combining 
samples can help you here

Best wishes Graeme

On 29 Aug 2019, at 19:07, Kimberly Stanek 
mailto:ksta...@uci.edu>> wrote:

ALS 822. I tried as low as 0.2 sec exposure but it didn't seem to help much.


Kimberly Stanek
Postdoctoral Researcher, Goulding Lab
Co-chair, UCI Postdoctoral Association
University of California, Irvine
Natural Science I, Room 2302
(949) 824-0014

From: James Holton mailto:jmhol...@lbl.gov>>
Sent: Thursday, August 29, 2019 10:50 AM
To: Kimberly Stanek mailto:ksta...@uci.edu>>; 
CCP4BB@JISCMAIL.AC.UK 
mailto:CCP4BB@JISCMAIL.AC.UK>>
Subject: Re: [ccp4bb] Semet derivative dying almost immediately in beam

What exposure time are you using?  And which beamline?

-James Holton
MAD Scientist

On 8/29/2019 10:26 AM, Kimberly Stanek wrote:
Hi folks,

We have a protein that we have been trying to solve the structure of for a 
while now but so far haven't been able to get any diffraction better than 
~4.5A. I was able to collect a full 360 degrees of data and index, but MR is 
failing so we have turned to de novo phasing.

Recently we prepared crystals of the Semet derivative under the same condition. 
While these crystals diffracted to about the same resolution, I found they were 
dying after just one or two snaps, even with increased beam attenuation and 
decreased exposure time. I am wondering if anyone has experienced anything like 
this before and had any suggestions on what to do about it.

Thank you,



Kimberly Stanek
Postdoctoral Researcher, Goulding Lab
Co-chair, UCI Postdoctoral Association
University of California, Irvine
Natural Science I, Room 2302
(949) 824-0014



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

-- 
This e-mail and any attachments may contain confidential, copyright and or 
privileged material, and are for the use of the intended addressee only. If you 
are not the intended addressee or an authorised recipient of the addressee 
please notify us of receipt by returning the e-mail and do not use, copy, 
retain, distribute or disclose the information in or attached to the e-mail.
Any opinions expressed within this e-mail are those of the individual and not 
necessarily of Diamond Light Source Ltd. 
Diamond Light Source Ltd. cannot guarantee that this e-mail or any attachments 
are free from viruses and we cannot accept liability for any damage which you 
may sustain as a result of software viruses which may be transmitted in or with 
the message.
Diamond Light Source Limited (company no. 4375679). Registered in England and 
Wales with its registered office at Diamond House, Harwell Science and 
Innovation Campus, Didcot, Oxfordshire, OX11 0DE, United Kingdom




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

Re: [ccp4bb] Better Beamline suggestion!

[graeme.win...@diamond.ac.uk]

Chandra

What you are looking for here is a beamline with a detector with many pixels 
(so you can resolve the long axis) and a multi-axis goniometer - probably a 
SmarGon / kappa and an Eiger 16M would make a good combination for this. 
Searching on

http://biosync.sbkb.org/

Should allow you to make up a short list

Best wishes Graeme

On 19 Aug 2019, at 16:08, Chandramohan Kattamuri 
<1c5b7cb6c764-dmarc-requ...@jiscmail.ac.uk>
 wrote:


Dear All
We recently collected a data set at APS, Chicago with unit cell dimensions of 
68.4; 68.4 and 991.6 A. Our diffraction data extends to 3A with the APS set up, 
however, the long axis has been problematic, resulting in streaking of the 
diffraction data and requires a very specific orientation of the crystal for 
usable diffraction. Can anyone recommend beamlines that can give us higher 
resolution, or a source with a better goniometer allowing for more angle 
manipulation after looping?
Thank a lot
Chandra K






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


-- 
This e-mail and any attachments may contain confidential, copyright and or 
privileged material, and are for the use of the intended addressee only. If you 
are not the intended addressee or an authorised recipient of the addressee 
please notify us of receipt by returning the e-mail and do not use, copy, 
retain, distribute or disclose the information in or attached to the e-mail.
Any opinions expressed within this e-mail are those of the individual and not 
necessarily of Diamond Light Source Ltd. 
Diamond Light Source Ltd. cannot guarantee that this e-mail or any attachments 
are free from viruses and we cannot accept liability for any damage which you 
may sustain as a result of software viruses which may be transmitted in or with 
the message.
Diamond Light Source Limited (company no. 4375679). Registered in England and 
Wales with its registered office at Diamond House, Harwell Science and 
Innovation Campus, Didcot, Oxfordshire, OX11 0DE, United Kingdom




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

Re: [ccp4bb] challenges in structural biology

[graeme.win...@diamond.ac.uk]

Dear all

While I am well aware as are many that complimentary methods offer a great deal 
these days, I think X ray diffraction is not a solved problem for the reasons 
originally enumerated by James amongst others

I would also remind that the conference is

Diffraction Methods in Structural Biology

And is unique in being a conference where us methods types can get together and 
exchange ideas. I for one would be disappointed if it became a biology results 
only conference focussed on non diffraction methods. While I recognise the 
value that these methods bring, no one technique rules them all, which applies 
to X ray diffraction as much as any other

There are dedicated GRCs for EM etc.

Best wishes Graeme

On 17 Jul 2019, at 12:36, Bärbel Blaum 
mailto:baerbel.bl...@intherabio.com>> wrote:

Dear all,

I totally agree with Radu. James was not entirely clear if he wanted to 
exclusively cover challenges "faced during structure determination" or, maybe 
more generally, "challenges faced by structural-biologists", which makes a big 
difference in the eyes of some of us. Now for the actual scientific part of the 
meeting it might be best to concentrate on the first type of challenges, since 
there are plenty. However, since Gordon conferences attract a number of young 
participants who have not yet decided where to go I would think it is an 
excellent place to openly discuss those broader-perspective type of questions 
as well. Non-structural biology techniques that are closer to the real thing 
(like microscopy) have gained a lot of ground as well, and while it might be 
incomprehensive for some of us why anyone would choose any biological 
discipline other than structural biology I am under the stark impression that 
some students have indeed already started to regard crystallography as a 
dinosaur technique, and not just because cryoEM improved - that is a challenge 
to structural biology, too.

Kind regards,

Bärbel

--
Bärbel Blaum, PhD
Inthera Bioscience AG
Einsiedlerstrasse 34
CH-8820 Waedenswil
Switzerland
E-Mail: baerbel.bl...@intherabio.com
Phone: +41 43 477 94 72--



Am 17.07.19, 11:53 schrieb "CCP4 bulletin board im Auftrag von 
r...@mrc-lmb.cam.ac.uk" 
mailto:CCP4BB@JISCMAIL.AC.UK> im Auftrag von 
r...@mrc-lmb.cam.ac.uk>:

   Hi Paul,

   Fair point, apologies if anyone was offended by my comments! I simply thought
   that such matters are meaningful for this forum. I am just as guilty as
   everyone, and it is important to put our work into the broader perspective
   from time to time.

   Best wishes,

   Radu


Hi Radu and all

Could i humbly suggest some careful reflection before this ends up polarising
the amazing structural biology community. Since the year dot everyone has been
contributing to integrated approaches and I fear that the tone of this debate
will create much negativity around the community which seems pointless at
least to me..

Maybe a commentary published somewhere would be a better way to debate what
are important issues and not through the  CCP4 forum?

best wishes

Paul




On 17 Jul 2019, at 10:21, r...@mrc-lmb.cam.ac.uk 
wrote:

Hi Susan,

We are not naive if we care about using the limited resources of this
planet
responsibly. This has nothing to do with whoever's favourite method. I have
nothing against crystallography, it is a beautiful art and has been a
success
historically. I have solved plenty of crystal structures myself and will
probably have to keep doing it for a little while. But it is naive to
ignore
that the time to move on has arrived, and that we have to use resources to
develop better technologies which address the real biological questions
instead of keeping dinosaurs on life support.

How many of the structures solved on synchrotrons worldwide and of the
zillions in the PDB are of any use or biological relevance (original
question)? There is an enormous amount of waste, including the nasty
chemicals
use to grow crystals and to phase pointless structures, let's be honest.

Best wishes,

Radu



I think we are naive if we care about the method used to obtain the
structure
- what matters is getting at the structure.  What is great is that the
variety
of ways we can do this has increased meaning more samples become tractable
for
high resolution structure determination. I donâ•˙t see the point of
ridiculous
my method is better than your method arguments - for some samples all
methods
are equivalent, for some there is only one method that will yield answers -
we
just need to train students and develop methods that allow the broadest
access. Everything else is bias-driven posturing. Letâ•˙s just solve some
structures and learn something about biology.


Susan

Sent from my iPhone

On 17 Jul 2019, at 08:43, r...@mrc-lmb.cam.ac.uk 
mailto:r...@mrc-lmb.cam.ac.uk>>
wrote:

Hi Both,

I am not 

Re: [ccp4bb] challenges in structural biology

[graeme.win...@diamond.ac.uk]

Dear All,

I have been enjoying “lurking” on this thread - some thoughts

I love this approach to conference organising :-) 

You missed radiation damage from this list ;-)  - is critically connected to 
isomorphism, resolution, serial methods and is probably the single greatest 
limitation on X-ray experiments. Also takes us back to the 80’s / 90’s - pre 
cryo - where many crystallographic studies were serial (and this was not 
special!) - we are just orders of magnitude faster today

Isomorphism, resolution, damage, serial methods, dynamic crystallography - 
these are all aspects of the same problem i.e. collection in an environment 
where the sample under study evolves - a topic of “moving targets” would seem 
to capture some of these ideas

I also echo Kay’s comment that serial _rotation_ crystallography is fine - we 
understand this and can easily get results which look OK / good according to 
traditional measures - when it comes to still shots from almost any source we 
are a long way behind

Back to lurking now

All best Graeme

> On 15 Jul 2019, at 20:44, Holton, James M 
> <270165b9f4cf-dmarc-requ...@jiscmail.ac.uk> wrote:
> 
> Hello folks,
> 
> I have the distinct honor of chairing the next Gordon Research 
> Conference on Diffraction Methods in Structural Biology (July 26-31 
> 2020).  This meeting will focus on the biggest challenges currently 
> faced by structural biologists, and I mean actual real-world 
> challenges.  As much as possible, these challenges will take the form of 
> friendly competitions with defined parameters, data, a scoring system, 
> and "winners", to be established along with other unpublished results 
> only at the meeting, as is tradition at GRCs.
> 
> But what are the principle challenges in biological structure 
> determination today?  I of course have my own ideas, but I feel like I'm 
> forgetting something.  Obvious choices are:
> 1) getting crystals to diffract better
> 2) building models into low-resolution maps (after failing at #1)
> 3) telling if a ligand is really there or not
> 4) the phase problem (dealing with weak signal, twinning and 
> pseudotranslation)
> 5) what does "resolution" really mean?
> 6) why are macromolecular R factors so much higher than small-molecule ones?
> 7) what is the best way to process serial crystallography data?
> 8) how should one deal with non-isomorphism in multi-crystal methods?
> 9) what is the "structure" of something that won't sit still?
> 
> What am I missing?  Is industry facing different problems than 
> academics?  Are there specific challenges facing electron-based 
> techniques?  If so, could the combined strength of all the world's 
> methods developers solve them?  I'm interested in hearing the voice of 
> this community.  On or off-list is fine.
> 
> -James Holton
> MAD Scientist
> 
> 
> 
> 
> To unsubscribe from the CCP4BB list, click the following link:
> https://www.jiscmail.ac.uk/cgi-bin/webadmin?SUBED1=CCP4BB=1


-- 
This e-mail and any attachments may contain confidential, copyright and or 
privileged material, and are for the use of the intended addressee only. If you 
are not the intended addressee or an authorised recipient of the addressee 
please notify us of receipt by returning the e-mail and do not use, copy, 
retain, distribute or disclose the information in or attached to the e-mail.
Any opinions expressed within this e-mail are those of the individual and not 
necessarily of Diamond Light Source Ltd. 
Diamond Light Source Ltd. cannot guarantee that this e-mail or any attachments 
are free from viruses and we cannot accept liability for any damage which you 
may sustain as a result of software viruses which may be transmitted in or with 
the message.
Diamond Light Source Limited (company no. 4375679). Registered in England and 
Wales with its registered office at Diamond House, Harwell Science and 
Innovation Campus, Didcot, Oxfordshire, OX11 0DE, United Kingdom




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

Re: [ccp4bb] resolution

[graeme.win...@diamond.ac.uk]

Pavel,

Please correct if wrong, but I thought most refinement programs used the 
weights e.g. sig(I/F) with I/F so would not really have a hard cut off anyway? 
You’re just making the stats worse but the model should stay ~ the same (unless 
you have outliers in there)

Clearly there will be a point where the model stops improving, which is the 
“true” limit…

Cheers Graeme



On 5 Jul 2019, at 06:49, Pavel Afonine 
mailto:pafon...@gmail.com>> wrote:

Hi Sam Tang,

Sorry for a naive question. Is there any circumstances where one may wish to 
refine to a lower resolution? For example if one has a dataset processed to 2 
A, is there any good reasons for he/she to refine to only, say 2.5 A?

yes, certainly. For example, when information content in the data can justify 
it.. Randy Read can comment on this more! Also instead of a hard cutoff using a 
smooth weight based attenuation may be even better. AFAIK, no refinement 
program can do this smartly currently.
Pavel



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


-- 
This e-mail and any attachments may contain confidential, copyright and or 
privileged material, and are for the use of the intended addressee only. If you 
are not the intended addressee or an authorised recipient of the addressee 
please notify us of receipt by returning the e-mail and do not use, copy, 
retain, distribute or disclose the information in or attached to the e-mail.
Any opinions expressed within this e-mail are those of the individual and not 
necessarily of Diamond Light Source Ltd. 
Diamond Light Source Ltd. cannot guarantee that this e-mail or any attachments 
are free from viruses and we cannot accept liability for any damage which you 
may sustain as a result of software viruses which may be transmitted in or with 
the message.
Diamond Light Source Limited (company no. 4375679). Registered in England and 
Wales with its registered office at Diamond House, Harwell Science and 
Innovation Campus, Didcot, Oxfordshire, OX11 0DE, United Kingdom




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

Re: [ccp4bb] resolution

[graeme.win...@diamond.ac.uk]

Hi Sam,

If you have good data to 2A, then I cannot imagine throwing away a significant 
fraction of it (there are lot of spots from 2.5-2A) will make your model better

Suggest reading

http://scripts.iucr.org/cgi-bin/paper?S0907444913001121

All best Graeme

On 5 Jul 2019, at 06:43, Sam Tang 
mailto:samtys0...@gmail.com>> wrote:

Hello everyone

Sorry for a naive question. Is there any circumstances where one may wish to 
refine to a lower resolution? For example if one has a dataset processed to 2 
A, is there any good reasons for he/she to refine to only, say 2.5 A?

Thanks!

Sam Tang



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


-- 
This e-mail and any attachments may contain confidential, copyright and or 
privileged material, and are for the use of the intended addressee only. If you 
are not the intended addressee or an authorised recipient of the addressee 
please notify us of receipt by returning the e-mail and do not use, copy, 
retain, distribute or disclose the information in or attached to the e-mail.
Any opinions expressed within this e-mail are those of the individual and not 
necessarily of Diamond Light Source Ltd. 
Diamond Light Source Ltd. cannot guarantee that this e-mail or any attachments 
are free from viruses and we cannot accept liability for any damage which you 
may sustain as a result of software viruses which may be transmitted in or with 
the message.
Diamond Light Source Limited (company no. 4375679). Registered in England and 
Wales with its registered office at Diamond House, Harwell Science and 
Innovation Campus, Didcot, Oxfordshire, OX11 0DE, United Kingdom




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

[ccp4bb]

[graeme.win...@diamond.ac.uk]

Hi Scott,

You can run CAD two or more times - merge the columns incrementally (i.e. 1..9 
then (1..9)+10..16)

Best wishes Graeme

On 10 May 2019, at 23:57, Scott Horowitz 
mailto:horow...@umich.edu>> wrote:

Hi all,

I’m trying to combine 16 datasets together using Cad, and it’s failing with the 
following in the log file:

Key_Word Error, For LABIN FILE_NUMBER line:-
  File_Number Given =   10 Is invalid only files 1 to  9 Allowed, Ignoring this 
line -

It does that for all the datasets starting with number 10, which makes it seem 
like it can only combine 9 datasets at a time. I was just wondering if that’s 
something others have run into and dealt with before?

The whole of the log file is below, if you want to peruse it.

Thanks,
Scott
#CCP4I VERSION CCP4Interface 7.0.045
#CCP4I SCRIPT LOG cad
#CCP4I DATE 10 May 2019  14:54:40
#CCP4I USER 'UNKNOWN'
#CCP4I PROJECT Serena
#CCP4I JOB_ID 7
#CCP4I SCRATCH C:/ccp4temp
#CCP4I HOSTNAME DU-1KDZDH2
#CCP4I PID 17552








 ###
###
###
### CCP4 7.0.045: CAD  version 7.0.045 : ##
###
User: Scott.Horowitz  Run date: 10/ 5/2019 Run time: 14:54:41


Please reference: Collaborative Computational Project, Number 4. 2011.
"Overview of the CCP4 suite and current developments". Acta Cryst. D67, 235-242.
as well as any specific reference in the program write-up.


Data line--- title [No title given]
Data line--- monitor FULL
Data line--- labin file 1 E1 = R-free-flags(+) E2 = R-free-flags(-)
Data line--- labout file 1 E1 = R-free-flags(+) E2 = R-free-flags(-)
Data line--- ctypin file 1 E1 = I E2 = I
Data line--- labin file 2 E1 = F E2 = SIGF E3 = DANO E4 = 
SIGDANO E5 = F(+) E6 = SIGF(+) E7 = F(-) E8 = SIGF(-) E9 = 
ISYM E10 = IMEAN E11 = SIGIMEAN E12 = I(+) E13 = SIGI(+) 
E14 = I(-) E15 = SIGI(-)
Data line--- labout file 2 E1 = F E2 = SIGF E3 = DANO E4 = 
SIGDANO E5 = F(+) E6 = SIGF(+) E7 = F(-) E8 = SIGF(-) E9 = 
ISYM E10 = IMEAN E11 = SIGIMEAN E12 = I(+) E13 = SIGI(+) 
E14 = I(-) E15 = SIGI(-)
Data line--- ctypin file 2 E1 = F E2 = Q E3 = D E4 = Q E5 = 
G E6 = L E7 = G E8 = L E9 = Y E10 = J E11 = Q E12 = 
K E13 = M E14 = K E15 = M
Data line--- labin file 3 E1 = R-free-flags
Data line--- labout file 3 E1 = R-free-flags_4p5
Data line--- ctypin file 3 E1 = I
Data line--- labin file 4 E1 = F E2 = SIGF E3 = DANO E4 = 
SIGDANO E5 = F(+) E6 = SIGF(+) E7 = F(-) E8 = SIGF(-) E9 = 
ISYM E10 = IMEAN E11 = SIGIMEAN E12 = I(+) E13 = SIGI(+) 
E14 = I(-) E15 = SIGI(-)
Data line--- labout file 4 E1 = F_4p5 E2 = SIGF_4p5 E3 = DANO_4p5   
  E4 = SIGDANO_4p5 E5 = F(+)_4p5 E6 = SIGF(+)_4p5 E7 = F(-)_4p5 
E8 = SIGF(-)_4p5 E9 = ISYM_4p5 E10 = IMEAN_4p5 E11 = SIGIMEAN_4p5   
  E12 = I(+)_4p5 E13 = SIGI(+)_4p5 E14 = I(-)_4p5 E15 = SIGI(-)_4p5
Data line--- ctypin file 4 E1 = F E2 = Q E3 = D E4 = Q E5 = 
G E6 = L E7 = G E8 = L E9 = Y E10 = J E11 = Q E12 = 
K E13 = M E14 = K E15 = M
Data line--- labin file 5 E1 = R-free-flags
Data line--- labout file 5 E1 = R-free-flags_2p87
Data line--- ctypin file 5 E1 = I
Data line--- labin file 6 E1 = F E2 = SIGF E3 = DANO E4 = 
SIGDANO E5 = F(+) E6 = SIGF(+) E7 = F(-) E8 = SIGF(-) E9 = 
ISYM E10 = IMEAN E11 = SIGIMEAN E12 = I(+) E13 = SIGI(+) 
E14 = I(-) E15 = SIGI(-)
Data line--- labout file 6 E1 = F_2p87 E2 = SIGF_2p87 E3 = 
DANO_2p87 E4 = SIGDANO_2p87 E5 = F(+)_2p87 E6 = SIGF(+)_2p87 E7 
= F(-)_2p87 E8 = SIGF(-)_2p87 E9 = ISYM_2p87 E10 = IMEAN_2p87 
E11 = SIGIMEAN_2p87 E12 = I(+)_2p87 E13 = SIGI(+)_2p87 E14 = 
I(-)_2p87 E15 = SIGI(-)_2p87
Data line--- ctypin file 6 E1 = F E2 = Q E3 = D E4 = Q E5 = 
G E6 = L E7 = G E8 = L E9 = Y E10 = J E11 = Q E12 = 
K E13 = M E14 = K E15 = M
Data line--- labin file 7 E1 = R-free-flags
Data line--- labout file 7 E1 = R-free-flags_2p75
Data line--- ctypin file 7 E1 = I
Data line--- labin file 8 E1 = F E2 = SIGF E3 = DANO E4 = 
SIGDANO E5 = F(+) E6 = SIGF(+) E7 = F(-) E8 = SIGF(-) E9 = 
ISYM E10 = IMEAN E11 = SIGIMEAN E12 = I(+) E13 = SIGI(+) 
E14 = I(-) E15 = SIGI(-)
Data line--- labout file 8 E1 = F_2p75 E2 = SIGF_2p75 E3 = 
DANO_2p75 E4 = SIGDANO_2p75 E5 = F(+)_2p75 E6 = SIGF(+)_2p75 E7 
= 

Re: [ccp4bb] installation of XDS

[graeme.win...@diamond.ac.uk]

Hi Nadine

The program is probably correct - I suspect you have no XDS.INP in there

I recommend using e.g. generate_XDS.INP for this purpose

https://strucbio.biologie.uni-konstanz.de/xdswiki/index.php/Generate_XDS.INP

You may find the wider XDS wiki worth a read

Best wishes Graeme


On 2 Apr 2019, at 15:51, Nadine Gerlach 
mailto:ngerl...@marum.de>> wrote:


Hello,

I need help installing XDS on the computer. Apparently the current lisence 
expired on March 31 2019, which is why I downloaded and extracted the 
XDS_html_doc.tar.gz
  from http://xds.mpimf-heidelberg.mpg.de/html_doc/downloading.html in 
/home/Programs/XDS-INTEL64_Linux_x86_64. This directory also contains the 
uncrompressed XDS_html_doc folder. However, if I wanna run xds I get the 
following error message:

!!! ERROR !!! CANNOT OPEN OR READ XDS.INP

I am not really experience with ubuntu or linux. Can someone please help me?

Thanks in advance!

Best,

Nadine

--
PhD student
Joint Research Group Marine Glycobiology
Max Planck Institute for Marine Microbiology &
MARUM - Center for Marine Environmental Sciences, University Bremen
MARUM Pavillon Raum 1110
Leobener Str. 2
28359 Bremen, Germany



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


-- 
This e-mail and any attachments may contain confidential, copyright and or 
privileged material, and are for the use of the intended addressee only. If you 
are not the intended addressee or an authorised recipient of the addressee 
please notify us of receipt by returning the e-mail and do not use, copy, 
retain, distribute or disclose the information in or attached to the e-mail.
Any opinions expressed within this e-mail are those of the individual and not 
necessarily of Diamond Light Source Ltd. 
Diamond Light Source Ltd. cannot guarantee that this e-mail or any attachments 
are free from viruses and we cannot accept liability for any damage which you 
may sustain as a result of software viruses which may be transmitted in or with 
the message.
Diamond Light Source Limited (company no. 4375679). Registered in England and 
Wales with its registered office at Diamond House, Harwell Science and 
Innovation Campus, Didcot, Oxfordshire, OX11 0DE, United Kingdom




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

Re: [ccp4bb] Backup of whole synchrotrons

[graeme.win...@diamond.ac.uk]

While this may sound absurd, the principle of incremental backups can help out 
a great deal here. Like Apple’s Time Machine, all we need to do is store a copy 
of the things which have changed rather than the entire facility, which reduces 
the burden by at least a few orders of magnitude. Such efficiency savings will 
I am sure be of great interest in this project. Surely though we could save a 
copy of the experimental Eigenstate before the experiment too, offering the 
option of going back and having another go - every experimentalists dream!

I do however take issue with your hypothesis that only the experimental 
equipment need be backed up - surely the experimenters also need to be 
archived, to allow the question “What were you thinking??” to be accurately 
answered when the reviewer’s questions come back. Unfortunately due to quantum 
entanglement issues this would probably require archiving the mind-state of 
dozens of people every time you hit “go” with the associated data protection 
issues - I for one would not like to fill in the GDPR section of that EU 
application :-)

Anyhow, best of luck with your application,

Graeme

On 1 Apr 2019, at 04:59, Petr Kolenko 
mailto:petr.kole...@fjfi.cvut.cz>> wrote:

Dear colleagues,
We all are very happy about the storage of raw crystallographic datasets. But, 
is it really enough? No! Can we do better? Yes, of course!
The problem is that the crystal after the measurement is usually burned. It 
does not make sense to store them any more. But, in order to maximize 
reproducibility and increase the reliability of all our results, the committee 
of the Czech and Slovak Crystallographic Association has decided to force our 
researchers to back up the whole experimental station (including synchrotrons 
and their storage rings) after each crystal, each use. Storage of synchrotrons 
under liquid nitrogen is welcomed, but not necessary, yet. For the next decade, 
in-house storage of complete XFELs is expected (EU project Horizon 2030, 
proposal EC.2030.14.1.CZ.004).
Best regards,
Petr



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


-- 
This e-mail and any attachments may contain confidential, copyright and or 
privileged material, and are for the use of the intended addressee only. If you 
are not the intended addressee or an authorised recipient of the addressee 
please notify us of receipt by returning the e-mail and do not use, copy, 
retain, distribute or disclose the information in or attached to the e-mail.
Any opinions expressed within this e-mail are those of the individual and not 
necessarily of Diamond Light Source Ltd. 
Diamond Light Source Ltd. cannot guarantee that this e-mail or any attachments 
are free from viruses and we cannot accept liability for any damage which you 
may sustain as a result of software viruses which may be transmitted in or with 
the message.
Diamond Light Source Limited (company no. 4375679). Registered in England and 
Wales with its registered office at Diamond House, Harwell Science and 
Innovation Campus, Didcot, Oxfordshire, OX11 0DE, United Kingdom




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

Re: [ccp4bb] Deposition requirement of anomalous pairs?

[graeme.win...@diamond.ac.uk]

Hi Eleanor

I’d raise you scaled but unmerged intensities :-)

Best wishes Graeme


On 20 Mar 2019, at 12:21, Eleanor Dodson 
<176a9d5ebad7-dmarc-requ...@jiscmail.ac.uk>
 wrote:


Wouldn't it be a good idea if the pdb required that data deposition provide h k 
l I+ SIGI+  I- SIGI-  ??

Even if the depositor has not exploited the anomalous signal, it may well be 
there sufficiently strongly to validate CYS or phosphates.

I believe aata processing programs provide this information ?

Eleanor Dodson



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

-- 
This e-mail and any attachments may contain confidential, copyright and or 
privileged material, and are for the use of the intended addressee only. If you 
are not the intended addressee or an authorised recipient of the addressee 
please notify us of receipt by returning the e-mail and do not use, copy, 
retain, distribute or disclose the information in or attached to the e-mail.
Any opinions expressed within this e-mail are those of the individual and not 
necessarily of Diamond Light Source Ltd. 
Diamond Light Source Ltd. cannot guarantee that this e-mail or any attachments 
are free from viruses and we cannot accept liability for any damage which you 
may sustain as a result of software viruses which may be transmitted in or with 
the message.
Diamond Light Source Limited (company no. 4375679). Registered in England and 
Wales with its registered office at Diamond House, Harwell Science and 
Innovation Campus, Didcot, Oxfordshire, OX11 0DE, United Kingdom




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

Re: [ccp4bb] Thoughtful remark...

[graeme.win...@diamond.ac.uk]

Dear Leo,

I would argue that not getting diffraction would indicate that the sample under 
study is not a crystal ;-) 

That way the two scenarios are the same - in neither case do you have a crystal 
in the loop

All the best Graeme



> On 1 Feb 2019, at 08:42, CHAVAS Leonard 
>  wrote:
> 
> Dear all
> 
> I had one interesting comment today at the beamline, that I would like to 
> share with you for your advice on how to answer this...
> 
> Is it better to have no diffraction from a crystal you shoot, or to have no 
> crystal in the loop?
> 
> Hum, difficult one...
> 
> Cheers, leo
> 
> -
> Leonard Chavas
> - 
> Synchrotron SOLEIL
> Proxima-I
> L'Orme des Merisiers
> Saint-Aubin - BP 48
> 91192 Gif-sur-Yvette Cedex
> France
> - 
> Phone:  +33 169 359 746
> Mobile: +33 644 321 614
> E-mail: leonard.cha...@synchrotron-soleil.fr
> -
> 
> 
> 
> To unsubscribe from the CCP4BB list, click the following link:
> https://www.jiscmail.ac.uk/cgi-bin/webadmin?SUBED1=CCP4BB=1


-- 
This e-mail and any attachments may contain confidential, copyright and or 
privileged material, and are for the use of the intended addressee only. If you 
are not the intended addressee or an authorised recipient of the addressee 
please notify us of receipt by returning the e-mail and do not use, copy, 
retain, distribute or disclose the information in or attached to the e-mail.
Any opinions expressed within this e-mail are those of the individual and not 
necessarily of Diamond Light Source Ltd. 
Diamond Light Source Ltd. cannot guarantee that this e-mail or any attachments 
are free from viruses and we cannot accept liability for any damage which you 
may sustain as a result of software viruses which may be transmitted in or with 
the message.
Diamond Light Source Limited (company no. 4375679). Registered in England and 
Wales with its registered office at Diamond House, Harwell Science and 
Innovation Campus, Didcot, Oxfordshire, OX11 0DE, United Kingdom




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

Re: [ccp4bb] old data

[graeme.win...@diamond.ac.uk]

Hi Dean

Usually there is a serial number buried somewhere in the header - many are text 
headers though some have TIFF format binary headers. Often a timestamp as well 
though this is less common

From there biosync may help e.g.

http://biosync.sbkb.org/beamlineupdatehistory.jsp?region=european_id=esrf_name=BM14=400=600

(the list of ESRF MX beamlines is short so should not be too painful)

Knowing the format, filename you can probably pin it down or if you share a 
little more info someone on the BB will know

All the best Graeme



On 31 Jan 2019, at 09:38, Dean Derbyshire 
mailto:dean.derbysh...@medivir.com>> wrote:

maybe a silly question it there a data base or other way to tell what detector 
was used to collect historic data. Image header isn’t hugely helpful
ESRF is all I know for the source but I’d like to know what the detector was at 
the time… -  I’m talking 2005-2010

   Dean Derbyshire
   Principal Scientist Protein Crystallography
[X]
   Box 1086
   SE-141 22 Huddinge
   SWEDEN
   Visit: Lunastigen 7
   Direct: +46 8 54683219
   Mobile: +46731251723
   www.medivir.com
--
This transmission is intended for the person to whom or the entity
to which it is addressed and may contain information that is privileged,
confidential and exempt from disclosure under applicable law.
If you are not the intended recipient, please be notified that any 
dissemination,
distribution or copying is strictly prohibited.
If you have received this transmission in error, please notify us immediately.
Thank you for your cooperation.



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


-- 
This e-mail and any attachments may contain confidential, copyright and or 
privileged material, and are for the use of the intended addressee only. If you 
are not the intended addressee or an authorised recipient of the addressee 
please notify us of receipt by returning the e-mail and do not use, copy, 
retain, distribute or disclose the information in or attached to the e-mail.
Any opinions expressed within this e-mail are those of the individual and not 
necessarily of Diamond Light Source Ltd. 
Diamond Light Source Ltd. cannot guarantee that this e-mail or any attachments 
are free from viruses and we cannot accept liability for any damage which you 
may sustain as a result of software viruses which may be transmitted in or with 
the message.
Diamond Light Source Limited (company no. 4375679). Registered in England and 
Wales with its registered office at Diamond House, Harwell Science and 
Innovation Campus, Didcot, Oxfordshire, OX11 0DE, United Kingdom




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

Re: [ccp4bb] visualising anis B factors

[graeme.win...@diamond.ac.uk]

Hi Eleanor,


This is pretty routine in chemical crystallography using e.g. Olex2 or similar 
- they use thermal ellipsoids to represent the anisotropic B parameters.


I am guessing though that for any non-trivially sized protein this would be 
quite a computational challenge?


best wishes Graeme


From: CCP4 bulletin board  on behalf of Eleanor Dodson 
<176a9d5ebad7-dmarc-requ...@jiscmail.ac.uk>
Sent: 23 January 2019 15:17:27
To: ccp4bb
Subject: [ccp4bb] visualising anis B factors

Is there any easy way to do this?

Coot? ccp4mg?

Eleanor Dodson



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

-- 
This e-mail and any attachments may contain confidential, copyright and or 
privileged material, and are for the use of the intended addressee only. If you 
are not the intended addressee or an authorised recipient of the addressee 
please notify us of receipt by returning the e-mail and do not use, copy, 
retain, distribute or disclose the information in or attached to the e-mail.
Any opinions expressed within this e-mail are those of the individual and not 
necessarily of Diamond Light Source Ltd. 
Diamond Light Source Ltd. cannot guarantee that this e-mail or any attachments 
are free from viruses and we cannot accept liability for any damage which you 
may sustain as a result of software viruses which may be transmitted in or with 
the message.
Diamond Light Source Limited (company no. 4375679). Registered in England and 
Wales with its registered office at Diamond House, Harwell Science and 
Innovation Campus, Didcot, Oxfordshire, OX11 0DE, United Kingdom




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

Re: [ccp4bb] Open Access Repositories for Big Data?

[graeme.win...@diamond.ac.uk]

Hi Aaron

I would guess most places would start to want $$ for storing multiples of 100 GB

Google, Amazon, Microsoft all offer this kind of thing. Getting the data in and 
out can be slow, and I would expect as the data size tends towards big and the 
time tends to a long time it would be comparable to doing it yourself in terms 
of cost

Unless you can tag yourself onto a CERN Tier1 
http://wlcg-public.web.cern.ch/tier-centres

Cheers Graeme

On 18 Jan 2019, at 15:31, Aaron Finke 
mailto:af...@cornell.edu>> wrote:

Dear CCP4ites,

Is anyone aware of online repositories that will store huge sets of raw data 
(>100 GB)? I’m aware of Zenodo and SBGrid, but Zenodo’s limit is typically 50 
GB and their absolute limit is 100 GB. SBGrid has yet to respond to my emails.

I could host them myself, but the involuntary dry heaving response I got when I 
brought up the idea to our IT department implied they were less enthused with 
the idea than I was. So a cloud service would be far more preferable as a long 
term solution.

Thanks,
Aaron

--
Aaron Finke
Staff Scientist, MacCHESS
Cornell University
e-mail: af...@cornell.edu




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


-- 
This e-mail and any attachments may contain confidential, copyright and or 
privileged material, and are for the use of the intended addressee only. If you 
are not the intended addressee or an authorised recipient of the addressee 
please notify us of receipt by returning the e-mail and do not use, copy, 
retain, distribute or disclose the information in or attached to the e-mail.
Any opinions expressed within this e-mail are those of the individual and not 
necessarily of Diamond Light Source Ltd. 
Diamond Light Source Ltd. cannot guarantee that this e-mail or any attachments 
are free from viruses and we cannot accept liability for any damage which you 
may sustain as a result of software viruses which may be transmitted in or with 
the message.
Diamond Light Source Limited (company no. 4375679). Registered in England and 
Wales with its registered office at Diamond House, Harwell Science and 
Innovation Campus, Didcot, Oxfordshire, OX11 0DE, United Kingdom




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

Re: [ccp4bb] Live stream of CCP4 Study Weekend?

[graeme.win...@diamond.ac.uk]

I have enabled Flash but just get a black rectangle and no sound…

Guessing that using Chrome on OS X is not supported?

:-(

> On 9 Jan 2019, at 09:33, Marcin Wojdyr  wrote:
> 
> On Wed, 9 Jan 2019 at 10:28, Kay Diederichs
>  wrote:
>> 
>> Sorry, I need some additional help with this.
>> 
>> If I use my browser (Firefox or Chrome on Linux) to go to 
>> http://sas.stfc.ac.uk/p.jsp?i=2 it gets redirected to 
>> https://sas.stfc.ac.uk/vportal/VideoPlayer.jsp?ccsid=C-5d13ead9-b217-4b5b-bceb-bb37e04bbefe:-1
> 
> I also use it on Firefox on Linux and it works for me. I got
> redirected to almost the same address, except that the last digit is
> 4:
> https://sas.stfc.ac.uk/vportal/VideoPlayer.jsp?ccsid=C-5d13ead9-b217-4b5b-bceb-bb37e04bbefe:4
> (I had to enable Flash)
> 
> 
> 
> To unsubscribe from the CCP4BB list, click the following link:
> https://www.jiscmail.ac.uk/cgi-bin/webadmin?SUBED1=CCP4BB=1


-- 
This e-mail and any attachments may contain confidential, copyright and or 
privileged material, and are for the use of the intended addressee only. If you 
are not the intended addressee or an authorised recipient of the addressee 
please notify us of receipt by returning the e-mail and do not use, copy, 
retain, distribute or disclose the information in or attached to the e-mail.
Any opinions expressed within this e-mail are those of the individual and not 
necessarily of Diamond Light Source Ltd. 
Diamond Light Source Ltd. cannot guarantee that this e-mail or any attachments 
are free from viruses and we cannot accept liability for any damage which you 
may sustain as a result of software viruses which may be transmitted in or with 
the message.
Diamond Light Source Limited (company no. 4375679). Registered in England and 
Wales with its registered office at Diamond House, Harwell Science and 
Innovation Campus, Didcot, Oxfordshire, OX11 0DE, United Kingdom




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

Re: [ccp4bb] buying a cluster

[graeme.win...@diamond.ac.uk]

Re: publishing benchmarks - great idea - expand on what James described earlier.

Most programs are GHz dependent (for most “sensible” definitions of GHz (not 
the mega-hyper-pipeline stall prone P4 say) however I see your point that 
“threaded” and “optimised for vector systems (e.g. AVX512)” would be very 
useful.

I am certainly not advocating that computers > 3 years old should be thrown 
away ;-) I am one of those folks with a bad hoarding instinct, “it’s good for 
parts” “it still works fine” are all in my lexicon. If you are coot-ing and 
want to refine a modest structure probably most machines < 10 years old will be 
fine.

What I was trying to say is that your experience of how fast something is will 
depend on your use case, and that the boffins in Santa Clara and Sunnyvale have 
not been sitting on their hands this past decade.

Finally, processing “modern” data sets can be a challenge even on fairly hefty 
machines - if you pull data04 from https://zenodo.org/record/1443110 you will 
find a 3 minute data set [1] which (even with XDS; tweaked for speed script) 
can take a long while on a modern-ish machine. 10 year old core2 duo will not 
get this done in the same kind of time-frame.

best wishes Graeme

PS kudos to folks for sharing the data online

[1] which would make a fun challenge benchmark :-)

On 3 Dec 2018, at 02:16, Markus Heckmann 
mailto:markus.21...@gmail.com>> wrote:

Hi Graeme,

I suspect that this conclusions depends very closely on (i) the shape of the 
problem and (ii) the extent to which the binary has been optimised for the 
given platform.

I do hope some of these info are analyzed and either published or at least put 
at ccp4 wiki.

I am pretty sure that there are some applications (heavily threaded, making 
extensive use of vector operations) which would be massively quicker on 2018 
hardware than something a decade old. Certainly though, if you are comparing a 
not-highly-optimised single threaded binary then your conclusion is probably a 
valid one

I really request all the program developers (in the ccp4bb) to clearly have a 
table in the website mentioning if certain program is purely GHz dependent and 
not multi-threaded.



Also how much power the machines take to get work done is a non-trivial factor…

But what about the environment? Trashing a decent machine from 2015 for the 
latest threadripper2? These old maches have 80-90 + gold power supply. Many 
(like Apple's planned obsolescence) are *forcibly* destroyed not refurbished at 
all.

Does DIALS run that much quicker? How much time is saved for a phd student in 
their career if data processing speeds up from 15 min to 10 min?
 Sure perfect for use @synchrotron but otherwise?

May the beamlines/synchrotons should allow for remote data processing and even 
refinement. May be all program devs need to put benchmarks - will help users 
greatly.

These days i have a feeling science copied the typical electron/website 
framework programmers? Programs/website getting fatter not efficient and hoping 
everyone has 128GB RAM.

Markus


Cheerio Graeme



> On 30 Nov 2018, at 19:32, James Holton 
> <270165b9f4cf-dmarc-requ...@jiscmail.ac.uk>
>  wrote:
>
> I have a dissenting opinion about computers "moving on a bit".  At least when 
> it comes to most crystallography software.
>
> Back in the late 20th century I defined some benchmarks for common 
> crystallographic programs with the aim of deciding which hardware to buy.  By 
> about 2003 the champion of my refmac benchmark 
> (https://bl831.als.lbl.gov/~jamesh/benchmarks/index.html#refmac) was the new 
> (at the time) AMD "Opteron" at 1.4 GHz.  That ran in 74 seconds.
>
> Last year, I bought a rather expensive 4-socket Intel Xeon E7-8870 v3 (turbos 
> to 3.0 GHz), which is the current champion of my XDS benchmark.  The same old 
> refmac benchmark on this new machine, however, runs in 68.6 seconds.  Only a 
> smidge faster than that old Opteron (which I threw away years ago).
>
> The Xeon X5550 in consideration here takes 74.1 seconds to run this same 
> refmac benchmark, so price/performance wise I'd say that's not such a bad 
> deal.
>
> The fastest time I have for refmac to date is 41.4 seconds on a Xeon W-2155, 
> but if you scale by GHz you can see this is mostly due to its fast clock 
> speed (turbo to 4.5 GHz). With a few notable exceptions like XDS, HKL2k and 
> shelx, which are multi-processing and optimized to take advantage of the 
> latest processor features using intel compilers, most crystallographic 
> software is either written in Python or compiled with gcc.  In both these 
> cases you end up with performance pretty much scaling with GHz.  And GHz is 
> heat.
>
> Admittedly, the correlation is not perfect, and software has changed a wee 
> bit over the years, so comparisons across the decades are not exactly fair, 
> but the lesson I have learned from all my benchmarking is that single-core 
> raw 

Re: [ccp4bb] buying a cluster

[graeme.win...@diamond.ac.uk]

HI James,

Re: dissenting opinion

I suspect that this conclusions depends very closely on (i) the shape of the 
problem and (ii) the extent to which the binary has been optimised for the 
given platform. 

I am pretty sure that there are some applications (heavily threaded, making 
extensive use of vector operations) which would be massively quicker on 2018 
hardware than something a decade old. Certainly though, if you are comparing a 
not-highly-optimised single threaded binary then your conclusion is probably a 
valid one

Also how much power the machines take to get work done is a non-trivial factor… 

Cheerio Graeme



> On 30 Nov 2018, at 19:32, James Holton 
> <270165b9f4cf-dmarc-requ...@jiscmail.ac.uk> wrote:
> 
> I have a dissenting opinion about computers "moving on a bit".  At least when 
> it comes to most crystallography software.
> 
> Back in the late 20th century I defined some benchmarks for common 
> crystallographic programs with the aim of deciding which hardware to buy.  By 
> about 2003 the champion of my refmac benchmark 
> (https://bl831.als.lbl.gov/~jamesh/benchmarks/index.html#refmac) was the new 
> (at the time) AMD "Opteron" at 1.4 GHz.  That ran in 74 seconds.
> 
> Last year, I bought a rather expensive 4-socket Intel Xeon E7-8870 v3 (turbos 
> to 3.0 GHz), which is the current champion of my XDS benchmark.  The same old 
> refmac benchmark on this new machine, however, runs in 68.6 seconds.  Only a 
> smidge faster than that old Opteron (which I threw away years ago).
> 
> The Xeon X5550 in consideration here takes 74.1 seconds to run this same 
> refmac benchmark, so price/performance wise I'd say that's not such a bad 
> deal.
> 
> The fastest time I have for refmac to date is 41.4 seconds on a Xeon W-2155, 
> but if you scale by GHz you can see this is mostly due to its fast clock 
> speed (turbo to 4.5 GHz). With a few notable exceptions like XDS, HKL2k and 
> shelx, which are multi-processing and optimized to take advantage of the 
> latest processor features using intel compilers, most crystallographic 
> software is either written in Python or compiled with gcc.  In both these 
> cases you end up with performance pretty much scaling with GHz.  And GHz is 
> heat.
> 
> Admittedly, the correlation is not perfect, and software has changed a wee 
> bit over the years, so comparisons across the decades are not exactly fair, 
> but the lesson I have learned from all my benchmarking is that single-core 
> raw performance has not changed much in the last ~10 years or so.  Almost all 
> the speed increase we have seen has come from parallelization.
> 
> And one should not be too quick to dismiss clusters in favor of a single box 
> with a high core count. The latter can be held back by memory contention and 
> other hard-to-diagnose problems.  Even with parallel execution many 
> crystallography programs don't get any faster beyond using about 8-10 cores.  
> Don't let 100% utilization fool you!  Use a timer and you'll see.  I'm not 
> really sure why that is, but it is the reason that same Xeon W-2155 that 
> leads my refmac benchmark is also my champion system for running DIALS and 
> phenix.refine.
> 
> My two cents,
> 
> -James Holton
> MAD Scientist
> 
> 
> On 11/26/2018 1:10 AM, V F wrote:
>> Dear all,
>> Thanks for all the off/list replies.
>> 
>>> To be honest, how much are they paying you to take it? Can you sell it for
>>> scrap?
>> May be I will give it a pass.
>> 
>>> To compare, two dual CPU servers with Skylake Gold 6148 - that is 40 cores -
>>> will probably beat the whole lot even if you could keep the cluster going.
>>> And keeping clusters busy is a time consuming challenge... I know!
>>> If they are 250W servers, then you are looking at £8000 per year to power
>>> and cool it. The two modern servers will be more like £1500 per year to run.
>>> And the servers will only cost about £6000... the economics and planet don't
>>> stack up!
>> By servers do you mean tower/standalone?
>> 
>> Thanks for the detailed explanation. From 2012, we already have many
>> dell precision T5600 with 2 x Xeon E5-2643 (8 Cores) (16 threads) and
>> I was hoping parallellisation with clusters maybe of some help. Looks
>> not.
>> 
>> These are running so well (takes about 45 min for a typical dataset
>> reduction with DIALS) I am not sure buying new ones is useful.
>> 
>> 
>> 
>> 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


-- 
This e-mail and any attachments may contain confidential, copyright and or 
privileged material, and are for the use of the intended addressee only. If you 
are not the intended addressee or an 

Re: [ccp4bb] Apple deprecating OpenGL

[graeme.win...@diamond.ac.uk]

Hi Rob,

I would think that this phrase is the key one:

"The move will mean that, while applications and games developed with OpenGL 
and OpenCL will continue to run, they will almost certainly become increasingly 
unreliable.”

Given that (IIUC) most crystallographic software uses pretty basic openGL I 
would expect it to keep working for a while i.e. 3-5 years. Certainly though I 
can see a time when supporting Windows, OS X and Linux with one code base for 
graphic-heavy applications becoming a real pain. 

Thing is, providing us with nice laptops etc, which work great with COOT does 
not add much to anyone’s bottom line… and supporting anything (even things 
which work) costs someone money.

Cheerio Graeme

> On 1 Dec 2018, at 15:11, R. D. Oeffner  wrote:
> 
> Hi,
> 
> I'm sure many of you have heard that Apple is deprecating OpenGL on MacOS 
> with the Metal API being their alternative.
> 
> https://www.v3.co.uk/v3-uk/news/3033587/apple-deprecates-opengl-and-opencl-from-macos-1014-mojave
> 
> Do people think this is really going to happen and that they will not try to 
> support OpenGL for the foreseeable future given the number of legacy programs 
> out there? I'm curious to learn what people writing cross platform 3D 
> graphics programs plan to do for MacOS?
> 
> 
> Rob
> 
> 
> --
> Robert Oeffner, Ph.D.
> Research Associate, The Read Group
> Department of Haematology,
> Cambridge Institute for Medical Research
> University of Cambridge
> Cambridge Biomedical Campus
> Wellcome Trust/MRC Building
> Hills Road
> Cambridge CB2 0XY
> www.cimr.cam.ac.uk/investigators/read/index.html
> 
> 
> 
> To unsubscribe from the CCP4BB list, click the following link:
> https://www.jiscmail.ac.uk/cgi-bin/webadmin?SUBED1=CCP4BB=1


-- 
This e-mail and any attachments may contain confidential, copyright and or 
privileged material, and are for the use of the intended addressee only. If you 
are not the intended addressee or an authorised recipient of the addressee 
please notify us of receipt by returning the e-mail and do not use, copy, 
retain, distribute or disclose the information in or attached to the e-mail.
Any opinions expressed within this e-mail are those of the individual and not 
necessarily of Diamond Light Source Ltd. 
Diamond Light Source Ltd. cannot guarantee that this e-mail or any attachments 
are free from viruses and we cannot accept liability for any damage which you 
may sustain as a result of software viruses which may be transmitted in or with 
the message.
Diamond Light Source Limited (company no. 4375679). Registered in England and 
Wales with its registered office at Diamond House, Harwell Science and 
Innovation Campus, Didcot, Oxfordshire, OX11 0DE, United Kingdom




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

Re: [ccp4bb] Long term storage for raw images/ crystallographic data sets

[graeme.win...@diamond.ac.uk]

Dear Tim,

I do not think Zenodo is limited to Europeans - at least I could not find this 
on their policy page:

http://about.zenodo.org/policies/

I know of plenty of uploads from Japan for example

Best wishes Graeme

On 29 Nov 2018, at 21:16, Tim Gruene 
mailto:tim.gru...@psi.ch>> wrote:

Dear Raquel,

when they are associated with a publication, you can publish them on
data.sbgrid.org in the US or at 
zenodo.org in Europe.

Best regards,
Tim

On Thursday, November 29, 2018 9:54:02 PM CET Lieberman, Raquel L wrote:
Dear All,

How do your labs handle long-term raw data backups? My lab is maxing out our
6TB RAID backup (with two off-site mirrors) so I am investigating our next
long term solution. The vast majority of the data sets are published
structures (i.e. processed data deposited in PDB) or redundant/unusable so
immediate access is not anticipated, but the size of data sets is
increasing quickly with time, so I am looking for a scalable-yet-affordable
solution.

Would be grateful for input into various options, e.g. bigger HD/RAIDs,
cloud backup, tape, anything else.

I will compile.

Thank you,

Raquel
--
Raquel L. Lieberman, Ph.D.
Professor
School of Chemistry and Biochemistry
Georgia Institute of Technology





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

--
--
Paul Scherrer Institut
Tim Gruene
- persoenlich -
OSUA/204
Forschungsstrasse 111
CH-5232 Villigen PSI
phone: +41 (0)56 310 5297

GPG Key ID = A46BEE1A



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


-- 
This e-mail and any attachments may contain confidential, copyright and or 
privileged material, and are for the use of the intended addressee only. If you 
are not the intended addressee or an authorised recipient of the addressee 
please notify us of receipt by returning the e-mail and do not use, copy, 
retain, distribute or disclose the information in or attached to the e-mail.
Any opinions expressed within this e-mail are those of the individual and not 
necessarily of Diamond Light Source Ltd. 
Diamond Light Source Ltd. cannot guarantee that this e-mail or any attachments 
are free from viruses and we cannot accept liability for any damage which you 
may sustain as a result of software viruses which may be transmitted in or with 
the message.
Diamond Light Source Limited (company no. 4375679). Registered in England and 
Wales with its registered office at Diamond House, Harwell Science and 
Innovation Campus, Didcot, Oxfordshire, OX11 0DE, United Kingdom




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

Re: [ccp4bb] Long term storage for raw images/ crystallographic data sets

[graeme.win...@diamond.ac.uk]

Dear Raquel,

For published structures you can publish the raw data, which means that 
somebody else is looking after it - for this I would say that the current front 
runner is Zenodo - https://zenodo.org/ - which is paid for by CERN / EU etc. so 
someone else is (currently) picking up the tab.

This has the happy side effect that it is useful to others :-)

Best wishes Graeme

On 29 Nov 2018, at 20:54, Lieberman, Raquel L 
mailto:raquel.lieber...@chemistry.gatech.edu>>
 wrote:

Dear All,

How do your labs handle long-term raw data backups? My lab is maxing out our 
6TB RAID backup (with two off-site mirrors) so I am investigating our next long 
term solution. The vast majority of the data sets are published structures 
(i.e. processed data deposited in PDB) or redundant/unusable so immediate 
access is not anticipated, but the size of data sets is increasing quickly with 
time, so I am looking for a scalable-yet-affordable solution.

Would be grateful for input into various options, e.g. bigger HD/RAIDs, cloud 
backup, tape, anything else.

I will compile.

Thank you,

Raquel
--
Raquel L. Lieberman, Ph.D.
Professor
School of Chemistry and Biochemistry
Georgia Institute of Technology





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


-- 
This e-mail and any attachments may contain confidential, copyright and or 
privileged material, and are for the use of the intended addressee only. If you 
are not the intended addressee or an authorised recipient of the addressee 
please notify us of receipt by returning the e-mail and do not use, copy, 
retain, distribute or disclose the information in or attached to the e-mail.
Any opinions expressed within this e-mail are those of the individual and not 
necessarily of Diamond Light Source Ltd. 
Diamond Light Source Ltd. cannot guarantee that this e-mail or any attachments 
are free from viruses and we cannot accept liability for any damage which you 
may sustain as a result of software viruses which may be transmitted in or with 
the message.
Diamond Light Source Limited (company no. 4375679). Registered in England and 
Wales with its registered office at Diamond House, Harwell Science and 
Innovation Campus, Didcot, Oxfordshire, OX11 0DE, United Kingdom




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

Re: [ccp4bb] VERY old mtz file..

[graeme.win...@diamond.ac.uk]

Dear Pavol,

Reading text files without any software is a neat trick, if you can do it.

(no file on a computer is “human readable” - but many are encoded in a form 
which allows a wide range of general tools to display it, not just specialist 
crystallography software)

;-)

I have to say, I am more impressed that Eleanor has files from ’92 - quite 
possibly older than many who will read this message!

All the best, Graeme


On 9 Nov 2018, at 13:53, Pavel Afonine 
mailto:pafon...@gmail.com>> wrote:

Now I see the value of storing data in plain text files even more (mind Shelx 
or X-plor formats, for example) -;)



On Fri, Nov 9, 2018 at 9:47 PM Clemens Vonrhein 
mailto:vonrh...@globalphasing.com>> wrote:
Hi Eleanor,

You could try running the oldest MTZ2VARIOUS binary you can find -
e.g.

  wget ftp://ftp.ccp4.ac.uk/ccp4/4.2/binaries/ccp4-4.2_Linux.tar.gz
  tar -xvf ccp4-4.2_Linux.tar.gz bin/mtz2various

  bin/mtz2various hklin ...

Any older binaries (ftp://ftp.ccp4.ac.uk/ccp4/4.0.1/) will require an
SGI or Dec/Alpha machine ;-)

If that doesn't help I would first check that it is actually a correct
MTZ file: does the ASCII header (trailer) show up with

  strings your.mtz

towards the end?

Cheers

Clemens

On Fri, Nov 09, 2018 at 12:47:09PM +, Eleanor Dodson wrote:
> Anyone any idea what to do about this?? Created in 1992!!
> Seems unreadable..
>
> No CTYP lines input for file:  1
> Indices output even if all data items flagged "missing"
>  Warning, NOT all LABOUT data lines given
> Warning: Machine stamp corrupted? Assuming native format.
> >> CCP4 library signal library_file:End of File (Error)
>
> 
>
> To unsubscribe from the CCP4BB list, click the following link:
> https://www.jiscmail.ac.uk/cgi-bin/webadmin?SUBED1=CCP4BB=1

--

*--
* Clemens Vonrhein, Ph.D. vonrhein AT GlobalPhasing DOT com
* Global Phasing Ltd., Sheraton House, Castle Park
* Cambridge CB3 0AX, UK   
www.globalphasing.com
*--



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


-- 
This e-mail and any attachments may contain confidential, copyright and or 
privileged material, and are for the use of the intended addressee only. If you 
are not the intended addressee or an authorised recipient of the addressee 
please notify us of receipt by returning the e-mail and do not use, copy, 
retain, distribute or disclose the information in or attached to the e-mail.
Any opinions expressed within this e-mail are those of the individual and not 
necessarily of Diamond Light Source Ltd. 
Diamond Light Source Ltd. cannot guarantee that this e-mail or any attachments 
are free from viruses and we cannot accept liability for any damage which you 
may sustain as a result of software viruses which may be transmitted in or with 
the message.
Diamond Light Source Limited (company no. 4375679). Registered in England and 
Wales with its registered office at Diamond House, Harwell Science and 
Innovation Campus, Didcot, Oxfordshire, OX11 0DE, United Kingdom




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

Re: [ccp4bb] Off topic: 'Difficult' Datasets for Processing Practice

[graeme.win...@diamond.ac.uk]

Matthew,

One SBGrid example I used for a workshop was

https://data.sbgrid.org/dataset/218/

This has the “wrong” beam centre as understood by (me/dials/xia2) which causes 
a certain amount of fun, nice example for use of the reciprocal lattice viewer 
and image viewer in DIALS to make sensible choices

Best wishes Graeme




On 20 Sep 2018, at 01:15, Whitley, Matthew J 
mailto:mjw...@pitt.edu>> wrote:

Dear colleagues,

For teaching purposes, I am looking for a small number (< 5) of
macromolecular diffraction datasets (raw images) that might be
considered 'difficult' for a beginning crystallography student to
process.  By 'difficult' I generally mean not able to be processed
automatically by a common processing package (XDS, Mosflm, DIALS, etc)
using default settings, i.e., no black box "click and done" processing.
The datasets I am looking for would have some stumbling block such as
incorrect experimental parameters recorded in the image headers,
multiple lattices that cause indexing to fail, datasets for which
determining the correct space group is tricky, datasets for experiments
in which the crystal slipped or moved in the beam, or anything else you
can think of.  The idea is for these beginning students to examine
several datasets that highlight various phenomena that can lead one
astray during processing.

A good candidate dataset would also ideally comprise a modest number of
images so as to keep integration time to a minimum.  Factors that are
mostly irrelevant for my purpose: resolution (as long as better than
~3.5 Å), source (home vs synchrotron), presence/absence of anomalous
scattering,  presence/absence of ligands, monomeric vs oligomeric
structures, etc.  Also, to be clear, I am not looking for datasets that
have so many pathologies that they would require many long hours of work
for an expert to process correctly.

I have checked public repositories such as 
proteindiffraction.org and
SBGrid databank, but all of the datasets I acquired from these sources
process satisfactorily with little effort, and in any event I know of no
way to search for 'challenging' datasets.  (I also wonder whether
anybody is in the habit of depositing, shall we say, less-than-pristine
images to public repositories?)

If you know of such a dataset that is already publicly available, or if
you have such a dataset that you are willing to share for solely
educational purposes, I would appreciate hearing from you, either on- or
off-list.

Thank you in advance for your suggestions.

Matthew

--
Matthew J. Whitley, Ph.D.
Department of Pharmacology & Chemical Biology
University of Pittsburgh School of Medicine




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


-- 
This e-mail and any attachments may contain confidential, copyright and or 
privileged material, and are for the use of the intended addressee only. If you 
are not the intended addressee or an authorised recipient of the addressee 
please notify us of receipt by returning the e-mail and do not use, copy, 
retain, distribute or disclose the information in or attached to the e-mail.
Any opinions expressed within this e-mail are those of the individual and not 
necessarily of Diamond Light Source Ltd. 
Diamond Light Source Ltd. cannot guarantee that this e-mail or any attachments 
are free from viruses and we cannot accept liability for any damage which you 
may sustain as a result of software viruses which may be transmitted in or with 
the message.
Diamond Light Source Limited (company no. 4375679). Registered in England and 
Wales with its registered office at Diamond House, Harwell Science and 
Innovation Campus, Didcot, Oxfordshire, OX11 0DE, United Kingdom




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

Re: [ccp4bb] Structure solution - hexapeptide

[graeme.win...@diamond.ac.uk]

Kristof,

Just checking - have you tried SHELXT? Feeding in umerged HKL file

I appreciate that this is direct methods but the tool is pretty powerful

Also: you could find processing the data with different tools helps… 

Best wishes Graeme (who dabbles in “small" molecule stuff, too) 

> On 2 Aug 2018, at 08:53, Kristof Van Hecke  
> wrote:
> 
> Dear all, 
> 
> I’m trying to solve a structure of a (modified) hexapeptide:
> - inhouse (very decent) data up to 0.8 Angstrom
> - average redundancy = 10 
> - according to the Matthews coefficient of 1.88 with 34.77 %solvent, there 
> should be 3 Nmol/asym
> - ‘large’ unit cell of about a=54, b=54, c=12 
> - SG = P3(1)12 or P3(2)12 
> 
> As there’s (presumably) only C, H, N and O in the structure, I’m not able to 
> solve this via Direct Methods, Charge Flipping etc,. 
> Trying MR (with Phaser) doesn’t give any results either, as there’s hardly 
> any homologous models
> 
> 
> Has anyone encountered a similar problem please, and could provide any 
> possible solutions? 
> (building in heavy atoms isn’t my first option at the moment,. )
> 
> 
> Thank you very much
> 
> Regards
> 
> Kristof 
> 
> 
> To unsubscribe from the CCP4BB list, click the following link:
> https://www.jiscmail.ac.uk/cgi-bin/webadmin?SUBED1=CCP4BB=1


-- 
This e-mail and any attachments may contain confidential, copyright and or 
privileged material, and are for the use of the intended addressee only. If you 
are not the intended addressee or an authorised recipient of the addressee 
please notify us of receipt by returning the e-mail and do not use, copy, 
retain, distribute or disclose the information in or attached to the e-mail.
Any opinions expressed within this e-mail are those of the individual and not 
necessarily of Diamond Light Source Ltd. 
Diamond Light Source Ltd. cannot guarantee that this e-mail or any attachments 
are free from viruses and we cannot accept liability for any damage which you 
may sustain as a result of software viruses which may be transmitted in or with 
the message.
Diamond Light Source Limited (company no. 4375679). Registered in England and 
Wales with its registered office at Diamond House, Harwell Science and 
Innovation Campus, Didcot, Oxfordshire, OX11 0DE, United Kingdom




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

Re: [ccp4bb] data processing with split/bad crystals

[graeme.win...@diamond.ac.uk]

Dear Andreas, all,


With DIALS, correct treatment of overlapping reflections is current work in 
progress - yes, you can index and refine two or more independent lattices, but 
running dials integration on this will probably not work as well as we'd like 
at the moment. It should do something sensible-ish but... Split lattices are 
tricky: at low angle the spots tend to overlap / merge, at higher angles become 
resolved, so treating them as independent lattices as Andreas describes may not 
be successful.


My experience of chemical crystallography at a synchrotron is that a large 
fraction of samples come with satellites etc, so developing robust handling for 
this is very much on our to-do and in current active development.


Of course, this is one of those data processing problems which is perhaps best 
fixed with a better sample  but that's not a very helpful answer!


Best wishes Graeme



From: CCP4 bulletin board  on behalf of Andreas Förster 

Sent: 16 July 2018 22:14:49
To: ccp4bb
Subject: Re: [ccp4bb] data processing with split/bad crystals

Dear Tommi,

DIALS is good with multiple lattices.  It might not have given you best
results as part of the Diamond pipeline, but give it a try with the
max_lattices=2 parameter during dials.index and see where it takes you.

That said, you'll end up with worse statistics if you have two lattices.
  Don't expect magic from your processing programs.

All best.


Andreas



On 16/07/2018 10:55, Kajander, Tommi A wrote:
> Dear All,
>
> I was wondering what would be the best software nowadays to try to process 
> data from crystal that clearly is split or
> has a secondary set of lattice points (close, poor data) in the raw data - 
> data can be processed with XDS (2.9-2.8 Å) but Rmerge tends to be
> bit high at low resolution (close to 7-8% depending on processing) - using 
> XSCALE helps with the radiation damage correction some what.
>
> Data looks like primitive orthorombic but not quite sure (also seems like it 
> has one screw axis e.g. P2212 - but oddly phaser finds
> solutions in P22121 also or even preferably…..). I am wondering a bit if it 
> isn’t actually monoclinic.
>
> Based on automated processing by Diamond pipeline XDS seems most robust - but 
> any hints on such cases would
> be welcome. Of course we will try to get better crystal but so far no luck.
>
> Thanks for comments,
>
> Best
> Tommi
>
>
>
> ---
>
> Tommi Kajander, Ph.D.
> Structural Biology and Biophysics
> Institute of Biotechnology
> University of Helsinki
> Viikinkaari 1 (P.O. Box 65)
> 00014 Helsinki, Finland
>
>
>
> 
>
> 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

-- 
This e-mail and any attachments may contain confidential, copyright and or 
privileged material, and are for the use of the intended addressee only. If you 
are not the intended addressee or an authorised recipient of the addressee 
please notify us of receipt by returning the e-mail and do not use, copy, 
retain, distribute or disclose the information in or attached to the e-mail.
Any opinions expressed within this e-mail are those of the individual and not 
necessarily of Diamond Light Source Ltd. 
Diamond Light Source Ltd. cannot guarantee that this e-mail or any attachments 
are free from viruses and we cannot accept liability for any damage which you 
may sustain as a result of software viruses which may be transmitted in or with 
the message.
Diamond Light Source Limited (company no. 4375679). Registered in England and 
Wales with its registered office at Diamond House, Harwell Science and 
Innovation Campus, Didcot, Oxfordshire, OX11 0DE, United Kingdom




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

Re: [ccp4bb] Should we still keep copies of all raw data?

[graeme.win...@diamond.ac.uk]

Sergei, all,

I for one would always recommend saving data - not least as this is the basis 
for your science and you may need to revisit it later, perhaps before or after 
publication. Re: (a) I know we’re all working on improving the methods but they 
are still have scope for improvement (b) obviously depends on the local 
policies, and may not be guaranteed…

I know the software we have in DIALS is better than 2 years ago… sure XDS etc 
the same so you could well get better results revisiting old data, for marginal 
cases.

Best wishes Graeme



On 13 Jul 2018, at 10:30, Sergei Strelkov 
mailto:sergei.strel...@kuleuven.be>> wrote:

Dear All,

I believe this question may be of some interest.
In the past, we always stored all raw data ever collected by the lab.
With the recent advances, such as
(a) automated/on-the-fly processing offered by some (European) synchrotrons, and
(b) an ongoing discussion on centralized raw data archiving,
I wonder if it is time to revise the strict policy of keeping all data
(before we invest in a new NAS system... )

Best wishes,
Sergei


Prof. Sergei V. Strelkov Laboratory for Biocrystallography Department of 
Pharmaceutical Sciences, KU Leuven 


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


-- 
This e-mail and any attachments may contain confidential, copyright and or 
privileged material, and are for the use of the intended addressee only. If you 
are not the intended addressee or an authorised recipient of the addressee 
please notify us of receipt by returning the e-mail and do not use, copy, 
retain, distribute or disclose the information in or attached to the e-mail.
Any opinions expressed within this e-mail are those of the individual and not 
necessarily of Diamond Light Source Ltd. 
Diamond Light Source Ltd. cannot guarantee that this e-mail or any attachments 
are free from viruses and we cannot accept liability for any damage which you 
may sustain as a result of software viruses which may be transmitted in or with 
the message.
Diamond Light Source Limited (company no. 4375679). Registered in England and 
Wales with its registered office at Diamond House, Harwell Science and 
Innovation Campus, Didcot, Oxfordshire, OX11 0DE, United Kingdom




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

Re: [ccp4bb] [ccp4bb] Oxford University Press

[graeme.win...@diamond.ac.uk]

Jacob,

This is a known thing in other circles - see e.g.

https://arxiv.org/abs/1011.6590

"Extending ArXiv.org to Achieve Open Peer Review and 
Publishing

Axel Boldt
(Submitted on 23 Nov 2010)
Today's peer review process for scientific articles is unnecessarily opaque and 
offers few incentives to referees. Likewise, the publishing process is 
unnecessarily inefficient and its results are only rarely made freely available 
to the public. Here we outline a comparatively simple extension of 
arXiv.org, an online preprint archive widely used in the 
mathematical and physical sciences, that addresses both of these problems. 
Under the proposal, editors invite referees to write public and signed reviews 
to be attached to the posted preprints, and then elevate selected articles to 
"published" status.”

Also:

http://blog.scienceopen.com/2016/04/what-if-you-could-peer-review-the-arxiv/

And:

https://www.theguardian.com/science/occams-corner/2015/sep/07/peer-review-preprints-speed-science-journals

(different things)

I think the idea here is that people want to trust the manuscript - having it 
in Acta Cryst D (or whatever else) does give some measure of provenance. I 
suspect we could achieve the same with an open peer review process but it would 
be non-trivial, especially for most of the stuff which ends up in Nature… 
though this does not make it wrong, just hard.

Cheerio Graeme

On 1 Jul 2018, at 04:17, Keller, Jacob 
mailto:kell...@janelia.hhmi.org>> wrote:

I don't fully understand the cynicism in the response, unless it is simply the 
outpouring from years of painstaking review work for no monetary reward in a 
very broken publication system. Everybody I have talked to thinks the system is 
terrible, and various solutions have been proposed. One of these is, believe it 
or not, what I suggested, which is to pay reviewers. It is a huge amount of 
work, if one has a conscience about it, and the number of people with the 
expertise and experience required for this type of work is exceedingly small. 
Further, a real review of a paper takes significantly more than 2 hours of 
work, depending on the type of paper (I think you were joking about 2 h, but 
not totally sure). What really kills me is that the publishing houses are 
making money hand over fist, and this because they know that they can get very 
cooperative scientists (G-d bless them) to do huge amounts of work for free. It 
is really scandalous, and I am not sure why we scientists go along with it. To 
put it bluntly: we are being exploited by the journals; why not do something 
about it? I am sure that the journals will not be overjoyed to release their 
grip on the profits, but that should not stop us.

JPK

+
Jacob Pearson Keller
Research Scientist / Looger Lab
HHMI Janelia Research Campus
19700 Helix Dr, Ashburn, VA 20147
Desk: (571)209-4000 x3159
Cell: (301)592-7004
+

The content of this email is confidential and intended for the recipient 
specified in message only. It is strictly forbidden to share any part of this 
message with any third party, without a written consent of the sender. If you 
received this message by mistake, please reply to this message and follow with 
its deletion, so that we can ensure such a mistake does not occur in the future.

-Original Message-
From: CCP4 bulletin board [mailto:CCP4BB@JISCMAIL.AC.UK] On Behalf Of Hughes, 
Jon
Sent: Saturday, June 30, 2018 6:13 AM
To: CCP4BB@JISCMAIL.AC.UK
Subject: [ccp4bb] AW: [ccp4bb] [ccp4bb] Oxford University Press

great idea! 2 hours at €200 per hour makes €1000 - sounds like an eminently 
reasonable starting point for negotiations. if the publishers don't like our 
price, they can do the reviewing themselves - and after a while no one will 
bother to buy the resulting rubbish anyhow! in the mean time we put our stuff 
online directly (without wasting our time, for example, still formatting 
reference lists in the 21st century!). we have them over a barrel. the only 
problem i see is how to get grants without papers in Nature. anyone have a 
solution to that one?
one final aspect is: who gets the money? surely the universities etc. should 
get it, not us: the taxpayer pays us already.
best,
jon

-Ursprüngliche Nachricht-
Von: CCP4 bulletin board [mailto:CCP4BB@JISCMAIL.AC.UK] Im Auftrag von Keller, 
Jacob
Gesendet: Samstag, 30. Juni 2018 00:00
An: CCP4BB@JISCMAIL.AC.UK
Betreff: Re: [ccp4bb] [ccp4bb] Oxford University Press

The one I don't get is why not pay reviewers? $1000 per review? If you look at 
publishers' profit margins, you will see that they can afford it. I actually 
think the scientific community should go on a "review strike" until reviewers 
get paid.

JPK

+
Jacob Pearson Keller
Research Scientist / 

Re: [ccp4bb] Python3 and MTZ

[graeme.win...@diamond.ac.uk]

Hi Marcin,

I do not think that this is an unreasonable burden, given what you gain as a 
result of it - the languages are probably >> 90% identical, and you get access 
to a bucket full of tools by staying in the common ground area. I appreciate 
that rewriting cctbx could be a fun challenge, but I for one don’t have time to 
do so ;-) 

Kay, quite by chance I find myself writing a jiffy script which compares 
scaled-but-unmerged data with scaled and merged data, to look at the 
distributions about the mean value - clearly I could merge the data myself 
using cctbx tools, but the aim was to compare the reflections files as they 
came from aimless - anyway, this computes a “z” score for each reflection i.e. 
(i - ) / sig(i) for each observation & forms a histogram:

20 ish lines of code and a few minutes later:



from __future__ import print_function, division

from iotbx import mtz
from scitbx.array_family import flex
import sys

merged = mtz.object(sys.argv[1])
unmerged = mtz.object(sys.argv[2])

unique_indices = merged.extract_miller_indices()
all_indices = unmerged.extract_miller_indices()
imean = merged.extract_observations('IMEAN', 'SIGIMEAN')
iuniq = unmerged.extract_observations('I', 'SIGI')

z = flex.double(iuniq.data.size(), 0.0)

for index, i in zip(unique_indices, imean.data):
  sel = (all_indices == index)
  z.set_selected(sel, (iuniq.data - i) / iuniq.sigmas)

h = flex.histogram(z, data_min=-5, data_max=5, n_slots=100)

for c, v in zip(h.slot_centers(), h.slots()):
  print(c, v)



thought it may help the discussion. 

best wishes Graeme


> On 7 Jun 2018, at 11:43, Marcin Wojdyr  wrote:
> 
> On 7 June 2018 at 05:29, graeme.win...@diamond.ac.uk
>  wrote:
>> Dear Kay,
>> 
>> Yes, it’s writing code to be compatible with Python2 and Python3 - in real 
>> life they are largely idiomatically similar, with well documented 
>> differences e.g.
> 
> In other words, it's learning both Python2 and Python3 and using the
> subset of the language that works with both interpreters.
> It's an extra burden and if one is learning Python choosing any of the
> two versions will make it easier.


-- 
This e-mail and any attachments may contain confidential, copyright and or 
privileged material, and are for the use of the intended addressee only. If you 
are not the intended addressee or an authorised recipient of the addressee 
please notify us of receipt by returning the e-mail and do not use, copy, 
retain, distribute or disclose the information in or attached to the e-mail.
Any opinions expressed within this e-mail are those of the individual and not 
necessarily of Diamond Light Source Ltd. 
Diamond Light Source Ltd. cannot guarantee that this e-mail or any attachments 
are free from viruses and we cannot accept liability for any damage which you 
may sustain as a result of software viruses which may be transmitted in or with 
the message.
Diamond Light Source Limited (company no. 4375679). Registered in England and 
Wales with its registered office at Diamond House, Harwell Science and 
Innovation Campus, Didcot, Oxfordshire, OX11 0DE, United Kingdom




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

Re: [ccp4bb] Python3 and MTZ

[graeme.win...@diamond.ac.uk]

Dear Kay,

Yes, it’s writing code to be compatible with Python2 and Python3 - in real life 
they are largely idiomatically similar, with well documented differences e.g.

http://python-future.org/compatible_idioms.html

Most of this will not affect you unless you are doing a pretty major project...

Re: cctbx -> python3 - there is a roadmap at

https://github.com/cctbx/cctbx_project/wiki/Python-3-roadmap

Unlike e.g. FORTRAN where you can still compile 40 year old code, the choice 
was made in Python to fix some things which were not “right” and make Python3 a 
different dialect - since Python3 is now a decade old and only really now 
gaining traction a lot of people have found this challenging. That said, cctbx 
is > 15 years old now so has seen some changes too..

In terms of learning Python, obviously Python3 _syntax_ is the way forward - my 
daughter learns this at school! - but using Python2 _compatible_ code as per 
the idioms above will make life easier in the short term, and will allow use of 
cctbx… adding

from __future__ import division, print_function

to the very top of your source files will help this

Best wishes Graeme

On 6 Jun 2018, at 21:36, Kay Diederichs 
mailto:kay.diederi...@uni-konstanz.de>> wrote:

Dear Graeme,

that sounded to me at first like xia2 and DIALS could be written in Python3 and 
still use cctbx. But thinking about it, this cannot be true; once you run your 
code, you have to run either the Python2 or the Python3 interpreter. And if you 
try to use Python3, it will not correctly run cctbx.

I think what you do in xia2 and DIALS is write code that now runs under 
Python2, but will/would still work if run under Python3 - but this requires 
converting cctbx to Python3 (which, as I saw on some webpage, is a goal for 
2018 IIUC).

Right? Pls ignore my ignorance; I'm a beginner in this area ...

best,

Kay

On Wed, 6 Jun 2018 20:22:10 +, 
graeme.win...@diamond.ac.uk<mailto:graeme.win...@diamond.ac.uk> 
mailto:graeme.win...@diamond.ac.uk>> wrote:

Dear Kay,


While I am obviously biased, I have to say that using cctbx (even if it is 
"old" Python) has a lot to be said for it - there are a lot of tools in there 
which are useful once you have read the reflection data & want to do 
crystallography.


Re: Python 3: within xia2, DIALS and other cctbx-derived projects we have moved 
to writing Python which is compatible with 2.7.x and 3.x language standards - 
by and large it is not a hardship and means you can write code today which will 
continue to be useful. There is a wider push to migrate cctbx to 2.7.x and 3.x 
compatibility however it is a large code base and it's a fair amount of work. 
There's more to it than just adding brackets after print though :-)


Best wishes Graeme


From: CCP4 bulletin board mailto:CCP4BB@JISCMAIL.AC.UK>> 
on behalf of Kay Diederichs 
mailto:kay.diederi...@uni-konstanz.de>>
Sent: 06 June 2018 19:47:07
To: ccp4bb
Subject: Re: [ccp4bb] Python3 and MTZ

Dear Nicolas,

my (our) motivation is purely that when learning Python today, and developing 
something from scratch, Python3 appears like the better choice (compared to 
version 2) - provided that basic crystallographic libraries can be used.

Just a note (for those whose operating system provides only one of the two 
Python flavours): RHEL7 has Python2 as system library, but Python3 can be 
installed in parallel (using "Software Collections"). The user makes a choice 
by setting the PATH variable.

best,

Kay

On Wed, 6 Jun 2018 15:43:16 +0200, Nicolas FOOS 
mailto:nicolas.f...@esrf.fr>> wrote:

Dear Kay,

depending of the motivation to develop in python3 (could be due to an OS
using python3 by default or you really prefer to work with python3). If
it's due to the OS, a possible strategy is to use virtualenv
(https://virtualenv.pypa.io/en/stable/) which let you use python2 even
if python3 is the default version for the OS. It exist probably other
method to have a contain installation of python2 with all the library needs.

I used this strategy (virtualenv) to install ccp4 (with the installer
which needed python2) on a manjaro linux (Arch based) running python3
and that works very well.

Nicolas

Nicolas Foos
PhD
Structural Biology Group
European Synchrotron Radiation Facility (E.S.R.F)
71, avenue des Martyrs
CS 40220
38043 GRENOBLE Cedex 9
+33 (0)6 76 88 14 87
+33 (0)4 76 88 45 19

On 06/06/2018 14:25, Kay Diederichs wrote:
Dear all,

I haven't tried to read MTZ files from Python until now, but for a new
project in my lab I'd like to do that - and with Python3.

Googling around, it seems that iotbx from cctbx is not (yet)
Python3-compatible.

So, what are my options?

thanks,

Kay



To unsubscribe from the CCP4BB list, click the following

Re: [ccp4bb] Python3 and MTZ

[graeme.win...@diamond.ac.uk]

Dear Kay,


While I am obviously biased, I have to say that using cctbx (even if it is 
"old" Python) has a lot to be said for it - there are a lot of tools in there 
which are useful once you have read the reflection data & want to do 
crystallography.


Re: Python 3: within xia2, DIALS and other cctbx-derived projects we have moved 
to writing Python which is compatible with 2.7.x and 3.x language standards - 
by and large it is not a hardship and means you can write code today which will 
continue to be useful. There is a wider push to migrate cctbx to 2.7.x and 3.x 
compatibility however it is a large code base and it's a fair amount of work. 
There's more to it than just adding brackets after print though :-)


Best wishes Graeme


From: CCP4 bulletin board  on behalf of Kay Diederichs 

Sent: 06 June 2018 19:47:07
To: ccp4bb
Subject: Re: [ccp4bb] Python3 and MTZ

Dear Nicolas,

my (our) motivation is purely that when learning Python today, and developing 
something from scratch, Python3 appears like the better choice (compared to 
version 2) - provided that basic crystallographic libraries can be used.

Just a note (for those whose operating system provides only one of the two 
Python flavours): RHEL7 has Python2 as system library, but Python3 can be 
installed in parallel (using "Software Collections"). The user makes a choice 
by setting the PATH variable.

best,

Kay

On Wed, 6 Jun 2018 15:43:16 +0200, Nicolas FOOS  wrote:

>Dear Kay,
>
>depending of the motivation to develop in python3 (could be due to an OS
>using python3 by default or you really prefer to work with python3). If
>it's due to the OS, a possible strategy is to use virtualenv
>(https://virtualenv.pypa.io/en/stable/) which let you use python2 even
>if python3 is the default version for the OS. It exist probably other
>method to have a contain installation of python2 with all the library needs.
>
>I used this strategy (virtualenv) to install ccp4 (with the installer
>which needed python2) on a manjaro linux (Arch based) running python3
>and that works very well.
>
>Nicolas
>
>Nicolas Foos
>PhD
>Structural Biology Group
>European Synchrotron Radiation Facility (E.S.R.F)
>71, avenue des Martyrs
>CS 40220
>38043 GRENOBLE Cedex 9
>+33 (0)6 76 88 14 87
>+33 (0)4 76 88 45 19
>
>On 06/06/2018 14:25, Kay Diederichs wrote:
>> Dear all,
>>
>> I haven't tried to read MTZ files from Python until now, but for a new
>> project in my lab I'd like to do that - and with Python3.
>>
>> Googling around, it seems that iotbx from cctbx is not (yet)
>> Python3-compatible.
>>
>> So, what are my options?
>>
>> thanks,
>>
>> Kay
>
>
>
>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

-- 
This e-mail and any attachments may contain confidential, copyright and or 
privileged material, and are for the use of the intended addressee only. If you 
are not the intended addressee or an authorised recipient of the addressee 
please notify us of receipt by returning the e-mail and do not use, copy, 
retain, distribute or disclose the information in or attached to the e-mail.
Any opinions expressed within this e-mail are those of the individual and not 
necessarily of Diamond Light Source Ltd. 
Diamond Light Source Ltd. cannot guarantee that this e-mail or any attachments 
are free from viruses and we cannot accept liability for any damage which you 
may sustain as a result of software viruses which may be transmitted in or with 
the message.
Diamond Light Source Limited (company no. 4375679). Registered in England and 
Wales with its registered office at Diamond House, Harwell Science and 
Innovation Campus, Didcot, Oxfordshire, OX11 0DE, United Kingdom




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

Re: [ccp4bb] Acceptable range of CC1/2

[graeme.win...@diamond.ac.uk]

Usual recommendations are to have CC-half > 0.3 or 0.5 (these are usually not 
so far separated)

For the most part the refinement software is smart enough to down-weight 
“noise” in the outer shell so there is very little penalty in including weak 
measurements, and you should put up a fight with reviewers who complain about 
the Rmerge in the outer shell! Paired refinement is a good metric for 
determining if the new measurements add anything

You could probably go a little further than you have, since the outer shell is 
also complete which suggests you have not hit detector limit…

best wishes Graeme

On 5 Jun 2018, at 10:29, Deepali Verma 
mailto:deepali.biotechnol...@gmail.com>> wrote:

Dear all,

I am trying to process a crystal data at 2.8Å and having CC1/2 is 0.771 (outer 
shell). I just want to know the acceptable range of CC1/2. These are the 
statistics of the process data.



   Overall  InnerShell  OuterShell

  Low resolution limit   74.67 74.67  2.95

  High resolution limit   2.80  8.85  2.80


  Rmerge 0.067 0.042 0.964

  Rmerge in top intensity bin0.043- -

  Rmeas (within I+/I-)   0.072 0.046 1.032

  Rmeas (all I+ & I-)0.072 0.046 1.032

  Rpim (within I+/I-)0.026 0.018 0.368

  Rpim (all I+ & I-) 0.026 0.018 0.368

  Fractional partial bias   -0.025-0.019-0.071

  Total number of observations  289022  8892 42020

  Total number unique37156  1218  5376

  Mean((I)/sd(I)) 16.5  39.0   2.1

  Mn(I) half-set correlation CC(1/2) 0.999 0.998 0.771

  Completeness99.3  98.7  99.0

  Multiplicity 7.8   7.3   7.8


  Anomalous completeness  99.3  98.5  98.9

  Anomalous multiplicity   4.0   3.9   4.0

  DelAnom correlation between half-sets -0.042-0.036 0.015

  Mid-Slope of Anom Normal Probability   0.937   - -

--
Regards,
Deepali Verma
Junior Research Fellow
Jaypee Institute of Information Technology
[http://ampmfacilityservices.com/assets/Uploads/image001-1.gif]



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


-- 
This e-mail and any attachments may contain confidential, copyright and or 
privileged material, and are for the use of the intended addressee only. If you 
are not the intended addressee or an authorised recipient of the addressee 
please notify us of receipt by returning the e-mail and do not use, copy, 
retain, distribute or disclose the information in or attached to the e-mail.
Any opinions expressed within this e-mail are those of the individual and not 
necessarily of Diamond Light Source Ltd. 
Diamond Light Source Ltd. cannot guarantee that this e-mail or any attachments 
are free from viruses and we cannot accept liability for any damage which you 
may sustain as a result of software viruses which may be transmitted in or with 
the message.
Diamond Light Source Limited (company no. 4375679). Registered in England and 
Wales with its registered office at Diamond House, Harwell Science and 
Innovation Campus, Didcot, Oxfordshire, OX11 0DE, United Kingdom




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

Re: [ccp4bb] According correct space group assignment...

[graeme.win...@diamond.ac.uk]

Rafal,

Unit cell parameters: if you look at the images, and all the reflections are 
integrated, you should see little blue boxes & no missed reflections - if this 
is correct then the P1 unit cell is probably correct

Regarding the space group: for this case you may find NCS confusing the 
symmetry determination routines so I would take the outcome with a pinch of 
salt, but it could be that you have something different to what you expect. 
With this resolution you could probably solve it in P1 and work out the 
symmetry a posteri. I have solved structures of DNA in the past with SHELXT but 
this was (i) small and (ii) made the computer sweat. 

Re: I222/I212121 you cannot tell the difference from systematic absences i.e. 
what POINTLESS does. 

If XSD and DIALS give a similar solution and the reflections are all 
integrated, then on the balance of probability I would guess the answer is 
correct i.e. PG 222 and body centred, but only probably - some one will always 
come up with exceptions

As someone said earlier this week - you only know the symmetry once you’ve 
refined the structure

Best wishes Graeme

> On 20 Apr 2018, at 14:30, Rafal Dolot  wrote:
> 
> Dear CCP4BB,
> 
> I've recently collected data for 11mer build of DNA (9xG, 2xT). XDS, and 
> DIALS gave me similar solution - SG: I2(1)2(1)2(1) or I222, with cell 
> dimension 20.65, 22.96, 43.37, 90, 90, 90, what is too small for this size of 
> the molecule. 11mer is rich in G, so we expect the G-tetraplex formation. 
> Data were collected to almost 1 A, so it should be enough for trials with 
> direct methods/ab initio solution. What I should do first to find correct SG 
> and/or cell parameters?
> 
> Best regards,
> 
> Rafal
> -- 
> |--|
> |Rafal Dolot, Ph.D.|
> |  |
> |Polish Academy of Sciences|
> |Centre of Molecular and Macromolecular Studies|
> |Department of Bioorganic Chemistry|
> |Macromolecular Crystallography Team   |
> |Sienkiewicza 112  |
> |90-363 Lodz, Poland   |
> |Phone: +48(42)6803215 |
> |Cell:  +48 502897781  |
> |--|


-- 
This e-mail and any attachments may contain confidential, copyright and or 
privileged material, and are for the use of the intended addressee only. If you 
are not the intended addressee or an authorised recipient of the addressee 
please notify us of receipt by returning the e-mail and do not use, copy, 
retain, distribute or disclose the information in or attached to the e-mail.
Any opinions expressed within this e-mail are those of the individual and not 
necessarily of Diamond Light Source Ltd. 
Diamond Light Source Ltd. cannot guarantee that this e-mail or any attachments 
are free from viruses and we cannot accept liability for any damage which you 
may sustain as a result of software viruses which may be transmitted in or with 
the message.
Diamond Light Source Limited (company no. 4375679). Registered in England and 
Wales with its registered office at Diamond House, Harwell Science and 
Innovation Campus, Didcot, Oxfordshire, OX11 0DE, United Kingdom

Re: [ccp4bb] xds_par licence expired error

[graeme.win...@diamond.ac.uk]

Dear Nishant

XDS always has an expiry date - you download a new version from 
http://xds.mpimf-heidelberg.mpg.de/html_doc/downloading.html to replace the old 
version.

I do not know if XDSGUI also has an expiry date

This should not be a surprise - when you run XDS you will see something like

[gw56@cs03r-sc-serv-16 ~]$ xds

 * XDS * (VERSION Nov 11, 2017  BUILT=2017)  20-Apr-2018
 Author: Wolfgang Kabsch
 Copy licensed until 30-Jun-2018 to
  academic users for non-commercial applications
 No redistribution.

best wishes Graeme

On 20 Apr 2018, at 09:36, Nishant Varshney 
> wrote:

Dear All,

I am sure I have done it before but do not remember/finding the solution online 
for this now.

My XDSGUI returns with the error of xds_par  "Licence Expired on 31st Mar 2018".

Before Reinstalling XDS and XDSGUI on my iMac I would like to ask the experts 
if there is an easy solution to start XDS to work again?

Looking forward to your expert solutions

Regards

Nishant

--
Dr. Nishant Kumar Varshney,
Research Associate,
C/O Dr. Sameena Khan,
Drug Discovery Research Center,
Translational Health Science and Technology Institute (THSTI)
NCR Biotech Science Cluster,
3rd Milestone, Faridabad – Gurgaon Expressway,
Faridabad – 121001 (HARYANA), India
Ph: +91- 0129-2876477
Mob: 8390564690


-- 
This e-mail and any attachments may contain confidential, copyright and or 
privileged material, and are for the use of the intended addressee only. If you 
are not the intended addressee or an authorised recipient of the addressee 
please notify us of receipt by returning the e-mail and do not use, copy, 
retain, distribute or disclose the information in or attached to the e-mail.
Any opinions expressed within this e-mail are those of the individual and not 
necessarily of Diamond Light Source Ltd. 
Diamond Light Source Ltd. cannot guarantee that this e-mail or any attachments 
are free from viruses and we cannot accept liability for any damage which you 
may sustain as a result of software viruses which may be transmitted in or with 
the message.
Diamond Light Source Limited (company no. 4375679). Registered in England and 
Wales with its registered office at Diamond House, Harwell Science and 
Innovation Campus, Didcot, Oxfordshire, OX11 0DE, United Kingdom

Re: [ccp4bb] determining the point group and the space group

[graeme.win...@diamond.ac.uk]

Dear Gihan

I would say collecting X-FEL data to solve a novel structure is unusual, as the 
real power of these machines is in time resolved experiments. If you have not 
already, I would recommend recording a fairly complete low dose data set on a 
synchrotron beamline with one or two of the crystals (I assume you must have 
thousands) to get the correct crystal parameters and do any molecular 
replacement. From there you would be in a much stronger position to analyse the 
X-FEL data and you will also have a useful reference data set to avoid indexing 
ambiguities etc.

Finally, if you are involved in an X-FEL experiment it is normal to have people 
on the proposal who are experienced with data processing - for X-FEL data this 
is not trivial - so you may find it is worth asking around in the lab / 
collaboration as well...

Best wishes Graeme

-Original Message-
From: CCP4 bulletin board  On Behalf Of Gihan Ketawala
Sent: 19 April 2018 02:13
To: ccp4bb 
Subject: [ccp4bb] determining the point group and the space group

Hi,
my question is;
how should one determine a point group and the space group of an unknown 
crystal?

I have a protein crystal with know unit-cell parameters. (these are XFEL data 
so indexing wouldn't give the point and space groups). I checked the PDB, but 
no luck the PDB structures have the different space group assigned, no 
definitive answer hopefully, somebody can point me in the right direction 

Best,
Gihan

-- 
This e-mail and any attachments may contain confidential, copyright and or 
privileged material, and are for the use of the intended addressee only. If you 
are not the intended addressee or an authorised recipient of the addressee 
please notify us of receipt by returning the e-mail and do not use, copy, 
retain, distribute or disclose the information in or attached to the e-mail.
Any opinions expressed within this e-mail are those of the individual and not 
necessarily of Diamond Light Source Ltd. 
Diamond Light Source Ltd. cannot guarantee that this e-mail or any attachments 
are free from viruses and we cannot accept liability for any damage which you 
may sustain as a result of software viruses which may be transmitted in or with 
the message.
Diamond Light Source Limited (company no. 4375679). Registered in England and 
Wales with its registered office at Diamond House, Harwell Science and 
Innovation Campus, Didcot, Oxfordshire, OX11 0DE, United Kingdom

Re: [ccp4bb] (arcane) How to generate complete set of indices at low res

[graeme.win...@diamond.ac.uk]

Hi Frank

I think this is a feature of (c)truncate - to avoid actually absent reflections 
messing up the French & Wilson correction for present-but-weak-or-negative 
reflections they are chucked out.

If you put data in e.g. P212121 into AIMLESS absent reflections will be written 
out. They only vanish when you make F’s.

Cheers Graeme

On 6 Apr 2018, at 08:11, Frank von Delft 
> wrote:


Thanks James, that's a very useful steer - this is definitely an easy thing to 
get mixed up with, we can go scratch around there.

I now vaguely recall an ancient BB thread, where people were asking why the 
systematic absences get scrubbed out of the mtz files at all.  I must agree 
that I do not understand the rationale either:  the symmetry should be simply a 
label attached to the reflections, not something that wipes out potential 
observations.

(I'd be very happy to be wrong about this.)

Frank





On 06/04/2018 01:01, James Holton wrote:

I say "putative" because I don't know what your space group is.

In P212121 the reflection h,k,l = 0,0,1 is absent, but in P222 it is not 
absent.  So, if your unit cell is a=30 b=40 c=60 the lowest-angle hkl you will 
get is at 60 A resolution (0,0,1) in P222, but the lowest-angle reflection you 
will get out of P212121 will be (0,1,1), at 33.3 A resolution.  This is because 
0,1,0 is also absent.  So, if you ever specify P212121 in your pipeline the 
0,0,1 reflection will be lost.  Same thing happens with most any 
screw-vs-rotation axis assignment.

You loose other reflections to absences too, of course, but the lowest-order 
ones have an annoying habit of defining the "resolution range", and this can 
sometimes get set at one point in the pipeline and applied to subsequent 
operations, even if you change the space group back.  This could also be 
happening to you?

It is also possible to a subtle change in unit cell can move your lowest-order 
(and also the highest order) reflections across the defined "resolution range" 
boundaries.  Sometimes even round-off error can be enough.

So, if low-resolution is important it is always a good idea to replace the 
low-angle resolution limit with  A.  Just be sure your beamstop was 
properly masked off.

-James Holton
MAD Scientist


On 4/5/2018 10:55 AM, Pearce, N.M. (Nick) wrote:
Could you expand a bit on what you mean by a “putative” systematic absence? 
(e.g. why only the lowest order hkl?)



On 5 Apr 2018, at 19:39, James Holton 
> wrote:


You need to be careful with the exact space group at the particular stage in 
your pipeline here.  Often the lowest-order hkl is a putative systematic 
absence, so if you uniqueify in P222 you will get it, but if you uniqueify in 
P212121, then you won't.  That sort of thing.  Note that it doesn't matter what 
the "true" space group is, it only matters what is in the mtz header when you 
run uniqueify.

Could that be what is going on?

-James Holton

MAD Scisntist

On 4/5/2018 3:52 AM, Frank von Delft wrote:

Hello - can anybody shed light on this mystery:

We need (for PanDDA analysis) a lot of datasets each to have the complete set 
of low resolution indices, whether measured or not.  (Refmac adds the estimates 
as DFc, which is crucial when comparing maps.)

In ccp4, there are two obvious ways to get these indices complete:

  *   uniqueify
  *   CAD using the keyword "RESOLUTION FILE 1 999 "  (999 is the low 
resolution limit).

Mystifyingly, in ~1% of datasets, one or the other route misses one or two 
indices.  Our work-around is to go belt-and-braces and run both for each 
dataset.


It does however remain a bug.  Does anybody have any idea what's happening?  We 
can send example datasets to any volunteers who want to fiddle with it.

phx







-- 
This e-mail and any attachments may contain confidential, copyright and or 
privileged material, and are for the use of the intended addressee only. If you 
are not the intended addressee or an authorised recipient of the addressee 
please notify us of receipt by returning the e-mail and do not use, copy, 
retain, distribute or disclose the information in or attached to the e-mail.
Any opinions expressed within this e-mail are those of the individual and not 
necessarily of Diamond Light Source Ltd. 
Diamond Light Source Ltd. cannot guarantee that this e-mail or any attachments 
are free from viruses and we cannot accept liability for any damage which you 
may sustain as a result of software viruses which may be transmitted in or with 
the message.
Diamond Light Source Limited (company no. 4375679). Registered in England and 
Wales with its registered office at Diamond House, Harwell Science and 
Innovation Campus, Didcot, Oxfordshire, OX11 0DE, United Kingdom