Re: [ccp4bb] xds crashes

2022-11-29 Thread Demetres D. Leonidas

Dear Kay,

many thanks for your suggestions. We will look into this.

best

Demetres

On 11/29/2022 2:35 PM, Kay Diederichs wrote:

Dear Demetres,

I googled the Ubuntu 22.04 release notes and found 
https://discourse.ubuntu.com/t/jammy-jellyfish-release-notes/24668 which says "We’ve enabled 
the userspace OOMD service and are shipping the systemd-oomd package by default on the “Ubuntu 
Desktop” flavour, to avoid overloaded systems and the need of the kernel’s OOM killer to kick in. 
The OOMD status can be checked using oomctl." Then googling "Ubuntu 22.04 oomctl" 
takes me e.g. to https://askubuntu.com/questions/1405021/firefox-closes-by-itself-in-ubuntu-22-04 
and https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1972159 which confirms that there may be 
a problem in Ubuntu 22.04 with processes being killed without good reason, and some hints on how to 
configure your system to avoid that.

Maybe the systems-oomd package can simply be removed.

Hope that helps,
Kay


On Tue, 29 Nov 2022 10:25:17 +0200, Demetres D. Leonidas 
 wrote:


Dear Kay,

you are right and I do apologize for the misunderstanding. Point 1 and 2
are sufficient.

best

Demetres

On 11/29/2022 10:00 AM, Kay Diederichs wrote:

Dear Demetres,

sounds a bit drastic!
The second point alone would certainly suffice, because then no forking is done.

What kind of hardware is that?
I would expect that on a contemporary workstation you have 8GB of RAM or more; 
that would allow for 8 or more processes.
Do you have a swapfile? If not, create one.

Please check out 
https://strucbio.biologie.uni-konstanz.de/xdswiki/index.php/Performance

Best wishes,
Kay


On Tue, 29 Nov 2022 09:34:49 +0200, Demetres D. Leonidas 
 wrote:


Dear Kay,

after some digging and help from Max Nanao we found that the problem
was the memory.  It was fulling rapidly. The workaround was to:

1. unzip the cbf files prior to processing

2. use maximum number of jobs 1

3. use number of processors 4

4. run xds_par

Many thanks for all your help

Demetres

On 11/29/2022 9:03 AM, Kay Diederichs wrote:

Dear Demetres,

I agree with what James says: this is the operating system trying to to 
prevent, in an over-zealous way, the
forking of too many or too big (in terms of memory) processes.
In other words, XDS hasn't changed, but the operating system changed - it 
applies different limits to its processes.
Your friendly system administrator should try to find out exactly which 
limit(s) changed, and reset the value(s).
Perhaps a hint is in the Release Notes of Ubuntu 22.04 ?

Pls report here when you've found it - currently you are the only one reporting 
it.

Best wishes,
Kay


On Mon, 28 Nov 2022 12:06:43 -0800, James Holton  wrote:


Sounds like your kernel might think "forkxds" is creating a "fork
bomb".  Too many sub-processes firing off in too short a time triggers
this.  On one of my systems, I fixed it by editing
/etc/security/limits.d/20-nproc.conf so that users are allowed ~10x more
pids than normal.  This tends to prevent these mysterious "Killed" errors.

HTH?

-James Holton
MAD Scientist


On 11/28/2022 7:44 AM, Demetres D. Leonidas wrote:

Dear all,

I do not know if this is the right list and I would like to apologize
if it is not.

We have repeatedly experienced xds crashes in machines running ubuntu
22.04.1 with the following message repeated several times at the
INTEGRATE step

/usr/local/bin/forkxds: line 60:  3427 Done echo "$itask"

     3428 Killed  | $amain

We are trying to process data from P13 at EMBL-Hamburg.

We are running XDS version Jan 10, 2022 BUILT=20220820

Any ideas ?

Demetres




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

This message was issued to members of www.jiscmail.ac.uk/CCP4BB, a mailing list 
hosted by www.jiscmail.ac.uk, terms & conditions are available at 
https://www.jiscmail.ac.uk/policyandsecurity/



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

This message was issued to members of www.jiscmail.ac.uk/CCP4BB, a mailing list 
hosted by www.jiscmail.ac.uk, terms & conditions are available at 
https://www.jiscmail.ac.uk/policyandsecurity/

--
---
Dr. Demetres D. Leonidas
Professor in Biochemistry
Department of Biochemistry & Biotechnology
University of Thessaly
Biopolis 41500 Larissa, Greece
-
Tel. +302410 565278
Tel. +302410 565297 (Lab)
Tel. +304210 565263 (X-ray)
Fax. +302410 565290
E-mail: ddleoni...@bio.uth.gr
ORCID ID orcid.org/-0002-3874-2523
---


--
Αυτό το email έχει ελεγχθεί για ιούς από το Avast antivirus.
www.avast.com


Re: [ccp4bb] xds crashes

2022-11-29 Thread Kay Diederichs
Dear Demetres,

I googled the Ubuntu 22.04 release notes and found 
https://discourse.ubuntu.com/t/jammy-jellyfish-release-notes/24668 which says 
"We’ve enabled the userspace OOMD service and are shipping the systemd-oomd 
package by default on the “Ubuntu Desktop” flavour, to avoid overloaded systems 
and the need of the kernel’s OOM killer to kick in. The OOMD status can be 
checked using oomctl." Then googling "Ubuntu 22.04 oomctl" takes me e.g. to 
https://askubuntu.com/questions/1405021/firefox-closes-by-itself-in-ubuntu-22-04
 and https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1972159 which 
confirms that there may be a problem in Ubuntu 22.04 with processes being 
killed without good reason, and some hints on how to configure your system to 
avoid that.

Maybe the systems-oomd package can simply be removed.

Hope that helps,
Kay


On Tue, 29 Nov 2022 10:25:17 +0200, Demetres D. Leonidas 
 wrote:

>Dear Kay,
>
>you are right and I do apologize for the misunderstanding. Point 1 and 2 
>are sufficient.
>
>best
>
>Demetres
>
>On 11/29/2022 10:00 AM, Kay Diederichs wrote:
>> Dear Demetres,
>>
>> sounds a bit drastic!
>> The second point alone would certainly suffice, because then no forking is 
>> done.
>>
>> What kind of hardware is that?
>> I would expect that on a contemporary workstation you have 8GB of RAM or 
>> more; that would allow for 8 or more processes.
>> Do you have a swapfile? If not, create one.
>>
>> Please check out 
>> https://strucbio.biologie.uni-konstanz.de/xdswiki/index.php/Performance
>>
>> Best wishes,
>> Kay
>>
>>
>> On Tue, 29 Nov 2022 09:34:49 +0200, Demetres D. Leonidas 
>>  wrote:
>>
>>> Dear Kay,
>>>
>>> after some digging and help from Max Nanao we found that the problem
>>> was the memory.  It was fulling rapidly. The workaround was to:
>>>
>>> 1. unzip the cbf files prior to processing
>>>
>>> 2. use maximum number of jobs 1
>>>
>>> 3. use number of processors 4
>>>
>>> 4. run xds_par
>>>
>>> Many thanks for all your help
>>>
>>> Demetres
>>>
>>> On 11/29/2022 9:03 AM, Kay Diederichs wrote:
 Dear Demetres,

 I agree with what James says: this is the operating system trying to to 
 prevent, in an over-zealous way, the
 forking of too many or too big (in terms of memory) processes.
 In other words, XDS hasn't changed, but the operating system changed - it 
 applies different limits to its processes.
 Your friendly system administrator should try to find out exactly which 
 limit(s) changed, and reset the value(s).
 Perhaps a hint is in the Release Notes of Ubuntu 22.04 ?

 Pls report here when you've found it - currently you are the only one 
 reporting it.

 Best wishes,
 Kay


 On Mon, 28 Nov 2022 12:06:43 -0800, James Holton  wrote:

> Sounds like your kernel might think "forkxds" is creating a "fork
> bomb".  Too many sub-processes firing off in too short a time triggers
> this.  On one of my systems, I fixed it by editing
> /etc/security/limits.d/20-nproc.conf so that users are allowed ~10x more
> pids than normal.  This tends to prevent these mysterious "Killed" errors.
>
> HTH?
>
> -James Holton
> MAD Scientist
>
>
> On 11/28/2022 7:44 AM, Demetres D. Leonidas wrote:
>> Dear all,
>>
>> I do not know if this is the right list and I would like to apologize
>> if it is not.
>>
>> We have repeatedly experienced xds crashes in machines running ubuntu
>> 22.04.1 with the following message repeated several times at the
>> INTEGRATE step
>>
>> /usr/local/bin/forkxds: line 60:  3427 Done echo "$itask"
>>
>>     3428 Killed  | $amain
>>
>> We are trying to process data from P13 at EMBL-Hamburg.
>>
>> We are running XDS version Jan 10, 2022 BUILT=20220820
>>
>> Any ideas ?
>>
>> Demetres
>>
> 
>
> To unsubscribe from the CCP4BB list, click the following link:
> https://www.jiscmail.ac.uk/cgi-bin/WA-JISC.exe?SUBED1=CCP4BB=1
>
> This message was issued to members of www.jiscmail.ac.uk/CCP4BB, a 
> mailing list hosted by www.jiscmail.ac.uk, terms & conditions are 
> available at https://www.jiscmail.ac.uk/policyandsecurity/
 

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

 This message was issued to members of www.jiscmail.ac.uk/CCP4BB, a mailing 
 list hosted by www.jiscmail.ac.uk, terms & conditions are available at 
 https://www.jiscmail.ac.uk/policyandsecurity/
>>> -- 
>>> ---
>>> Dr. Demetres D. Leonidas
>>> Professor in Biochemistry
>>> Department of Biochemistry & Biotechnology
>>> University of 

Re: [ccp4bb] xds crashes

2022-11-29 Thread ClAuS Flensburg
Dear Demetres,

On Tue, Nov 29, 2022 at 10:25:17AM +0200, Demetres D. Leonidas wrote:
> Dear Kay,
> 
> you are right and I do apologize for the misunderstanding. Point 1
> and 2 are sufficient.

You can probably avoid doing any of this by using the LIB= feature of
XDS on gzipped CBF files with the excellent xds-zcbf plugin [1].

If you have autoPROC available this will be used automatically [2].


Regards,

ClAuS & Clemens

[1] https://git.embl.de/nikolova/xds-zcbf
[2] https://www.globalphasing.com/autoproc

> 
> best
> 
> Demetres
> 
> On 11/29/2022 10:00 AM, Kay Diederichs wrote:
> >Dear Demetres,
> >
> >sounds a bit drastic!
> >The second point alone would certainly suffice, because then no forking is 
> >done.
> >
> >What kind of hardware is that?
> >I would expect that on a contemporary workstation you have 8GB of RAM or 
> >more; that would allow for 8 or more processes.
> >Do you have a swapfile? If not, create one.
> >
> >Please check out 
> >https://strucbio.biologie.uni-konstanz.de/xdswiki/index.php/Performance
> >
> >Best wishes,
> >Kay
> >
> >
> >On Tue, 29 Nov 2022 09:34:49 +0200, Demetres D. Leonidas 
> > wrote:
> >
> >>Dear Kay,
> >>
> >>after some digging and help from Max Nanao we found that the problem
> >>was the memory.  It was fulling rapidly. The workaround was to:
> >>
> >>1. unzip the cbf files prior to processing
> >>
> >>2. use maximum number of jobs 1
> >>
> >>3. use number of processors 4
> >>
> >>4. run xds_par
> >>
> >>Many thanks for all your help
> >>
> >>Demetres
> >>
> >>On 11/29/2022 9:03 AM, Kay Diederichs wrote:
> >>>Dear Demetres,
> >>>
> >>>I agree with what James says: this is the operating system trying to to 
> >>>prevent, in an over-zealous way, the
> >>>forking of too many or too big (in terms of memory) processes.
> >>>In other words, XDS hasn't changed, but the operating system changed - it 
> >>>applies different limits to its processes.
> >>>Your friendly system administrator should try to find out exactly which 
> >>>limit(s) changed, and reset the value(s).
> >>>Perhaps a hint is in the Release Notes of Ubuntu 22.04 ?
> >>>
> >>>Pls report here when you've found it - currently you are the only one 
> >>>reporting it.
> >>>
> >>>Best wishes,
> >>>Kay
> >>>
> >>>
> >>>On Mon, 28 Nov 2022 12:06:43 -0800, James Holton  wrote:
> >>>
> Sounds like your kernel might think "forkxds" is creating a "fork
> bomb".  Too many sub-processes firing off in too short a time triggers
> this.  On one of my systems, I fixed it by editing
> /etc/security/limits.d/20-nproc.conf so that users are allowed ~10x more
> pids than normal.  This tends to prevent these mysterious "Killed" errors.
> 
> HTH?
> 
> -James Holton
> MAD Scientist
> 
> 
> On 11/28/2022 7:44 AM, Demetres D. Leonidas wrote:
> >Dear all,
> >
> >I do not know if this is the right list and I would like to apologize
> >if it is not.
> >
> >We have repeatedly experienced xds crashes in machines running ubuntu
> >22.04.1 with the following message repeated several times at the
> >INTEGRATE step
> >
> >/usr/local/bin/forkxds: line 60:  3427 Done echo "$itask"
> >
> >    3428 Killed  | $amain
> >
> >We are trying to process data from P13 at EMBL-Hamburg.
> >
> >We are running XDS version Jan 10, 2022 BUILT=20220820
> >
> >Any ideas ?
> >
> >Demetres
> >
> 
> 
> To unsubscribe from the CCP4BB list, click the following link:
> https://www.jiscmail.ac.uk/cgi-bin/WA-JISC.exe?SUBED1=CCP4BB=1
> 
> This message was issued to members of www.jiscmail.ac.uk/CCP4BB, a 
> mailing list hosted by www.jiscmail.ac.uk, terms & conditions are 
> available at https://www.jiscmail.ac.uk/policyandsecurity/
> >>>
> >>>
> >>>To unsubscribe from the CCP4BB list, click the following link:
> >>>https://www.jiscmail.ac.uk/cgi-bin/WA-JISC.exe?SUBED1=CCP4BB=1
> >>>
> >>>This message was issued to members of www.jiscmail.ac.uk/CCP4BB, a mailing 
> >>>list hosted by www.jiscmail.ac.uk, terms & conditions are available at 
> >>>https://www.jiscmail.ac.uk/policyandsecurity/
> >>-- 
> >>---
> >>Dr. Demetres D. Leonidas
> >>Professor in Biochemistry
> >>Department of Biochemistry & Biotechnology
> >>University of Thessaly
> >>Biopolis 41500 Larissa, Greece
> >>-
> >>Tel. +302410 565278
> >>Tel. +302410 565297 (Lab)
> >>Tel. +304210 565263 (X-ray)
> >>Fax. +302410 565290
> >>E-mail: ddleoni...@bio.uth.gr
> >>ORCID ID orcid.org/-0002-3874-2523
> >>---
> >>
> >>
> >>-- 
> >>  email   ??  ??  
> >>Avast antivirus.
> >>www.avast.com
> >>
> 

Re: [ccp4bb] xds crashes

2022-11-29 Thread Demetres D. Leonidas

Dear Kay,

you are right and I do apologize for the misunderstanding. Point 1 and 2 
are sufficient.


best

Demetres

On 11/29/2022 10:00 AM, Kay Diederichs wrote:

Dear Demetres,

sounds a bit drastic!
The second point alone would certainly suffice, because then no forking is done.

What kind of hardware is that?
I would expect that on a contemporary workstation you have 8GB of RAM or more; 
that would allow for 8 or more processes.
Do you have a swapfile? If not, create one.

Please check out 
https://strucbio.biologie.uni-konstanz.de/xdswiki/index.php/Performance

Best wishes,
Kay


On Tue, 29 Nov 2022 09:34:49 +0200, Demetres D. Leonidas 
 wrote:


Dear Kay,

after some digging and help from Max Nanao we found that the problem
was the memory.  It was fulling rapidly. The workaround was to:

1. unzip the cbf files prior to processing

2. use maximum number of jobs 1

3. use number of processors 4

4. run xds_par

Many thanks for all your help

Demetres

On 11/29/2022 9:03 AM, Kay Diederichs wrote:

Dear Demetres,

I agree with what James says: this is the operating system trying to to 
prevent, in an over-zealous way, the
forking of too many or too big (in terms of memory) processes.
In other words, XDS hasn't changed, but the operating system changed - it 
applies different limits to its processes.
Your friendly system administrator should try to find out exactly which 
limit(s) changed, and reset the value(s).
Perhaps a hint is in the Release Notes of Ubuntu 22.04 ?

Pls report here when you've found it - currently you are the only one reporting 
it.

Best wishes,
Kay


On Mon, 28 Nov 2022 12:06:43 -0800, James Holton  wrote:


Sounds like your kernel might think "forkxds" is creating a "fork
bomb".  Too many sub-processes firing off in too short a time triggers
this.  On one of my systems, I fixed it by editing
/etc/security/limits.d/20-nproc.conf so that users are allowed ~10x more
pids than normal.  This tends to prevent these mysterious "Killed" errors.

HTH?

-James Holton
MAD Scientist


On 11/28/2022 7:44 AM, Demetres D. Leonidas wrote:

Dear all,

I do not know if this is the right list and I would like to apologize
if it is not.

We have repeatedly experienced xds crashes in machines running ubuntu
22.04.1 with the following message repeated several times at the
INTEGRATE step

/usr/local/bin/forkxds: line 60:  3427 Done echo "$itask"

    3428 Killed  | $amain

We are trying to process data from P13 at EMBL-Hamburg.

We are running XDS version Jan 10, 2022 BUILT=20220820

Any ideas ?

Demetres




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

This message was issued to members of www.jiscmail.ac.uk/CCP4BB, a mailing list 
hosted by www.jiscmail.ac.uk, terms & conditions are available at 
https://www.jiscmail.ac.uk/policyandsecurity/



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

This message was issued to members of www.jiscmail.ac.uk/CCP4BB, a mailing list 
hosted by www.jiscmail.ac.uk, terms & conditions are available at 
https://www.jiscmail.ac.uk/policyandsecurity/

--
---
Dr. Demetres D. Leonidas
Professor in Biochemistry
Department of Biochemistry & Biotechnology
University of Thessaly
Biopolis 41500 Larissa, Greece
-
Tel. +302410 565278
Tel. +302410 565297 (Lab)
Tel. +304210 565263 (X-ray)
Fax. +302410 565290
E-mail: ddleoni...@bio.uth.gr
ORCID ID orcid.org/-0002-3874-2523
---


--
Αυτό το email έχει ελεγχθεί για ιούς από το Avast antivirus.
www.avast.com



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

This message was issued to members of www.jiscmail.ac.uk/CCP4BB, a mailing list 
hosted by www.jiscmail.ac.uk, terms & conditions are available at 
https://www.jiscmail.ac.uk/policyandsecurity/



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

This message was issued to members of www.jiscmail.ac.uk/CCP4BB, a mailing list 
hosted by www.jiscmail.ac.uk, terms & conditions are available at 
https://www.jiscmail.ac.uk/policyandsecurity/


--
---
Dr. Demetres D. Leonidas
Professor in Biochemistry
Department of Biochemistry & Biotechnology
University of Thessaly
Biopolis 41500 Larissa, Greece
-
Tel. +302410 565278
Tel. +302410 565297 (Lab)
Tel. 

Re: [ccp4bb] xds crashes

2022-11-29 Thread Kay Diederichs
Dear Demetres,

sounds a bit drastic!
The second point alone would certainly suffice, because then no forking is done.

What kind of hardware is that?
I would expect that on a contemporary workstation you have 8GB of RAM or more; 
that would allow for 8 or more processes.
Do you have a swapfile? If not, create one.

Please check out 
https://strucbio.biologie.uni-konstanz.de/xdswiki/index.php/Performance

Best wishes,
Kay


On Tue, 29 Nov 2022 09:34:49 +0200, Demetres D. Leonidas 
 wrote:

>Dear Kay,
>
>after some digging and help from Max Nanao we found that the problem  
>was the memory.  It was fulling rapidly. The workaround was to:
>
>1. unzip the cbf files prior to processing
>
>2. use maximum number of jobs 1
>
>3. use number of processors 4
>
>4. run xds_par
>
>Many thanks for all your help
>
>Demetres
>
>On 11/29/2022 9:03 AM, Kay Diederichs wrote:
>> Dear Demetres,
>>
>> I agree with what James says: this is the operating system trying to to 
>> prevent, in an over-zealous way, the
>> forking of too many or too big (in terms of memory) processes.
>> In other words, XDS hasn't changed, but the operating system changed - it 
>> applies different limits to its processes.
>> Your friendly system administrator should try to find out exactly which 
>> limit(s) changed, and reset the value(s).
>> Perhaps a hint is in the Release Notes of Ubuntu 22.04 ?
>>
>> Pls report here when you've found it - currently you are the only one 
>> reporting it.
>>
>> Best wishes,
>> Kay
>>
>>
>> On Mon, 28 Nov 2022 12:06:43 -0800, James Holton  wrote:
>>
>>> Sounds like your kernel might think "forkxds" is creating a "fork
>>> bomb".  Too many sub-processes firing off in too short a time triggers
>>> this.  On one of my systems, I fixed it by editing
>>> /etc/security/limits.d/20-nproc.conf so that users are allowed ~10x more
>>> pids than normal.  This tends to prevent these mysterious "Killed" errors.
>>>
>>> HTH?
>>>
>>> -James Holton
>>> MAD Scientist
>>>
>>>
>>> On 11/28/2022 7:44 AM, Demetres D. Leonidas wrote:
 Dear all,

 I do not know if this is the right list and I would like to apologize
 if it is not.

 We have repeatedly experienced xds crashes in machines running ubuntu
 22.04.1 with the following message repeated several times at the
 INTEGRATE step

 /usr/local/bin/forkxds: line 60:  3427 Done echo "$itask"

    3428 Killed  | $amain

 We are trying to process data from P13 at EMBL-Hamburg.

 We are running XDS version Jan 10, 2022 BUILT=20220820

 Any ideas ?

 Demetres

>>> 
>>>
>>> To unsubscribe from the CCP4BB list, click the following link:
>>> https://www.jiscmail.ac.uk/cgi-bin/WA-JISC.exe?SUBED1=CCP4BB=1
>>>
>>> This message was issued to members of www.jiscmail.ac.uk/CCP4BB, a mailing 
>>> list hosted by www.jiscmail.ac.uk, terms & conditions are available at 
>>> https://www.jiscmail.ac.uk/policyandsecurity/
>> 
>>
>> To unsubscribe from the CCP4BB list, click the following link:
>> https://www.jiscmail.ac.uk/cgi-bin/WA-JISC.exe?SUBED1=CCP4BB=1
>>
>> This message was issued to members of www.jiscmail.ac.uk/CCP4BB, a mailing 
>> list hosted by www.jiscmail.ac.uk, terms & conditions are available at 
>> https://www.jiscmail.ac.uk/policyandsecurity/
>
>-- 
>---
>Dr. Demetres D. Leonidas
>Professor in Biochemistry
>Department of Biochemistry & Biotechnology
>University of Thessaly
>Biopolis 41500 Larissa, Greece
>-
>Tel. +302410 565278
>Tel. +302410 565297 (Lab)
>Tel. +304210 565263 (X-ray)
>Fax. +302410 565290
>E-mail: ddleoni...@bio.uth.gr
>ORCID ID orcid.org/-0002-3874-2523
>---
>
>
>-- 
>Αυτό το email έχει ελεγχθεί για ιούς από το Avast antivirus.
>www.avast.com
>
>
>
>To unsubscribe from the CCP4BB list, click the following link:
>https://www.jiscmail.ac.uk/cgi-bin/WA-JISC.exe?SUBED1=CCP4BB=1
>
>This message was issued to members of www.jiscmail.ac.uk/CCP4BB, a mailing 
>list hosted by www.jiscmail.ac.uk, terms & conditions are available at 
>https://www.jiscmail.ac.uk/policyandsecurity/



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

This message was issued to members of www.jiscmail.ac.uk/CCP4BB, a mailing list 
hosted by www.jiscmail.ac.uk, terms & conditions are available at 
https://www.jiscmail.ac.uk/policyandsecurity/


[ccp4bb] MhRe: [ccp4bb] xds crashes

2022-11-28 Thread Bret Church
Iu

W BRET CHURCH
Sydney Pharmacy School A15
THE UNIVERSITY OF SYDNEY

E bret.chu...@sydney.edu.au | W http://sydney.edu.au


Get Outlook for iOS<https://aka.ms/o0ukef>

From: CCP4 bulletin board  on behalf of Demetres D. 
Leonidas <8f316b2a2e17-dmarc-requ...@jiscmail.ac.uk>
Sent: Tuesday, November 29, 2022 6:34:49 PM
To: CCP4BB@JISCMAIL.AC.UK 
Subject: Re: [ccp4bb] xds crashes

Dear Kay,

after some digging and help from Max Nanao we found that the problem
was the memory.  It was fulling rapidly. The workaround was to:

1. unzip the cbf files prior to processing

2. use maximum number of jobs 1

3. use number of processors 4

4. run xds_par

Many thanks for all your help

Demetres

On 11/29/2022 9:03 AM, Kay Diederichs wrote:
> Dear Demetres,
>
> I agree with what James says: this is the operating system trying to to 
> prevent, in an over-zealous way, the
> forking of too many or too big (in terms of memory) processes.
> In other words, XDS hasn't changed, but the operating system changed - it 
> applies different limits to its processes.
> Your friendly system administrator should try to find out exactly which 
> limit(s) changed, and reset the value(s).
> Perhaps a hint is in the Release Notes of Ubuntu 22.04 ?
>
> Pls report here when you've found it - currently you are the only one 
> reporting it.
>
> Best wishes,
> Kay
>
>
> On Mon, 28 Nov 2022 12:06:43 -0800, James Holton  wrote:
>
>> Sounds like your kernel might think "forkxds" is creating a "fork
>> bomb".  Too many sub-processes firing off in too short a time triggers
>> this.  On one of my systems, I fixed it by editing
>> /etc/security/limits.d/20-nproc.conf so that users are allowed ~10x more
>> pids than normal.  This tends to prevent these mysterious "Killed" errors.
>>
>> HTH?
>>
>> -James Holton
>> MAD Scientist
>>
>>
>> On 11/28/2022 7:44 AM, Demetres D. Leonidas wrote:
>>> Dear all,
>>>
>>> I do not know if this is the right list and I would like to apologize
>>> if it is not.
>>>
>>> We have repeatedly experienced xds crashes in machines running ubuntu
>>> 22.04.1 with the following message repeated several times at the
>>> INTEGRATE step
>>>
>>> /usr/local/bin/forkxds: line 60:  3427 Done echo "$itask"
>>>
>>>3428 Killed  | $amain
>>>
>>> We are trying to process data from P13 at EMBL-Hamburg.
>>>
>>> We are running XDS version Jan 10, 2022 BUILT=20220820
>>>
>>> Any ideas ?
>>>
>>> Demetres
>>>
>> 
>>
>> To unsubscribe from the CCP4BB list, click the following link:
>> https://protect-au.mimecast.com/s/Uo06CZY1NqiMg1KlZTzx1F8?domain=jiscmail.ac.uk
>>
>> This message was issued to members of 
>> www.jiscmail.ac.uk/CCP4BB<http://www.jiscmail.ac.uk/CCP4BB>, a mailing list 
>> hosted by www.jiscmail.ac.uk<http://www.jiscmail.ac.uk>, terms & conditions 
>> are available at 
>> https://protect-au.mimecast.com/s/F-D-C1WLPxcpGrJ3yTG9B2_?domain=jiscmail.ac.uk
> 
>
> To unsubscribe from the CCP4BB list, click the following link:
> https://protect-au.mimecast.com/s/Uo06CZY1NqiMg1KlZTzx1F8?domain=jiscmail.ac.uk
>
> This message was issued to members of 
> www.jiscmail.ac.uk/CCP4BB<http://www.jiscmail.ac.uk/CCP4BB>, a mailing list 
> hosted by www.jiscmail.ac.uk<http://www.jiscmail.ac.uk>, terms & conditions 
> are available at 
> https://protect-au.mimecast.com/s/F-D-C1WLPxcpGrJ3yTG9B2_?domain=jiscmail.ac.uk/

--
---
Dr. Demetres D. Leonidas
Professor in Biochemistry
Department of Biochemistry & Biotechnology
University of Thessaly
Biopolis 41500 Larissa, Greece
-
Tel. +302410 565278
Tel. +302410 565297 (Lab)
Tel. +304210 565263 (X-ray)
Fax. +302410 565290
E-mail: ddleoni...@bio.uth.gr
ORCID ID orcid.org/-0002-3874-2523
---


--
Αυτό το email έχει ελεγχθεί για ιούς από το Avast antivirus.
www.avast.com<http://www.avast.com>



To unsubscribe from the CCP4BB list, click the following link:
https://protect-au.mimecast.com/s/Uo06CZY1NqiMg1KlZTzx1F8?domain=jiscmail.ac.uk

This message was issued to members of 
www.jiscmail.ac.uk/CCP4BB<http://www.jiscmail.ac.uk/CCP4BB>, a mailing list 
hosted by www.jiscmail.ac.uk<http

Re: [ccp4bb] xds crashes

2022-11-28 Thread Demetres D. Leonidas

Dear Kay,

after some digging and help from Max Nanao we found that the problem  
was the memory.  It was fulling rapidly. The workaround was to:


1. unzip the cbf files prior to processing

2. use maximum number of jobs 1

3. use number of processors 4

4. run xds_par

Many thanks for all your help

Demetres

On 11/29/2022 9:03 AM, Kay Diederichs wrote:

Dear Demetres,

I agree with what James says: this is the operating system trying to to 
prevent, in an over-zealous way, the
forking of too many or too big (in terms of memory) processes.
In other words, XDS hasn't changed, but the operating system changed - it 
applies different limits to its processes.
Your friendly system administrator should try to find out exactly which 
limit(s) changed, and reset the value(s).
Perhaps a hint is in the Release Notes of Ubuntu 22.04 ?

Pls report here when you've found it - currently you are the only one reporting 
it.

Best wishes,
Kay


On Mon, 28 Nov 2022 12:06:43 -0800, James Holton  wrote:


Sounds like your kernel might think "forkxds" is creating a "fork
bomb".  Too many sub-processes firing off in too short a time triggers
this.  On one of my systems, I fixed it by editing
/etc/security/limits.d/20-nproc.conf so that users are allowed ~10x more
pids than normal.  This tends to prevent these mysterious "Killed" errors.

HTH?

-James Holton
MAD Scientist


On 11/28/2022 7:44 AM, Demetres D. Leonidas wrote:

Dear all,

I do not know if this is the right list and I would like to apologize
if it is not.

We have repeatedly experienced xds crashes in machines running ubuntu
22.04.1 with the following message repeated several times at the
INTEGRATE step

/usr/local/bin/forkxds: line 60:  3427 Done echo "$itask"

   3428 Killed  | $amain

We are trying to process data from P13 at EMBL-Hamburg.

We are running XDS version Jan 10, 2022 BUILT=20220820

Any ideas ?

Demetres




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

This message was issued to members of www.jiscmail.ac.uk/CCP4BB, a mailing list 
hosted by www.jiscmail.ac.uk, terms & conditions are available at 
https://www.jiscmail.ac.uk/policyandsecurity/



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

This message was issued to members of www.jiscmail.ac.uk/CCP4BB, a mailing list 
hosted by www.jiscmail.ac.uk, terms & conditions are available at 
https://www.jiscmail.ac.uk/policyandsecurity/


--
---
Dr. Demetres D. Leonidas
Professor in Biochemistry
Department of Biochemistry & Biotechnology
University of Thessaly
Biopolis 41500 Larissa, Greece
-
Tel. +302410 565278
Tel. +302410 565297 (Lab)
Tel. +304210 565263 (X-ray)
Fax. +302410 565290
E-mail: ddleoni...@bio.uth.gr
ORCID ID orcid.org/-0002-3874-2523
---


--
Αυτό το email έχει ελεγχθεί για ιούς από το Avast antivirus.
www.avast.com



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

This message was issued to members of www.jiscmail.ac.uk/CCP4BB, a mailing list 
hosted by www.jiscmail.ac.uk, terms & conditions are available at 
https://www.jiscmail.ac.uk/policyandsecurity/


Re: [ccp4bb] xds crashes

2022-11-28 Thread Kay Diederichs
Dear Demetres,

I agree with what James says: this is the operating system trying to to 
prevent, in an over-zealous way, the 
forking of too many or too big (in terms of memory) processes.
In other words, XDS hasn't changed, but the operating system changed - it 
applies different limits to its processes.
Your friendly system administrator should try to find out exactly which 
limit(s) changed, and reset the value(s).
Perhaps a hint is in the Release Notes of Ubuntu 22.04 ?

Pls report here when you've found it - currently you are the only one reporting 
it.

Best wishes,
Kay


On Mon, 28 Nov 2022 12:06:43 -0800, James Holton  wrote:

>Sounds like your kernel might think "forkxds" is creating a "fork
>bomb".  Too many sub-processes firing off in too short a time triggers
>this.  On one of my systems, I fixed it by editing
>/etc/security/limits.d/20-nproc.conf so that users are allowed ~10x more
>pids than normal.  This tends to prevent these mysterious "Killed" errors.
>
>HTH?
>
>-James Holton
>MAD Scientist
>
>
>On 11/28/2022 7:44 AM, Demetres D. Leonidas wrote:
>> Dear all,
>>
>> I do not know if this is the right list and I would like to apologize
>> if it is not.
>>
>> We have repeatedly experienced xds crashes in machines running ubuntu
>> 22.04.1 with the following message repeated several times at the
>> INTEGRATE step
>>
>> /usr/local/bin/forkxds: line 60:  3427 Done echo "$itask"
>>
>>   3428 Killed  | $amain
>>
>> We are trying to process data from P13 at EMBL-Hamburg.
>>
>> We are running XDS version Jan 10, 2022 BUILT=20220820
>>
>> Any ideas ?
>>
>> Demetres
>>
>
>
>
>To unsubscribe from the CCP4BB list, click the following link:
>https://www.jiscmail.ac.uk/cgi-bin/WA-JISC.exe?SUBED1=CCP4BB=1
>
>This message was issued to members of www.jiscmail.ac.uk/CCP4BB, a mailing 
>list hosted by www.jiscmail.ac.uk, terms & conditions are available at 
>https://www.jiscmail.ac.uk/policyandsecurity/



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

This message was issued to members of www.jiscmail.ac.uk/CCP4BB, a mailing list 
hosted by www.jiscmail.ac.uk, terms & conditions are available at 
https://www.jiscmail.ac.uk/policyandsecurity/


Re: [ccp4bb] xds crashes

2022-11-28 Thread James Holton
Sounds like your kernel might think "forkxds" is creating a "fork 
bomb".  Too many sub-processes firing off in too short a time triggers 
this.  On one of my systems, I fixed it by editing 
/etc/security/limits.d/20-nproc.conf so that users are allowed ~10x more 
pids than normal.  This tends to prevent these mysterious "Killed" errors.


HTH?

-James Holton
MAD Scientist


On 11/28/2022 7:44 AM, Demetres D. Leonidas wrote:

Dear all,

I do not know if this is the right list and I would like to apologize 
if it is not.


We have repeatedly experienced xds crashes in machines running ubuntu 
22.04.1 with the following message repeated several times at the 
INTEGRATE step


/usr/local/bin/forkxds: line 60:  3427 Done echo "$itask"

  3428 Killed  | $amain

We are trying to process data from P13 at EMBL-Hamburg.

We are running XDS version Jan 10, 2022 BUILT=20220820

Any ideas ?

Demetres





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

This message was issued to members of www.jiscmail.ac.uk/CCP4BB, a mailing list 
hosted by www.jiscmail.ac.uk, terms & conditions are available at 
https://www.jiscmail.ac.uk/policyandsecurity/


[ccp4bb] xds crashes

2022-11-28 Thread Demetres D. Leonidas

Dear all,

I do not know if this is the right list and I would like to apologize if 
it is not.


We have repeatedly experienced xds crashes in machines running ubuntu 
22.04.1 with the following message repeated several times at the 
INTEGRATE step


/usr/local/bin/forkxds: line 60:  3427 Done echo "$itask"

  3428 Killed  | $amain

We are trying to process data from P13 at EMBL-Hamburg.

We are running XDS version Jan 10, 2022 BUILT=20220820

Any ideas ?

Demetres

--
---
Dr. Demetres D. Leonidas
Professor in Biochemistry
Department of Biochemistry & Biotechnology
University of Thessaly
Biopolis 41500 Larissa, Greece
-
Tel. +302410 565278
Tel. +302410 565297 (Lab)
Tel. +304210 565263 (X-ray)
Fax. +302410 565290
E-mail: ddleoni...@bio.uth.gr
ORCID ID orcid.org/-0002-3874-2523
---


--
Αυτό το email έχει ελεγχθεί για ιούς από το Avast antivirus.
www.avast.com



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

This message was issued to members of www.jiscmail.ac.uk/CCP4BB, a mailing list 
hosted by www.jiscmail.ac.uk, terms & conditions are available at 
https://www.jiscmail.ac.uk/policyandsecurity/


[ccp4bb] XDS package: new version and support for Apple M1

2022-01-10 Thread Kay Diederichs
Dear academic users of XDS,

there is an updated version available at https://xds.mr.mpg.de/ . Since the old 
(current) version will expire in March, it is advisable to download and test 
the updated version before that.
The biggest change is the availability of binaries for the Apple M1 processor. 
As you might know, the OSX_64 binaries (for Intel/AMD processors) do work on 
the Apple M1, but by emulation, and tests show that this native version is much 
faster. Feedback is welcome!

Best wishes for 2022!
Kay



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

This message was issued to members of www.jiscmail.ac.uk/CCP4BB, a mailing list 
hosted by www.jiscmail.ac.uk, terms & conditions are available at 
https://www.jiscmail.ac.uk/policyandsecurity/


Re: [ccp4bb] [xds] how to specify measuring angle

2020-10-09 Thread Johan Hattne

On 2020-10-09 01:59, Dirk Kostrewa wrote:

Dear Doo Nam Kim,

On 09.10.20 08:43, Doo Nam Kim wrote:
Since I don't know correct value of OSCILLATION_RANGE, I just changed 
to the example value (0.1) from (0.89976, I know it is not a 
positive multiple of 0.0001, but worked for ketone data).


without knowing the correct value for the OSCILLATION_RANGE, data 
processing might run through but produces non-sense results, independent 
of the data processing program you use. So, it is absolutely important 
to know the correct value for the oscillation range per frame.


For these data, the oscillation range should be 0.37 degrees, because 
the rotation rate is 0.09 degrees per second (as per SBGrid reprocessing 
instructions) and the time between successive frames is ~4.1 s (as 
determined by tvips2smv).


I just checked, and this is indeed what's in OSC_RANGE header item, 
assuming you actually used tvips2smv to make the SMV files.


// Cheers; Johan



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

This message was issued to members of www.jiscmail.ac.uk/CCP4BB, a mailing list 
hosted by www.jiscmail.ac.uk, terms & conditions are available at 
https://www.jiscmail.ac.uk/policyandsecurity/


Re: [ccp4bb] [xds] how to specify measuring angle

2020-10-09 Thread Jessica Bruhn
Hi Doo Nam Kim,

If you do not know your OSCILLATION_RANGE, a good guess would be to take
your collection angle range (-60 to +60 or 120 degrees) and divide that by
the number of frames.

Best,
Jessica

On Fri, Oct 9, 2020 at 2:00 AM Dirk Kostrewa <
dirk.kostr...@lrz.uni-muenchen.de> wrote:

> Dear Doo Nam Kim,
>
> On 09.10.20 08:43, Doo Nam Kim wrote:
> > Since I don't know correct value of OSCILLATION_RANGE, I just changed to
> the example value (0.1) from (0.89976, I know it is not a positive
> multiple of 0.0001, but worked for ketone data).
>
> without knowing the correct value for the OSCILLATION_RANGE, data
> processing might run through but produces non-sense results, independent
> of the data processing program you use. So, it is absolutely important
> to know the correct value for the oscillation range per frame.
>
> Cheers,
>
> Dirk.
>
> --
>
> ***
> Dirk Kostrewa
> Gene Center Munich
> Department of Biochemistry, AG Hopfner
> Ludwig-Maximilians-Universität München
> Feodor-Lynen-Str. 25
> D-81377 Munich
> Germany
> Phone:  +49-89-2180-76845
> Fax:+49-89-2180-76998
> E-mail: dirk.kostr...@lmu.de
> WWW:www.genzentrum.lmu.de
>  strubio.userweb.mwn.de
> ***
>
> 
>
> To unsubscribe from the CCP4BB list, click the following link:
> https://www.jiscmail.ac.uk/cgi-bin/WA-JISC.exe?SUBED1=CCP4BB=1
>
> This message was issued to members of www.jiscmail.ac.uk/CCP4BB, a
> mailing list hosted by www.jiscmail.ac.uk, terms & conditions are
> available at https://www.jiscmail.ac.uk/policyandsecurity/
>


-- 
Jessica Bruhn, Ph.D
Principal Scientist
NanoImaging Services, Inc.
4940 Carroll Canyon Road, Suite 115
San Diego, CA 92121
Phone #: (888) 675-8261
www.nanoimagingservices.com



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

This message was issued to members of www.jiscmail.ac.uk/CCP4BB, a mailing list 
hosted by www.jiscmail.ac.uk, terms & conditions are available at 
https://www.jiscmail.ac.uk/policyandsecurity/


Re: [ccp4bb] [xds] how to specify measuring angle

2020-10-09 Thread Dirk Kostrewa

Dear Doo Nam Kim,

On 09.10.20 08:43, Doo Nam Kim wrote:

Since I don't know correct value of OSCILLATION_RANGE, I just changed to the 
example value (0.1) from (0.89976, I know it is not a positive multiple of 
0.0001, but worked for ketone data).


without knowing the correct value for the OSCILLATION_RANGE, data 
processing might run through but produces non-sense results, independent 
of the data processing program you use. So, it is absolutely important 
to know the correct value for the oscillation range per frame.


Cheers,

Dirk.

--

***
Dirk Kostrewa
Gene Center Munich
Department of Biochemistry, AG Hopfner
Ludwig-Maximilians-Universität München
Feodor-Lynen-Str. 25
D-81377 Munich
Germany
Phone:  +49-89-2180-76845
Fax:+49-89-2180-76998
E-mail: dirk.kostr...@lmu.de
WWW:www.genzentrum.lmu.de
strubio.userweb.mwn.de
***



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

This message was issued to members of www.jiscmail.ac.uk/CCP4BB, a mailing list 
hosted by www.jiscmail.ac.uk, terms & conditions are available at 
https://www.jiscmail.ac.uk/policyandsecurity/


Re: [ccp4bb] [xds] how to specify measuring angle

2020-10-09 Thread Kay Diederichs
Dear  Doo Nam Kim,

actually the results of XDS processing are deterministic for all practical 
purposes (to be nitpicking, the multi-processor version xds_par may result in 
slighly different output each time it is run, because for a few calculations 
the order of operations is influenced by the operating system's scheduler, but 
this only typically affects the last digit and is of no practical importance).

XDS needs to know the starting and end angle of each frame. It calculates these 
values internally, from STARTING_ANGLE and OSCILLATION_RANGE and the frame 
number (you specify the frames to process with DATA_RANGE for INTEGRATE, and 
with SPOT_RANGE for COLSPOT and IDXREF). If you don't specify STARTING_ANGLE, 
it will use 0 as the default. This does not affect the success of indexing, nor 
the data quality. There is no corresponding ENDING_ANGLE, because - as I said - 
the ENDING_ANGLE is anyway calculated internally; it is the end angle of the 
last frame.

Concerning completeness:
if your DATA_RANGE is specified correctly, AND the indexing succeeds, AND the 
space group is found (or given) correctly, then I see no reason why the 
completeness should not result in 60% for you, if someone else got 60%.

Apart from http://xds.mpimf-heidelberg.mpg.de, there is documentation and 
examples in XDSwiki at 
https://strucbio.biologie.uni-konstanz.de/xdswiki/index.php/Main_page

Hope this helps,
Kay



On Fri, 9 Oct 2020 07:43:22 +0100, Doo Nam Kim  wrote:

>Thank you Tim and Kay.
>
>
>
>"the indexing procedure is independent of the starting angle of the first 
>frame."
>--> I see, since XDS does indexing, I think that XDS is independent of the 
>starting angle of the first frame
>
>
>"Are you possibly looking for the OSCILLATION_WIDTH=, i.e. the degree
>per frame during data collection?"
>
>--> As I see 
>http://xds.mpimf-heidelberg.mpg.de/html_doc/xds_parameters.html#OSCILLATION_RANGE=
>
>OSCILLATION_RANGE= ! (not OSCILLATION_WIDTH!)
>appears to designate 1 value, rather than 2 values (like min and max, e.g. 
>-60, 60).
>
>Since I don't know correct value of OSCILLATION_RANGE, I just changed to the 
>example value (0.1) from (0.89976, I know it is not a positive multiple of 
>0.0001, but worked for ketone data).
>
>Then, xds ran without error.
>
>Then, according to recommendtion, I changed from
>JOB=XYCORR INIT COLSPOT IDXREF DEFPIX INTEGRATE CORRECT
>to
>JOB= DEFPIX INTEGRATE CORRECT
>
>and ran again.
>
>This time, it generated CORRECT.LP, but I see COMPLETENESS is only ~6%, while 
>my predecessor achieved ~60%
>
>I think that results of XDS are somehow random (not 100% deterministic). But I 
>didn't expect this big difference of COMPLETENESS (6% vs 60%).
>
>I think that I still entered a wrong option value somewhere in my XDS.INP.
>
>I think that I need to use well documented (with respect to needed xds.INP 
>parameters) microED dataset but I can't download from
>https://cryoem.ucla.edu/MicroED
>
>
>
>To unsubscribe from the CCP4BB list, click the following link:
>https://www.jiscmail.ac.uk/cgi-bin/WA-JISC.exe?SUBED1=CCP4BB=1
>
>This message was issued to members of www.jiscmail.ac.uk/CCP4BB, a mailing 
>list hosted by www.jiscmail.ac.uk, terms & conditions are available at 
>https://www.jiscmail.ac.uk/policyandsecurity/



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

This message was issued to members of www.jiscmail.ac.uk/CCP4BB, a mailing list 
hosted by www.jiscmail.ac.uk, terms & conditions are available at 
https://www.jiscmail.ac.uk/policyandsecurity/


Re: [ccp4bb] [xds] how to specify measuring angle

2020-10-09 Thread Doo Nam Kim
Once I turned off my vpn, I could download from 
https://data.sbgrid.org/dataset/222/

Thank you for your help.



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

This message was issued to members of www.jiscmail.ac.uk/CCP4BB, a mailing list 
hosted by www.jiscmail.ac.uk, terms & conditions are available at 
https://www.jiscmail.ac.uk/policyandsecurity/


Re: [ccp4bb] [xds] how to specify measuring angle

2020-10-09 Thread Doo Nam Kim
Thank you Tim and Kay.



"the indexing procedure is independent of the starting angle of the first 
frame."
--> I see, since XDS does indexing, I think that XDS is independent of the 
starting angle of the first frame


"Are you possibly looking for the OSCILLATION_WIDTH=, i.e. the degree
per frame during data collection?"

--> As I see 
http://xds.mpimf-heidelberg.mpg.de/html_doc/xds_parameters.html#OSCILLATION_RANGE=

OSCILLATION_RANGE= ! (not OSCILLATION_WIDTH!)
appears to designate 1 value, rather than 2 values (like min and max, e.g. -60, 
60).

Since I don't know correct value of OSCILLATION_RANGE, I just changed to the 
example value (0.1) from (0.89976, I know it is not a positive multiple of 
0.0001, but worked for ketone data).

Then, xds ran without error.

Then, according to recommendtion, I changed from
JOB=XYCORR INIT COLSPOT IDXREF DEFPIX INTEGRATE CORRECT
to
JOB= DEFPIX INTEGRATE CORRECT

and ran again.

This time, it generated CORRECT.LP, but I see COMPLETENESS is only ~6%, while 
my predecessor achieved ~60%

I think that results of XDS are somehow random (not 100% deterministic). But I 
didn't expect this big difference of COMPLETENESS (6% vs 60%).

I think that I still entered a wrong option value somewhere in my XDS.INP.

I think that I need to use well documented (with respect to needed xds.INP 
parameters) microED dataset but I can't download from
https://cryoem.ucla.edu/MicroED



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

This message was issued to members of www.jiscmail.ac.uk/CCP4BB, a mailing list 
hosted by www.jiscmail.ac.uk, terms & conditions are available at 
https://www.jiscmail.ac.uk/policyandsecurity/


Re: [ccp4bb] [xds] how to specify measuring angle

2020-10-08 Thread Kay Diederichs
I agree with Tim that Doo Nam Kim's question appears to be directed towards the 
rotation per frame, 
which is specified in XDS.INP using
 OSCILLATION_RANGE= ! (not OSCILLATION_WIDTH!)
please see the documentation at  
http://xds.mpimf-heidelberg.mpg.de/html_doc/xds_parameters.html#OSCILLATION_RANGE=

best,
Kay

On Thu, 8 Oct 2020 11:04:21 +0200, Tim Gruene  wrote:

>Dear Doo Nam Kim,
>
>the indexing procedure is independent of the starting angle of the
>first frame.
>
>Are you possibly looking for the OSCILLATION_WIDTH=, i.e. the degree
>per frame during data collection?
>
>Best regards,
>Tim
>
>On Thu, 8 Oct 2020 09:28:07 +0100
>Doo Nam Kim <4e720d49e642-dmarc-requ...@jiscmail.ac.uk> wrote:
>
>> I think that my microED data was measured with -60 to 60 rotation
>> angle.
>> 
>> However, 
>> STARTING_ANGLE=  -60.
>> in my XDS.INP
>> 
>> resulted in 
>> ...
>>   #  COORDINATES OF REC. BASIS VECTORREDUCED CELL INDICES
>> 
>> 1   0.0020349 0.0108237 0.0096964 1.00   -0.00   -0.00
>> 2  -0.0056895-0.0002762 0.0015024 0.001.00   -0.00
>> 3   0.0011313-0.0034716 0.0036457 0.00   -0.001.00
>> 
>> 
>>  * REFINED SOLUTION BASED ON INDEXED REFLECTIONS IN SUBTREE # 1
>> * !!! ERROR IN REFINE !!! RETURN CODE IS IER=   0
>> 
>> I assume that rotation angle should be specified in XDS.INP.
>> 
>> Anyone knows how to specify measuring angle in XDS.INP?
>> 
>> If there's no such option in XDS.INP, please let me know as well.
>> Then, my other part of XDS.INP should be corrected.
>> 
>> Thank you
>> 
>> 
>> 
>> To unsubscribe from the CCP4BB list, click the following link:
>> https://www.jiscmail.ac.uk/cgi-bin/WA-JISC.exe?SUBED1=CCP4BB=1
>> 
>> This message was issued to members of www.jiscmail.ac.uk/CCP4BB, a
>> mailing list hosted by www.jiscmail.ac.uk, terms & conditions are
>> available at https://www.jiscmail.ac.uk/policyandsecurity/
>
>
>
>-- 
>--
>Tim Gruene
>Head of the Centre for X-ray Structure Analysis
>Faculty of Chemistry
>University of Vienna
>
>Phone: +43-1-4277-70202
>
>GPG Key ID = A46BEE1A
>
>
>
>To unsubscribe from the CCP4BB list, click the following link:
>https://www.jiscmail.ac.uk/cgi-bin/WA-JISC.exe?SUBED1=CCP4BB=1
>
>This message was issued to members of www.jiscmail.ac.uk/CCP4BB, a mailing 
>list hosted by www.jiscmail.ac.uk, terms & conditions are available at 
>https://www.jiscmail.ac.uk/policyandsecurity/
>



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

This message was issued to members of www.jiscmail.ac.uk/CCP4BB, a mailing list 
hosted by www.jiscmail.ac.uk, terms & conditions are available at 
https://www.jiscmail.ac.uk/policyandsecurity/


Re: [ccp4bb] [xds] how to specify measuring angle

2020-10-08 Thread Tim Gruene
Dear Doo Nam Kim,

the indexing procedure is independent of the starting angle of the
first frame.

Are you possibly looking for the OSCILLATION_WIDTH=, i.e. the degree
per frame during data collection?

Best regards,
Tim

On Thu, 8 Oct 2020 09:28:07 +0100
Doo Nam Kim <4e720d49e642-dmarc-requ...@jiscmail.ac.uk> wrote:

> I think that my microED data was measured with -60 to 60 rotation
> angle.
> 
> However, 
> STARTING_ANGLE=  -60.
> in my XDS.INP
> 
> resulted in 
> ...
>   #  COORDINATES OF REC. BASIS VECTORREDUCED CELL INDICES
> 
> 1   0.0020349 0.0108237 0.0096964 1.00   -0.00   -0.00
> 2  -0.0056895-0.0002762 0.0015024 0.001.00   -0.00
> 3   0.0011313-0.0034716 0.0036457 0.00   -0.001.00
> 
> 
>  * REFINED SOLUTION BASED ON INDEXED REFLECTIONS IN SUBTREE # 1
> * !!! ERROR IN REFINE !!! RETURN CODE IS IER=   0
> 
> I assume that rotation angle should be specified in XDS.INP.
> 
> Anyone knows how to specify measuring angle in XDS.INP?
> 
> If there's no such option in XDS.INP, please let me know as well.
> Then, my other part of XDS.INP should be corrected.
> 
> Thank you
> 
> 
> 
> To unsubscribe from the CCP4BB list, click the following link:
> https://www.jiscmail.ac.uk/cgi-bin/WA-JISC.exe?SUBED1=CCP4BB=1
> 
> This message was issued to members of www.jiscmail.ac.uk/CCP4BB, a
> mailing list hosted by www.jiscmail.ac.uk, terms & conditions are
> available at https://www.jiscmail.ac.uk/policyandsecurity/



-- 
--
Tim Gruene
Head of the Centre for X-ray Structure Analysis
Faculty of Chemistry
University of Vienna

Phone: +43-1-4277-70202

GPG Key ID = A46BEE1A



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

This message was issued to members of www.jiscmail.ac.uk/CCP4BB, a mailing list 
hosted by www.jiscmail.ac.uk, terms & conditions are available at 
https://www.jiscmail.ac.uk/policyandsecurity/


pgpz9OxPGhw8u.pgp
Description: OpenPGP digital signature


[ccp4bb] [xds] how to specify measuring angle

2020-10-08 Thread Doo Nam Kim
I think that my microED data was measured with -60 to 60 rotation angle.

However, 
STARTING_ANGLE=  -60.
in my XDS.INP

resulted in 
...
  #  COORDINATES OF REC. BASIS VECTORREDUCED CELL INDICES

1   0.0020349 0.0108237 0.0096964 1.00   -0.00   -0.00
2  -0.0056895-0.0002762 0.0015024 0.001.00   -0.00
3   0.0011313-0.0034716 0.0036457 0.00   -0.001.00


 * REFINED SOLUTION BASED ON INDEXED REFLECTIONS IN SUBTREE # 1 *
  !!! ERROR IN REFINE !!! RETURN CODE IS IER=   0

I assume that rotation angle should be specified in XDS.INP.

Anyone knows how to specify measuring angle in XDS.INP?

If there's no such option in XDS.INP, please let me know as well.
Then, my other part of XDS.INP should be corrected.

Thank you



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

This message was issued to members of www.jiscmail.ac.uk/CCP4BB, a mailing list 
hosted by www.jiscmail.ac.uk, terms & conditions are available at 
https://www.jiscmail.ac.uk/policyandsecurity/


Re: [ccp4bb] XDS Data Processing

2018-02-22 Thread Kay Diederichs
Hi Maria,

XDSGUI is documented at 
https://strucbio.biologie.uni-konstanz.de/xdswiki/index.php/XDSGUI . The 
easiest way to learn it is of course if you find somebody to show it to you. 
Are you the only one in your lab who uses it?

If you have a XDS-on-Mac problem, check out the Installation article of XDSwiki.

HTH

Kay

On Wed, 21 Feb 2018 17:04:25 -0600, Maria Jones  wrote:

>Hello Friends,
>I am trying to use XDS GUI for data processing in  Mac. I am having an error 
>while loading the raw image files. Should I convert them to any specific 
>format? Also is there any good tutorial for the beginners for using the GUI?
>Thanks in advance.


Re: [ccp4bb] XDS Data Processing

2018-02-21 Thread Lorenzo Briganti
Hello Maria!

I would recommend these 2 links:

https://strucbio.biologie.uni-konstanz.de/xdswiki/index.php/Tutorial(First_Steps)

and for difficult datasets:

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

Are you having problems with the “generate XDS.inp?” Maybe it’s not installed 
properly (not in the path)

Best regards,

Lorenzo


quarta-feira, 21 de fevereiro de 2018 20:04 -0300 de duskyde...@gmail.com 
:
Hello Friends,
I am trying to use XDS GUI for data processing in Mac. I am having an error 
while loading the raw image files. Should I convert them to any specific 
format? Also is there any good tutorial for the beginners for using the GUI?
Thanks in advance.


[ccp4bb] XDS Data Processing

2018-02-21 Thread Maria Jones
Hello Friends,
I am trying to use XDS GUI for data processing in  Mac. I am having an error 
while loading the raw image files. Should I convert them to any specific 
format? Also is there any good tutorial for the beginners for using the GUI?
Thanks in advance.


Re: [ccp4bb] XDS on Windows

2017-05-26 Thread Jan Gebauer

Hi Jan, Hi Rob, hi Gustavo,

thanks for you answers. I totally missed the thread in the bb and 
couldn't find anything in the archive also the wiki entry - frankly 
I havn't checked that one for a while ...


Great to know that the CU update solves most of the issues regarding the 
openMP virtualisation - I also can confirm that here...


Just did a little testing in a virtual machine running Win10CU or Ubuntu 
16. The times XDS needed to analyse the Helmholtz #3 MR dataset are below:


Window 10 =  286 sec (mean of 3 trials)
Ubuntu 16  = 293 sec (mean of 3 trials)

I tried to keep the settings of the VM similar, so I guess this will 
give us a general idea of the speed of XDS on both OSs I am suprised 
that Windows seems (at least in my setting) not to be slower than Linux...


Best,
Jan


Am 24.05.2017 um 09:25 schrieb Kay Diederichs:

Hi Jan, Rob,

it is documented in XDSwiki 
athttp://strucbio.biologie.uni-konstanz.de/xdswiki/index.php/Installation#Windows
  - I just added the hints concerning the Creators Update (can anybody verify 
that OpenMP parallelization works with that??).

best,

Kay


On Tue, 23 May 2017 14:06:54 +0100, R.D. Oeffner  wrote:


Hi Jan,

There were some postings on the bulletin board about this in the latter
half of August last year. I also recall problems with the parallel
version of XDS but I think this was fixed by Microsoft in a patch that I
believe is included in the recent Creators update to Windows 10. Can't
verify this right now as the XDS download site appears to be offline.
But will do so when I get home.

Rob

On 23/05/2017 12:52, Jan Gebauer wrote:


Dear XDS users,

I haven't read anything about this here, but probably I missed it:

With the relatively new "Windows Subsystem for Linux" you can "natively" (i.e. 
without an virtual machine) run XDS on Windows 10.

In theory it should have a similar performance than on a native Linux System. 
However, currently I wasn't able to get the parrallised version (xds_par) to 
work - which negates the potential speed advantage over an virtual machine.

In principle XDS-GUI is also working with some tricks... but it is a little bit 
buggy...

I haven't tested other suites yet nor carefully checked the output, so be 
carefull.

With kind regards,

Jan

PS: Before anyone wonders: I DO use Linux normally, however on my small 
ulltrabook it could be useful for satisfying my curiosity on the trip back form 
the synchrotron.





Re: [ccp4bb] XDS on Windows

2017-05-24 Thread Kay Diederichs
Hi Jan, Rob,

it is documented in XDSwiki at 
http://strucbio.biologie.uni-konstanz.de/xdswiki/index.php/Installation#Windows 
- I just added the hints concerning the Creators Update (can anybody verify 
that OpenMP parallelization works with that??).

best,

Kay


On Tue, 23 May 2017 14:06:54 +0100, R.D. Oeffner  wrote:

>
>
>Hi Jan,
>
>There were some postings on the bulletin board about this in the latter
>half of August last year. I also recall problems with the parallel
>version of XDS but I think this was fixed by Microsoft in a patch that I
>believe is included in the recent Creators update to Windows 10. Can't
>verify this right now as the XDS download site appears to be offline.
>But will do so when I get home.
>
>Rob
>
>On 23/05/2017 12:52, Jan Gebauer wrote:
>
>> Dear XDS users,
>>
>> I haven't read anything about this here, but probably I missed it:
>>
>> With the relatively new "Windows Subsystem for Linux" you can "natively" 
>> (i.e. without an virtual machine) run XDS on Windows 10.
>>
>> In theory it should have a similar performance than on a native Linux 
>> System. However, currently I wasn't able to get the parrallised version 
>> (xds_par) to work - which negates the potential speed advantage over an 
>> virtual machine.
>>
>> In principle XDS-GUI is also working with some tricks... but it is a little 
>> bit buggy...
>>
>> I haven't tested other suites yet nor carefully checked the output, so be 
>> carefull.
>>
>> With kind regards,
>>
>> Jan
>>
>> PS: Before anyone wonders: I DO use Linux normally, however on my small 
>> ulltrabook it could be useful for satisfying my curiosity on the trip back 
>> form the synchrotron.
>
>


Re: [ccp4bb] XDS on Windows

2017-05-23 Thread R.D. Oeffner
 

Hi Jan, 

There were some postings on the bulletin board about this in the latter
half of August last year. I also recall problems with the parallel
version of XDS but I think this was fixed by Microsoft in a patch that I
believe is included in the recent Creators update to Windows 10. Can't
verify this right now as the XDS download site appears to be offline.
But will do so when I get home. 

Rob 

On 23/05/2017 12:52, Jan Gebauer wrote: 

> Dear XDS users,
> 
> I haven't read anything about this here, but probably I missed it:
> 
> With the relatively new "Windows Subsystem for Linux" you can "natively" 
> (i.e. without an virtual machine) run XDS on Windows 10.
> 
> In theory it should have a similar performance than on a native Linux System. 
> However, currently I wasn't able to get the parrallised version (xds_par) to 
> work - which negates the potential speed advantage over an virtual machine.
> 
> In principle XDS-GUI is also working with some tricks... but it is a little 
> bit buggy...
> 
> I haven't tested other suites yet nor carefully checked the output, so be 
> carefull.
> 
> With kind regards,
> 
> Jan
> 
> PS: Before anyone wonders: I DO use Linux normally, however on my small 
> ulltrabook it could be useful for satisfying my curiosity on the trip back 
> form the synchrotron.

 

Re: [ccp4bb] XDS plugin for efficient reading of HDF5 data

2017-03-23 Thread Kay Diederichs
Dear all,

unfortunately the very latest BUILT of the XDS package (which fixed a problem 
in XDSCONV) introduced a last-minute bug in the routine that uses the "Neggia" 
plugin. This is documented, together with two workarounds, in the 
Troubleshooting section of the Eiger article in XDSwiki : 
http://strucbio.biologie.uni-konstanz.de/xdswiki/index.php/Eiger#Troubleshooting
 .

The easiest workaround is to just use the 20161205 BUILT of the XDS package 
(replacing the old XDSCONV with the one from the latest BUILT).
 
Sorry about this!

Kay


On Thu, 23 Mar 2017 10:56:54 +0100, Andreas Förster 
 wrote:

>Dear all,
>
>DECTRIS is proud to announce the release of an HDF5 read plugin to take
>advantage of the recently added XDS plugin support (thanks to Wolfgang
>Kabsch and Kay Diederichs) and accelerate the reading of HDF5 files.
>
>EIGER detectors produce data in the large-data format HDF5. Despite
>substantial advantages (few files to handle, excellent compression), HDF5
>data pose some difficulties.  While DIALS and HKL-2000 process HDF5 data
>natively, they are limited in their performance by the lack of parallel
>reading of the HDF library.  Processing of HDF5 data by XDS has thus far
>relied on extraction of temporary CBF images, which adds to the processing
>time.
>
>Neggia, our read plugin for XDS, presents HDF5 data to XDS in a fully
>parallelized way, directly and without interconversion.  Processing of HDF5
>data is now as fast as processing of CBFs.  Refer to the plugin with LIB=
>/path/to/plugin.so in XDS.INP.  The parameter DETECTOR= EIGER should remain.
>
>You can download the plugin from www.dectris.com/neggia.html (registration
>required).  To run it you need a reasonably recent OSX or linux system with
>gcc 4.8 or higher.  We have tested macOS Sierra, CentOS 6, CentOS 7, Mint
>17.3.  Alternatively, you can compile the plugin from the source available
>at https://github.com/dectris/neggia.
>
>The plugin was written to work with recent EIGER data and has been tested
>in house and at a few adventurous beamlines.  If you encounter issues,
>please let me now.  Your problem reports will help make the plugin better,
>to the benefit of the entire community.
>
>All best and happy data processing
>
>
>Andreas
>
>
>
>-- 
>
>Andreas Förster, Ph.D.
>MX Application Scientist, Scientific Sales
>Phone: +41 56 500 2100 | Direct: +41 56 500 2176 | Email:
>andreas.foers...@dectris.com
>DECTRIS Ltd. | Taefernweg 1 | 5405 Baden-Daettwil | Switzerland |
>www.dectris.com
>
>[image: LinkedIn] 
> [image: facebook]
>
>
>
>
>
>
>
>Confidentiality Note: This message is intended only for the use of the
>named
>recipient(s) and may contain confidential and/or privileged information. If
>you
>are not the intended recipient, please contact the sender and delete the
>message.
>Any unauthorized use of the information contained in this message is
>prohibited.
>


[ccp4bb] XDS plugin for efficient reading of HDF5 data

2017-03-23 Thread Andreas Förster
Dear all,

DECTRIS is proud to announce the release of an HDF5 read plugin to take
advantage of the recently added XDS plugin support (thanks to Wolfgang
Kabsch and Kay Diederichs) and accelerate the reading of HDF5 files.

EIGER detectors produce data in the large-data format HDF5. Despite
substantial advantages (few files to handle, excellent compression), HDF5
data pose some difficulties.  While DIALS and HKL-2000 process HDF5 data
natively, they are limited in their performance by the lack of parallel
reading of the HDF library.  Processing of HDF5 data by XDS has thus far
relied on extraction of temporary CBF images, which adds to the processing
time.

Neggia, our read plugin for XDS, presents HDF5 data to XDS in a fully
parallelized way, directly and without interconversion.  Processing of HDF5
data is now as fast as processing of CBFs.  Refer to the plugin with LIB=
/path/to/plugin.so in XDS.INP.  The parameter DETECTOR= EIGER should remain.

You can download the plugin from www.dectris.com/neggia.html (registration
required).  To run it you need a reasonably recent OSX or linux system with
gcc 4.8 or higher.  We have tested macOS Sierra, CentOS 6, CentOS 7, Mint
17.3.  Alternatively, you can compile the plugin from the source available
at https://github.com/dectris/neggia.

The plugin was written to work with recent EIGER data and has been tested
in house and at a few adventurous beamlines.  If you encounter issues,
please let me now.  Your problem reports will help make the plugin better,
to the benefit of the entire community.

All best and happy data processing


Andreas



-- 

Andreas Förster, Ph.D.
MX Application Scientist, Scientific Sales
Phone: +41 56 500 2100 | Direct: +41 56 500 2176 | Email:
andreas.foers...@dectris.com
DECTRIS Ltd. | Taefernweg 1 | 5405 Baden-Daettwil | Switzerland |
www.dectris.com

[image: LinkedIn] 
 [image: facebook]







Confidentiality Note: This message is intended only for the use of the
named
recipient(s) and may contain confidential and/or privileged information. If
you
are not the intended recipient, please contact the sender and delete the
message.
Any unauthorized use of the information contained in this message is
prohibited.


Re: [ccp4bb] XDS Gui license expired?

2017-01-09 Thread Karine Röwer

Hi Susan,

it looks like your XDS license has expired.
Download a newer XDS version from 
http://xds.mpimf-heidelberg.mpg.de/html_doc/downloading.html

Best regards,
Karine


On 01/09/17 16:33, Susan Kathleen Fetics wrote:

Hello,


I was trying to open XDS gui in Linux and it would not work. I was given the notice 
"Sorry, license expired Sept 30, 2016" with no other options as far as I could 
tell. How can I correct this so XDS gui works again?


Thanks in advance,


- Susan



--
Dr. Karine Röwer (formerly Sparta)
Soft Matter and Functional Materials
Macromolecular Crystallography (BESSY-MX)
Elektronenspeicherring BESSY II
Albert-Einstein-Str. 15, D-12489 Berlin, Germany

Fon: +49 30 8062 14869
http://de.linkedin.com/pub/karine-sparta/2a/48/1b3/en



Helmholtz-Zentrum Berlin für Materialien und Energie GmbH

Mitglied der Hermann von Helmholtz-Gemeinschaft Deutscher Forschungszentren e.V.

Aufsichtsrat: Vorsitzender Dr. Karl Eugen Huthmacher, stv. Vorsitzende Dr. 
Jutta Koch-Unterseher
Geschäftsführung: Prof. Dr. Anke Rita Kaysser-Pyzalla, Thomas Frederking

Sitz Berlin, AG Charlottenburg, 89 HRB 5583

Postadresse:
Hahn-Meitner-Platz 1
D-14109 Berlin

http://www.helmholtz-berlin.de


[ccp4bb] XDS Gui license expired?

2017-01-09 Thread Susan Kathleen Fetics
Hello,


I was trying to open XDS gui in Linux and it would not work. I was given the 
notice "Sorry, license expired Sept 30, 2016" with no other options as far as I 
could tell. How can I correct this so XDS gui works again?


Thanks in advance,


- Susan


Re: [ccp4bb] XDS questions

2016-12-03 Thread Jan Stransky
I had some cases, when path INTEGRATE.HKL -> Aimless gave data, from 
which it was not possible to solve structure by Phaser. It looked like 
structure solved, but then I got 45-50% Rwork/free. There were no 
problems with XDS_ASCCI.HKL -> Aimless (Not scale, just merge) path.

Jan

On 11/24/2016 06:44 PM, Nishant Varshney wrote:

Thanks everyone  for your replies.
cheers
Nishant

On Mon, Nov 21, 2016 at 6:03 PM, Wei Wang > wrote:


My personal test shows that the different paths vary little with
each other, as long as the scaling is done only once. Another way
could be what is said on XDSwiki: Minimum I/Sigma=50,
CORRECTIONS=MODULATION, NBATCH=1. Then the XDS_ASCII.HKL is handed
over to Aimless with default settings.

One question raised is that how can I move the 'aliens' with Z>20
to REMOVE.HKL? I didn't find answer yet. Maybe I didn't read
carefully over the documents, but I would appreciate it if someone
can teach me.

Regards,

Wei


On Mon, Nov 21, 2016 at 6:13 AM, Tim Gruene > wrote:

Dear Nishant,

XDS_ASCII.HKL contains corrected, scaled, but not merged
reflections.
You can specifically ask XDS to merge your data, but I would
not do so unless
really necessary - you loose a lot of information.

I would like to offer a different opinion to Graeme's:
You can read XDS_ASCII.HKL into pointless and aimless and
provide aimless with
the option 'onlymerge'. This way aimless merges the data, but
it does not
rescale them.

XDS performs a couple of corrections in the CORRECT step, the
output of which
is XDS_ASCII.HKL. And while XDS is extremely well documented,
I am not sure
aimless takes into account how XDS treats the data. I would
therefore trust
the step of scaling to the same author and continue with
XDS_ASCII.HKL.

Best,
Tim


On Monday, November 21, 2016 11:37:15 AM Nishant Varshney wrote:
> Dear All,
>
> Just to understand more, the XDS_ASCII.HKL file generated
after running XDS
> contains scaled and merged reflections?
>
> Moreover, what happens exactly, if you use XDS_ASCII.HKL
file in AIMLESS
> instead of INTEGRATE.HKL file??
>
> I ran AIMLESS separately, one using already scaled
XDS_ASCII.HKL and
> another using INTEGRATE.HKL and I found that in the run
using XDS_ASCII.HKL
> little lesser total number of observation but marginally
better statistics.
>
> Thanks
> Nishant
>
> On Thu, Nov 17, 2016 at 10:08 PM, Andreas Forster
>
>
> wrote:
> > Dear Wei,
> >
> > if you process your data with XDS, the best is probably to
do the scaling
> > in XDS (CORRECT) and be done with it.  If you want to use
Aimless for
> > merging, you can turn off scaling with the ONLYMERGE
keyword or use SCALES
> > CONSTANT.
> >
> > All best.
> >
> >
> > Andreas
> >
> > On Thu, Nov 17, 2016 at 9:40 PM, Wei Wang
> wrote:
> >> Hi,
> >>
> >> Is there a way to let xds_par use less than all
processors/threads on the
> >> machine? Sometimes I would like to process something else
while XDS is
> >> running.
> >>
> >> Another question is related to the scaling procedure. My
understanding is
> >> that the XDS already does the scaling during correction.
So if I follow
> >> the
> >> XDS-Aimless route, then probably I should let Aimless do
"skip scaling
> >> and
> >> only merge"? Please elucidate me on this issue.
> >>
> >> Regards,
> >>
> >> Wei
>
> --
> Dr. Nishant Kumar Varshney,
> IISc-ICTP Fellow
> XRD2 Beamline, Elettra-Sincrotrone,
> In Area Science Park,
> Basovizza, S.S. 14, Km 163,5,
> 34012 Trieste, Italy
> +39-040-375 8737  (office ESP4 P1 031)
> +39-040-375-8435  (XRD2 beamline)
> +39 3318809798  (Mobile)
--
--
Paul Scherrer Institut
Dr. Tim Gruene
- persoenlich -
Principal Investigator
Biology and Chemistry
OFLC/102
CH-5232 Villigen PSI

Phone: +41 (0)56 310 5297 

GPG Key ID = A46BEE1A





--
Dr. Nishant Kumar Varshney,
IISc-ICTP 

Re: [ccp4bb] XDS questions

2016-11-24 Thread Nishant Varshney
Thanks everyone  for your replies.
cheers
Nishant

On Mon, Nov 21, 2016 at 6:03 PM, Wei Wang  wrote:

> My personal test shows that the different paths vary little with each
> other, as long as the scaling is done only once. Another way could be what
> is said on XDSwiki: Minimum I/Sigma=50, CORRECTIONS=MODULATION, NBATCH=1.
> Then the XDS_ASCII.HKL is handed over to Aimless with default settings.
>
> One question raised is that how can I move the 'aliens' with Z>20 to
> REMOVE.HKL? I didn't find answer yet. Maybe I didn't read carefully over
> the documents, but I would appreciate it if someone can teach me.
>
> Regards,
>
> Wei
>
>
> On Mon, Nov 21, 2016 at 6:13 AM, Tim Gruene  wrote:
>
>> Dear Nishant,
>>
>> XDS_ASCII.HKL contains corrected, scaled, but not merged reflections.
>> You can specifically ask XDS to merge your data, but I would not do so
>> unless
>> really necessary - you loose a lot of information.
>>
>> I would like to offer a different opinion to Graeme's:
>> You can read XDS_ASCII.HKL into pointless and aimless and provide aimless
>> with
>> the option 'onlymerge'. This way aimless merges the data, but it does not
>> rescale them.
>>
>> XDS performs a couple of corrections in the CORRECT step, the output of
>> which
>> is XDS_ASCII.HKL. And while XDS is extremely well documented, I am not
>> sure
>> aimless takes into account how XDS treats the data. I would therefore
>> trust
>> the step of scaling to the same author and continue with XDS_ASCII.HKL.
>>
>> Best,
>> Tim
>>
>>
>> On Monday, November 21, 2016 11:37:15 AM Nishant Varshney wrote:
>> > Dear All,
>> >
>> > Just to understand more, the XDS_ASCII.HKL file generated after running
>> XDS
>> > contains scaled and merged reflections?
>> >
>> > Moreover, what happens exactly, if you use XDS_ASCII.HKL file in AIMLESS
>> > instead of INTEGRATE.HKL file??
>> >
>> > I ran AIMLESS separately, one using already scaled XDS_ASCII.HKL and
>> > another using INTEGRATE.HKL and I found that in the run using
>> XDS_ASCII.HKL
>> > little lesser total number of observation but marginally better
>> statistics.
>> >
>> > Thanks
>> > Nishant
>> >
>> > On Thu, Nov 17, 2016 at 10:08 PM, Andreas Forster > >
>> >
>> > wrote:
>> > > Dear Wei,
>> > >
>> > > if you process your data with XDS, the best is probably to do the
>> scaling
>> > > in XDS (CORRECT) and be done with it.  If you want to use Aimless for
>> > > merging, you can turn off scaling with the ONLYMERGE keyword or use
>> SCALES
>> > > CONSTANT.
>> > >
>> > > All best.
>> > >
>> > >
>> > > Andreas
>> > >
>> > > On Thu, Nov 17, 2016 at 9:40 PM, Wei Wang 
>> wrote:
>> > >> Hi,
>> > >>
>> > >> Is there a way to let xds_par use less than all processors/threads
>> on the
>> > >> machine? Sometimes I would like to process something else while XDS
>> is
>> > >> running.
>> > >>
>> > >> Another question is related to the scaling procedure. My
>> understanding is
>> > >> that the XDS already does the scaling during correction. So if I
>> follow
>> > >> the
>> > >> XDS-Aimless route, then probably I should let Aimless do "skip
>> scaling
>> > >> and
>> > >> only merge"? Please elucidate me on this issue.
>> > >>
>> > >> Regards,
>> > >>
>> > >> Wei
>> >
>> > --
>> > Dr. Nishant Kumar Varshney,
>> > IISc-ICTP Fellow
>> > XRD2 Beamline, Elettra-Sincrotrone,
>> > In Area Science Park,
>> > Basovizza, S.S. 14, Km 163,5,
>> > 34012 Trieste, Italy
>> > +39-040-375 8737 (office ESP4 P1 031)
>> > +39-040-375-8435 (XRD2 beamline)
>> > +39 3318809798 (Mobile)
>> --
>> --
>> Paul Scherrer Institut
>> Dr. Tim Gruene
>> - persoenlich -
>> Principal Investigator
>> Biology and Chemistry
>> OFLC/102
>> CH-5232 Villigen PSI
>>
>> Phone: +41 (0)56 310 5297
>>
>> GPG Key ID = A46BEE1A
>>
>>
>


-- 
Dr. Nishant Kumar Varshney,
IISc-ICTP Fellow
XRD2 Beamline, Elettra-Sincrotrone,
In Area Science Park,
Basovizza, S.S. 14, Km 163,5,
34012 Trieste, Italy
+39-040-375 8737 (office ESP4 P1 031)
+39-040-375-8435 (XRD2 beamline)
+39 3318809798 (Mobile)


Re: [ccp4bb] XDS questions

2016-11-21 Thread Boaz Shaanan



Hi,



I do this by editor (and cut / paste). Clumsy but works. Let me know if you find a more elegant way.
Cheers,
Boaz


 Original message 
From: Wei Wang <ww2...@columbia.edu> 
Date: 21/11/2016 19:05 (GMT+02:00) 
To: CCP4BB@JISCMAIL.AC.UK 
Subject: Re: [ccp4bb] XDS questions 





My personal test shows that the different paths vary little with each other, as long as the scaling is done only once. Another way could be what is said on XDSwiki: Minimum I/Sigma=50, CORRECTIONS=MODULATION, NBATCH=1. Then the XDS_ASCII.HKL is handed
 over to Aimless with default settings.


One question raised is that how can I move the 'aliens' with Z>20 to REMOVE.HKL? I didn't find answer yet. Maybe I didn't read carefully over the documents, but I would appreciate it if someone can teach me.


Regards,


Wei





On Mon, Nov 21, 2016 at 6:13 AM, Tim Gruene 
<tim.gru...@psi.ch> wrote:

Dear Nishant,

XDS_ASCII.HKL contains corrected, scaled, but not merged reflections.
You can specifically ask XDS to merge your data, but I would not do so unless
really necessary - you loose a lot of information.

I would like to offer a different opinion to Graeme's:
You can read XDS_ASCII.HKL into pointless and aimless and provide aimless with
the option 'onlymerge'. This way aimless merges the data, but it does not
rescale them.

XDS performs a couple of corrections in the CORRECT step, the output of which
is XDS_ASCII.HKL. And while XDS is extremely well documented, I am not sure
aimless takes into account how XDS treats the data. I would therefore trust
the step of scaling to the same author and continue with XDS_ASCII.HKL.

Best,
Tim



On Monday, November 21, 2016 11:37:15 AM Nishant Varshney wrote:
> Dear All,
>
> Just to understand more, the XDS_ASCII.HKL file generated after running XDS
> contains scaled and merged reflections?
>
> Moreover, what happens exactly, if you use XDS_ASCII.HKL file in AIMLESS
> instead of INTEGRATE.HKL file??
>
> I ran AIMLESS separately, one using already scaled XDS_ASCII.HKL and
> another using INTEGRATE.HKL and I found that in the run using XDS_ASCII.HKL
> little lesser total number of observation but marginally better statistics.
>
> Thanks
> Nishant
>
> On Thu, Nov 17, 2016 at 10:08 PM, Andreas Forster <docandr...@gmail.com>
>
> wrote:
> > Dear Wei,
> >
> > if you process your data with XDS, the best is probably to do the scaling
> > in XDS (CORRECT) and be done with it.  If you want to use Aimless for
> > merging, you can turn off scaling with the ONLYMERGE keyword or use SCALES
> > CONSTANT.
> >
> > All best.
> >
> >
> > Andreas
> >
> > On Thu, Nov 17, 2016 at 9:40 PM, Wei Wang <ww2...@columbia.edu> wrote:
> >> Hi,
> >>
> >> Is there a way to let xds_par use less than all processors/threads on the
> >> machine? Sometimes I would like to process something else while XDS is
> >> running.
> >>
> >> Another question is related to the scaling procedure. My understanding is
> >> that the XDS already does the scaling during correction. So if I follow
> >> the
> >> XDS-Aimless route, then probably I should let Aimless do "skip scaling
> >> and
> >> only merge"? Please elucidate me on this issue.
> >>
> >> Regards,
> >>
> >> Wei
>
> --
> Dr. Nishant Kumar Varshney,
> IISc-ICTP Fellow
> XRD2 Beamline, Elettra-Sincrotrone,
> In Area Science Park,
> Basovizza, S.S. 14, Km 163,5,
> 34012 Trieste, Italy
> +39-040-375 8737 (office ESP4 P1 031)
> +39-040-375-8435 (XRD2 beamline)
> +39 3318809798 (Mobile)


--
--
Paul Scherrer Institut
Dr. Tim Gruene
- persoenlich -
Principal Investigator
Biology and Chemistry
OFLC/102
CH-5232 Villigen PSI

Phone: +41 (0)56 310 5297

GPG Key ID = A46BEE1A















Re: [ccp4bb] XDS questions

2016-11-21 Thread Wei Wang
My personal test shows that the different paths vary little with each
other, as long as the scaling is done only once. Another way could be what
is said on XDSwiki: Minimum I/Sigma=50, CORRECTIONS=MODULATION, NBATCH=1.
Then the XDS_ASCII.HKL is handed over to Aimless with default settings.

One question raised is that how can I move the 'aliens' with Z>20 to
REMOVE.HKL? I didn't find answer yet. Maybe I didn't read carefully over
the documents, but I would appreciate it if someone can teach me.

Regards,

Wei

On Mon, Nov 21, 2016 at 6:13 AM, Tim Gruene  wrote:

> Dear Nishant,
>
> XDS_ASCII.HKL contains corrected, scaled, but not merged reflections.
> You can specifically ask XDS to merge your data, but I would not do so
> unless
> really necessary - you loose a lot of information.
>
> I would like to offer a different opinion to Graeme's:
> You can read XDS_ASCII.HKL into pointless and aimless and provide aimless
> with
> the option 'onlymerge'. This way aimless merges the data, but it does not
> rescale them.
>
> XDS performs a couple of corrections in the CORRECT step, the output of
> which
> is XDS_ASCII.HKL. And while XDS is extremely well documented, I am not sure
> aimless takes into account how XDS treats the data. I would therefore trust
> the step of scaling to the same author and continue with XDS_ASCII.HKL.
>
> Best,
> Tim
>
>
> On Monday, November 21, 2016 11:37:15 AM Nishant Varshney wrote:
> > Dear All,
> >
> > Just to understand more, the XDS_ASCII.HKL file generated after running
> XDS
> > contains scaled and merged reflections?
> >
> > Moreover, what happens exactly, if you use XDS_ASCII.HKL file in AIMLESS
> > instead of INTEGRATE.HKL file??
> >
> > I ran AIMLESS separately, one using already scaled XDS_ASCII.HKL and
> > another using INTEGRATE.HKL and I found that in the run using
> XDS_ASCII.HKL
> > little lesser total number of observation but marginally better
> statistics.
> >
> > Thanks
> > Nishant
> >
> > On Thu, Nov 17, 2016 at 10:08 PM, Andreas Forster 
> >
> > wrote:
> > > Dear Wei,
> > >
> > > if you process your data with XDS, the best is probably to do the
> scaling
> > > in XDS (CORRECT) and be done with it.  If you want to use Aimless for
> > > merging, you can turn off scaling with the ONLYMERGE keyword or use
> SCALES
> > > CONSTANT.
> > >
> > > All best.
> > >
> > >
> > > Andreas
> > >
> > > On Thu, Nov 17, 2016 at 9:40 PM, Wei Wang  wrote:
> > >> Hi,
> > >>
> > >> Is there a way to let xds_par use less than all processors/threads on
> the
> > >> machine? Sometimes I would like to process something else while XDS is
> > >> running.
> > >>
> > >> Another question is related to the scaling procedure. My
> understanding is
> > >> that the XDS already does the scaling during correction. So if I
> follow
> > >> the
> > >> XDS-Aimless route, then probably I should let Aimless do "skip scaling
> > >> and
> > >> only merge"? Please elucidate me on this issue.
> > >>
> > >> Regards,
> > >>
> > >> Wei
> >
> > --
> > Dr. Nishant Kumar Varshney,
> > IISc-ICTP Fellow
> > XRD2 Beamline, Elettra-Sincrotrone,
> > In Area Science Park,
> > Basovizza, S.S. 14, Km 163,5,
> > 34012 Trieste, Italy
> > +39-040-375 8737 (office ESP4 P1 031)
> > +39-040-375-8435 (XRD2 beamline)
> > +39 3318809798 (Mobile)
> --
> --
> Paul Scherrer Institut
> Dr. Tim Gruene
> - persoenlich -
> Principal Investigator
> Biology and Chemistry
> OFLC/102
> CH-5232 Villigen PSI
>
> Phone: +41 (0)56 310 5297
>
> GPG Key ID = A46BEE1A
>
>


Re: [ccp4bb] XDS questions

2016-11-21 Thread Phil Evans
XDS-CORRECT and Aimless use 

1. different scaling models - CORRECT includes a poorly documented correction 
across the detector plane not present in Aimless: this may or may not be a Good 
Thing

2. different outlier rejection algorithms - XDS seems to reject more 
observations

3. different “correction” of the sigma(I) estimates - XDS seems to do a better 
job at this

In practice, the differences are likely to be marginal, and it is hard to 
decide which is better

Phil

> On 21 Nov 2016, at 11:13, Tim Gruene  wrote:
> 
> Dear Nishant,
> 
> XDS_ASCII.HKL contains corrected, scaled, but not merged reflections. 
> You can specifically ask XDS to merge your data, but I would not do so unless 
> really necessary - you loose a lot of information.
> 
> I would like to offer a different opinion to Graeme's:
> You can read XDS_ASCII.HKL into pointless and aimless and provide aimless 
> with 
> the option 'onlymerge'. This way aimless merges the data, but it does not 
> rescale them.
> 
> XDS performs a couple of corrections in the CORRECT step, the output of which 
> is XDS_ASCII.HKL. And while XDS is extremely well documented, I am not sure 
> aimless takes into account how XDS treats the data. I would therefore trust 
> the step of scaling to the same author and continue with XDS_ASCII.HKL.
> 
> Best,
> Tim
> 
> 
> On Monday, November 21, 2016 11:37:15 AM Nishant Varshney wrote:
>> Dear All,
>> 
>> Just to understand more, the XDS_ASCII.HKL file generated after running XDS
>> contains scaled and merged reflections?
>> 
>> Moreover, what happens exactly, if you use XDS_ASCII.HKL file in AIMLESS
>> instead of INTEGRATE.HKL file??
>> 
>> I ran AIMLESS separately, one using already scaled XDS_ASCII.HKL and
>> another using INTEGRATE.HKL and I found that in the run using XDS_ASCII.HKL
>> little lesser total number of observation but marginally better statistics.
>> 
>> Thanks
>> Nishant
>> 
>> On Thu, Nov 17, 2016 at 10:08 PM, Andreas Forster 
>> 
>> wrote:
>>> Dear Wei,
>>> 
>>> if you process your data with XDS, the best is probably to do the scaling
>>> in XDS (CORRECT) and be done with it.  If you want to use Aimless for
>>> merging, you can turn off scaling with the ONLYMERGE keyword or use SCALES
>>> CONSTANT.
>>> 
>>> All best.
>>> 
>>> 
>>> Andreas
>>> 
>>> On Thu, Nov 17, 2016 at 9:40 PM, Wei Wang  wrote:
 Hi,
 
 Is there a way to let xds_par use less than all processors/threads on the
 machine? Sometimes I would like to process something else while XDS is
 running.
 
 Another question is related to the scaling procedure. My understanding is
 that the XDS already does the scaling during correction. So if I follow
 the
 XDS-Aimless route, then probably I should let Aimless do "skip scaling
 and
 only merge"? Please elucidate me on this issue.
 
 Regards,
 
 Wei
>> 
>> --
>> Dr. Nishant Kumar Varshney,
>> IISc-ICTP Fellow
>> XRD2 Beamline, Elettra-Sincrotrone,
>> In Area Science Park,
>> Basovizza, S.S. 14, Km 163,5,
>> 34012 Trieste, Italy
>> +39-040-375 8737 (office ESP4 P1 031)
>> +39-040-375-8435 (XRD2 beamline)
>> +39 3318809798 (Mobile)
> -- 
> --
> Paul Scherrer Institut
> Dr. Tim Gruene
> - persoenlich -
> Principal Investigator
> Biology and Chemistry
> OFLC/102
> CH-5232 Villigen PSI
> 
> Phone: +41 (0)56 310 5297
> 
> GPG Key ID = A46BEE1A
> 


Re: [ccp4bb] XDS questions

2016-11-21 Thread Graeme Winter
Dear All,

I agree with Tim - what I was getting at was to perform the scaling exactly 
once - i.e. with AIMLESS or XDS CORRECT but not both

The behaviour Tim describes below is exactly what xia2 does :)

Best wishes Graeme

-Original Message-
From: CCP4 bulletin board [mailto:CCP4BB@JISCMAIL.AC.UK] On Behalf Of Tim Gruene
Sent: 21 November 2016 11:14
To: ccp4bb
Subject: Re: [ccp4bb] XDS questions

Dear Nishant,

XDS_ASCII.HKL contains corrected, scaled, but not merged reflections. 
You can specifically ask XDS to merge your data, but I would not do so unless 
really necessary - you loose a lot of information.

I would like to offer a different opinion to Graeme's:
You can read XDS_ASCII.HKL into pointless and aimless and provide aimless with 
the option 'onlymerge'. This way aimless merges the data, but it does not 
rescale them.

XDS performs a couple of corrections in the CORRECT step, the output of which 
is XDS_ASCII.HKL. And while XDS is extremely well documented, I am not sure 
aimless takes into account how XDS treats the data. I would therefore trust the 
step of scaling to the same author and continue with XDS_ASCII.HKL.

Best,
Tim


On Monday, November 21, 2016 11:37:15 AM Nishant Varshney wrote:
> Dear All,
> 
> Just to understand more, the XDS_ASCII.HKL file generated after 
> running XDS contains scaled and merged reflections?
> 
> Moreover, what happens exactly, if you use XDS_ASCII.HKL file in 
> AIMLESS instead of INTEGRATE.HKL file??
> 
> I ran AIMLESS separately, one using already scaled XDS_ASCII.HKL and 
> another using INTEGRATE.HKL and I found that in the run using 
> XDS_ASCII.HKL little lesser total number of observation but marginally better 
> statistics.
> 
> Thanks
> Nishant
> 
> On Thu, Nov 17, 2016 at 10:08 PM, Andreas Forster 
> <docandr...@gmail.com>
> 
> wrote:
> > Dear Wei,
> > 
> > if you process your data with XDS, the best is probably to do the 
> > scaling in XDS (CORRECT) and be done with it.  If you want to use 
> > Aimless for merging, you can turn off scaling with the ONLYMERGE 
> > keyword or use SCALES CONSTANT.
> > 
> > All best.
> > 
> > 
> > Andreas
> > 
> > On Thu, Nov 17, 2016 at 9:40 PM, Wei Wang <ww2...@columbia.edu> wrote:
> >> Hi,
> >> 
> >> Is there a way to let xds_par use less than all processors/threads 
> >> on the machine? Sometimes I would like to process something else 
> >> while XDS is running.
> >> 
> >> Another question is related to the scaling procedure. My 
> >> understanding is that the XDS already does the scaling during 
> >> correction. So if I follow the XDS-Aimless route, then probably I 
> >> should let Aimless do "skip scaling and only merge"? Please 
> >> elucidate me on this issue.
> >> 
> >> Regards,
> >> 
> >> Wei
> 
> --
> Dr. Nishant Kumar Varshney,
> IISc-ICTP Fellow
> XRD2 Beamline, Elettra-Sincrotrone,
> In Area Science Park,
> Basovizza, S.S. 14, Km 163,5,
> 34012 Trieste, Italy
> +39-040-375 8737 (office ESP4 P1 031)
> +39-040-375-8435 (XRD2 beamline)
> +39 3318809798 (Mobile)
--
--
Paul Scherrer Institut
Dr. Tim Gruene
- persoenlich -
Principal Investigator
Biology and Chemistry
OFLC/102
CH-5232 Villigen PSI

Phone: +41 (0)56 310 5297

GPG Key ID = A46BEE1A


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

2016-11-21 Thread Tim Gruene
Dear Nishant,

XDS_ASCII.HKL contains corrected, scaled, but not merged reflections. 
You can specifically ask XDS to merge your data, but I would not do so unless 
really necessary - you loose a lot of information.

I would like to offer a different opinion to Graeme's:
You can read XDS_ASCII.HKL into pointless and aimless and provide aimless with 
the option 'onlymerge'. This way aimless merges the data, but it does not 
rescale them.

XDS performs a couple of corrections in the CORRECT step, the output of which 
is XDS_ASCII.HKL. And while XDS is extremely well documented, I am not sure 
aimless takes into account how XDS treats the data. I would therefore trust 
the step of scaling to the same author and continue with XDS_ASCII.HKL.

Best,
Tim


On Monday, November 21, 2016 11:37:15 AM Nishant Varshney wrote:
> Dear All,
> 
> Just to understand more, the XDS_ASCII.HKL file generated after running XDS
> contains scaled and merged reflections?
> 
> Moreover, what happens exactly, if you use XDS_ASCII.HKL file in AIMLESS
> instead of INTEGRATE.HKL file??
> 
> I ran AIMLESS separately, one using already scaled XDS_ASCII.HKL and
> another using INTEGRATE.HKL and I found that in the run using XDS_ASCII.HKL
> little lesser total number of observation but marginally better statistics.
> 
> Thanks
> Nishant
> 
> On Thu, Nov 17, 2016 at 10:08 PM, Andreas Forster 
> 
> wrote:
> > Dear Wei,
> > 
> > if you process your data with XDS, the best is probably to do the scaling
> > in XDS (CORRECT) and be done with it.  If you want to use Aimless for
> > merging, you can turn off scaling with the ONLYMERGE keyword or use SCALES
> > CONSTANT.
> > 
> > All best.
> > 
> > 
> > Andreas
> > 
> > On Thu, Nov 17, 2016 at 9:40 PM, Wei Wang  wrote:
> >> Hi,
> >> 
> >> Is there a way to let xds_par use less than all processors/threads on the
> >> machine? Sometimes I would like to process something else while XDS is
> >> running.
> >> 
> >> Another question is related to the scaling procedure. My understanding is
> >> that the XDS already does the scaling during correction. So if I follow
> >> the
> >> XDS-Aimless route, then probably I should let Aimless do "skip scaling
> >> and
> >> only merge"? Please elucidate me on this issue.
> >> 
> >> Regards,
> >> 
> >> Wei
> 
> --
> Dr. Nishant Kumar Varshney,
> IISc-ICTP Fellow
> XRD2 Beamline, Elettra-Sincrotrone,
> In Area Science Park,
> Basovizza, S.S. 14, Km 163,5,
> 34012 Trieste, Italy
> +39-040-375 8737 (office ESP4 P1 031)
> +39-040-375-8435 (XRD2 beamline)
> +39 3318809798 (Mobile)
-- 
--
Paul Scherrer Institut
Dr. Tim Gruene
- persoenlich -
Principal Investigator
Biology and Chemistry
OFLC/102
CH-5232 Villigen PSI

Phone: +41 (0)56 310 5297

GPG Key ID = A46BEE1A



signature.asc
Description: This is a digitally signed message part.


Re: [ccp4bb] XDS questions

2016-11-21 Thread Graeme Winter
Dear Nishant

Your statistics will be better taking XDS_ASCII because the scaling has been 
performed twice i.e. you have had two goes (with different models) of reducing 
the differences between reflections. This will *always* make the R factors etc 
smaller – whether the data are better or more true is a matter for debate!

Personally I would recommend not doing this however I gather that there are 
folks who feel scaling twice is a good thing, so your mileage may vary. If 
differences are marginal I would suggest taking the most simply treated data 
i.e. INTEGRATE.HKL -> aimless

Best wishes Graeme

From: CCP4 bulletin board [mailto:CCP4BB@JISCMAIL.AC.UK] On Behalf Of Nishant 
Varshney
Sent: 21 November 2016 10:37
To: ccp4bb
Subject: Re: [ccp4bb] XDS questions

Dear All,

Just to understand more, the XDS_ASCII.HKL file generated after running XDS 
contains scaled and merged reflections?

Moreover, what happens exactly, if you use XDS_ASCII.HKL file in AIMLESS 
instead of INTEGRATE.HKL file??

I ran AIMLESS separately, one using already scaled XDS_ASCII.HKL and another 
using INTEGRATE.HKL and I found that in the run using XDS_ASCII.HKL little 
lesser total number of observation but marginally better statistics.

Thanks
Nishant

On Thu, Nov 17, 2016 at 10:08 PM, Andreas Forster 
<docandr...@gmail.com<mailto:docandr...@gmail.com>> wrote:
Dear Wei,

if you process your data with XDS, the best is probably to do the scaling in 
XDS (CORRECT) and be done with it.  If you want to use Aimless for merging, you 
can turn off scaling with the ONLYMERGE keyword or use SCALES CONSTANT.

All best.


Andreas




On Thu, Nov 17, 2016 at 9:40 PM, Wei Wang 
<ww2...@columbia.edu<mailto:ww2...@columbia.edu>> wrote:
Hi,
Is there a way to let xds_par use less than all processors/threads on the 
machine? Sometimes I would like to process something else while XDS is running.
Another question is related to the scaling procedure. My understanding is that 
the XDS already does the scaling during correction. So if I follow the 
XDS-Aimless route, then probably I should let Aimless do "skip scaling and only 
merge"? Please elucidate me on this issue.
Regards,
Wei




--
Dr. Nishant Kumar Varshney,
IISc-ICTP Fellow
XRD2 Beamline, Elettra-Sincrotrone,
In Area Science Park,
Basovizza, S.S. 14, Km 163,5,
34012 Trieste, Italy
+39-040-375 8737 (office ESP4 P1 031)
+39-040-375-8435 (XRD2 beamline)
+39 3318809798 (Mobile)

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

2016-11-21 Thread Nishant Varshney
Dear All,

Just to understand more, the XDS_ASCII.HKL file generated after running XDS
contains scaled and merged reflections?

Moreover, what happens exactly, if you use XDS_ASCII.HKL file in AIMLESS
instead of INTEGRATE.HKL file??

I ran AIMLESS separately, one using already scaled XDS_ASCII.HKL and
another using INTEGRATE.HKL and I found that in the run using XDS_ASCII.HKL
little lesser total number of observation but marginally better statistics.

Thanks
Nishant

On Thu, Nov 17, 2016 at 10:08 PM, Andreas Forster 
wrote:

> Dear Wei,
>
> if you process your data with XDS, the best is probably to do the scaling
> in XDS (CORRECT) and be done with it.  If you want to use Aimless for
> merging, you can turn off scaling with the ONLYMERGE keyword or use SCALES
> CONSTANT.
>
> All best.
>
>
> Andreas
>
>
>
>
> On Thu, Nov 17, 2016 at 9:40 PM, Wei Wang  wrote:
>
>> Hi,
>>
>> Is there a way to let xds_par use less than all processors/threads on the
>> machine? Sometimes I would like to process something else while XDS is
>> running.
>>
>> Another question is related to the scaling procedure. My understanding is
>> that the XDS already does the scaling during correction. So if I follow the
>> XDS-Aimless route, then probably I should let Aimless do "skip scaling and
>> only merge"? Please elucidate me on this issue.
>>
>> Regards,
>>
>> Wei
>>
>
>


-- 
Dr. Nishant Kumar Varshney,
IISc-ICTP Fellow
XRD2 Beamline, Elettra-Sincrotrone,
In Area Science Park,
Basovizza, S.S. 14, Km 163,5,
34012 Trieste, Italy
+39-040-375 8737 (office ESP4 P1 031)
+39-040-375-8435 (XRD2 beamline)
+39 3318809798 (Mobile)


Re: [ccp4bb] XDS questions

2016-11-17 Thread Wei Wang
Thanks everyone for answering the question!

Best,

Wei

On Thu, Nov 17, 2016 at 4:20 PM, Michael Martynowycz <
michael.martynow...@gmail.com> wrote:

> Wei,
>
> You can use the integrated integrated intensities only if you want to go
> the ccp4 route. Sort the integrated reflections, then scale and truncate
> them using:
>
> Pointless xdsin INTEGRATE.HKL hklout sorted.mtz
>
> Aimless hklin sorted.mtz hklout scaled.mtz
>
> Hope that helps.
>
> -Mike
>
> Sent from my iPhone
>
> On Nov 17, 2016, at 4:08 PM, Andreas Forster  > wrote:
>
> Dear Wei,
>
> if you process your data with XDS, the best is probably to do the scaling
> in XDS (CORRECT) and be done with it.  If you want to use Aimless for
> merging, you can turn off scaling with the ONLYMERGE keyword or use SCALES
> CONSTANT.
>
> All best.
>
>
> Andreas
>
>
>
>
> On Thu, Nov 17, 2016 at 9:40 PM, Wei Wang  wrote:
>
>> Hi,
>>
>> Is there a way to let xds_par use less than all processors/threads on the
>> machine? Sometimes I would like to process something else while XDS is
>> running.
>>
>> Another question is related to the scaling procedure. My understanding is
>> that the XDS already does the scaling during correction. So if I follow the
>> XDS-Aimless route, then probably I should let Aimless do "skip scaling and
>> only merge"? Please elucidate me on this issue.
>>
>> Regards,
>>
>> Wei
>>
>
>


Re: [ccp4bb] XDS questions

2016-11-17 Thread Michael Martynowycz
Wei,

You can use the integrated integrated intensities only if you want to go the 
ccp4 route. Sort the integrated reflections, then scale and truncate them using:

Pointless xdsin INTEGRATE.HKL hklout sorted.mtz

Aimless hklin sorted.mtz hklout scaled.mtz

Hope that helps.

-Mike

Sent from my iPhone

> On Nov 17, 2016, at 4:08 PM, Andreas Forster  wrote:
> 
> Dear Wei,
> 
> if you process your data with XDS, the best is probably to do the scaling in 
> XDS (CORRECT) and be done with it.  If you want to use Aimless for merging, 
> you can turn off scaling with the ONLYMERGE keyword or use SCALES CONSTANT.
> 
> All best.
> 
> 
> Andreas
> 
> 
>  
> 
>> On Thu, Nov 17, 2016 at 9:40 PM, Wei Wang  wrote:
>> Hi,
>> 
>> Is there a way to let xds_par use less than all processors/threads on the 
>> machine? Sometimes I would like to process something else while XDS is 
>> running.
>> 
>> Another question is related to the scaling procedure. My understanding is 
>> that the XDS already does the scaling during correction. So if I follow the 
>> XDS-Aimless route, then probably I should let Aimless do "skip scaling and 
>> only merge"? Please elucidate me on this issue.
>> 
>> Regards,
>> 
>> Wei
> 


Re: [ccp4bb] XDS questions

2016-11-17 Thread Andreas Forster
Dear Wei,

if you process your data with XDS, the best is probably to do the scaling
in XDS (CORRECT) and be done with it.  If you want to use Aimless for
merging, you can turn off scaling with the ONLYMERGE keyword or use SCALES
CONSTANT.

All best.


Andreas




On Thu, Nov 17, 2016 at 9:40 PM, Wei Wang  wrote:

> Hi,
>
> Is there a way to let xds_par use less than all processors/threads on the
> machine? Sometimes I would like to process something else while XDS is
> running.
>
> Another question is related to the scaling procedure. My understanding is
> that the XDS already does the scaling during correction. So if I follow the
> XDS-Aimless route, then probably I should let Aimless do "skip scaling and
> only merge"? Please elucidate me on this issue.
>
> Regards,
>
> Wei
>


Re: [ccp4bb] XDS questions

2016-11-17 Thread Jim Fairman
Wei,

The flag MAXIMUM_NUMBER_OF_PROCESSORS=

in XDS.INP should allow you to choose the number of processors you wish to
use.

Cheers, Jim

--
Jim Fairman
C: 1-240-479-6575

On Thu, Nov 17, 2016 at 12:40 PM, Wei Wang  wrote:

> Hi,
>
> Is there a way to let xds_par use less than all processors/threads on the
> machine? Sometimes I would like to process something else while XDS is
> running.
>
> Another question is related to the scaling procedure. My understanding is
> that the XDS already does the scaling during correction. So if I follow the
> XDS-Aimless route, then probably I should let Aimless do "skip scaling and
> only merge"? Please elucidate me on this issue.
>
> Regards,
>
> Wei
>


[ccp4bb] XDS questions

2016-11-17 Thread Wei Wang
Hi,

Is there a way to let xds_par use less than all processors/threads on the
machine? Sometimes I would like to process something else while XDS is
running.

Another question is related to the scaling procedure. My understanding is
that the XDS already does the scaling during correction. So if I follow the
XDS-Aimless route, then probably I should let Aimless do "skip scaling and
only merge"? Please elucidate me on this issue.

Regards,

Wei


Re: [ccp4bb] Fwd: [ccp4bb] XDS Rmeas in space group determination

2015-05-14 Thread Clemens Vonrhein
Dear Chen,

On Thu, May 14, 2015 at 10:05:05AM -0400, Chen Zhao wrote:
 Thanks a lot for your reply! I am a little surprised to learn that the
 centrosymmetry is always considered as a point groups symmetry component.
 That might explain why all the anomalous data I have seen have higher Rmeas
 than their native counterpart.

Somehow related: the fact that one can compute R-values ignoring
anomalous or taking it into account can actually be a good
thing. AIMLESS for example computes RmeasOv (ignoring anomalous) and
Rmeas (keeping I+ and I- separate) - if I understand that
correctly. You can use those two values as a function of resolution to
see up to which resolution you have anomalous signal, ie where RmeasOv
is still higher than Rmeas.

It doesn't necessarily give you new information compared to CCanom or
SigAno, but it is nice to have as another opinion I think.

Cheers

Clemens

-- 

***
* Clemens Vonrhein, Ph.D. vonrhein AT GlobalPhasing DOT com
*
*  Global Phasing Ltd.
*  Sheraton House, Castle Park 
*  Cambridge CB3 0AX, UK
*--
* BUSTER Development Group  (http://www.globalphasing.com)
***


Re: [ccp4bb] XDS Rmeas in space group determination

2015-05-14 Thread Kay Diederichs
Hi Chen,

if Rmeas is high (like 50 and up) even in P1 then maybe the integration was not 
right, or the indexing is offset by 1 in h or k or l ?

To check the former, look at FRAME.cbf and see if the predictions match the 
spots.

To test the latter try
echo CENTRE | pointless XDS_ASCII.HKL

best,

Kay

P.S. in XDS's space group determination, Friedels are indeed considered 
symmetry-related.

On Wed, 13 May 2015 19:24:30 -0400, Chen Zhao c.z...@yale.edu wrote:

 Hi Ethan,
 
 Thanks a lot for your detailed information. I am aware that in IDXREF only 
 the lattice symmetry was tried to be determined. I went back to check the 
 subtrees in IDXREF because even for P1 the Rmeas is very high, meaning that 
 the multiple measurements for the same reflections are already very 
 imprecise (test resolution 10-5). I therefore am worried about multiple 
 lattices. 
 
 Also related to the probability thing you talked about, there is no point 
 group has significantly low Rmeas in this case. Or it is just because even 
 P1 has high Rmeas, so that the highest point group tried were considered to 
 be correct? If so, it sounds hard to determine the point group in this 
 case...
 
 Thank you so much,
 Chen
 
 
 On May 13, 2015, at 6:48 PM, Ethan A Merritt merr...@u.washington.edu 
 wrote:
 
 On Wednesday, 13 May, 2015 18:17:04 Chen Zhao wrote:
 Hi Ethan,
 
 Sorry, I'm coming in late on this so I might have missed an
 earlier explanation of exactly what programs are involved.
 
 
 Yes. My question was simply whether it calculates the statistics
 
 from completely unmerged intensities and just compare say h,k,l with 
 -h,-k,l (or -h,-k,-l and h,k,-l) if there is a 2-fold? Although I believe 
 so...
 
 What is it?
 
 If you mean the tables in IDXREF.LP, they only report the fit of points
 to a particular lattice.  They do not compare the intensities of 
 potential symmetry mates.  Quoting from the program output:
 
 Note, that reflection integration is based only on orientation and metric
 of the lattice. It does not require knowledge of the correct space group!
 Thus, if no such information is provided by the user in XDS.INP,
 reflections are integrated assuming a triclinic reduced cell lattice;
 the space group is assigned automatically or by the user in the last
 step (CORRECT) when integrated intensities are available.
 
 If you mean the output from a later run of pointless/aimless,
 so far as I know it applies the symmetry operation being tested
 to all reflections, which means that Friedel/Bijvoet pairs are 
 not compared.  But I could be wrong on that point.
 
 And what is a good number? Is 20 % OK? What about 30 % and even higher?
 
 Still refering to output from pointless/aimless, the crucial point is not
 the absolute number but rather how the agreement for the symmetry operation
 being tested compares to the agreement for the identity operation.
 
 For example, here is the output for a lousy data set with a real 2-fold:
 
 %
 Scores for each symmetry element
 
 Nelmt  Lklhd  Z-ccCCN  RmeasSymmetry  operator (in Lattice 
 Cell)
 
 1   0.806   6.97   0.70   17852  0.516 identity
 2   0.919   7.67   0.77   21302  0.486 *** 2-fold k ( 0 1 0) {-h,k,-l}
 
 [snip]
 
  Laue Group   Lklhd   NetZc  Zc+   Zc-CCCC-  Rmeas   R-  Delta 
 ReindexOperator
 
 1  P 1 2/m 1  ***  0.919   7.30  7.30  0.00   0.73  0.00   0.50  0.00   0.1 
 [-h,-l,-k]
 2   P -1   0.081  -0.69  6.97  7.67   0.70  0.77   0.52  0.49   0.0 
 [h,-k,-l]
 %%
 
 In this case the program reports a 0.91 likelihood that the Laue
 group is P2 even though the Rmeas is horrible.
 
   Ethan
 
 
 Thanks a lot,
 Chen 
 
 
 On May 13, 2015, at 6:07 PM, Ethan A Merritt merr...@u.washington.edu 
 wrote:
 
 On Wednesday, 13 May, 2015 17:51:59 Chen Zhao wrote:
 Hi all,
 
 I am sorry about this question which I should have figured out earlier. 
 For
 point group determination, does the Rmeas consider Fridel pairs
 differently?
 
 A Friedel pair consists of the [hkl] and [-h-k-l] reflections.
 This pairing is independent of space group.
 So the agreement or lack of agreement between Friedel pairs is
 not informative about selection of point group or space group. 
 
 You may be thinking of a Bijvoet pair, which consists of 
 [hkl] and the Friedel mate of some symmetry equivalent of [hkl]
 within a particular spacegroup.
 
 But even in the presence of anomalous scattering I think that
 Bijvoet pairs are expected to agree with each other better than
 with a reflection not related by point group symmetry.
 
 (although I think it should be...) This is because I saw a
 derivative dataset collected at peak (from a demo) whose Rmeas is quite
 high (50 %) for all the space groups tested (including P1). However, the
 native dataset has only 10 % Rmeas. Should I worry about the derivative
 dataset? There seems to be multiple 

Re: [ccp4bb] XDS INP

2015-05-13 Thread Kay Diederichs
On Tue, 12 May 2015 17:24:18 -0500, Gerd Rosenbaum rosenb...@anl.gov wrote:

...
But no big deal. It's a -1 in one of the axes definitions. There are, as
you stated, many more axes definitions and they depend on the geometry
of the end station. E.g., at the SBC, the orientation of otherwise
identical goniostats is mirror-image between the ID and the BM for
reasons of layout of the two beamlines relative to each other. The idea
that the axes definitions should be uniform is not practical.


Yeah, in principle no big deal, I agree. But the mirror-image concept does not 
extend to everything: e.g. screws will still be right-handed in the mirror 
beamline, and motors (in vacuum pumps etc.) will rotate in a given direction in 
both the beamline and its mirror. Those motors that move devices up/down or 
left/right may require the other direction in the mirror beamline. The same is 
true for the spindle motor: if you don't reverse its direction in the mirror 
beamline, then a user will e.g. not be able to switch measurements of a mounted 
crystal easily between mirror-related beamlines: s/he will have to use 
different inputs to data processing programs, and will have to re-index.  
So yes, the principle is easy to understand, but to make users happy in 
practice, during beamline commissioning and setup of user operation a conscious 
decision can and should be made (and yes, I have talked to beamline people who 
were not aware of this). If that decision is reverse phi, ok, but this needs 
to be documented in an accessible way.

best,
Kay


[ccp4bb] XDS Rmeas in space group determination

2015-05-13 Thread Chen Zhao
Hi all,

I am sorry about this question which I should have figured out earlier. For
point group determination, does the Rmeas consider Fridel pairs
differently? (although I think it should be...) This is because I saw a
derivative dataset collected at peak (from a demo) whose Rmeas is quite
high (50 %) for all the space groups tested (including P1). However, the
native dataset has only 10 % Rmeas. Should I worry about the derivative
dataset? There seems to be multiple lattices in both datasets based on
IDXREF.

You inputs are really appreciated!

Sincerely,
Chen


Re: [ccp4bb] XDS Rmeas in space group determination

2015-05-13 Thread Chen Zhao
Hi Ethan,

Yes. My question was simply whether it calculates the statistics from 
completely unmerged intensities and just compare say h,k,l with -h,-k,l (or 
-h,-k,-l and h,k,-l) if there is a 2-fold? Although I believe so...

And what is a good number? Is 20 % OK? What about 30 % and even higher?

Thanks a lot,
Chen 


 On May 13, 2015, at 6:07 PM, Ethan A Merritt merr...@u.washington.edu wrote:
 
 On Wednesday, 13 May, 2015 17:51:59 Chen Zhao wrote:
 Hi all,
 
 I am sorry about this question which I should have figured out earlier. For
 point group determination, does the Rmeas consider Fridel pairs
 differently?
 
 A Friedel pair consists of the [hkl] and [-h-k-l] reflections.
 This pairing is independent of space group.
 So the agreement or lack of agreement between Friedel pairs is
 not informative about selection of point group or space group. 
 
 You may be thinking of a Bijvoet pair, which consists of 
 [hkl] and the Friedel mate of some symmetry equivalent of [hkl]
 within a particular spacegroup.
 
 But even in the presence of anomalous scattering I think that
 Bijvoet pairs are expected to agree with each other better than
 with a reflection not related by point group symmetry.
 
 (although I think it should be...) This is because I saw a
 derivative dataset collected at peak (from a demo) whose Rmeas is quite
 high (50 %) for all the space groups tested (including P1). However, the
 native dataset has only 10 % Rmeas. Should I worry about the derivative
 dataset? There seems to be multiple lattices in both datasets based on
 IDXREF.
 
 You inputs are really appreciated!
 
 Sincerely,
 Chen
 -- 
 Ethan A Merritt
 Biomolecular Structure Center,  K-428 Health Sciences Bldg
 MS 357742,   University of Washington, Seattle 98195-7742
 


Re: [ccp4bb] XDS Rmeas in space group determination

2015-05-13 Thread Ethan A Merritt
On Wednesday, 13 May, 2015 17:51:59 Chen Zhao wrote:
 Hi all,
 
 I am sorry about this question which I should have figured out earlier. For
 point group determination, does the Rmeas consider Fridel pairs
 differently?

A Friedel pair consists of the [hkl] and [-h-k-l] reflections.
This pairing is independent of space group.
So the agreement or lack of agreement between Friedel pairs is
not informative about selection of point group or space group. 

You may be thinking of a Bijvoet pair, which consists of 
[hkl] and the Friedel mate of some symmetry equivalent of [hkl]
within a particular spacegroup.

But even in the presence of anomalous scattering I think that
Bijvoet pairs are expected to agree with each other better than
with a reflection not related by point group symmetry.

 (although I think it should be...) This is because I saw a
 derivative dataset collected at peak (from a demo) whose Rmeas is quite
 high (50 %) for all the space groups tested (including P1). However, the
 native dataset has only 10 % Rmeas. Should I worry about the derivative
 dataset? There seems to be multiple lattices in both datasets based on
 IDXREF.
 
 You inputs are really appreciated!
 
 Sincerely,
 Chen
-- 
Ethan A Merritt
Biomolecular Structure Center,  K-428 Health Sciences Bldg
MS 357742,   University of Washington, Seattle 98195-7742


[ccp4bb] XDS Rmeas in space group determination

2015-05-13 Thread Chen Zhao
 Hi Ethan,
 
 Thanks a lot for your detailed information. I am aware that in IDXREF only 
 the lattice symmetry was tried to be determined. I went back to check the 
 subtrees in IDXREF because even for P1 the Rmeas is very high, meaning that 
 the multiple measurements for the same reflections are already very imprecise 
 (test resolution 10-5). I therefore am worried about multiple lattices. 
 
 Also related to the probability thing you talked about, there is no point 
 group has significantly low Rmeas in this case. Or it is just because even P1 
 has high Rmeas, so that the highest point group tried were considered to be 
 correct? If so, it sounds hard to determine the point group in this case...
 
 Thank you so much,
 Chen
 
 
 On May 13, 2015, at 6:48 PM, Ethan A Merritt merr...@u.washington.edu 
 wrote:
 
 On Wednesday, 13 May, 2015 18:17:04 Chen Zhao wrote:
 Hi Ethan,
 
 Sorry, I'm coming in late on this so I might have missed an
 earlier explanation of exactly what programs are involved.
 
 
 Yes. My question was simply whether it calculates the statistics
 
 from completely unmerged intensities and just compare say h,k,l with 
 -h,-k,l (or -h,-k,-l and h,k,-l) if there is a 2-fold? Although I believe 
 so...
 
 What is it?
 
 If you mean the tables in IDXREF.LP, they only report the fit of points
 to a particular lattice.  They do not compare the intensities of 
 potential symmetry mates.  Quoting from the program output:
 
 Note, that reflection integration is based only on orientation and metric
 of the lattice. It does not require knowledge of the correct space group!
 Thus, if no such information is provided by the user in XDS.INP,
 reflections are integrated assuming a triclinic reduced cell lattice;
 the space group is assigned automatically or by the user in the last
 step (CORRECT) when integrated intensities are available.
 
 If you mean the output from a later run of pointless/aimless,
 so far as I know it applies the symmetry operation being tested
 to all reflections, which means that Friedel/Bijvoet pairs are 
 not compared.  But I could be wrong on that point.
 
 And what is a good number? Is 20 % OK? What about 30 % and even higher?
 
 Still refering to output from pointless/aimless, the crucial point is not
 the absolute number but rather how the agreement for the symmetry operation
 being tested compares to the agreement for the identity operation.
 
 For example, here is the output for a lousy data set with a real 2-fold:
 
 %
 Scores for each symmetry element
 
 Nelmt  Lklhd  Z-ccCCN  RmeasSymmetry  operator (in Lattice 
 Cell)
 
 1   0.806   6.97   0.70   17852  0.516 identity
 2   0.919   7.67   0.77   21302  0.486 *** 2-fold k ( 0 1 0) {-h,k,-l}
 
 [snip]
 
  Laue Group   Lklhd   NetZc  Zc+   Zc-CCCC-  Rmeas   R-  Delta 
 ReindexOperator
 
 1  P 1 2/m 1  ***  0.919   7.30  7.30  0.00   0.73  0.00   0.50  0.00   0.1 
 [-h,-l,-k]
 2   P -1   0.081  -0.69  6.97  7.67   0.70  0.77   0.52  0.49   0.0 
 [h,-k,-l]
 %%
 
 In this case the program reports a 0.91 likelihood that the Laue
 group is P2 even though the Rmeas is horrible.
 
   Ethan
 
 
 Thanks a lot,
 Chen 
 
 
 On May 13, 2015, at 6:07 PM, Ethan A Merritt merr...@u.washington.edu 
 wrote:
 
 On Wednesday, 13 May, 2015 17:51:59 Chen Zhao wrote:
 Hi all,
 
 I am sorry about this question which I should have figured out earlier. 
 For
 point group determination, does the Rmeas consider Fridel pairs
 differently?
 
 A Friedel pair consists of the [hkl] and [-h-k-l] reflections.
 This pairing is independent of space group.
 So the agreement or lack of agreement between Friedel pairs is
 not informative about selection of point group or space group. 
 
 You may be thinking of a Bijvoet pair, which consists of 
 [hkl] and the Friedel mate of some symmetry equivalent of [hkl]
 within a particular spacegroup.
 
 But even in the presence of anomalous scattering I think that
 Bijvoet pairs are expected to agree with each other better than
 with a reflection not related by point group symmetry.
 
 (although I think it should be...) This is because I saw a
 derivative dataset collected at peak (from a demo) whose Rmeas is quite
 high (50 %) for all the space groups tested (including P1). However, the
 native dataset has only 10 % Rmeas. Should I worry about the derivative
 dataset? There seems to be multiple lattices in both datasets based on
 IDXREF.
 
 You inputs are really appreciated!
 
 Sincerely,
 Chen
 -- 
 Ethan A Merritt
 Biomolecular Structure Center,  K-428 Health Sciences Bldg
 MS 357742,   University of Washington, Seattle 98195-7742
 


Re: [ccp4bb] XDS Rmeas in space group determination

2015-05-13 Thread Ethan A Merritt
On Wednesday, 13 May, 2015 18:17:04 Chen Zhao wrote:
 Hi Ethan,

Sorry, I'm coming in late on this so I might have missed an
earlier explanation of exactly what programs are involved.


 Yes. My question was simply whether it calculates the statistics 
  
 from completely unmerged intensities and just compare say h,k,l with -h,-k,l 
 (or -h,-k,-l and h,k,-l) if there is a 2-fold? Although I believe so...

What is it?

If you mean the tables in IDXREF.LP, they only report the fit of points
to a particular lattice.  They do not compare the intensities of 
potential symmetry mates.  Quoting from the program output:

  Note, that reflection integration is based only on orientation and metric
  of the lattice. It does not require knowledge of the correct space group!
  Thus, if no such information is provided by the user in XDS.INP,
  reflections are integrated assuming a triclinic reduced cell lattice;
  the space group is assigned automatically or by the user in the last
  step (CORRECT) when integrated intensities are available.

If you mean the output from a later run of pointless/aimless,
so far as I know it applies the symmetry operation being tested
to all reflections, which means that Friedel/Bijvoet pairs are 
not compared.  But I could be wrong on that point.

 And what is a good number? Is 20 % OK? What about 30 % and even higher?

Still refering to output from pointless/aimless, the crucial point is not
the absolute number but rather how the agreement for the symmetry operation
being tested compares to the agreement for the identity operation.

For example, here is the output for a lousy data set with a real 2-fold:

%
Scores for each symmetry element

Nelmt  Lklhd  Z-ccCCN  RmeasSymmetry  operator (in Lattice 
Cell)

  1   0.806   6.97   0.70   17852  0.516 identity
  2   0.919   7.67   0.77   21302  0.486 *** 2-fold k ( 0 1 0) {-h,k,-l}

[snip]

   Laue Group   Lklhd   NetZc  Zc+   Zc-CCCC-  Rmeas   R-  Delta 
ReindexOperator

 1  P 1 2/m 1  ***  0.919   7.30  7.30  0.00   0.73  0.00   0.50  0.00   0.1 
[-h,-l,-k]
 2   P -1   0.081  -0.69  6.97  7.67   0.70  0.77   0.52  0.49   0.0 
[h,-k,-l]
%%

In this case the program reports a 0.91 likelihood that the Laue
group is P2 even though the Rmeas is horrible.

Ethan

 
 Thanks a lot,
 Chen 
 
 
  On May 13, 2015, at 6:07 PM, Ethan A Merritt merr...@u.washington.edu 
  wrote:
  
  On Wednesday, 13 May, 2015 17:51:59 Chen Zhao wrote:
  Hi all,
  
  I am sorry about this question which I should have figured out earlier. For
  point group determination, does the Rmeas consider Fridel pairs
  differently?
  
  A Friedel pair consists of the [hkl] and [-h-k-l] reflections.
  This pairing is independent of space group.
  So the agreement or lack of agreement between Friedel pairs is
  not informative about selection of point group or space group. 
  
  You may be thinking of a Bijvoet pair, which consists of 
  [hkl] and the Friedel mate of some symmetry equivalent of [hkl]
  within a particular spacegroup.
  
  But even in the presence of anomalous scattering I think that
  Bijvoet pairs are expected to agree with each other better than
  with a reflection not related by point group symmetry.
  
  (although I think it should be...) This is because I saw a
  derivative dataset collected at peak (from a demo) whose Rmeas is quite
  high (50 %) for all the space groups tested (including P1). However, the
  native dataset has only 10 % Rmeas. Should I worry about the derivative
  dataset? There seems to be multiple lattices in both datasets based on
  IDXREF.
  
  You inputs are really appreciated!
  
  Sincerely,
  Chen
 
-- 
Ethan A Merritt
Biomolecular Structure Center,  K-428 Health Sciences Bldg
MS 357742,   University of Washington, Seattle 98195-7742


Re: [ccp4bb] XDS INP

2015-05-12 Thread Kay Diederichs
According to 
http://homes.mpimf-heidelberg.mpg.de/~kabsch/xds/html_doc/xds_parameters.html#ROTATION_AXIS=
 the definition of a positive value in the ROTATION_AXIS= line is:

When looking along the axis, the crystal would rotate clockwise when 
proceeding to the next data image.

There is of course no right or wrong when it comes to choosing the direction of 
rotation. However, conventionally the sense of rotation is positive; only a 
small minority of beamlines needs a -1 (reverse phi). 
The problem is that 
a) beamlines do not usually document this on their webpages, and sometimes 
change it without notice
b) the headers of the frames usually do not document this (exceptions are 
d*trek and Nexus headers, it seems)

Personally, I wish that beamline designers would be aware of the potential 
problem for users; I suspect they often are not. Life would be easier if all 
beamlines would use the same convention, and I'm pretty sure that spindle 
motors can be produced/bought/programmed for both directions. 

So when a dataset from an unknown beamline is processed, both possibilities 
need to be tried, and one of them then turns out to be correct. Sorry that I 
did not earlier think of this, in your case. Usually, the beamline support 
provides suitable templates for XDS processing.

best,

Kay


Re: [ccp4bb] XDS INP

2015-05-12 Thread Clemens Vonrhein
Hi Kay,

On Tue, May 12, 2015 at 08:39:24PM +0100, Kay Diederichs wrote:
 According to
 http://homes.mpimf-heidelberg.mpg.de/~kabsch/xds/html_doc/xds_parameters.html#ROTATION_AXIS=
 the definition of a positive value in the ROTATION_AXIS= line is:
 
 When looking along the axis, the crystal would rotate clockwise
 when proceeding to the next data image.

I find the even better description in that part of the XDS
documentation is

  The direction of the axis is chosen to describe a right-handed
  rotation.

which should follow the right-hand rule a la

  http://en.wikipedia.org/wiki/Right-hand_rule

The looking along the axis doesn't clearly define if it is (a)
looking from the crystal towards the base of the rotation axis or (b)
from the rotation-axis base towards the crystal.

 There is of course no right or wrong when it comes to choosing the
 direction of rotation. However, conventionally the sense of rotation
 is positive; only a small minority of beamlines needs a -1 (reverse
 phi).

Yes: one can always define the rotation axis without the need for a
'-1'. But this has an impact on the chosen lab coordinate system and
therefore might require a change of INCIDENT_BEAM_DIRECTION= and/or
DIRECTION_OF_DETECTOR_{X,y}-AXIS= ... and there might be good reasons
for having those defined in a particular way (eg. to avoid a negative
value for DETECTOR_DISTANCE= or to have them aligned with the
fast/slow changing axis of the image array as X and Y).

 The problem is that 
 a) beamlines do not usually document this on their webpages, and
 sometimes change it without notice

Indeed.

Most beamlines are quite good in providing up-to-date XDS.INP
templates that are known to work with data collected on that
beamline. Ideally, the {X,Y}-GEO_CORR files for Pilatus detectors
should also be placed in a public space (and everything else that
might be required). All so that users can process the data again once
they are back in the home lab with more time and less stress - trying
to reproduce what happened by the automatic processing systems
installed on most beamlines (and through that task especially new
users will actually learn what entails good data processing practice).

 Personally, I wish that beamline designers would be aware of the
 potential problem for users; I suspect they often are not. Life
 would be easier if all beamlines would use the same convention, and
 I'm pretty sure that spindle motors can be
 produced/bought/programmed for both directions.

Sometimes there are restrictions upon beamlines regarding the choice
of coordinate system to be used: this often has to be identical for
everything and all beamlines at a given synchrotron.

Reaching perfection in an imperfect world ;-)

Cheers

Clemens

-- 

***
* Clemens Vonrhein, Ph.D. vonrhein AT GlobalPhasing DOT com
*
*  Global Phasing Ltd.
*  Sheraton House, Castle Park 
*  Cambridge CB3 0AX, UK
*--
* BUSTER Development Group  (http://www.globalphasing.com)
***


Re: [ccp4bb] XDS INP

2015-05-12 Thread luzuok
Dear Natalie,
I try to run my images with fast_dp, but got the error message:

 Fast_DP installed in: /home/lu/bin/fast_dp_20141205
Starting image: /home/lu/Documents/hg6l3/Hg6_L3_1_2.mccd
Number of jobs: 1
Number of cores: 0
Processing images: 1 - 360
Phi range: 112.50 - 472.50
Template: Hg6_L3_1_#.mccd
Wavelength: 0.97853
Working in: /home/lu/bin/fast_dp_20141205/bin
Autoindexing error: 'sensor'

I cannot find any relative document about fast_dp or autoindexing.
Do you have any idea?

Best!
Lu






--
卢作焜
南开大学新生物站A202

在 2015-05-12 21:08:42,Natalie Tatum nataliejta...@gmail.com 写道:

Dear Lu, 


Just last week I faced an almost identical problem: iMoslfm had no problem but 
XDS failed. I discovered, as Kay has suggested, the ORGX and ORGY values were 
incorrect in XDS.INP. In fact, they had essentially been swapped. If you have 
AUTOINDEX.INP from fast_dp, you can compare the values. For me, they were 
correct in AUTOINDEX.INP but incorrect in XDS.INP. I'd suggest (because it 
fixed the problem for me) simply swapping the values of ORGX and ORGY back, and 
rerunning XDS.


HTH


Natalie




On 12 May 2015 at 13:54, Kay Diederichs kay.diederi...@uni-konstanz.de wrote:
Dear LU,

yes, your spot_15.png looks good. What worries me now is the table

  INDEX_   QUALITY  DELTAXD   YD   X   Y   Z   DH  
DK  DL
  ORIGIN

  0  0  0  1.70.1997.7   1020.9  0.0010  0.0005  1.02190.38
0.510.25
  0 -1  0  3.00.4   1002.5   1000.4  0.0026 -0.0063  1.02190.36
0.270.16
  0  0 -1  3.30.4972.7   1021.8 -0.0073  0.0009  1.02190.30
0.420.19
  0 -1 -1  4.00.5977.6   1001.3 -0.0057 -0.0059  1.02190.34
0.320.15
  1 -1  0  5.20.4   1012.8   1027.9  0.0060  0.0029  1.02190.48
0.640.30
  1 -1 -1  5.40.2988.2   1028.8 -0.0022  0.0032  1.02190.58
0.750.38
  0  0  1  6.00.5   1022.8   1019.9  0.0094  0.0002  1.02190.48
0.630.31
  1  0  0  6.20.6   1008.1   1048.3  0.0045  0.0097  1.02190.28
0.530.15
  1  0 -1  6.70.6983.3   1049.2 -0.0038  0.0100  1.02190.36
0.560.19
  0 -1  1  7.70.7   1027.5999.4  0.0109 -0.0066  1.02190.38
0.260.18
  0  1  0  7.90.4992.8   1041.6 -0.0006  0.0074  1.02190.61
1.050.46
  0  1 -1  9.60.7967.7   1042.5 -0.0090  0.0077  1.02190.50
0.910.40
  0 -1 -2 10.50.8952.9   1002.3 -0.0139 -0.0056  1.02180.35
0.400.17
...

That table is based on the assumption of ORGX=994.64 ORGY=1019.22 (the values 
from the header), so IDXREF puts the origin of the reciprocal lattice closest 
to these given values. However, as the table indicates, choosing the origin at 
other places (columns XD YD) would result in much lower DH DK DL, so it may 
well be the case that the values of ORGX ORGY are not correct.
From the frame hg6_L1_1_1.mccd you posted, I would rather (visually, based 
on beamstop shadow) estimate ORGX ORGY to be at 980 1060 or so.
If I run (using the SPOT.XDS you posted yesterday) IDXREF with e.g. ORGX=994.64 
ORGY= 1035 then I get better indexing, and a rather clear indication that the 
space group is orthorhombic:
  INDEX_   QUALITY  DELTAXD   YD   X   Y   Z   DH  
DK  DL
  ORIGIN

  0  0  0  1.80.2998.4   1022.2  0.0015 -0.0050  1.20190.25
0.350.15
  0 -1  0  2.50.1994.3   1040.4 -0.0001  0.0021  1.20190.38
0.570.25
  0  0  1  3.30.4977.2   1020.4 -0.0068 -0.0057  1.20190.21
0.370.14
  0 -1  1  4.00.4973.1   1038.5 -0.0084  0.0014  1.20190.32
0.520.22
  0  0 -1  4.70.5   1019.7   1024.1  0.0098 -0.0043  1.20190.35
0.350.18
  0 -1 -1  5.30.4   1015.5   1042.3  0.0082  0.0029  1.20190.45
0.620.28
and
  LATTICE-  BRAVAIS-   QUALITY  UNIT CELL CONSTANTS (ANGSTROEM  DEGREES)
 CHARACTER  LATTICE OF FIT  a  b  c   alpha  beta gamma

 *  44aP  0.0  64.5   93.3  116.4  90.2  90.0  90.0
 *  31aP  0.4  64.5   93.3  116.4  89.8  90.0  90.0
 *  35mP  1.0  93.3   64.5  116.4  90.0  90.2  90.0
 *  33mP  4.0  64.5   93.3  116.4  90.2  90.0  90.0
 *  34mP  4.1  64.5  116.4   93.3  90.2  90.0  90.0
 *  32oP  4.5  64.5   93.3  116.4  90.2  90.0  90.0
37mC249.9 241.6   64.5   93.3  90.0  90.2  74.5

I would hypothesize that the beam position is incorrect. Personally, I'd use
JOB= DEFPIX INTEGRATE CORRECT
ORGX=994.64 ORGY= 1035
for a tentative round of integration, maybe together with
SPACE_GROUP_NUMBER=19
UNIT_CELL_CONSTANTS= 64.5   93.3  116.4  90.  90.0  90.0
and then inspect the result. If the statistics look reasonable (ISa  10 or 
so), you should optimize it (see 

Re: [ccp4bb] XDS INP

2015-05-12 Thread Gerd Rosenbaum

Hi Clemens,

your suggested description of positive rotation doesn't remove the 
ambiguity.


My intuitive way to define positive rotation (in  1994 or so, when 
building the SBC) was:
Looking onto the sample, rotation  of the sample in mathematically 
positive direction


Only later I was told that in HKL (and I believe also d*trek) the 
definition was mathematically positive direction for an observer 
standing behind the rotary table looking through the base to the sample. 
Not the way a user approaches the goniostat's rotary table.


But no big deal. It's a -1 in one of the axes definitions. There are, as 
you stated, many more axes definitions and they depend on the geometry 
of the end station. E.g., at the SBC, the orientation of otherwise 
identical goniostats is mirror-image between the ID and the BM for 
reasons of layout of the two beamlines relative to each other. The idea 
that the axes definitions should be uniform is not practical.


Regards,

Gerd

On 12.05.2015 16:24, Clemens Vonrhein wrote:

Hi Kay,

On Tue, May 12, 2015 at 08:39:24PM +0100, Kay Diederichs wrote:

According to
http://homes.mpimf-heidelberg.mpg.de/~kabsch/xds/html_doc/xds_parameters.html#ROTATION_AXIS=
the definition of a positive value in the ROTATION_AXIS= line is:

When looking along the axis, the crystal would rotate clockwise
when proceeding to the next data image.

I find the even better description in that part of the XDS
documentation is

   The direction of the axis is chosen to describe a right-handed
   rotation.

which should follow the right-hand rule a la

   http://en.wikipedia.org/wiki/Right-hand_rule

The looking along the axis doesn't clearly define if it is (a)
looking from the crystal towards the base of the rotation axis or (b)
from the rotation-axis base towards the crystal.


There is of course no right or wrong when it comes to choosing the
direction of rotation. However, conventionally the sense of rotation
is positive; only a small minority of beamlines needs a -1 (reverse
phi).

Yes: one can always define the rotation axis without the need for a
'-1'. But this has an impact on the chosen lab coordinate system and
therefore might require a change of INCIDENT_BEAM_DIRECTION= and/or
DIRECTION_OF_DETECTOR_{X,y}-AXIS= ... and there might be good reasons
for having those defined in a particular way (eg. to avoid a negative
value for DETECTOR_DISTANCE= or to have them aligned with the
fast/slow changing axis of the image array as X and Y).


The problem is that
a) beamlines do not usually document this on their webpages, and
sometimes change it without notice

Indeed.

Most beamlines are quite good in providing up-to-date XDS.INP
templates that are known to work with data collected on that
beamline. Ideally, the {X,Y}-GEO_CORR files for Pilatus detectors
should also be placed in a public space (and everything else that
might be required). All so that users can process the data again once
they are back in the home lab with more time and less stress - trying
to reproduce what happened by the automatic processing systems
installed on most beamlines (and through that task especially new
users will actually learn what entails good data processing practice).


Personally, I wish that beamline designers would be aware of the
potential problem for users; I suspect they often are not. Life
would be easier if all beamlines would use the same convention, and
I'm pretty sure that spindle motors can be
produced/bought/programmed for both directions.

Sometimes there are restrictions upon beamlines regarding the choice
of coordinate system to be used: this often has to be identical for
everything and all beamlines at a given synchrotron.

Reaching perfection in an imperfect world ;-)

Cheers

Clemens



Re: [ccp4bb] XDS INP

2015-05-12 Thread Natalie Tatum
Dear Lu,

Just last week I faced an almost identical problem: iMoslfm had no problem
but XDS failed. I discovered, as Kay has suggested, the ORGX and ORGY
values were incorrect in XDS.INP. In fact, they had essentially been
swapped. If you have AUTOINDEX.INP from fast_dp, you can compare the
values. For me, they were correct in AUTOINDEX.INP but incorrect in
XDS.INP. I'd suggest (because it fixed the problem for me) simply swapping
the values of ORGX and ORGY back, and rerunning XDS.

HTH

Natalie


On 12 May 2015 at 13:54, Kay Diederichs kay.diederi...@uni-konstanz.de
wrote:

 Dear LU,

 yes, your spot_15.png looks good. What worries me now is the table

   INDEX_   QUALITY  DELTAXD   YD   X   Y   Z   DH
 DK  DL
   ORIGIN

   0  0  0  1.70.1997.7   1020.9  0.0010  0.0005  1.0219
 0.380.510.25
   0 -1  0  3.00.4   1002.5   1000.4  0.0026 -0.0063  1.0219
 0.360.270.16
   0  0 -1  3.30.4972.7   1021.8 -0.0073  0.0009  1.0219
 0.300.420.19
   0 -1 -1  4.00.5977.6   1001.3 -0.0057 -0.0059  1.0219
 0.340.320.15
   1 -1  0  5.20.4   1012.8   1027.9  0.0060  0.0029  1.0219
 0.480.640.30
   1 -1 -1  5.40.2988.2   1028.8 -0.0022  0.0032  1.0219
 0.580.750.38
   0  0  1  6.00.5   1022.8   1019.9  0.0094  0.0002  1.0219
 0.480.630.31
   1  0  0  6.20.6   1008.1   1048.3  0.0045  0.0097  1.0219
 0.280.530.15
   1  0 -1  6.70.6983.3   1049.2 -0.0038  0.0100  1.0219
 0.360.560.19
   0 -1  1  7.70.7   1027.5999.4  0.0109 -0.0066  1.0219
 0.380.260.18
   0  1  0  7.90.4992.8   1041.6 -0.0006  0.0074  1.0219
 0.611.050.46
   0  1 -1  9.60.7967.7   1042.5 -0.0090  0.0077  1.0219
 0.500.910.40
   0 -1 -2 10.50.8952.9   1002.3 -0.0139 -0.0056  1.0218
 0.350.400.17
 ...

 That table is based on the assumption of ORGX=994.64 ORGY=1019.22 (the
 values from the header), so IDXREF puts the origin of the reciprocal
 lattice closest to these given values. However, as the table indicates,
 choosing the origin at other places (columns XD YD) would result in much
 lower DH DK DL, so it may well be the case that the values of ORGX ORGY are
 not correct.
 From the frame hg6_L1_1_1.mccd you posted, I would rather (visually,
 based on beamstop shadow) estimate ORGX ORGY to be at 980 1060 or so.
 If I run (using the SPOT.XDS you posted yesterday) IDXREF with e.g.
 ORGX=994.64 ORGY= 1035 then I get better indexing, and a rather clear
 indication that the space group is orthorhombic:
   INDEX_   QUALITY  DELTAXD   YD   X   Y   Z   DH
 DK  DL
   ORIGIN

   0  0  0  1.80.2998.4   1022.2  0.0015 -0.0050  1.2019
 0.250.350.15
   0 -1  0  2.50.1994.3   1040.4 -0.0001  0.0021  1.2019
 0.380.570.25
   0  0  1  3.30.4977.2   1020.4 -0.0068 -0.0057  1.2019
 0.210.370.14
   0 -1  1  4.00.4973.1   1038.5 -0.0084  0.0014  1.2019
 0.320.520.22
   0  0 -1  4.70.5   1019.7   1024.1  0.0098 -0.0043  1.2019
 0.350.350.18
   0 -1 -1  5.30.4   1015.5   1042.3  0.0082  0.0029  1.2019
 0.450.620.28
 and
   LATTICE-  BRAVAIS-   QUALITY  UNIT CELL CONSTANTS (ANGSTROEM  DEGREES)
  CHARACTER  LATTICE OF FIT  a  b  c   alpha  beta gamma

  *  44aP  0.0  64.5   93.3  116.4  90.2  90.0  90.0
  *  31aP  0.4  64.5   93.3  116.4  89.8  90.0  90.0
  *  35mP  1.0  93.3   64.5  116.4  90.0  90.2  90.0
  *  33mP  4.0  64.5   93.3  116.4  90.2  90.0  90.0
  *  34mP  4.1  64.5  116.4   93.3  90.2  90.0  90.0
  *  32oP  4.5  64.5   93.3  116.4  90.2  90.0  90.0
 37mC249.9 241.6   64.5   93.3  90.0  90.2  74.5

 I would hypothesize that the beam position is incorrect. Personally, I'd
 use
 JOB= DEFPIX INTEGRATE CORRECT
 ORGX=994.64 ORGY= 1035
 for a tentative round of integration, maybe together with
 SPACE_GROUP_NUMBER=19
 UNIT_CELL_CONSTANTS= 64.5   93.3  116.4  90.  90.0  90.0
 and then inspect the result. If the statistics look reasonable (ISa  10
 or so), you should optimize it (see XDSwiki). If it looks very bad (ISa 
 5), you can run
 echo CENTRE | pointless XDS_ASCII.HKL
 afterwards, which will tell you whether an offset in one of the indices
 has to be applied. In that case, you should inspect the INDEX ORIGIN
 table of IDXREF.LP again, to see which ORGX ORGY this corresponds to. After
 this, re-integrate, optimize ...

 If you are not successful, compress your frames, upload them to some
 Dropbox-like directory, and send me the link. I'll look at your data,
 treating them confidentially of course, and tell you what I find.

 best,
 Kay






 Dear Kay,
 
 I've tune these parameter for many 

Re: [ccp4bb] XDS INP

2015-05-12 Thread luzuok
Dear Kay,

I've tune these parameter for many times, and I got best results . :



SPOT_RANGE=1 100

INCLUDE_RESOLUTION_RANGE=50 4.2

MINIMUM_NUMBER_OF_PIXELS_IN_A_SPOT=20




but still got the same error message!




The SPOT.XDS file was ploted (see attachment spot_15.png ), it seems that the 
ice ring and beam stop shadow was excluded. But the result is still frustrating.




 Best wishes!




LU zuokun








--
卢作焜
南开大学新生物站A202





At 2015-05-11 23:20:55, Kay Diederichs kay.diederi...@uni-konstanz.de wrote:
Hi LU,

the reason why IDXREF is not indexing smoothly is that the spot positions in 
your SPOT.XDS are not very meaningful - you pick up a lot of noise! I plotted 
your SPOT.XDS using

%%:-/tmp/luo% gnuplot
gnuplot set size square
gnuplot set out tmp.png
gnuplot  set term png nocrop medium size 1280,960
Terminal type set to 'png'
Options are 'nocrop medium size 1280,960 '
gnuplot plot 'SPOT.XDS' us 1:2 w dots
gnuplot quit

and got the attached file tmp.png. This shows:
- ice rings
- streaks parallel to the x-axis 
- some modules of the detector behave very differently from others

Poor IDXREF tries to make sense of all of this and still somehow manages to 
come up with something that may be useful for further processing.
But the real remedy of the problems would be to properly set the parameters 
influencing the COLSPOT step. These are documented at 
http://homes.mpimf-heidelberg.mpg.de/~kabsch/xds/html_doc/xds_parameters.html 
(load the page into your browser, and search for occurrences of COLSPOT). The 
most important ones in this case are probably
MINIMUM_NUMBER_OF_PIXELS_IN_A_SPOT=6  ! this is the default
STRONG_PIXEL=3! this 
is the default
INCLUDE_RESOLUTION_RANGE =50 0 ! no default, but you could try 50 4 to 
exclude the ice rings
I don't know which values you used (you forgot to post XDS.INP), so I would 
try with the above first, run COLSPOT, inspect with the gnuplot technique I 
described, and then modify the parameters until the plot looks more 
meaningful, at which point IDXREF will most likely happily index.

No, this is not fully automatic, but at least it's a logical way forward.

good luck,

Kay 


On Mon, 11 May 2015 19:56:33 +0800, luzuok luzuo...@126.com wrote:

 Dear Karine and Jürgen,
 
 The   XDS terminated in IDXREF with error message:

 
 !! ERROR !!! INSUFFICIENT PERCENTAGE ( 50%) OF INDEXED REFLECTIONS
 
 
 In the COLSPOT, I can see
 
 NUMBER OF DIFFRACTION SPOTS LOCATED 53669
 
 IGNORED BECAUSE OF SPOT MAXIMUM OUT OF CENTER 174
 
 IGNORED BECAUSE OF SPOT CLOSE TO UNTRUSTED REGION 450
 
 WEAK SPOTS OMITTED 11753
 
 NUMBER OF DIFFRACTION SPOTS ACCEPTED 41292
 
 
 It seems that the accepted spots are enough. But I don't know why there
 are so many spots which cannot be indexed.
 
 
 Best wishes!
 
 
 LU
 





XDS.INP
Description: Binary data


IDXREF.LP
Description: Binary data


Re: [ccp4bb] XDS INP

2015-05-12 Thread Kay Diederichs
Dear LU,

yes, your spot_15.png looks good. What worries me now is the table

  INDEX_   QUALITY  DELTAXD   YD   X   Y   Z   DH  
DK  DL
  ORIGIN

  0  0  0  1.70.1997.7   1020.9  0.0010  0.0005  1.02190.38
0.510.25
  0 -1  0  3.00.4   1002.5   1000.4  0.0026 -0.0063  1.02190.36
0.270.16
  0  0 -1  3.30.4972.7   1021.8 -0.0073  0.0009  1.02190.30
0.420.19
  0 -1 -1  4.00.5977.6   1001.3 -0.0057 -0.0059  1.02190.34
0.320.15
  1 -1  0  5.20.4   1012.8   1027.9  0.0060  0.0029  1.02190.48
0.640.30
  1 -1 -1  5.40.2988.2   1028.8 -0.0022  0.0032  1.02190.58
0.750.38
  0  0  1  6.00.5   1022.8   1019.9  0.0094  0.0002  1.02190.48
0.630.31
  1  0  0  6.20.6   1008.1   1048.3  0.0045  0.0097  1.02190.28
0.530.15
  1  0 -1  6.70.6983.3   1049.2 -0.0038  0.0100  1.02190.36
0.560.19
  0 -1  1  7.70.7   1027.5999.4  0.0109 -0.0066  1.02190.38
0.260.18
  0  1  0  7.90.4992.8   1041.6 -0.0006  0.0074  1.02190.61
1.050.46
  0  1 -1  9.60.7967.7   1042.5 -0.0090  0.0077  1.02190.50
0.910.40
  0 -1 -2 10.50.8952.9   1002.3 -0.0139 -0.0056  1.02180.35
0.400.17
...

That table is based on the assumption of ORGX=994.64 ORGY=1019.22 (the values 
from the header), so IDXREF puts the origin of the reciprocal lattice closest 
to these given values. However, as the table indicates, choosing the origin at 
other places (columns XD YD) would result in much lower DH DK DL, so it may 
well be the case that the values of ORGX ORGY are not correct.
From the frame hg6_L1_1_1.mccd you posted, I would rather (visually, based 
on beamstop shadow) estimate ORGX ORGY to be at 980 1060 or so. 
If I run (using the SPOT.XDS you posted yesterday) IDXREF with e.g. ORGX=994.64 
ORGY= 1035 then I get better indexing, and a rather clear indication that the 
space group is orthorhombic:
  INDEX_   QUALITY  DELTAXD   YD   X   Y   Z   DH  
DK  DL
  ORIGIN

  0  0  0  1.80.2998.4   1022.2  0.0015 -0.0050  1.20190.25
0.350.15
  0 -1  0  2.50.1994.3   1040.4 -0.0001  0.0021  1.20190.38
0.570.25
  0  0  1  3.30.4977.2   1020.4 -0.0068 -0.0057  1.20190.21
0.370.14
  0 -1  1  4.00.4973.1   1038.5 -0.0084  0.0014  1.20190.32
0.520.22
  0  0 -1  4.70.5   1019.7   1024.1  0.0098 -0.0043  1.20190.35
0.350.18
  0 -1 -1  5.30.4   1015.5   1042.3  0.0082  0.0029  1.20190.45
0.620.28
and
  LATTICE-  BRAVAIS-   QUALITY  UNIT CELL CONSTANTS (ANGSTROEM  DEGREES)
 CHARACTER  LATTICE OF FIT  a  b  c   alpha  beta gamma

 *  44aP  0.0  64.5   93.3  116.4  90.2  90.0  90.0
 *  31aP  0.4  64.5   93.3  116.4  89.8  90.0  90.0
 *  35mP  1.0  93.3   64.5  116.4  90.0  90.2  90.0
 *  33mP  4.0  64.5   93.3  116.4  90.2  90.0  90.0
 *  34mP  4.1  64.5  116.4   93.3  90.2  90.0  90.0
 *  32oP  4.5  64.5   93.3  116.4  90.2  90.0  90.0
37mC249.9 241.6   64.5   93.3  90.0  90.2  74.5

I would hypothesize that the beam position is incorrect. Personally, I'd use 
JOB= DEFPIX INTEGRATE CORRECT
ORGX=994.64 ORGY= 1035 
for a tentative round of integration, maybe together with
SPACE_GROUP_NUMBER=19
UNIT_CELL_CONSTANTS= 64.5   93.3  116.4  90.  90.0  90.0
and then inspect the result. If the statistics look reasonable (ISa  10 or 
so), you should optimize it (see XDSwiki). If it looks very bad (ISa  5), you 
can run
echo CENTRE | pointless XDS_ASCII.HKL
afterwards, which will tell you whether an offset in one of the indices has to 
be applied. In that case, you should inspect the INDEX ORIGIN table of 
IDXREF.LP again, to see which ORGX ORGY this corresponds to. After this, 
re-integrate, optimize ...

If you are not successful, compress your frames, upload them to some 
Dropbox-like directory, and send me the link. I'll look at your data, treating 
them confidentially of course, and tell you what I find.

best,
Kay






Dear Kay,

I've tune these parameter for many times, and I got best results . :

SPOT_RANGE=1 100 

INCLUDE_RESOLUTION_RANGE=50 4.2

MINIMUM_NUMBER_OF_PIXELS_IN_A_SPOT=20

but still got the same error message!

The SPOT.XDS file was ploted (see attachment spot_15.png ), it seems that 
the ice ring and beam stop shadow was excluded. But the result is still 
frustrating.

 Best wishes!

LU zuokun


Re: [ccp4bb] XDS INP

2015-05-12 Thread Huw Jenkins
Hi,

Also the IXDREF.LP files from yesterday and today suggest that you are having 
problems with 2 different datasets. Is that correct?

IDXREF from yesterday had:

NAME_TEMPLATE_OF_DATA_FRAMES=/home/lu/Documents/StructurePro/images/luzk/Hg6/hg6_L1_1_?
OSCILLATION_RANGE=0.5000
X-RAY_WAVELENGTH=   0.832010

whereas today’s has:

NAME_TEMPLATE_OF_DATA_FRAMES=/home/lu/Documents/StructurePro/images/luzk/Hg6_L3/Hg6_L3_1_?.mccd
OSCILLATION_RANGE=1.
X-RAY_WAVELENGTH=   0.978530



Huw

Re: [ccp4bb] XDS INP

2015-05-12 Thread Kay Diederichs
You found it!

XDS.INP needs
ROTATION_AXIS=-1 0 0

with this setting, IDXREF indexes more than half of the reflections:
 REFINED VALUES OF DIFFRACTION PARAMETERS DERIVED FROM  10956 INDEXED SPOTS
 REFINED PARAMETERS:   AXIS BEAM ORIENTATION CELL
 STANDARD DEVIATION OF SPOTPOSITION (PIXELS) 0.60
 STANDARD DEVIATION OF SPINDLE POSITION (DEGREES)0.15

I assume this is beamline BL17B1 from the Taiwanese NSRRC synchrotron, right? 
Why oh why do they rotate the spindle this way?

Kay

On Tue, 12 May 2015 14:50:26 +0100, Huw Jenkins h.t.jenk...@me.com wrote:

On 12 May 2015, at 13:09, luzuok luzuo...@126.com wrote:

 STANDARD DEVIATION OF SPINDLE POSITION (DEGREES)   11.13

Is the oscillation range and rotation axis direction correct in your XDS.INP 
file?



Huw


Re: [ccp4bb] XDS INP

2015-05-12 Thread Clemens Vonrhein
Dear Natalie,

On Tue, May 12, 2015 at 02:08:42PM +0100, Natalie Tatum wrote:
 Dear Lu,
 
 Just last week I faced an almost identical problem: iMoslfm had no problem
 but XDS failed.

Yes - that happens often because the beam centre recorded in the image
header doesn't specify what coordinate system is being used. So these
values are often 'program specific' and might even depend on the
'standard program' used for processing at the beamline.

Please note that the actual values are nearly always correct (apart
from some beamlines that rely solely on def.site files for HKL2000 and
don't populate the image header with meaningful values): it is the
coordinate convention that is missing.

We try to record those specialities on the autoPROC wiki at

  http://www.globalphasing.com/autoproc/wiki/index.cgi?BeamlineSettings

where you could find a lot of settings relevant to XDS processing for
different beamlines and detectors.

Cheers

Clemens

PS: we always hope that any change in beamline/detector/header
configuration is passed down to software developers before any
user starts collecting data ... but most of the time the
problems/changes are only discovered after the fact ;-)



 I discovered, as Kay has suggested, the ORGX and ORGY
 values were incorrect in XDS.INP. In fact, they had essentially been
 swapped. If you have AUTOINDEX.INP from fast_dp, you can compare the
 values. For me, they were correct in AUTOINDEX.INP but incorrect in
 XDS.INP. I'd suggest (because it fixed the problem for me) simply swapping
 the values of ORGX and ORGY back, and rerunning XDS.
 
 HTH
 
 Natalie
 
 
 On 12 May 2015 at 13:54, Kay Diederichs kay.diederi...@uni-konstanz.de
 wrote:
 
  Dear LU,
 
  yes, your spot_15.png looks good. What worries me now is the table
 
INDEX_   QUALITY  DELTAXD   YD   X   Y   Z   DH
  DK  DL
ORIGIN
 
0  0  0  1.70.1997.7   1020.9  0.0010  0.0005  1.0219
  0.380.510.25
0 -1  0  3.00.4   1002.5   1000.4  0.0026 -0.0063  1.0219
  0.360.270.16
0  0 -1  3.30.4972.7   1021.8 -0.0073  0.0009  1.0219
  0.300.420.19
0 -1 -1  4.00.5977.6   1001.3 -0.0057 -0.0059  1.0219
  0.340.320.15
1 -1  0  5.20.4   1012.8   1027.9  0.0060  0.0029  1.0219
  0.480.640.30
1 -1 -1  5.40.2988.2   1028.8 -0.0022  0.0032  1.0219
  0.580.750.38
0  0  1  6.00.5   1022.8   1019.9  0.0094  0.0002  1.0219
  0.480.630.31
1  0  0  6.20.6   1008.1   1048.3  0.0045  0.0097  1.0219
  0.280.530.15
1  0 -1  6.70.6983.3   1049.2 -0.0038  0.0100  1.0219
  0.360.560.19
0 -1  1  7.70.7   1027.5999.4  0.0109 -0.0066  1.0219
  0.380.260.18
0  1  0  7.90.4992.8   1041.6 -0.0006  0.0074  1.0219
  0.611.050.46
0  1 -1  9.60.7967.7   1042.5 -0.0090  0.0077  1.0219
  0.500.910.40
0 -1 -2 10.50.8952.9   1002.3 -0.0139 -0.0056  1.0218
  0.350.400.17
  ...
 
  That table is based on the assumption of ORGX=994.64 ORGY=1019.22 (the
  values from the header), so IDXREF puts the origin of the reciprocal
  lattice closest to these given values. However, as the table indicates,
  choosing the origin at other places (columns XD YD) would result in much
  lower DH DK DL, so it may well be the case that the values of ORGX ORGY are
  not correct.
  From the frame hg6_L1_1_1.mccd you posted, I would rather (visually,
  based on beamstop shadow) estimate ORGX ORGY to be at 980 1060 or so.
  If I run (using the SPOT.XDS you posted yesterday) IDXREF with e.g.
  ORGX=994.64 ORGY= 1035 then I get better indexing, and a rather clear
  indication that the space group is orthorhombic:
INDEX_   QUALITY  DELTAXD   YD   X   Y   Z   DH
  DK  DL
ORIGIN
 
0  0  0  1.80.2998.4   1022.2  0.0015 -0.0050  1.2019
  0.250.350.15
0 -1  0  2.50.1994.3   1040.4 -0.0001  0.0021  1.2019
  0.380.570.25
0  0  1  3.30.4977.2   1020.4 -0.0068 -0.0057  1.2019
  0.210.370.14
0 -1  1  4.00.4973.1   1038.5 -0.0084  0.0014  1.2019
  0.320.520.22
0  0 -1  4.70.5   1019.7   1024.1  0.0098 -0.0043  1.2019
  0.350.350.18
0 -1 -1  5.30.4   1015.5   1042.3  0.0082  0.0029  1.2019
  0.450.620.28
  and
LATTICE-  BRAVAIS-   QUALITY  UNIT CELL CONSTANTS (ANGSTROEM  DEGREES)
   CHARACTER  LATTICE OF FIT  a  b  c   alpha  beta gamma
 
   *  44aP  0.0  64.5   93.3  116.4  90.2  90.0  90.0
   *  31aP  0.4  64.5   93.3  116.4  89.8  90.0  90.0
   *  35mP  1.0  93.3   64.5  116.4  90.0  90.2  90.0
   *  33mP  4.0  64.5   93.3  116.4  90.2  90.0  90.0
   *  34mP  4.1  64.5  

Re: [ccp4bb] XDS INP

2015-05-12 Thread Huw Jenkins
On 12 May 2015, at 13:09, luzuok luzuo...@126.com wrote:

 STANDARD DEVIATION OF SPINDLE POSITION (DEGREES)   11.13

Is the oscillation range and rotation axis direction correct in your XDS.INP 
file?



Huw

Re: [ccp4bb] XDS INP

2015-05-12 Thread Tim Gruene
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Dear Natalie,

I usually look at the first frame with adxv and estimate the ORGX ORGY
(which can be different from the direct beam position) by eye based on
shadows (as Kay mentioned before) or ice rings and copy the values
into XDS.INP.

Regards,
Tim

On 05/12/2015 03:08 PM, Natalie Tatum wrote:
 Dear Lu,
 
 Just last week I faced an almost identical problem: iMoslfm had no
 problem but XDS failed. I discovered, as Kay has suggested, the
 ORGX and ORGY values were incorrect in XDS.INP. In fact, they had
 essentially been swapped. If you have AUTOINDEX.INP from fast_dp,
 you can compare the values. For me, they were correct in
 AUTOINDEX.INP but incorrect in XDS.INP. I'd suggest (because it
 fixed the problem for me) simply swapping the values of ORGX and
 ORGY back, and rerunning XDS.
 
 HTH
 
 Natalie
 
 
 On 12 May 2015 at 13:54, Kay Diederichs
 kay.diederi...@uni-konstanz.de wrote:
 
 Dear LU,
 
 yes, your spot_15.png looks good. What worries me now is the
 table
 
 INDEX_   QUALITY  DELTAXD   YD   X   Y   Z
 DH DK  DL ORIGIN
 
 0  0  0  1.70.1997.7   1020.9  0.0010  0.0005
 1.0219 0.380.510.25 0 -1  0  3.00.4   1002.5
 1000.4  0.0026 -0.0063  1.0219 0.360.270.16 0  0 -1
 3.30.4972.7   1021.8 -0.0073  0.0009  1.0219 0.300.42
 0.19 0 -1 -1  4.00.5977.6   1001.3 -0.0057 -0.0059
 1.0219 0.340.320.15 1 -1  0  5.20.4   1012.8
 1027.9  0.0060  0.0029  1.0219 0.480.640.30 1 -1 -1
 5.40.2988.2   1028.8 -0.0022  0.0032  1.0219 0.580.75
 0.38 0  0  1  6.00.5   1022.8   1019.9  0.0094  0.0002
 1.0219 0.480.630.31 1  0  0  6.20.6   1008.1
 1048.3  0.0045  0.0097  1.0219 0.280.530.15 1  0 -1
 6.70.6983.3   1049.2 -0.0038  0.0100  1.0219 0.360.56
 0.19 0 -1  1  7.70.7   1027.5999.4  0.0109 -0.0066
 1.0219 0.380.260.18 0  1  0  7.90.4992.8
 1041.6 -0.0006  0.0074  1.0219 0.611.050.46 0  1 -1
 9.60.7967.7   1042.5 -0.0090  0.0077  1.0219 0.500.91
 0.40 0 -1 -2 10.50.8952.9   1002.3 -0.0139 -0.0056
 1.0218 0.350.400.17 ...
 
 That table is based on the assumption of ORGX=994.64 ORGY=1019.22
 (the values from the header), so IDXREF puts the origin of the
 reciprocal lattice closest to these given values. However, as the
 table indicates, choosing the origin at other places (columns XD
 YD) would result in much lower DH DK DL, so it may well be the
 case that the values of ORGX ORGY are not correct. From the frame
 hg6_L1_1_1.mccd you posted, I would rather (visually, based
 on beamstop shadow) estimate ORGX ORGY to be at 980 1060 or so. 
 If I run (using the SPOT.XDS you posted yesterday) IDXREF with
 e.g. ORGX=994.64 ORGY= 1035 then I get better indexing, and a
 rather clear indication that the space group is orthorhombic: 
 INDEX_   QUALITY  DELTAXD   YD   X   Y   Z
 DH DK  DL ORIGIN
 
 0  0  0  1.80.2998.4   1022.2  0.0015 -0.0050
 1.2019 0.250.350.15 0 -1  0  2.50.1994.3
 1040.4 -0.0001  0.0021  1.2019 0.380.570.25 0  0  1
 3.30.4977.2   1020.4 -0.0068 -0.0057  1.2019 0.210.37
 0.14 0 -1  1  4.00.4973.1   1038.5 -0.0084  0.0014
 1.2019 0.320.520.22 0  0 -1  4.70.5   1019.7
 1024.1  0.0098 -0.0043  1.2019 0.350.350.18 0 -1 -1
 5.30.4   1015.5   1042.3  0.0082  0.0029  1.2019 0.450.62
 0.28 and LATTICE-  BRAVAIS-   QUALITY  UNIT CELL CONSTANTS
 (ANGSTROEM  DEGREES) CHARACTER  LATTICE OF FIT  a  b
 c   alpha  beta gamma
 
 *  44aP  0.0  64.5   93.3  116.4  90.2  90.0
 90.0 *  31aP  0.4  64.5   93.3  116.4  89.8
 90.0  90.0 *  35mP  1.0  93.3   64.5  116.4
 90.0  90.2  90.0 *  33mP  4.0  64.5   93.3
 116.4  90.2  90.0  90.0 *  34mP  4.1  64.5
 116.4   93.3  90.2  90.0  90.0 *  32oP  4.5
 64.5   93.3  116.4  90.2  90.0  90.0 37mC249.9
 241.6   64.5   93.3  90.0  90.2  74.5
 
 I would hypothesize that the beam position is incorrect.
 Personally, I'd use JOB= DEFPIX INTEGRATE CORRECT ORGX=994.64
 ORGY= 1035 for a tentative round of integration, maybe together
 with SPACE_GROUP_NUMBER=19 UNIT_CELL_CONSTANTS= 64.5   93.3
 116.4  90.  90.0  90.0 and then inspect the result. If the
 statistics look reasonable (ISa  10 or so), you should optimize
 it (see XDSwiki). If it looks very bad (ISa  5), you can run 
 echo CENTRE | pointless XDS_ASCII.HKL afterwards, which will tell
 you whether an offset in one of the indices has to be applied. In
 that case, you should inspect the INDEX ORIGIN table of
 IDXREF.LP again, to see which ORGX ORGY this corresponds to.
 After this, re-integrate, optimize ...
 
 If you are not successful, compress your frames, upload them to
 some Dropbox-like 

Re: [ccp4bb] XDS INP

2015-05-12 Thread luzuok
Yes! two data sets from one crystal with 2 different wave length.





--
卢作焜
南开大学新生物站A202



在 2015-05-12 22:14:16,Huw Jenkins h.t.jenk...@me.com 写道:
Hi,

Also the IXDREF.LP files from yesterday and today suggest that you are having 
problems with 2 different datasets. Is that correct?

IDXREF from yesterday had:

NAME_TEMPLATE_OF_DATA_FRAMES=/home/lu/Documents/StructurePro/images/luzk/Hg6/hg6_L1_1_?
OSCILLATION_RANGE=0.5000
X-RAY_WAVELENGTH=   0.832010

whereas today’s has:

NAME_TEMPLATE_OF_DATA_FRAMES=/home/lu/Documents/StructurePro/images/luzk/Hg6_L3/Hg6_L3_1_?.mccd
OSCILLATION_RANGE=1.
X-RAY_WAVELENGTH=   0.978530



Huw


Re: [ccp4bb] XDS INP

2015-05-12 Thread luzuok


I not so familiar with data collection hardware! I still have a lot to learn.
This data set was collected from SSRF(Shanghai China). I don't know how they 
rotate the spindle.
Can you provide me some reference material?

Best wishes!





--
卢作焜
南开大学新生物站A202



At 2015-05-12 22:41:24, Kay Diederichs kay.diederi...@uni-konstanz.de wrote:
You found it!

XDS.INP needs
ROTATION_AXIS=-1 0 0

with this setting, IDXREF indexes more than half of the reflections:
 REFINED VALUES OF DIFFRACTION PARAMETERS DERIVED FROM  10956 INDEXED SPOTS
 REFINED PARAMETERS:   AXIS BEAM ORIENTATION CELL
 STANDARD DEVIATION OF SPOTPOSITION (PIXELS) 0.60
 STANDARD DEVIATION OF SPINDLE POSITION (DEGREES)0.15

I assume this is beamline BL17B1 from the Taiwanese NSRRC synchrotron, right? 
Why oh why do they rotate the spindle this way?

Kay

On Tue, 12 May 2015 14:50:26 +0100, Huw Jenkins h.t.jenk...@me.com wrote:

On 12 May 2015, at 13:09, luzuok luzuo...@126.com wrote:

 STANDARD DEVIATION OF SPINDLE POSITION (DEGREES)   11.13

Is the oscillation range and rotation axis direction correct in your XDS.INP 
file?



Huw


Re: [ccp4bb] XDS INP

2015-05-12 Thread Harry Powell
Hi

As far as I am aware beamline BL17U at Shanghai has what we in the Mosflm world 
call reverse phi (or in the XDS world you'd want to change the ROTATION AXIS 
vector).

There are often good reasons (to the engineers who have installed the equipment 
on the beamline) why the crystal rotation is in the opposite direction.

Unfortunately no-one bothers to tell us developers, and we have to find out 
when we get a 'problem' dataset.

I believe that James Holton has a pretty comprehensive list of the conventions 
used on the PX beamlines around the world

On 12 May 2015, at 16:04, luzuok wrote:

 
 I not so familiar with data collection hardware! I still have a lot to learn.
 This data set was collected from SSRF(Shanghai China). I don't know how they 
 rotate the spindle.
 Can you provide me some reference material?
 
 Best wishes!
 
 
 
 --
 卢作焜
 南开大学新生物站A202
 
 
 At 2015-05-12 22:41:24, Kay Diederichs kay.diederi...@uni-konstanz.de 
 wrote:
 You found it!
 
 XDS.INP needs
 ROTATION_AXIS=-1 0 0
 
 with this setting, IDXREF indexes more than half of the reflections:
  REFINED VALUES OF DIFFRACTION PARAMETERS DERIVED FROM  10956 INDEXED SPOTS
  REFINED PARAMETERS:   AXIS BEAM ORIENTATION CELL
  STANDARD DEVIATION OF SPOTPOSITION (PIXELS) 0.60
  STANDARD DEVIATION OF SPINDLE POSITION (DEGREES)0.15
 
 I assume this is beamline BL17B1 from the Taiwanese NSRRC synchrotron, 
 right? Why oh why do they rotate the spindle this way?
 
 Kay
 
 On Tue, 12 May 2015 14:50:26 +0100, Huw Jenkins h.t.jenk...@me.com wrote:
 
 On 12 May 2015, at 13:09, luzuok luzuo...@126.com wrote:
 
  STANDARD DEVIATION OF SPINDLE POSITION (DEGREES)   11.13
 
 Is the oscillation range and rotation axis direction correct in your 
 XDS.INP file?
 
 
 
 Huw
 
 

Harry
--
Dr Harry Powell, MRC Laboratory of Molecular Biology, Francis Crick Avenue, 
Cambridge Biomedical Campus, Cambridge CB2 0QH
Chairman of International Union of Crystallography Commission on 
Crystallographic Computing
Chairman of European Crystallographic Association SIG9 (Crystallographic 
Computing) 












Re: [ccp4bb] XDS INP

2015-05-11 Thread Jurgen Bosch
Edit your XDS.INP file to look like this:

!JOB= XYCORR INIT COLSPOT IDXREF
JOB=DEFPIX INTEGRATE CORRECT

Then rerun ads and be happy thereafter.

and RTFM !

Jürgen
..
Jürgen Bosch
Johns Hopkins University
Bloomberg School of Public Health
Department of Biochemistry  Molecular Biology
Johns Hopkins Malaria Research Institute
615 North Wolfe Street, W8708
Baltimore, MD 21205
Office: +1-410-614-4742tel:%2B1-410-614-4742
Lab:  +1-410-614-4894tel:%2B1-410-614-4894
Fax:  +1-410-955-2926tel:%2B1-410-955-2926
http://lupo.jhsph.edu

On May 11, 2015, at 9:19 AM, Harry Powell 
ha...@mrc-lmb.cam.ac.ukmailto:ha...@mrc-lmb.cam.ac.uk wrote:

Hi Lu

Mosflm indexes your image using all defaults without any problems ;-)

XDS shouldn't have any difficulties with indexing this.

I suspect your crystal only diffracts to ~3.0 - 3.5 Å so you could do a better 
experiment by moving the detector back to ~ 900mm...

BUT - PLEASE don't attach your original images to messages to the BB  - anyone 
on a slow data link will be considerably indisposed by having an 8Mb attachment 
that they (most probably) really don't want to have.


On 11 May 2015, at 12:56, luzuok wrote:

Dear Karine and Jürgen,

The   XDS terminated in IDXREF with error message:

!! ERROR !!! INSUFFICIENT PERCENTAGE ( 50%) OF INDEXED REFLECTIONS

In the COLSPOT, I can see
NUMBER OF DIFFRACTION SPOTS LOCATED 53669
IGNORED BECAUSE OF SPOT MAXIMUM OUT OF CENTER 174
IGNORED BECAUSE OF SPOT CLOSE TO UNTRUSTED REGION 450
WEAK SPOTS OMITTED 11753
NUMBER OF DIFFRACTION SPOTS ACCEPTED 41292

It seems that the accepted spots are enough. But I don't know why there are so 
many spots which cannot be indexed.

Best wishes!

LU






--
卢作焜
南开大学新生物站A202

在 2015-05-11 16:49:53,Karine Sparta 
karine.spa...@helmholtz-berlin.demailto:karine.spa...@helmholtz-berlin.de 
写道:
Dear Lu,

I'm sorry to read that you couldn't process your data with XDSAPP.
I've been busy last week updating our webpage, the latest version of XDSAPP is 
now available for download since friday (an official announcement will be made 
tomorrow).
Maybe it will help with your data set, if not, I would be interested in the 
reason for the failure (IDXREF.LP), I may learn something from it to improve 
the next version.

Best regards,
Karine Sparta


On 05/10/15 10:30, luzuok wrote:
Dear all,
Thank you for all your excellent suggestions! The XDS package now works 
smoothly in xdsapp in my Linux.
Unfortunately, due to the data quality or maybe my ability, the process was 
failed.

Best wishes!

Lu Zuokun




--
卢作焜
南开大学新生物站A202


At 2015-05-08 03:39:07, Clemens Vonrhein 
vonrh...@globalphasing.commailto:vonrh...@globalphasing.com wrote:
Dear Lu,

apart from the other excellent advice you got: autoPROC is another
pipeline that uses XDS under the hood (among other tools) and tries to
take most of the pain out of getting started with XDS. For free (to
academics) licences/download please see

  http://www.globalphasing.com/autoproc/

Cheers

Clemens

On Thu, May 07, 2015 at 04:33:38PM +0800, luzuok wrote:
 Dear all,
 I'm a XDS beginner and the first problem I encounter was the INP file. 
 The detector type is MX300. Is the detector supported by XDS? How to 
 modified the INP file?
 The sitefile of HKL2000 was attached.
 Can anyone provide some tutorial to use XDS?

 Best wishes!

 Lu zuokun







 --
 卢作焜
 南开大学新生物站A202

 [-- octet-filter file type: ASCII text --]

 HKLSuite0.95SITE
 {alig,1} {180}
 {beamline_name} {BL17B}
 {cass,rotx} {-0.119}
 {cass,roty} {-0.167}
 {crossx} {0.044}
 {crossxy} {0.009}
 {crossy} {0.001}
 {detec} {CCD unsupported-m300}
 {extension} {*.mccd}
 {last_saved,chix} {3.24}
 {last_saved,chiy} {1.65}
 {last_saved,date} {17:11:17 Apr 19, 2015}
 {last_saved,user} {17bdata1}
 {polar} {0.99}
 {rotation_axis} {Phi}
 {synchrotron_name} {SSRF}
 {xbeam} {149.336}
 {y_scale} {1}
 {ybeam} {145.711}


--

***
* Clemens Vonrhein, Ph.D. vonrhein AT GlobalPhasing DOT com
*
*  Global Phasing Ltd.
*  Sheraton House, Castle Park
*  Cambridge CB3 0AX, UK
*--
* BUSTER Development Group  
(http://www.globalphasing.comhttp://www.globalphasing.com/)
***






--
Dr. Karine Sparta
Soft Matter and Functional Materials
Macromolecular Crystallography (BESSY-MX)
Elektronenspeicherring BESSY II
Albert-Einstein-Str. 15, D-12489 Berlin, Germany

Fon: +49 30 8062 14869
http://de.linkedin.com/pub/karine-sparta/2a/48/1b3/en



Helmholtz-Zentrum Berlin für Materialien und Energie GmbH

Mitglied der Hermann von Helmholtz-Gemeinschaft Deutscher Forschungszentren e.V.

Aufsichtsrat: Vorsitzender Prof. Dr. Dr. h.c. mult. Joachim Treusch, stv. 
Vorsitzende Dr. Beatrix Vierkorn-Rudolph
Geschäftsführung: Prof. Dr. Anke Rita Kaysser-Pyzalla, Thomas Frederking

Sitz Berlin, AG 

Re: [ccp4bb] XDS INP

2015-05-11 Thread Harry Powell
Hi Lu

Mosflm indexes your image using all defaults without any problems ;-)

XDS shouldn't have any difficulties with indexing this.

I suspect your crystal only diffracts to ~3.0 - 3.5 Å so you could do a better 
experiment by moving the detector back to ~ 900mm...

BUT - PLEASE don't attach your original images to messages to the BB  - anyone 
on a slow data link will be considerably indisposed by having an 8Mb attachment 
that they (most probably) really don't want to have.


On 11 May 2015, at 12:56, luzuok wrote:

 Dear Karine and Jürgen,
 
 The   XDS terminated in IDXREF with error message:

 !! ERROR !!! INSUFFICIENT PERCENTAGE ( 50%) OF INDEXED REFLECTIONS
 
 In the COLSPOT, I can see
 NUMBER OF DIFFRACTION SPOTS LOCATED 53669
 IGNORED BECAUSE OF SPOT MAXIMUM OUT OF CENTER 174
 IGNORED BECAUSE OF SPOT CLOSE TO UNTRUSTED REGION 450
 WEAK SPOTS OMITTED 11753
 NUMBER OF DIFFRACTION SPOTS ACCEPTED 41292
 
 It seems that the accepted spots are enough. But I don't know why there are 
 so many spots which cannot be indexed.
 
 Best wishes!
 
 LU
 
 
 
 
 
 
 --
 卢作焜
 南开大学新生物站A202
 
 在 2015-05-11 16:49:53,Karine Sparta karine.spa...@helmholtz-berlin.de 写道:
 Dear Lu,
 
 I'm sorry to read that you couldn't process your data with XDSAPP.
 I've been busy last week updating our webpage, the latest version of XDSAPP 
 is now available for download since friday (an official announcement will be 
 made tomorrow).
 Maybe it will help with your data set, if not, I would be interested in the 
 reason for the failure (IDXREF.LP), I may learn something from it to improve 
 the next version.
 
 Best regards,
 Karine Sparta
 
 
 On 05/10/15 10:30, luzuok wrote:
 Dear all,
 Thank you for all your excellent suggestions! The XDS package now works 
 smoothly in xdsapp in my Linux. 
 Unfortunately, due to the data quality or maybe my ability, the process was 
 failed. 
 
 Best wishes!
 
 Lu Zuokun
 
 
 
 
 --
 卢作焜
 南开大学新生物站A202
 
 At 2015-05-08 03:39:07, Clemens Vonrhein vonrh...@globalphasing.com 
 wrote:
 Dear Lu,
 
 apart from the other excellent advice you got: autoPROC is another
 pipeline that uses XDS under the hood (among other tools) and tries to
 take most of the pain out of getting started with XDS. For free (to
 academics) licences/download please see
 
   http://www.globalphasing.com/autoproc/
 
 Cheers
 
 Clemens
 
 On Thu, May 07, 2015 at 04:33:38PM +0800, luzuok wrote:
  Dear all,
  I'm a XDS beginner and the first problem I encounter was the INP 
  file. The detector type is MX300. Is the detector supported by XDS? How 
  to modified the INP file?
  The sitefile of HKL2000 was attached.
  Can anyone provide some tutorial to use XDS?
  
  Best wishes!
  
  Lu zuokun
  
  
  
  
  
  
  
  --
  卢作焜
  南开大学新生物站A202
 
  [-- octet-filter file type: ASCII text --]
  
  HKLSuite0.95SITE
  {alig,1} {180}
  {beamline_name} {BL17B}
  {cass,rotx} {-0.119}
  {cass,roty} {-0.167}
  {crossx} {0.044}
  {crossxy} {0.009}
  {crossy} {0.001}
  {detec} {CCD unsupported-m300}
  {extension} {*.mccd}
  {last_saved,chix} {3.24}
  {last_saved,chiy} {1.65}
  {last_saved,date} {17:11:17 Apr 19, 2015}
  {last_saved,user} {17bdata1}
  {polar} {0.99}
  {rotation_axis} {Phi}
  {synchrotron_name} {SSRF}
  {xbeam} {149.336}
  {y_scale} {1}
  {ybeam} {145.711}
 
 
 -- 
 
 ***
 * Clemens Vonrhein, Ph.D. vonrhein AT GlobalPhasing DOT com
 *
 *  Global Phasing Ltd.
 *  Sheraton House, Castle Park 
 *  Cambridge CB3 0AX, UK
 *--
 * BUSTER Development Group  (http://www.globalphasing.com)
 ***
 
 
 
 
 -- 
 Dr. Karine Sparta
 Soft Matter and Functional Materials
 Macromolecular Crystallography (BESSY-MX)
 Elektronenspeicherring BESSY II
 Albert-Einstein-Str. 15, D-12489 Berlin, Germany
 
 Fon: +49 30 8062 14869
 http://de.linkedin.com/pub/karine-sparta/2a/48/1b3/en
 
 
 Helmholtz-Zentrum Berlin für Materialien und Energie GmbH
 
 Mitglied der Hermann von Helmholtz-Gemeinschaft Deutscher Forschungszentren 
 e.V.
 
 Aufsichtsrat: Vorsitzender Prof. Dr. Dr. h.c. mult. Joachim Treusch, stv. 
 Vorsitzende Dr. Beatrix Vierkorn-Rudolph
 Geschäftsführung: Prof. Dr. Anke Rita Kaysser-Pyzalla, Thomas Frederking
 
 Sitz Berlin, AG Charlottenburg, 89 HRB 5583
 
 Postadresse:
 Hahn-Meitner-Platz 1
 D-14109 Berlin
 
 http://www.helmholtz-berlin.de
 
 
 
 
 IDXREF.LPhg6_L1_1_1.mccdSPOT.XDS

Harry
--
Dr Harry Powell, MRC Laboratory of Molecular Biology, Francis Crick Avenue, 
Cambridge Biomedical Campus, Cambridge CB2 0QH
Chairman of International Union of Crystallography Commission on 
Crystallographic Computing
Chairman of European Crystallographic Association SIG9 (Crystallographic 
Computing) 












Re: [ccp4bb] XDS INP

2015-05-11 Thread Kay Diederichs
Hi LU,

the reason why IDXREF is not indexing smoothly is that the spot positions in 
your SPOT.XDS are not very meaningful - you pick up a lot of noise! I plotted 
your SPOT.XDS using

%%:-/tmp/luo% gnuplot
gnuplot set size square
gnuplot set out tmp.png
gnuplot  set term png nocrop medium size 1280,960
Terminal type set to 'png'
Options are 'nocrop medium size 1280,960 '
gnuplot plot 'SPOT.XDS' us 1:2 w dots
gnuplot quit

and got the attached file tmp.png. This shows:
- ice rings
- streaks parallel to the x-axis 
- some modules of the detector behave very differently from others

Poor IDXREF tries to make sense of all of this and still somehow manages to 
come up with something that may be useful for further processing.
But the real remedy of the problems would be to properly set the parameters 
influencing the COLSPOT step. These are documented at 
http://homes.mpimf-heidelberg.mpg.de/~kabsch/xds/html_doc/xds_parameters.html 
(load the page into your browser, and search for occurrences of COLSPOT). The 
most important ones in this case are probably
MINIMUM_NUMBER_OF_PIXELS_IN_A_SPOT=6  ! this is the default
STRONG_PIXEL=3! this is 
the default
INCLUDE_RESOLUTION_RANGE =50 0 ! no default, but you could try 50 4 to 
exclude the ice rings
I don't know which values you used (you forgot to post XDS.INP), so I would try 
with the above first, run COLSPOT, inspect with the gnuplot technique I 
described, and then modify the parameters until the plot looks more meaningful, 
at which point IDXREF will most likely happily index.

No, this is not fully automatic, but at least it's a logical way forward.

good luck,

Kay 


On Mon, 11 May 2015 19:56:33 +0800, luzuok luzuo...@126.com wrote:

 Dear Karine and Jürgen,
 
 The   XDS terminated in IDXREF with error message:

 
 !! ERROR !!! INSUFFICIENT PERCENTAGE ( 50%) OF INDEXED REFLECTIONS
 
 
 In the COLSPOT, I can see
 
 NUMBER OF DIFFRACTION SPOTS LOCATED 53669
 
 IGNORED BECAUSE OF SPOT MAXIMUM OUT OF CENTER 174
 
 IGNORED BECAUSE OF SPOT CLOSE TO UNTRUSTED REGION 450
 
 WEAK SPOTS OMITTED 11753
 
 NUMBER OF DIFFRACTION SPOTS ACCEPTED 41292
 
 
 It seems that the accepted spots are enough. But I don't know why there
 are so many spots which cannot be indexed.
 
 
 Best wishes!
 
 
 LU
 





[ccp4bb] AW: [ccp4bb] XDS INP

2015-05-11 Thread Herman . Schreuder
Dear Jürgen and Lu,



I am not sure IDXREF found the correct solution (taken from IDXREF.LP):



* INDEXING OF OBSERVED SPOTS IN SPACE GROUP #   3 *
2372 OUT OF   40947 SPOTS INDEXED.
   3 REJECTED REFLECTIONS (REASON: OVERLAP)
   38572 REJECTED REFLECTIONS (REASON: TOO FAR FROM IDEAL POSITION)
EXPECTED ERROR IN SPINDLE  POSITION 1.159 DEGREES
EXPECTED ERROR IN DETECTOR POSITION  1.67 PIXELS

Only ~2,000 reflections out of ~40,000 indexed with a relatively large error in 
spindle position and detector position.  I would check that the direct beam 
position in XDS.INP is correct and maybe try to only index the first 30° of 
data or so to get the orientation. This orientation can then be used to process 
the full data set. You may also try to give the cell parameters obtained from 
HKL2000 into your input file. In the XDS wiki should be many tips and tricks 
what you could do. You may even process with Mosflm and see what comes out here.

Best,
Herman


Von: CCP4 bulletin board [mailto:CCP4BB@JISCMAIL.AC.UK] Im Auftrag von Jurgen 
Bosch
Gesendet: Montag, 11. Mai 2015 15:57
An: CCP4BB@JISCMAIL.AC.UK
Betreff: Re: [ccp4bb] XDS INP

Edit your XDS.INP file to look like this:

!JOB= XYCORR INIT COLSPOT IDXREF
JOB=DEFPIX INTEGRATE CORRECT

Then rerun ads and be happy thereafter.

and RTFM !

Jürgen
..
Jürgen Bosch
Johns Hopkins University
Bloomberg School of Public Health
Department of Biochemistry  Molecular Biology
Johns Hopkins Malaria Research Institute
615 North Wolfe Street, W8708
Baltimore, MD 21205
Office: +1-410-614-4742tel:%2B1-410-614-4742
Lab:  +1-410-614-4894tel:%2B1-410-614-4894
Fax:  +1-410-955-2926tel:%2B1-410-955-2926
http://lupo.jhsph.edu

On May 11, 2015, at 9:19 AM, Harry Powell 
ha...@mrc-lmb.cam.ac.ukmailto:ha...@mrc-lmb.cam.ac.uk wrote:

Hi Lu

Mosflm indexes your image using all defaults without any problems ;-)

XDS shouldn't have any difficulties with indexing this.

I suspect your crystal only diffracts to ~3.0 - 3.5 Å so you could do a better 
experiment by moving the detector back to ~ 900mm...

BUT - PLEASE don't attach your original images to messages to the BB  - anyone 
on a slow data link will be considerably indisposed by having an 8Mb attachment 
that they (most probably) really don't want to have.


On 11 May 2015, at 12:56, luzuok wrote:


Dear Karine and Jürgen,

The   XDS terminated in IDXREF with error message:

!! ERROR !!! INSUFFICIENT PERCENTAGE ( 50%) OF INDEXED REFLECTIONS

In the COLSPOT, I can see
NUMBER OF DIFFRACTION SPOTS LOCATED 53669
IGNORED BECAUSE OF SPOT MAXIMUM OUT OF CENTER 174
IGNORED BECAUSE OF SPOT CLOSE TO UNTRUSTED REGION 450
WEAK SPOTS OMITTED 11753
NUMBER OF DIFFRACTION SPOTS ACCEPTED 41292

It seems that the accepted spots are enough. But I don't know why there are so 
many spots which cannot be indexed.

Best wishes!

LU





--
卢作焜
南开大学新生物站A202

在 2015-05-11 16:49:53,Karine Sparta 
karine.spa...@helmholtz-berlin.demailto:karine.spa...@helmholtz-berlin.de 
写道:

Dear Lu,

I'm sorry to read that you couldn't process your data with XDSAPP.
I've been busy last week updating our webpage, the latest version of XDSAPP is 
now available for download since friday (an official announcement will be made 
tomorrow).
Maybe it will help with your data set, if not, I would be interested in the 
reason for the failure (IDXREF.LP), I may learn something from it to improve 
the next version.

Best regards,
Karine Sparta


On 05/10/15 10:30, luzuok wrote:
Dear all,
Thank you for all your excellent suggestions! The XDS package now works 
smoothly in xdsapp in my Linux.
Unfortunately, due to the data quality or maybe my ability, the process was 
failed.

Best wishes!

Lu Zuokun



--
卢作焜
南开大学新生物站A202


At 2015-05-08 03:39:07, Clemens Vonrhein 
vonrh...@globalphasing.commailto:vonrh...@globalphasing.com wrote:

Dear Lu,



apart from the other excellent advice you got: autoPROC is another

pipeline that uses XDS under the hood (among other tools) and tries to

take most of the pain out of getting started with XDS. For free (to

academics) licences/download please see



  http://www.globalphasing.com/autoproc/



Cheers



Clemens



On Thu, May 07, 2015 at 04:33:38PM +0800, luzuok wrote:

 Dear all,

 I'm a XDS beginner and the first problem I encounter was the INP file. 
 The detector type is MX300. Is the detector supported by XDS? How to 
 modified the INP file?

 The sitefile of HKL2000 was attached.

 Can anyone provide some tutorial to use XDS?



 Best wishes!



 Lu zuokun















 --

 卢作焜

 南开大学新生物站A202



 [-- octet-filter file type: ASCII text --]



 HKLSuite0.95SITE

 {alig,1} {180}

 {beamline_name} {BL17B}

 {cass,rotx} {-0.119}

 {cass,roty} {-0.167}

 {crossx} {0.044}

 {crossxy} {0.009}

 {crossy} {0.001}

 {detec} {CCD unsupported-m300}

 {extension} {*.mccd}

 {last_saved,chix} {3.24}

 {last_saved,chiy} {1.65}

 {last_saved,date} {17:11:17 Apr 19, 2015}

 {last_saved

Re: [ccp4bb] XDS INP

2015-05-10 Thread luzuok
Dear all,
Thank you for all your excellent suggestions! The XDS package now works 
smoothly in xdsapp in my Linux. 
Unfortunately, due to the data quality or maybe my ability, the process was 
failed. 


Best wishes!


Lu Zuokun





--
卢作焜
南开大学新生物站A202



At 2015-05-08 03:39:07, Clemens Vonrhein vonrh...@globalphasing.com wrote:
Dear Lu,

apart from the other excellent advice you got: autoPROC is another
pipeline that uses XDS under the hood (among other tools) and tries to
take most of the pain out of getting started with XDS. For free (to
academics) licences/download please see

  http://www.globalphasing.com/autoproc/

Cheers

Clemens

On Thu, May 07, 2015 at 04:33:38PM +0800, luzuok wrote:
 Dear all,
 I'm a XDS beginner and the first problem I encounter was the INP file. 
 The detector type is MX300. Is the detector supported by XDS? How to 
 modified the INP file?
 The sitefile of HKL2000 was attached.
 Can anyone provide some tutorial to use XDS?
 
 Best wishes!
 
 Lu zuokun
 
 
 
 
 
 
 
 --
 卢作焜
 南开大学新生物站A202

 [-- octet-filter file type: ASCII text --]
 
 HKLSuite0.95SITE
 {alig,1} {180}
 {beamline_name} {BL17B}
 {cass,rotx} {-0.119}
 {cass,roty} {-0.167}
 {crossx} {0.044}
 {crossxy} {0.009}
 {crossy} {0.001}
 {detec} {CCD unsupported-m300}
 {extension} {*.mccd}
 {last_saved,chix} {3.24}
 {last_saved,chiy} {1.65}
 {last_saved,date} {17:11:17 Apr 19, 2015}
 {last_saved,user} {17bdata1}
 {polar} {0.99}
 {rotation_axis} {Phi}
 {synchrotron_name} {SSRF}
 {xbeam} {149.336}
 {y_scale} {1}
 {ybeam} {145.711}


-- 

***
* Clemens Vonrhein, Ph.D. vonrhein AT GlobalPhasing DOT com
*
*  Global Phasing Ltd.
*  Sheraton House, Castle Park 
*  Cambridge CB3 0AX, UK
*--
* BUSTER Development Group  (http://www.globalphasing.com)
***


Re: [ccp4bb] XDS INP

2015-05-10 Thread Jurgen Bosch
The process failed.
You mean it didn’t process the data past the indexing routine?
That just means you need to actually change some values and type in a couple of 
commands into XDS.INP - not everything can be designed to be point  click.

Look at IDXREF.LP and check out what the suggested space group is, then change 
that in XDS.INP and provide the correct cell dimensions. Change the JOB card to 
start with DEFPIX and remove the previous sub routines.

Look at the manual of XDS on Kabsch’s website.

Jürgen
..
Jürgen Bosch
Johns Hopkins University
Bloomberg School of Public Health
Department of Biochemistry  Molecular Biology
Johns Hopkins Malaria Research Institute
615 North Wolfe Street, W8708
Baltimore, MD 21205
Office: +1-410-614-4742tel:%2B1-410-614-4742
Lab:  +1-410-614-4894tel:%2B1-410-614-4894
Fax:  +1-410-955-2926tel:%2B1-410-955-2926
http://lupo.jhsph.edu

On May 10, 2015, at 4:30 AM, luzuok luzuo...@126.commailto:luzuo...@126.com 
wrote:

Dear all,
Thank you for all your excellent suggestions! The XDS package now works 
smoothly in xdsapp in my Linux.
Unfortunately, due to the data quality or maybe my ability, the process was 
failed.

Best wishes!

Lu Zuokun




--
卢作焜
南开大学新生物站A202


At 2015-05-08 03:39:07, Clemens Vonrhein 
vonrh...@globalphasing.commailto:vonrh...@globalphasing.com wrote:
Dear Lu,

apart from the other excellent advice you got: autoPROC is another
pipeline that uses XDS under the hood (among other tools) and tries to
take most of the pain out of getting started with XDS. For free (to
academics) licences/download please see

  http://www.globalphasing.com/autoproc/

Cheers

Clemens

On Thu, May 07, 2015 at 04:33:38PM +0800, luzuok wrote:
 Dear all,
 I'm a XDS beginner and the first problem I encounter was the INP file. 
 The detector type is MX300. Is the detector supported by XDS? How to 
 modified the INP file?
 The sitefile of HKL2000 was attached.
 Can anyone provide some tutorial to use XDS?

 Best wishes!

 Lu zuokun







 --
 卢作焜
 南开大学新生物站A202

 [-- octet-filter file type: ASCII text --]

 HKLSuite0.95SITE
 {alig,1} {180}
 {beamline_name} {BL17B}
 {cass,rotx} {-0.119}
 {cass,roty} {-0.167}
 {crossx} {0.044}
 {crossxy} {0.009}
 {crossy} {0.001}
 {detec} {CCD unsupported-m300}
 {extension} {*.mccd}
 {last_saved,chix} {3.24}
 {last_saved,chiy} {1.65}
 {last_saved,date} {17:11:17 Apr 19, 2015}
 {last_saved,user} {17bdata1}
 {polar} {0.99}
 {rotation_axis} {Phi}
 {synchrotron_name} {SSRF}
 {xbeam} {149.336}
 {y_scale} {1}
 {ybeam} {145.711}


--

***
* Clemens Vonrhein, Ph.D. vonrhein AT GlobalPhasing DOT com
*
*  Global Phasing Ltd.
*  Sheraton House, Castle Park
*  Cambridge CB3 0AX, UK
*--
* BUSTER Development Group  (http://www.globalphasing.com)
***






[ccp4bb] XDS INP

2015-05-07 Thread luzuok
Dear all,
I'm a XDS beginner and the first problem I encounter was the INP file. The 
detector type is MX300. Is the detector supported by XDS? How to modified the 
INP file?
The sitefile of HKL2000 was attached.
Can anyone provide some tutorial to use XDS?

Best wishes!

Lu zuokun







--
卢作焜
南开大学新生物站A202

def.site
Description: Binary data


[ccp4bb] Fwd: [ccp4bb] XDS INP

2015-05-07 Thread Fulvio Saccoccia, Sapienza
Dear Lu
   you can freely download the tutorial from here: 
http://strucbio.biologie.uni-konstanz.de/xdswiki/index.php/Main_Page 
You can check if your detector is supported here: 
http://xds.mpimf-heidelberg.mpg.de/html_doc/detectors.htm

Best
Fulvio


 Il giorno 07/mag/2015, alle ore 10:33, luzuok luzuo...@126.com ha scritto:
 
 Dear all,
 I'm a XDS beginner and the first problem I encounter was the INP file. 
 The detector type is MX300. Is the detector supported by XDS? How to 
 modified the INP file?
 The sitefile of HKL2000 was attached.
 Can anyone provide some tutorial to use XDS?
 
 Best wishes!
 
 Lu zuokun
 
 
 
 
 
 --
 卢作焜
 南开大学新生物站A202
 
 
 def.site
 



Re: [ccp4bb] XDS INP

2015-05-07 Thread Tim Gruene
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Dear  Lu zuokun,

the web site
http://homes.mpimf-heidelberg.mpg.de/~kabsch/xds/html_doc/detectors.html
lists all the detectors supported by XDS.

There are some graphical user interfaces for XDS which are very good
not only for beginners.

One I can recommend is XDSGUI by Kay Diederichs, available at
http://strucbio.biologie.uni-konstanz.de/xdswiki/index.php/XDSGUI

Another one is xdsapp
(http://www.helmholtz-berlin.de/forschung/oe/em/soft-matter/forschung/bessy-mx/xdsapp/index_en.html)

I recommend trying one of those to get started.

Best,
Tim

On 05/07/2015 10:33 AM, luzuok wrote:
 Dear all, I'm a XDS beginner and the first problem I encounter was
 the INP file. The detector type is MX300. Is the detector supported
 by XDS? How to modified the INP file? The sitefile of HKL2000 was
 attached. Can anyone provide some tutorial to use XDS?
 
 Best wishes!
 
 Lu zuokun
 
 
 
 
 
 
 
 -- 卢作焜 南开大学新生物站A202
 

- -- 
- --
Dr Tim Gruene
Institut fuer anorganische Chemie
Tammannstr. 4
D-37077 Goettingen
phone: +49 (0)551 39 22149

GPG Key ID = A46BEE1A

-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iD8DBQFVSynzUxlJ7aRr7hoRAltsAKCTWwhMYIJxcnEPrtuR4bK1SIdx0wCg63xi
xuj+552PZUl2GDkyb75P3QQ=
=bJ7y
-END PGP SIGNATURE-


Re: [ccp4bb] XDS INP

2015-05-07 Thread luzuok
Dear Fred,
 Actually I'm not very sure the detector type is MX300. The site file of 
HKL2000 is in the folder called MX300. I guess the detector is MX300 because 
there are another folder call PILATUS6M.
In the def.site, I can see
{dectec} {CCD unsupported-m300}.
And there seems no m300 dectector supported by XDS.



Regards!
Lu



--
卢作焜
南开大学新生物站A202

在 2015-05-07 16:59:36,vellieux frederic.velli...@ibs.fr 写道:

Hi,

I don't know what an MX300 detector is. From the template input files provided 
with XDS, I see the following:

XDS-ADSC.INP XDS-MAR345.INP  XDS-PILATUS_200K.INPXDS-SATURN.INP
XDS-BRANDEIS_B4.INP  XDS-MAR555.INP  XDS-PILATUS.INPXDS-SIEMENS.INP
XDS-CCDBRANDEIS.INP  XDS-MARCCD.INPXDS-RAXIS2.INP  XDS-SMARTCCD.INP
XDS-MAR.INPXDS-RAXIS4.INP  XDS-STOE.INP
XDS-Eiger.INP  XDS-PILATUS_12M.INPXDS-RAXIS5.INP

Normally what you do is to copy one of the above XDS input files (corresponding 
to your detector) to a file called XDS.INP and modify that in order to fix any 
changes in detector size, number of pixels... (if necessary - normally it 
shouldn't be) and to provide the correct data to XDS.

Hope this helps,

Fred.

On 07/05/15 10:33, luzuok wrote:

Dear all,
I'm a XDS beginner and the first problem I encounter was the INP file. The 
detector type is MX300. Is the detector supported by XDS? How to modified the 
INP file?
The sitefile of HKL2000 was attached.
Can anyone provide some tutorial to use XDS?

Best wishes!

Lu zuokun







--
卢作焜
南开大学新生物站A202





-- 
Fred. Vellieux (B.Sc., Ph.D., hdr)

IBS / ELMA
Campus EPN
71 avenue des Martyrs
CS 10090
F-38044 Grenoble Cedex 9
Tel: +33 457428605
Fax: +33 476501890

Re: [ccp4bb] XDS INP

2015-05-07 Thread Graeme Winter
Dear All,

Starting from here I would just use the generate_XDS.INP script developed
by Kay Diederichs:

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

It will make the necessary input files from just the image headers.

best wishes Graeme

On Thu, May 7, 2015 at 11:34 AM Tim Gruene t...@shelx.uni-ac.gwdg.de wrote:

 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1

 Dear Lu,

 according to the file ending (mccd) in the def-file, you collected
 data with a MAR CCD detector. The template file XDS-MARCCD.INP handles
 those. The pixel size, etc. are taken automatically from the frame
 headers. This detector type is also supported by XDSGUI which would
 generate XDS.INP for you.

 Best,
 Tim

 On 05/07/2015 11:19 AM, luzuok wrote:
  Dear Fred, Actually I'm not very sure the detector type is MX300.
  The site file of HKL2000 is in the folder called MX300. I guess
  the detector is MX300 because there are another folder call
  PILATUS6M. In the def.site, I can see {dectec} {CCD
  unsupported-m300}. And there seems no m300 dectector supported by
  XDS.
 
 
 
  Regards! Lu
 
 
 
  -- 卢作焜 南开大学新生物站A202
 
  在 2015-05-07 16:59:36,vellieux frederic.velli...@ibs.fr 写道:
 
  Hi,
 
  I don't know what an MX300 detector is. From the template input
  files provided with XDS, I see the following:
 
  XDS-ADSC.INP XDS-MAR345.INP  XDS-PILATUS_200K.INP
  XDS-SATURN.INP XDS-BRANDEIS_B4.INP  XDS-MAR555.INP XDS-PILATUS.INP
  XDS-SIEMENS.INP XDS-CCDBRANDEIS.INP XDS-MARCCD.INP
  XDS-RAXIS2.INP  XDS-SMARTCCD.INP XDS-MAR.INP XDS-RAXIS4.INP
  XDS-STOE.INP XDS-Eiger.INP XDS-PILATUS_12M.INPXDS-RAXIS5.INP
 
  Normally what you do is to copy one of the above XDS input files
  (corresponding to your detector) to a file called XDS.INP and
  modify that in order to fix any changes in detector size, number
  of pixels... (if necessary - normally it shouldn't be) and to
  provide the correct data to XDS.
 
  Hope this helps,
 
  Fred.
 
  On 07/05/15 10:33, luzuok wrote:
 
  Dear all, I'm a XDS beginner and the first problem I encounter was
  the INP file. The detector type is MX300. Is the detector
  supported by XDS? How to modified the INP file? The sitefile of
  HKL2000 was attached. Can anyone provide some tutorial to use XDS?
 
  Best wishes!
 
  Lu zuokun
 
 
 
 
 
 
 
  -- 卢作焜 南开大学新生物站A202
 
 
 
 
 

 - --
 - --
 Dr Tim Gruene
 Institut fuer anorganische Chemie
 Tammannstr. 4
 D-37077 Goettingen
 phone: +49 (0)551 39 22149

 GPG Key ID = A46BEE1A

 -BEGIN PGP SIGNATURE-
 Version: GnuPG v1

 iD8DBQFVSz7zUxlJ7aRr7hoRAgqcAJsH6Rgrs9mDcvlYZ3ObFV1Q4+FSVACfRwH3
 BZ2l+s1kRKwsh2qWaih0rxg=
 =Nulf
 -END PGP SIGNATURE-



Re: [ccp4bb] XDS INP

2015-05-07 Thread Tim Gruene
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Dear Lu,

according to the file ending (mccd) in the def-file, you collected
data with a MAR CCD detector. The template file XDS-MARCCD.INP handles
those. The pixel size, etc. are taken automatically from the frame
headers. This detector type is also supported by XDSGUI which would
generate XDS.INP for you.

Best,
Tim

On 05/07/2015 11:19 AM, luzuok wrote:
 Dear Fred, Actually I'm not very sure the detector type is MX300. 
 The site file of HKL2000 is in the folder called MX300. I guess
 the detector is MX300 because there are another folder call
 PILATUS6M. In the def.site, I can see {dectec} {CCD
 unsupported-m300}. And there seems no m300 dectector supported by
 XDS.
 
 
 
 Regards! Lu
 
 
 
 -- 卢作焜 南开大学新生物站A202
 
 在 2015-05-07 16:59:36,vellieux frederic.velli...@ibs.fr 写道:
 
 Hi,
 
 I don't know what an MX300 detector is. From the template input 
 files provided with XDS, I see the following:
 
 XDS-ADSC.INP XDS-MAR345.INP  XDS-PILATUS_200K.INP 
 XDS-SATURN.INP XDS-BRANDEIS_B4.INP  XDS-MAR555.INP XDS-PILATUS.INP
 XDS-SIEMENS.INP XDS-CCDBRANDEIS.INP XDS-MARCCD.INP
 XDS-RAXIS2.INP  XDS-SMARTCCD.INP XDS-MAR.INP XDS-RAXIS4.INP
 XDS-STOE.INP XDS-Eiger.INP XDS-PILATUS_12M.INPXDS-RAXIS5.INP
 
 Normally what you do is to copy one of the above XDS input files 
 (corresponding to your detector) to a file called XDS.INP and 
 modify that in order to fix any changes in detector size, number
 of pixels... (if necessary - normally it shouldn't be) and to
 provide the correct data to XDS.
 
 Hope this helps,
 
 Fred.
 
 On 07/05/15 10:33, luzuok wrote:
 
 Dear all, I'm a XDS beginner and the first problem I encounter was 
 the INP file. The detector type is MX300. Is the detector
 supported by XDS? How to modified the INP file? The sitefile of
 HKL2000 was attached. Can anyone provide some tutorial to use XDS?
 
 Best wishes!
 
 Lu zuokun
 
 
 
 
 
 
 
 -- 卢作焜 南开大学新生物站A202
 
 
 
 
 

- -- 
- --
Dr Tim Gruene
Institut fuer anorganische Chemie
Tammannstr. 4
D-37077 Goettingen
phone: +49 (0)551 39 22149

GPG Key ID = A46BEE1A

-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iD8DBQFVSz7zUxlJ7aRr7hoRAgqcAJsH6Rgrs9mDcvlYZ3ObFV1Q4+FSVACfRwH3
BZ2l+s1kRKwsh2qWaih0rxg=
=Nulf
-END PGP SIGNATURE-


Re: [ccp4bb] XDS Processing with Translated Detector and Radiation Sensitive Crystals

2015-04-16 Thread Fischmann, Thierry
- Regarding very low or very large unit cell after indexing in HKL2000 :

This behavior can be triggered by having either too many reflections (too many 
increases the chance that some are artefacts which are going to misled the 
indexing), or too few, respectively.

Editing the peak search results accordingly should help.

Sometimes it is useful to use other strategies. For instance scan the images 
and look for cleaner ones (5 images at 0.1° each won't help within a small 
set).

The trick is to index correctly a specific frame *anywhere* in the data set 
than use the integration parameters from this one frame to integrate the whole 
pack in one swell run. 

Another approach : sometimes satellite(s) yield detectable diffraction at low 
resolution but not at higher resolution. In this case you may choose a higher 
low resolution limit as the diffraction pattern warrants.

Integrating by 5 may more appropriate in your case. Once comment about 
helical data collection : in unusual situations (I've seen it occurring only 
for 1 system so far) the crystal has such mosaicity that the changes of 
orientation between two different pieces of crystals are elevated. HKL2000 may 
lose the indexing in the middle of the run. This requires that you process the 
datasets in several parts. Nonetheless you should not have to go back to 
indexing every 5 frames.

Be sure to properly parameter scaling to the 5 frame per pack data collection 
approach.

Hope this is of use.
Good luck
Thierry


-Original Message-
From: CCP4 bulletin board [mailto:CCP4BB@JISCMAIL.AC.UK] On Behalf Of 
Christopher Barnes
Sent: Thursday, April 16, 2015 4:38 PM
To: CCP4BB@JISCMAIL.AC.UK
Subject: [ccp4bb] XDS Processing with Translated Detector and Radiation 
Sensitive Crystals

Hi all,

I am having trouble processing synchrotron data with XDS for a large unit cell 
protein complex (Spacegroup P2, Cell 225 x 256 x 430). My crystals diffract to 
3.1 Angstrom, but at this resolution we had significant spatial overlaps. To 
alleviate this we translated the detector 40 mm in both the x and y directions 
to achieve higher resolution at a distance of 850mm (on a Pilatus 6M detector), 
as well as used fine slicing (0.1 degree) for data collection. In addition, our 
crystals are highly radiation sensitive, so we use vector data collection 
strategies to expose untouched crystal volumes to the beam to maintain high 
resolution diffraction. This usually allows us to get 5 frames/spot before 
moving to a new location due to radiation damage. 

However, during my processing with XDS, integration results in very low 
I/sigma, even at low resolution (ie a value of 1.8), even though we have high 
intensity reflections that are significantly above the background. 

Looking at the INTEGRATE.LP and CORRECT.LP, with the refined unit cell 
parameters the standard deviation of spot pixels is 1.15 and standard deviation 
of spindle position is 0.20. However, the average three-dimensional profile of 
strong reflections is usually missing spots in 3-4 out of the 9 boxes.

A check of the detector origin corresponds with the new beam position (967, 
1511) in all the log files. 

Any help or insight into processing with a translated detector or radiation 
sensitive crystals would be helpful. We have tried to use HKL and iMosflm, but 
neither program provides a consistent indexing solution (usually can identify a 
 b dimensions correctly, but they widely vary in c dimension, sometimes very 
low (ie 35) or sometimes very high (ie 660).

Thanks,
Christopher

Graduate Student - Department of Structural Biology
University of Pittsburgh - School of Medicine
3501 Fifth Avenue
BST3, Rm 1043
Pittsburgh, PA 15260
email: co...@pitt.edu
work: 412-648-8542
Notice:  This e-mail message, together with any attachments, contains
information of Merck  Co., Inc. (2000 Galloping Hill Road, Kenilworth,
New Jersey, USA 07033), and/or its affiliates Direct contact information
for affiliates is available at 
http://www.merck.com/contact/contacts.html) that may be confidential,
proprietary copyrighted and/or legally privileged. It is intended solely
for the use of the individual or entity named on this message. If you are
not the intended recipient, and have received this message in error,
please notify us immediately by reply e-mail and then delete it from 
your system.


[ccp4bb] XDS Processing with Translated Detector and Radiation Sensitive Crystals

2015-04-16 Thread Christopher Barnes
Hi all,

I am having trouble processing synchrotron data with XDS for a large unit cell 
protein complex (Spacegroup P2, Cell 225 x 256 x 430). My crystals diffract to 
3.1 Angstrom, but at this resolution we had significant spatial overlaps. To 
alleviate this we translated the detector 40 mm in both the x and y directions 
to achieve higher resolution at a distance of 850mm (on a Pilatus 6M detector), 
as well as used fine slicing (0.1 degree) for data collection. In addition, our 
crystals are highly radiation sensitive, so we use vector data collection 
strategies to expose untouched crystal volumes to the beam to maintain high 
resolution diffraction. This usually allows us to get 5 frames/spot before 
moving to a new location due to radiation damage. 

However, during my processing with XDS, integration results in very low 
I/sigma, even at low resolution (ie a value of 1.8), even though we have high 
intensity reflections that are significantly above the background. 

Looking at the INTEGRATE.LP and CORRECT.LP, with the refined unit cell 
parameters the standard deviation of spot pixels is 1.15 and standard deviation 
of spindle position is 0.20. However, the average three-dimensional profile of 
strong reflections is usually missing spots in 3-4 out of the 9 boxes.

A check of the detector origin corresponds with the new beam position (967, 
1511) in all the log files. 

Any help or insight into processing with a translated detector or radiation 
sensitive crystals would be helpful. We have tried to use HKL and iMosflm, but 
neither program provides a consistent indexing solution (usually can identify a 
 b dimensions correctly, but they widely vary in c dimension, sometimes very 
low (ie 35) or sometimes very high (ie 660).

Thanks,
Christopher

Graduate Student - Department of Structural Biology
University of Pittsburgh - School of Medicine
3501 Fifth Avenue
BST3, Rm 1043
Pittsburgh, PA 15260
email: co...@pitt.edu
work: 412-648-8542


Re: [ccp4bb] XDS Processing with Translated Detector and Radiation Sensitive Crystals

2015-04-16 Thread Jurgen Bosch
Hi Christopher,

you should also limit the resolution to say 6 A on the first pass to get your 
correct cell parameters. Your low I/sigI suggests that the indexing did not 
pick up the correct orientation of the crystal. You should also see this in 
your INTEGRATE.LP file if you look at the spot profiles. In your case they 
should look pretty flat instead of a nice three dimensional peak.

Here’s an example how it should look like:
 0  0  0 -1 -1  0  0  3  2  0  0  0  0 0  0  0 -1 -1  0  1  3  3  0  0  0  
0 0  0  0 -1 -1  0  1  3  2  0  0  0  0
 0  0  0  0  0  0  1  5  4  0 -2  0  0 0  0  0  0  0  0  2  5  4  0 -1  
0  0 0  0  0  0 -1  0  2  4  3  0 -1  0  0
 0  0  0  0  0  0  3  9  7  1 -2 -3  0 0  0  0  0 -1  0  4  9  6  0 -2 
-2  0 0  0  0 -1 -1  0  3  7  5  0 -1 -2  0
 0  0  0  0  0  0  7 18 12  2 -2 -4  0 0  0  0  0  0  1  7 16  9  1 -2 
-3  0 0  0  0  0  0  1  6 12  6  0 -2 -2  0
 0  0  0  0  0  2 16 35 20  3 -2 -4 -4 0  0  0  0  0  2 15 29 14  2 -2 
-3 -2 0  0  0  0  0  2 12 19  8  0 -1 -2 -2
 0  0  0  0  0  6 39 65 28  5 -1 -4 -5 0  0  0  0  1  5 32 50 19  2 -1 
-3 -4 0  0  0 -1  0  4 22 28  9  1 -1 -2 -3
 0 -1 -1  0  1 11 75100 34  5 -2 -4 -4 0  0  0  0  1 10 58 72 22  3 -1 
-3 -3 0  0  0  0  0  6 30 33 10  1 -1 -2 -2
 0 -1 -1 -1  1 15 88100 30  3 -2 -4 -4 0  0 -1 -1  1 12 68 76 21  2 -2 
-3 -4 0  0 -1  0  0  5 27 32  9  0 -1 -2 -3
 0 -1 -1 -1  0 13 67 66 16  0 -3 -4 -5-1 -1 -1 -1  0 10 51 53 14  0 -2 
-4 -4 0  0 -1 -1  0  4 19 22  6  0 -1 -2 -3
 0 -1 -1 -1  0  8 38 34  6 -2 -4 -5  0 0 -1 -1  0  0  7 29 28  6 -1 -3 
-4  0 0  0  0 -1  0  3 13 13  2 -1 -1 -2  0
 0 -1 -1 -1  0  3 17 14  1 -3 -4 -5  0 0 -1 -1  0  0  3 14 11  1 -2 -3 
-4  0 0 -1  0  0  0  2  8  7  0 -1 -1 -2  0
 0  0 -2 -1 -1  1  6  5 -1 -3 -4  0  0 0  0 -1 -1  0  2  6  4 -1 -2 -2  
0  0 0  0 -1  0  0  2  4  3 -1 -2 -1  0  0
 0  0  0 -2 -1  0  3  2 -2 -3  0  0  0 0  0  0 -3 -1  0  3  2 -2 -2  0  
0  0 0  0  0 -2  0  1  3  1 -1 -1  0  0  0
yours might look like this perhaps:
 0  0  0  0  1  0  0  0  1  0  0  0  0 0  0  0  0  0  0  0  1  2  0  0  
0  0 0  0  0  0  0 -1 -1  1  2  1  0  0  0
 0  0  0  0  0  0  0  1  1  1  0  0  0 0  0  0 -1  0  0  0  2  2  1  0  
0  0 0  0  0 -1 -1  0  0  3  3  1  0  0  0
 0  0  0  0  0  0  0  1  1  1  1  0  0 0  0  0 -1  0  0  1  3  2  1  0 
-1  0 0 -1 -1 -1 -1  0  1  4  4  2  0 -1  0
 0  0  0  0  0  0  1  1  1  1  0  0  0 0  0 -1 -1  0  0  1  2  2  1  0 
-1  0 0 -1 -1 -1  0  0  1  5  5  2  0 -1  0
 0  0  0  0  0  1  1  1  1  1  0  0  0 0  0  0  0  0  0  1  2  1  1  0  
0 -1 0  0  0 -1 -1  0  2  5  5  2  0 -1 -1
 0  0  0  0  0  1  1  1  1  0  0  0  0 0  0  0  0  0  1  1  1  1  1  0  
0  0-1  1  0  0  0  1  2  4  4  2  0 -1 -1
-1  0  0  0  0  1  2  1  0  0  0  0  0 0  0  0  0  0  1  2  2  1  1  0  
0 -1 0  0  0  0  0  1  2  3  3  2  0 -1 -2
 0  0  0  0  1  1  1  1  1  0  0  0  0 0  0  0  0  1  1  1  1  1  1  0  
0  0 0  0  0  0  0  1  2  2  2  1 -1 -1 -1
 0  0  0  1  0  1  1  1  1  1  1  0  0 0  0  0  1  1  1  1  1  1  0  0  
0  0 1  0  0  0  0  1  2  1  1  0 -1 -1 -1
 0  0  1  0  0  0  1  1  1  0  0  0  0 0  0  1  0  0  1  1  1  1  0 -1  
0  0 0  0  0  1  0  1  1  1  1  0  0 -1  0
 0  0  0  0  0  0  1  0  0  0  0  0  0 0  0  1  0  0  0  0  0  0  0  0  
0  0 0  1  1  1  1  1  1  1  1  0  0  0  0
 0  0  1  0  0  1  1  1  0  0  0  0  0 0  0  1  1  1  1  1  1  0  0  0  
0  0 0  0  1  1  1  1  1  1  1  0  0  0  0
 0  0  0  0  1  0  1  0  0  0  0  0  0 0  0  0  0  1  0  0  0  0  0  0  
0  0 0  0  0  1  1  1  0  1  1  0  0  0  0


It usually also helps to not refine everything at the same time. You can fix 
the distance for example.

Here’s another trick, index over the whole dataset, then edit the SPOT.XDS file 
to only include say the strongest 5000 or 1 spots.

Jürgen
..
Jürgen Bosch
Johns Hopkins University
Bloomberg School of Public Health
Department of Biochemistry  Molecular Biology
Johns Hopkins Malaria Research Institute
615 North Wolfe Street, W8708
Baltimore, MD 21205
Office: +1-410-614-4742tel:%2B1-410-614-4742
Lab:  +1-410-614-4894tel:%2B1-410-614-4894
Fax:  +1-410-955-2926tel:%2B1-410-955-2926
http://lupo.jhsph.edu

On Apr 16, 2015, at 4:37 PM, Christopher Barnes 
co...@pitt.edumailto:co...@pitt.edu wrote:

Hi all,

I am having trouble processing synchrotron data with XDS for a large unit cell 
protein complex (Spacegroup P2, Cell 225 x 256 x 430). My crystals diffract to 
3.1 Angstrom, but at this resolution we had significant spatial overlaps. To 
alleviate this we translated the detector 40 mm in both the x and y directions 
to achieve higher resolution at a distance of 850mm (on a Pilatus 6M detector), 
as well as used fine slicing (0.1 degree) for data 

Re: [ccp4bb] XDS orientation matrix inconsistent with Mosflm, DENZO

2014-12-29 Thread Kay Diederichs
On Sun, 28 Dec 2014 15:37:22 -0600, Igor Petrik petr...@illinois.edu wrote:

...
 DIRECT BEAM COORDINATES (REC. ANGSTROEM)   0.003134  0.005401  1.020962
 DETECTOR COORDINATES (PIXELS) OF DIRECT BEAM1230.87   1260.93
 DETECTOR ORIGIN (PIXELS) AT 1226.25   1252.96
 CRYSTAL TO DETECTOR DISTANCE (mm)   259.04
 LAB COORDINATES OF DETECTOR X-AXIS  1.00  0.00  0.00
 LAB COORDINATES OF DETECTOR Y-AXIS  0.00  1.00  0.00
...

(XDS defines spindle as X and beam as Z)
...

Hi Igor,

XDS does not define the geometry by itself; rather, the definition is specified 
by the _user_ , in XDS.INP! The trouble with improperly self-defining things is 
that one can get e.g. the wrong sign of the anomalous signal, which is why 
tested XDS.INP examples are provided.

Thus, I would redefine beam as Y and spindle as Z using:

DIRECTION_OF_DETECTOR_X-AXIS= 0 0 1  ! instead of 1 0 0
DIRECTION_OF_DETECTOR_Y-AXIS= 1 0 0  ! instead of 0 1 0
INCIDENT_BEAM_DIRECTION= 0 1 0 ! instead of 0 0 1
ROTATION_AXIS= 0 0 1 ! instead of 1 0 0

(this is a circular permutation so should be safe), and index with that. 

Finally, there is (in orthorhombic settings) a choice of 8 equivalent settings 
of the crystal.

best,

Kay


Re: [ccp4bb] XDS orientation matrix inconsistent with Mosflm, DENZO

2014-12-29 Thread James Holton
Yes, unfortunately an orientation matrix is completely useless without 
a frame of reference.  All it does is tell you where the cell axes lie 
relative to X, Y and Z, but X may be the x-ray beam, or 
sometimes that is Z and X is the spindle axis. Different people have 
different and strongly-held opinions about this.  The fast and slow 
axes on the detector are also a matter of widely-varying convention.  
The origin of the detector could be the first pixel in the image file, 
the upper-left corner, or it could be in cameraman view vs sample 
view and the beam center is also only meaningful relative to whatever 
the origin is.   Also, if you are at one of the four beamlines in the 
world that rotates their spindle the opposite direction of everyone 
else, then you may have to reverse the sign of one axis as well, usually 
Y, or there may be an option such as REVERSEPHI.  XDS lets you 
define all these things manually and there are formally no default 
settings.


To be fair, it is difficult for developers to keep track of what all 
~150 beamlines around the world, plus commercial home lab equipment 
manufacturers are doing.  I've been trying to some time to assemble a 
library of recent lysozyme datasets from as many beamlines as 
possible, but my collection is still far from complete:

http://bl831.als.lbl.gov/example_data_sets/

That said, I have written a few jiffies for inter-converting XDS and 
mosflm conventions, and posted them here:

http://bl831.als.lbl.gov/~jamesh/orientation_matrix/

Instructions are at the top of each awk script.  For example, 
mosflm2xds.awk takes the first three lines to be the *.mat file from 
mosflm, but also needs the mosflm input script after that to figure out 
how to convert it into XDS conventions.  Use it like this:

cat auto.mat mosflm.inp | ./mosflm2xds.awk  XDS.INP

You can convert the resulting XDS keywords into an XPARM.XDS file using 
xds2xparm.awk, which can be useful for feeding into some pipelines.  If 
you already have an XPARM.XDS, you can convert it back into XDS keywords 
using xparm2xds.awk, and these keywords can, in turn, be fed into 
xds2mosflm.awk to get a mosflm *.mat file again.  Note, however, that 
there can be some information loss here.  The *.mat file does NOT 
contain the full description of the detector and spindle geometry that 
XDS may be using.  I make some guesses in these scripts if not all the 
relevant XDS keywords are provided.  It works with my setup at ALS 
8.3.1, but I have not tested it thoroughly with other cameras.  I would 
be interested if you find any bugs!


As for what you're missing, could it perhaps be a reversed phi 
direction?  That might look like a 180-degree rotation.


Good luck!

-James Holton
MAD Scientist

On 12/28/2014 3:12 PM, Igor Petrik wrote:


Takanori and Pierre,

Thank you for your quick responses. If you read my post you will see 
that I used the xds2mos.py script to convert the xds orientation to 
Mosflm format, but this gives me a result that is inconsistent with 
the matrix calculated directly by moslfm or DENZO. For orthorombic 
space group P222 there are only a hand full of equivalent matrices 
related by changing sign of one of the vectors. The matrices generated 
by XDS and Mosflm do not seem equivalent. Or maybe I'm missing something.


Thanks,
- Igor



[ccp4bb] XDS orientation matrix inconsistent with Mosflm, DENZO

2014-12-28 Thread Igor Petrik
I am working on a small project which requires me to obtain the proper
orientation of a crystal lattice with respect to the gonistat and source. I
have until now successfully used the matrices from Mosflm and DENZO, which
are consistent with each other and define the orientation of the reciprocal
lattice in the lab space when the spindle is at 0deg.

I am trying to use the orientation computed by XDS, but this seems to not
be consistent with the others. Here is an example:

mosflm .mat file:
 -0.00458796 -0.01054146 -0.01052990
  0.00600652  0.01617284 -0.00696834
  0.02352343 -0.00618559 -0.00027442
   0.000   0.000   0.000
  -0.1856881  -0.5200068  -0.8337343
   0.2431015   0.7978011  -0.5517381
   0.9520617  -0.3051332  -0.0217278
 39.6412 48.3160 77.5507 90. 90. 90.
   0.000   0.000   0.000
SYMM P222

(top part is reciprocal matrix in the format:
 a*x  b*x  c*x
 a*y  b*y  c*y
 a*z  b*z  c*z
where x is the x-ray beam axis and z is the spindle axis)

DENZO (HKL2000) gives an equivalent matrix.

XDS orientation parameters:
CORRECT.LP
...
 REFINED VALUES OF DIFFRACTION PARAMETERS DERIVED FROM  30955 INDEXED SPOTS
 REFINED PARAMETERS:   DISTANCE BEAM ORIENTATION CELL AXIS
 STANDARD DEVIATION OF SPOTPOSITION (PIXELS) 0.70
 STANDARD DEVIATION OF SPINDLE POSITION (DEGREES)0.08
 SPACE GROUP NUMBER 16
 UNIT CELL PARAMETERS 39.52848.15377.542  90.000  90.000  90.000
 E.S.D. OF CELL PARAMETERS  4.0E-02 3.3E-02 3.8E-02 0.0E+00 0.0E+00 0.0E+00
 REC. CELL PARAMETERS   0.025299  0.020767  0.012896  90.000  90.000  90.000
 COORDINATES OF UNIT CELL A-AXIS   -37.65011.269-4.236
 COORDINATES OF UNIT CELL B-AXIS14.62441.546   -19.461
 COORDINATES OF UNIT CELL C-AXIS-1.764   -32.374   -70.439
 CRYSTAL MOSAICITY (DEGREES) 0.211
 LAB COORDINATES OF ROTATION AXIS  0.62  0.007232 -0.004834
 DIRECT BEAM COORDINATES (REC. ANGSTROEM)   0.003134  0.005401  1.020962
 DETECTOR COORDINATES (PIXELS) OF DIRECT BEAM1230.87   1260.93
 DETECTOR ORIGIN (PIXELS) AT 1226.25   1252.96
 CRYSTAL TO DETECTOR DISTANCE (mm)   259.04
 LAB COORDINATES OF DETECTOR X-AXIS  1.00  0.00  0.00
 LAB COORDINATES OF DETECTOR Y-AXIS  0.00  1.00  0.00
...

(XDS defines spindle as X and beam as Z)

Converted to reciprocal lattice orientation matrix in mosflm axis
conventions:
(output from xds2mos; manual calculation is consistent with this output)
 -0.00273114 -0.00809777 -0.01150308
 -0.00724876 -0.01754758  0.00521075
 -0.02353677  0.00634416 -0.00027012
   0.000   0.000   0.000
 -0.11022162 -0.39811300 -0.91068616
 -0.29254071 -0.86269689  0.41252918
 -0.94988163  0.31189970 -0.02138535
 39.5280 48.1530 77.5420 90. 90. 90.
   0.000   0.000   0.000


As you can see they are different. You can note that the component of each
vector along the mosflm-Z (spindle) axis is consistent, suggesting that it
is only the angle of rotation around the spindle axis that is inconsistent
between the two. I know that for mosflm and DENZO the orientation matrix
defines the orientation of the reciprocal lattice when the spindle is at 0
deg. XDS seems to be using a different reference point. Why is this and
what is the proper way to obtain the absolute reciprocal orientation at 0
deg from XDS?

(If anyone wants to test this on their own, I can provide the frames I used
to obtain these files.)

Thanks,
- Igor Petrik
University of Illinois


Re: [ccp4bb] XDS orientation matrix inconsistent with Mosflm, DENZO

2014-12-28 Thread Phil Evans
(I think) these matrices are roughly 180 degrees apart, so they may just 
correspond to different signs of the axes
Phil

On 28 Dec 2014, at 21:37, Igor Petrik petr...@illinois.edu wrote:

 I am working on a small project which requires me to obtain the proper 
 orientation of a crystal lattice with respect to the gonistat and source. I 
 have until now successfully used the matrices from Mosflm and DENZO, which 
 are consistent with each other and define the orientation of the reciprocal 
 lattice in the lab space when the spindle is at 0deg.
 
 I am trying to use the orientation computed by XDS, but this seems to not be 
 consistent with the others. Here is an example:
 
 mosflm .mat file:
  -0.00458796 -0.01054146 -0.01052990
   0.00600652  0.01617284 -0.00696834
   0.02352343 -0.00618559 -0.00027442
0.000   0.000   0.000
   -0.1856881  -0.5200068  -0.8337343
0.2431015   0.7978011  -0.5517381
0.9520617  -0.3051332  -0.0217278
  39.6412 48.3160 77.5507 90. 90. 90.
0.000   0.000   0.000
 SYMM P222  
 
 (top part is reciprocal matrix in the format:
  a*x  b*x  c*x
  a*y  b*y  c*y
  a*z  b*z  c*z
 where x is the x-ray beam axis and z is the spindle axis)
 
 DENZO (HKL2000) gives an equivalent matrix.
 
 XDS orientation parameters:
 CORRECT.LP
 ...
  REFINED VALUES OF DIFFRACTION PARAMETERS DERIVED FROM  30955 INDEXED SPOTS
  REFINED PARAMETERS:   DISTANCE BEAM ORIENTATION CELL AXIS
  STANDARD DEVIATION OF SPOTPOSITION (PIXELS) 0.70
  STANDARD DEVIATION OF SPINDLE POSITION (DEGREES)0.08
  SPACE GROUP NUMBER 16
  UNIT CELL PARAMETERS 39.52848.15377.542  90.000  90.000  90.000
  E.S.D. OF CELL PARAMETERS  4.0E-02 3.3E-02 3.8E-02 0.0E+00 0.0E+00 0.0E+00
  REC. CELL PARAMETERS   0.025299  0.020767  0.012896  90.000  90.000  90.000
  COORDINATES OF UNIT CELL A-AXIS   -37.65011.269-4.236
  COORDINATES OF UNIT CELL B-AXIS14.62441.546   -19.461
  COORDINATES OF UNIT CELL C-AXIS-1.764   -32.374   -70.439
  CRYSTAL MOSAICITY (DEGREES) 0.211
  LAB COORDINATES OF ROTATION AXIS  0.62  0.007232 -0.004834
  DIRECT BEAM COORDINATES (REC. ANGSTROEM)   0.003134  0.005401  1.020962
  DETECTOR COORDINATES (PIXELS) OF DIRECT BEAM1230.87   1260.93
  DETECTOR ORIGIN (PIXELS) AT 1226.25   1252.96
  CRYSTAL TO DETECTOR DISTANCE (mm)   259.04
  LAB COORDINATES OF DETECTOR X-AXIS  1.00  0.00  0.00
  LAB COORDINATES OF DETECTOR Y-AXIS  0.00  1.00  0.00
 ...
 
 (XDS defines spindle as X and beam as Z)
 
 Converted to reciprocal lattice orientation matrix in mosflm axis conventions:
 (output from xds2mos; manual calculation is consistent with this output)
  -0.00273114 -0.00809777 -0.01150308
  -0.00724876 -0.01754758  0.00521075
  -0.02353677  0.00634416 -0.00027012
0.000   0.000   0.000
  -0.11022162 -0.39811300 -0.91068616
  -0.29254071 -0.86269689  0.41252918
  -0.94988163  0.31189970 -0.02138535
  39.5280 48.1530 77.5420 90. 90. 90.
0.000   0.000   0.000
 
 
 As you can see they are different. You can note that the component of each 
 vector along the mosflm-Z (spindle) axis is consistent, suggesting that it is 
 only the angle of rotation around the spindle axis that is inconsistent 
 between the two. I know that for mosflm and DENZO the orientation matrix 
 defines the orientation of the reciprocal lattice when the spindle is at 0 
 deg. XDS seems to be using a different reference point. Why is this and what 
 is the proper way to obtain the absolute reciprocal orientation at 0 deg from 
 XDS?
 
 (If anyone wants to test this on their own, I can provide the frames I used 
 to obtain these files.)
 
 Thanks,
 - Igor Petrik
 University of Illinois
 


Re: [ccp4bb] XDS orientation matrix inconsistent with Mosflm, DENZO

2014-12-28 Thread Takanori Nakane

Hi,

xdsme has xds2mos.py script.

https://code.google.com/p/xdsme/
https://code.google.com/p/xdsme/source/browse/XOconv/xds2mos.py

Best regards,

Takanori Nakane

On 2014/12/29 6:37, Igor Petrik wrote:

I am working on a small project which requires me to obtain the proper
orientation of a crystal lattice with respect to the gonistat and source. I
have until now successfully used the matrices from Mosflm and DENZO, which
are consistent with each other and define the orientation of the reciprocal
lattice in the lab space when the spindle is at 0deg.

I am trying to use the orientation computed by XDS, but this seems to not
be consistent with the others. Here is an example:

mosflm .mat file:
  -0.00458796 -0.01054146 -0.01052990
   0.00600652  0.01617284 -0.00696834
   0.02352343 -0.00618559 -0.00027442
0.000   0.000   0.000
   -0.1856881  -0.5200068  -0.8337343
0.2431015   0.7978011  -0.5517381
0.9520617  -0.3051332  -0.0217278
  39.6412 48.3160 77.5507 90. 90. 90.
0.000   0.000   0.000
SYMM P222

(top part is reciprocal matrix in the format:
  a*x  b*x  c*x
  a*y  b*y  c*y
  a*z  b*z  c*z
where x is the x-ray beam axis and z is the spindle axis)

DENZO (HKL2000) gives an equivalent matrix.

XDS orientation parameters:
CORRECT.LP
...
  REFINED VALUES OF DIFFRACTION PARAMETERS DERIVED FROM  30955 INDEXED SPOTS
  REFINED PARAMETERS:   DISTANCE BEAM ORIENTATION CELL AXIS
  STANDARD DEVIATION OF SPOTPOSITION (PIXELS) 0.70
  STANDARD DEVIATION OF SPINDLE POSITION (DEGREES)0.08
  SPACE GROUP NUMBER 16
  UNIT CELL PARAMETERS 39.52848.15377.542  90.000  90.000  90.000
  E.S.D. OF CELL PARAMETERS  4.0E-02 3.3E-02 3.8E-02 0.0E+00 0.0E+00 0.0E+00
  REC. CELL PARAMETERS   0.025299  0.020767  0.012896  90.000  90.000  90.000
  COORDINATES OF UNIT CELL A-AXIS   -37.65011.269-4.236
  COORDINATES OF UNIT CELL B-AXIS14.62441.546   -19.461
  COORDINATES OF UNIT CELL C-AXIS-1.764   -32.374   -70.439
  CRYSTAL MOSAICITY (DEGREES) 0.211
  LAB COORDINATES OF ROTATION AXIS  0.62  0.007232 -0.004834
  DIRECT BEAM COORDINATES (REC. ANGSTROEM)   0.003134  0.005401  1.020962
  DETECTOR COORDINATES (PIXELS) OF DIRECT BEAM1230.87   1260.93
  DETECTOR ORIGIN (PIXELS) AT 1226.25   1252.96
  CRYSTAL TO DETECTOR DISTANCE (mm)   259.04
  LAB COORDINATES OF DETECTOR X-AXIS  1.00  0.00  0.00
  LAB COORDINATES OF DETECTOR Y-AXIS  0.00  1.00  0.00
...

(XDS defines spindle as X and beam as Z)

Converted to reciprocal lattice orientation matrix in mosflm axis
conventions:
(output from xds2mos; manual calculation is consistent with this output)
  -0.00273114 -0.00809777 -0.01150308
  -0.00724876 -0.01754758  0.00521075
  -0.02353677  0.00634416 -0.00027012
0.000   0.000   0.000
  -0.11022162 -0.39811300 -0.91068616
  -0.29254071 -0.86269689  0.41252918
  -0.94988163  0.31189970 -0.02138535
  39.5280 48.1530 77.5420 90. 90. 90.
0.000   0.000   0.000


As you can see they are different. You can note that the component of each
vector along the mosflm-Z (spindle) axis is consistent, suggesting that it
is only the angle of rotation around the spindle axis that is inconsistent
between the two. I know that for mosflm and DENZO the orientation matrix
defines the orientation of the reciprocal lattice when the spindle is at 0
deg. XDS seems to be using a different reference point. Why is this and
what is the proper way to obtain the absolute reciprocal orientation at 0
deg from XDS?

(If anyone wants to test this on their own, I can provide the frames I used
to obtain these files.)

Thanks,
- Igor Petrik
University of Illinois



Re: [ccp4bb] XDS orientation matrix inconsistent with Mosflm, DENZO

2014-12-28 Thread Igor Petrik
Takanori and Pierre,

Thank you for your quick responses. If you read my post you will see that I
used the xds2mos.py script to convert the xds orientation to Mosflm format,
but this gives me a result that is inconsistent with the matrix calculated
directly by moslfm or DENZO. For orthorombic space group P222 there are
only a hand full of equivalent matrices related by changing sign of one of
the vectors. The matrices generated by XDS and Mosflm do not seem
equivalent. Or maybe I'm missing something.

Thanks,
- Igor


[ccp4bb] XDS and XDSGUI latest versions

2014-12-19 Thread Kay Diederichs
Hi everybody,

pls note that the XDS version that you might have installed a year ago
will expire on Dec 31, and there's a new version at
http://xds.mpimf-heidelberg.mpg.de/ . The changes are: support for
Eiger, support for XZ compressed files, and assorted small fixes.

The XDS documentation is still being improved, e.g.
http://strucbio.biologie.uni-konstanz.de/xdswiki/index.php/Problems#IDXREF_produces_too_short_cell_parameter.28s.29

Furthermore the latest version of XDSGUI is documented in the XDSwiki
(http://strucbio.biologie.uni-konstanz.de/xdswiki/index.php/XDSGUI), and
the download links for Linux and Mac are provided there. I'm still
trying to find the easiest way to install XDS and related programs, and
I'd particularly appreciate help with a Mac installer that would package
xds-viewer, xdsstat, generate_XDS.INP and xdsgui. Some stuff that may be
helpful is in the Installation article in XDSwiki.

best wishes,

Kay
-- 
Kay Diederichshttp://strucbio.biologie.uni-konstanz.de
email: kay.diederi...@uni-konstanz.deTel +49 7531 88 4049 Fax 3183
Fachbereich Biologie, Universität Konstanz, Box M647, D-78457 Konstanz

This e-mail is digitally signed. If your e-mail client does not have the
necessary capabilities, just ignore the attached signature smime.p7s.


Re: [ccp4bb] XDS

2014-10-29 Thread Almudena Ponce Salvatierra
Thank you all for the suggestions.

What worked better for me was to run XDS with different batches of images
and to merge them later with XSCALE.

Best,

Almudena

2014-09-29 11:56 GMT+02:00 Almudena Ponce Salvatierra maps.fa...@gmail.com
:

 Dear all,

 I would like to ask something regarding XDS. Is it possible, without
 changing the Name of the Frames, to leave some out while processing?

 i.e. something like defining twice the data range
 DATA_RANGE= 1 900
 !DATA_RANGE= 901 1000
 DATA_RANGE= 1001 1200

 Is there a way to do so? to leave out wedges like this? I have tried like
 so, but I have the Impression it only takes then the last number of Frames,
 in this example it would only take 1001 to 1200.

 Thanks a lot.

 Best wishes,

 Almudena
 --
 Almudena Ponce-Salvatierra
 Macromolecular crystallography and Nucleic acid chemistry
 Max Planck Institute for Biophysical Chemistry
 Am Fassberg 11 37077 Göttingen
 Germany




-- 
Almudena Ponce-Salvatierra
Macromolecular crystallography and Nucleic acid chemistry
Max Planck Institute for Biophysical Chemistry
Am Fassberg 11 37077 Göttingen
Germany


[ccp4bb] XDS

2014-09-29 Thread Almudena Ponce Salvatierra
Dear all,

I would like to ask something regarding XDS. Is it possible, without
changing the Name of the Frames, to leave some out while processing?

i.e. something like defining twice the data range
DATA_RANGE= 1 900
!DATA_RANGE= 901 1000
DATA_RANGE= 1001 1200

Is there a way to do so? to leave out wedges like this? I have tried like
so, but I have the Impression it only takes then the last number of Frames,
in this example it would only take 1001 to 1200.

Thanks a lot.

Best wishes,

Almudena
-- 
Almudena Ponce-Salvatierra
Macromolecular crystallography and Nucleic acid chemistry
Max Planck Institute for Biophysical Chemistry
Am Fassberg 11 37077 Göttingen
Germany


Re: [ccp4bb] XDS

2014-09-29 Thread Andreas Förster

Hi Almudena,

if you run XDS through xia2, you can define multiple wedges in your info:

BEGIN SWEEP SWEEP1
IMAGE image_0001.cbf
DIRECTORY /path/to/files/
START_END 1 900
END SWEEP

BEGIN SWEEP SWEEP2
IMAGE image_0001.cbf
DIRECTORY /path/to/files/
START_END 1001 1200
END SWEEP



Andreas



On 29/09/2014 10:56, Almudena Ponce Salvatierra wrote:

Dear all,

I would like to ask something regarding XDS. Is it possible, without
changing the Name of the Frames, to leave some out while processing?

i.e. something like defining twice the data range
DATA_RANGE= 1 900
!DATA_RANGE= 901 1000
DATA_RANGE= 1001 1200

Is there a way to do so? to leave out wedges like this? I have tried
like so, but I have the Impression it only takes then the last number of
Frames, in this example it would only take 1001 to 1200.

Thanks a lot.

Best wishes,

Almudena
--
Almudena Ponce-Salvatierra
Macromolecular crystallography and Nucleic acid chemistry
Max Planck Institute for Biophysical Chemistry
Am Fassberg 11 37077 Göttingen
Germany



--
  Andreas Förster
 Crystallization and X-ray Facility Manager
   Centre for Structural Biology
  Imperial College London


Re: [ccp4bb] XDS

2014-09-29 Thread rajesh harijan
Hi Almudena,

 Greeting from Oulu.Other possibility would be, process the group of
Frames separately in XDS and merge them in the end.

Thank you
Rajesh




On Mon, Sep 29, 2014 at 12:56 PM, Almudena Ponce Salvatierra 
maps.fa...@gmail.com wrote:

 Dear all,

 I would like to ask something regarding XDS. Is it possible, without
 changing the Name of the Frames, to leave some out while processing?

 i.e. something like defining twice the data range
 DATA_RANGE= 1 900
 !DATA_RANGE= 901 1000
 DATA_RANGE= 1001 1200

 Is there a way to do so? to leave out wedges like this? I have tried like
 so, but I have the Impression it only takes then the last number of Frames,
 in this example it would only take 1001 to 1200.

 Thanks a lot.

 Best wishes,

 Almudena
 --
 Almudena Ponce-Salvatierra
 Macromolecular crystallography and Nucleic acid chemistry
 Max Planck Institute for Biophysical Chemistry
 Am Fassberg 11 37077 Göttingen
 Germany




-- 
---x
With regards
Rajesh K. Harijan
Phd Researcher
Faculty of Biochemistry and Molecular Medicine,
University of Oulu,
Oulu, Finland- 90014
Off Phone: +358 85531174
Mob: +358 417064469
http://www.biocenter.oulu.fi/projects/wierenga.html


Re: [ccp4bb] XDS

2014-09-29 Thread Boaz Shaanan



Hi,
Another option to do it in xds (following advice of a Kay) is to rename the frames you don't like differently than the template.
Boaz



 Original message 
From: Almudena Ponce Salvatierra maps.fa...@gmail.com 
Date: 
To: CCP4BB@JISCMAIL.AC.UK 
Subject: [ccp4bb] XDS 




Dear all, 


I would like to ask something regarding XDS. Is it possible, without changing the Name of the Frames, to leave some out while processing?


i.e. something like defining twice the data range
DATA_RANGE= 1 900
!DATA_RANGE= 901 1000
DATA_RANGE= 1001 1200


Is there a way to do so? to leave out wedges like this? I have tried like so, but I have the Impression it only takes then the last number of Frames, in this example it would only take 1001 to 1200.


Thanks a lot.

Best wishes, 

Almudena
-- 

Almudena Ponce-Salvatierra
Macromolecular crystallography and Nucleic acid chemistry
Max Planck Institute for Biophysical Chemistry
Am Fassberg 11 37077 Göttingen
Germany









[ccp4bb] AW: [ccp4bb] XDS

2014-09-29 Thread Herman . Schreuder
Dear Almudena,
Doing two different runs (1-900 and 1001-1200) will do what you want. You will 
have to do it from 2 different directories (called e.g. wedge1 and wedge2, or 
whatever). With XSCALE you can merge the runs.

Best,
Herman

Von: CCP4 bulletin board [mailto:CCP4BB@JISCMAIL.AC.UK] Im Auftrag von Almudena 
Ponce Salvatierra
Gesendet: Montag, 29. September 2014 11:57
An: CCP4BB@JISCMAIL.AC.UK
Betreff: [ccp4bb] XDS

Dear all,

I would like to ask something regarding XDS. Is it possible, without changing 
the Name of the Frames, to leave some out while processing?

i.e. something like defining twice the data range
DATA_RANGE= 1 900
!DATA_RANGE= 901 1000
DATA_RANGE= 1001 1200

Is there a way to do so? to leave out wedges like this? I have tried like so, 
but I have the Impression it only takes then the last number of Frames, in this 
example it would only take 1001 to 1200.

Thanks a lot.

Best wishes,

Almudena
--
Almudena Ponce-Salvatierra
Macromolecular crystallography and Nucleic acid chemistry
Max Planck Institute for Biophysical Chemistry
Am Fassberg 11 37077 Göttingen
Germany



Re: [ccp4bb] XDS

2014-09-29 Thread Boaz Shaanan



Hi,


Also, if you go from XDS to aimless with the INTEGRATE_ASCII.HKL or XDS_ASCII.HKL file, aimless has an option to omit batches (frames) as you wish from scaling or merging.


 Boaz




Boaz Shaanan, Ph.D.

Dept. of Life Sciences 
Ben-Gurion University of the Negev 
Beer-Sheva 84105 
Israel 
 
E-mail: bshaa...@bgu.ac.il
Phone: 972-8-647-2220Skype: boaz.shaanan 
Fax: 972-8-647-2992 or 972-8-646-1710










From: CCP4 bulletin board [CCP4BB@JISCMAIL.AC.UK] on behalf of Almudena Ponce Salvatierra [maps.fa...@gmail.com]
Sent: Monday, September 29, 2014 12:56 PM
To: CCP4BB@JISCMAIL.AC.UK
Subject: [ccp4bb] XDS





Dear all, 


I would like to ask something regarding XDS. Is it possible, without changing the Name of the Frames, to leave some out while processing?


i.e. something like defining twice the data range
DATA_RANGE= 1 900
!DATA_RANGE= 901 1000
DATA_RANGE= 1001 1200


Is there a way to do so? to leave out wedges like this? I have tried like so, but I have the Impression it only takes then the last number of Frames, in this example it would only take 1001 to 1200.


Thanks a lot.

Best wishes, 

Almudena
-- 

Almudena Ponce-Salvatierra
Macromolecular crystallography and Nucleic acid chemistry
Max Planck Institute for Biophysical Chemistry
Am Fassberg 11 37077 Göttingen
Germany











Re: [ccp4bb] XDS, refinement not converge

2014-09-22 Thread Kay Diederichs
Charles,

your posting does not provide enough detail to base advice on.

First of all, it's a warning and probably there is no reason to worry - but one 
has to look at the .LP files to be sure.
  
Second, it is not clear whether the warning is printed by IDXREF or by 
INTEGRATE. 

If it's IDXREF and you use 
REFINE(IDXREF)=CELL BEAM ORIENTATION AXIS ! DISTANCE
then just try a different (preferrably larger) SPOT_RANGE (of course re-run 
COLSPOT).

If it's INTEGRATE that prints the warning then you should probably use
REFINE(INTEGRATE)=DISTANCE BEAM ORIENTATION ! AXIS CELL
if you don't do it like that already (one should use this in any case, and 
generate_XDS.INP sets it up like this).

There is of course the possibility that something is wrong with your data (e.g. 
beam dump or dying crystal), starting at a specific frame. In such a case 
INTEGRATE may also print this kind of warning, but it should be obvious from 
the other output in INTEGRATE.LP what's going on.

I suggest to use XDSGUI because the graphics give you a fast way to spot 
problems.

HTH,

Kay

On Thu, 18 Sep 2014 16:44:28 -0400, CPMAS Chen cpmas...@gmail.com wrote:

Hi, there,

I saw some warning info during XDS data processing,

!!! WARNING !!! REFINEMENT DID NOT CONVERGE
LAST CORRECTION SHIFT WAS   6.1E-02 (should be   1.0E-03)


I have tries the suggested method,

REFINE(IDXREF)=CELL BEAM ORIENTATION AXIS ! DISTANCE

This warning is still there.

Are there other options I can try to make this converge?

Thanks!

Charles




--

***

Charles Chen

Research Associate

University of Pittsburgh School of Medicine

Department of Anesthesiology

**



[ccp4bb] AW: [ccp4bb] XDS, refinement not converge

2014-09-19 Thread Herman . Schreuder
Hi Charles,

This message usually means that refinement of cell parameters and distance 
blows up, e.g. huge cell dimensions and a huge distance. That is probably the 
reason behind the suggested method to fix the distance in IDXREF. However, I 
suspect that your error occurred in the INTEGRATE  stage. I checked the XDS 
manual, and there is also a “REFINE(INTEGRATE)=” keyword. If your error 
occurred in the INTEGRATE stage, I would try this keyword with the same 
parameters as for the “REFINE(IDXREF)=” keyword.
By the way, so far I got away with this problem by using a different (better) 
crystal, but next time I encounter this problem, I will try it as well!

Good luck and let me know if it worked,
Herman


Von: CCP4 bulletin board [mailto:CCP4BB@JISCMAIL.AC.UK] Im Auftrag von CPMAS 
Chen
Gesendet: Donnerstag, 18. September 2014 22:44
An: CCP4BB@JISCMAIL.AC.UK
Betreff: [ccp4bb] XDS, refinement not converge

Hi, there,

I saw some warning info during XDS data processing,

!!! WARNING !!! REFINEMENT DID NOT CONVERGE

LAST CORRECTION SHIFT WAS   6.1E-02 (should be   1.0E-03)

I have tries the suggested method,

REFINE(IDXREF)=CELL BEAM ORIENTATION AXIS ! DISTANCE

This warning is still there.

Are there other options I can try to make this converge?

Thanks!

Charles




--

***

Charles Chen

Research Associate

University of Pittsburgh School of Medicine

Department of Anesthesiology

**


[ccp4bb] XDS, refinement not converge

2014-09-18 Thread CPMAS Chen
Hi, there,

I saw some warning info during XDS data processing,

!!! WARNING !!! REFINEMENT DID NOT CONVERGE
LAST CORRECTION SHIFT WAS   6.1E-02 (should be   1.0E-03)


I have tries the suggested method,

REFINE(IDXREF)=CELL BEAM ORIENTATION AXIS ! DISTANCE

This warning is still there.

Are there other options I can try to make this converge?

Thanks!

Charles




-- 

***

Charles Chen

Research Associate

University of Pittsburgh School of Medicine

Department of Anesthesiology

**


Re: [ccp4bb] XDS, refinement not converge

2014-09-18 Thread Tim Gruene
Dear Charles,

first I would check again that the input parameters are correct in
XDS.INP, notably the wavelength, the distance, and the values of ORGX
and ORGY. I like to check the latter with adxv. If you collected data at
2theta = 0 deg, it is often good enough to set ORGX and ORGY to half the
respective detector dimensions.

Second check the images you used in SPOT_RANGE. Maybe there is a nicer
sweep of your crystal? If the diffraction images look all reasonable,
the SPOT_RANGE won't matter much, but sometimes a crystal looks decent
in one direction and horrible in another one - in that case restrict
SPOT_RANGE to the decent orientation.

Cheers,
Tim

On 09/18/2014 10:44 PM, CPMAS Chen wrote:
 Hi, there,
 
 I saw some warning info during XDS data processing,
 
 !!! WARNING !!! REFINEMENT DID NOT CONVERGE
 LAST CORRECTION SHIFT WAS   6.1E-02 (should be   1.0E-03)
 
 
 I have tries the suggested method,
 
 REFINE(IDXREF)=CELL BEAM ORIENTATION AXIS ! DISTANCE
 
 This warning is still there.
 
 Are there other options I can try to make this converge?
 
 Thanks!
 
 Charles
 
 
 
 

-- 
Dr Tim Gruene
Institut fuer anorganische Chemie
Tammannstr. 4
D-37077 Goettingen

GPG Key ID = A46BEE1A



signature.asc
Description: OpenPGP digital signature


  1   2   3   >