Re: [ccp4bb] mtz format problem from iMosflm
Dear Tom, I believe that I once had a similar problem and if I remember correctly (and I'm not certain about this) it was caused by having an extremely large negative intensity (rather than +ve), which could be why the scaling steps did not work because they might only look at +ve values, not -ve ones (I'm not certain about this either). If the suggestions Harry made do not help, one way that you could check this is to grep the mosflm log file for the string: "Minimum Intensity=" (or alternatively, grep for "Maximum Intensity=" to look for a very large +ve value".) Could I also ask what version of ipmosflm you are using, because I think this error had been trapped in recent versions. Bets wishes, Andrew On 30 May 2015, at 09:45, Tom Wong wrote: > Dear everyone: > > Recently I met a mtz format problem: after I processed a data by iMosflm and > scaled by AIMLESS. > The mtz file could not be processed for further phasing by shelx, it said: > > ** Input file /home/tom/ccp4test_6_1_sca.tmp.sca corrupted at line 7 ** > 0 0 6 38460.7 > > > > Later I use mtz2various program to convert that mtz to sca, i got this: > > > 54.66075.31475.31490.00090.00090.000 p 21 21 21 >0 0 372.269.2 >0 0 4 25749.5 1366.3 >0 0 544.463.6 >0 0 6 38460.7 >0 0 746.162.7 >0 0 8 1413.8 288.1 >0 0 9-2.957.4 >0 0 10424115.3 11976.6 > > > I think it is a format conflict problem between iMosflm and shelx. > Is there anyone who can help me get through this? > How to do the phasing by using the mtz generated by iMosflm? > > > Thank you very much! > > > Tom
Re: [ccp4bb] mtz format problem from iMosflm
an mtz file wont have *** - it is a binary file.
mtxdump produces a formatted ascii image of the file,so that could
result in **. That happens when a number you are trying to write is too
large for the allocated format..
Indeed mtz2sca and mtz2various produce an identical sca file give or take a
scale factor…
Eleanor
On 30 May 2015 at 17:29, Phil wrote:
> I thought Aimless automatically scaled things to avoid this
>
> Sent from my iPad
>
> > On 30 May 2015, at 16:47, Tim Gruene wrote:
> >
> > Dear Eleanor, dear Tom,
> >
> > I wrote mtz2sca specifically for the transit from mosflm to shelx. It
> > automatically scales the data to avoid overflows. I don't remember what
> > it will do when the asterisks are part of the input mtz-file, but you
> > should just give it a try. If it does not work, please let me know so
> > that I can think of a solution.
> >
> > mtz2sca is part of ccp4 now. mtz2various can scale, but needs to be told.
> >
> > Best wishes,
> > Tim
> >
> >> On 05/30/2015 02:13 PM, Eleanor Dodson wrote:
> >> As Harry says, this is a format problem. the sea file only allows
> >> intensities <= 99.99 .
> >> I thought mtz2various was meant to scale intensities automatically to
> avoid
> >> this, but obviously that hasn't worked.
> >>
> >> You can check from viewing the mtz what the largest intensity is, then
> give
> >> a SCALE instruction to mtz2various to make sure you largest I is below
> the
> >> above limit.
> >>
> >> Is that OK?
> >> Eleanor
> >> Eleanor
> >>
> >>> On 30 May 2015 at 11:44, Harry Powell wrote:
> >>>
> >>> Hi
> >>>
> >>> You clearly have a very strong (0 0 6) reflection (I ~ |F^2|
> >=1,000,000)
> >>> - it’s overflowing the fixed-width format field in the output of both
> >>> Aimless and mtz2various.
> >>>
> >>> The first thing I would do is to look at the image(s) that the
> reflection
> >>> occurs on - is it actually a reflection from your protein crystal or
> is it
> >>> from something like a satellite ice crystal? In this latter case you
> can
> >>> safely just delete that reflection from the .sca file (but you should
> >>> really re-integrate the dataset making sure the “exclude ice-rings”
> option
> >>> in iMosflm is turned on {snowflake symbol next to the MTZ filename
> entry
> >>> box}, to make sure all spots due to ice are ignored and don’t
> contaminate
> >>> your signal).
> >>>
> >>> I don’t run “mtzdump” very often, but to get the value that Aimless has
> >>> actually calculated for the reflection you could try -
> >>>
> >>> mtzdump hklin hklout < 6’
> >>> nref 999
> >>> eof
> >>>
> >>> where you replace with the output file from Aimless
> (called
> >>> “aimless_???.mtz in the iMosflm QuickScale option).
> >>>
> >>> I don’t know how the Scalepack format deals with reflections that
> strong -
> >>> that’s one for Phil Evans to address, maybe with help from ZO or
> Wladek.
> >>>
> >>> The immediate way round the problem might be to replace the in
> >>> the .sca file with 99.9 (use your favourite editor, e.g. vi, emacs,
> >>> pico…) which _might_ be a good enough estimate for you to carry on to
> phase
> >>> (99.9 would allow a better estimate than just deleting the
> reflection,
> >>> but George Sheldrick would be able to give the best advice on this).
> >>>
> >>> HTH
> >>>
> >>> 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)
> >>>
> >>> On 30 May 2015, at 09:45, Tom Wong wrote:
> >>>
> >>> Dear everyone:
> >>>
> >>> Recently I met a mtz format problem: after I processed a data by
> iMosflm
> >>> and scaled by AIMLESS.
> >>> The mtz file could not be processed for further phasing by shelx, it
> said:
> >>>
> >>> ** Input file /home/tom/ccp4test_6_1_sca.tmp.sca corrupted at line
>7
> >>> **
> >>>0 0 6 38460.7
> >>>
> >>>
> >>>
> >>> Later I use mtz2various program to convert that mtz to sca, i got this:
> >>>
> >>>
> >>> 54.66075.31475.31490.00090.00090.000 p 21 21 21
> >>> 0 0 372.269.2
> >>> 0 0 4 25749.5 1366.3
> >>> 0 0 544.463.6
> >>> 0 0 6 38460.7
> >>> 0 0 746.162.7
> >>> 0 0 8 1413.8 288.1
> >>> 0 0 9-2.957.4
> >>> 0 0 10424115.3 11976.6
> >>>
> >>>
> >>> I think it is a format conflict problem between iMosflm and shelx.
> >>> Is there anyone who can help me get through this?
> >>> How to do the phasing by using the mtz generated by iMosflm?
> >>>
> >>>
> >>> Thank you very much!
> >>>
> >>>
> >>> Tom
> >
> > --
> > --
> > Dr Tim Gruene
> > Institut fuer anorganische Chemie
> > Tammannstr. 4
> > D-37077 Goettingen
> > phone: +49 (0)551 39 22149
> >
> > GPG Key ID = A46BEE1A
> >
> >
>
Re: [ccp4bb] mtz format problem from iMosflm
I thought Aimless automatically scaled things to avoid this
Sent from my iPad
> On 30 May 2015, at 16:47, Tim Gruene wrote:
>
> Dear Eleanor, dear Tom,
>
> I wrote mtz2sca specifically for the transit from mosflm to shelx. It
> automatically scales the data to avoid overflows. I don't remember what
> it will do when the asterisks are part of the input mtz-file, but you
> should just give it a try. If it does not work, please let me know so
> that I can think of a solution.
>
> mtz2sca is part of ccp4 now. mtz2various can scale, but needs to be told.
>
> Best wishes,
> Tim
>
>> On 05/30/2015 02:13 PM, Eleanor Dodson wrote:
>> As Harry says, this is a format problem. the sea file only allows
>> intensities <= 99.99 .
>> I thought mtz2various was meant to scale intensities automatically to avoid
>> this, but obviously that hasn't worked.
>>
>> You can check from viewing the mtz what the largest intensity is, then give
>> a SCALE instruction to mtz2various to make sure you largest I is below the
>> above limit.
>>
>> Is that OK?
>> Eleanor
>> Eleanor
>>
>>> On 30 May 2015 at 11:44, Harry Powell wrote:
>>>
>>> Hi
>>>
>>> You clearly have a very strong (0 0 6) reflection (I ~ |F^2| >=1,000,000)
>>> - it’s overflowing the fixed-width format field in the output of both
>>> Aimless and mtz2various.
>>>
>>> The first thing I would do is to look at the image(s) that the reflection
>>> occurs on - is it actually a reflection from your protein crystal or is it
>>> from something like a satellite ice crystal? In this latter case you can
>>> safely just delete that reflection from the .sca file (but you should
>>> really re-integrate the dataset making sure the “exclude ice-rings” option
>>> in iMosflm is turned on {snowflake symbol next to the MTZ filename entry
>>> box}, to make sure all spots due to ice are ignored and don’t contaminate
>>> your signal).
>>>
>>> I don’t run “mtzdump” very often, but to get the value that Aimless has
>>> actually calculated for the reflection you could try -
>>>
>>> mtzdump hklin hklout <>> nref 999
>>> eof
>>>
>>> where you replace with the output file from Aimless (called
>>> “aimless_???.mtz in the iMosflm QuickScale option).
>>>
>>> I don’t know how the Scalepack format deals with reflections that strong -
>>> that’s one for Phil Evans to address, maybe with help from ZO or Wladek.
>>>
>>> The immediate way round the problem might be to replace the in
>>> the .sca file with 99.9 (use your favourite editor, e.g. vi, emacs,
>>> pico…) which _might_ be a good enough estimate for you to carry on to phase
>>> (99.9 would allow a better estimate than just deleting the reflection,
>>> but George Sheldrick would be able to give the best advice on this).
>>>
>>> HTH
>>>
>>> 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)
>>>
>>> On 30 May 2015, at 09:45, Tom Wong wrote:
>>>
>>> Dear everyone:
>>>
>>> Recently I met a mtz format problem: after I processed a data by iMosflm
>>> and scaled by AIMLESS.
>>> The mtz file could not be processed for further phasing by shelx, it said:
>>>
>>> ** Input file /home/tom/ccp4test_6_1_sca.tmp.sca corrupted at line 7
>>> **
>>>0 0 6 38460.7
>>>
>>>
>>>
>>> Later I use mtz2various program to convert that mtz to sca, i got this:
>>>
>>>
>>> 54.66075.31475.31490.00090.00090.000 p 21 21 21
>>> 0 0 372.269.2
>>> 0 0 4 25749.5 1366.3
>>> 0 0 544.463.6
>>> 0 0 6 38460.7
>>> 0 0 746.162.7
>>> 0 0 8 1413.8 288.1
>>> 0 0 9-2.957.4
>>> 0 0 10424115.3 11976.6
>>>
>>>
>>> I think it is a format conflict problem between iMosflm and shelx.
>>> Is there anyone who can help me get through this?
>>> How to do the phasing by using the mtz generated by iMosflm?
>>>
>>>
>>> Thank you very much!
>>>
>>>
>>> Tom
>
> --
> --
> Dr Tim Gruene
> Institut fuer anorganische Chemie
> Tammannstr. 4
> D-37077 Goettingen
> phone: +49 (0)551 39 22149
>
> GPG Key ID = A46BEE1A
>
>
Re: [ccp4bb] mtz format problem from iMosflm
Dear Eleanor, dear Tom,
I wrote mtz2sca specifically for the transit from mosflm to shelx. It
automatically scales the data to avoid overflows. I don't remember what
it will do when the asterisks are part of the input mtz-file, but you
should just give it a try. If it does not work, please let me know so
that I can think of a solution.
mtz2sca is part of ccp4 now. mtz2various can scale, but needs to be told.
Best wishes,
Tim
On 05/30/2015 02:13 PM, Eleanor Dodson wrote:
> As Harry says, this is a format problem. the sea file only allows
> intensities <= 99.99 .
> I thought mtz2various was meant to scale intensities automatically to avoid
> this, but obviously that hasn't worked.
>
> You can check from viewing the mtz what the largest intensity is, then give
> a SCALE instruction to mtz2various to make sure you largest I is below the
> above limit.
>
> Is that OK?
> Eleanor
> Eleanor
>
> On 30 May 2015 at 11:44, Harry Powell wrote:
>
>> Hi
>>
>> You clearly have a very strong (0 0 6) reflection (I ~ |F^2| >=1,000,000)
>> - it’s overflowing the fixed-width format field in the output of both
>> Aimless and mtz2various.
>>
>> The first thing I would do is to look at the image(s) that the reflection
>> occurs on - is it actually a reflection from your protein crystal or is it
>> from something like a satellite ice crystal? In this latter case you can
>> safely just delete that reflection from the .sca file (but you should
>> really re-integrate the dataset making sure the “exclude ice-rings” option
>> in iMosflm is turned on {snowflake symbol next to the MTZ filename entry
>> box}, to make sure all spots due to ice are ignored and don’t contaminate
>> your signal).
>>
>> I don’t run “mtzdump” very often, but to get the value that Aimless has
>> actually calculated for the reflection you could try -
>>
>> mtzdump hklin hklout <> nref 999
>> eof
>>
>> where you replace with the output file from Aimless (called
>> “aimless_???.mtz in the iMosflm QuickScale option).
>>
>> I don’t know how the Scalepack format deals with reflections that strong -
>> that’s one for Phil Evans to address, maybe with help from ZO or Wladek.
>>
>> The immediate way round the problem might be to replace the in
>> the .sca file with 99.9 (use your favourite editor, e.g. vi, emacs,
>> pico…) which _might_ be a good enough estimate for you to carry on to phase
>> (99.9 would allow a better estimate than just deleting the reflection,
>> but George Sheldrick would be able to give the best advice on this).
>>
>> HTH
>>
>> 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)
>>
>> On 30 May 2015, at 09:45, Tom Wong wrote:
>>
>> Dear everyone:
>>
>> Recently I met a mtz format problem: after I processed a data by iMosflm
>> and scaled by AIMLESS.
>> The mtz file could not be processed for further phasing by shelx, it said:
>>
>> ** Input file /home/tom/ccp4test_6_1_sca.tmp.sca corrupted at line 7
>> **
>> 0 0 6 38460.7
>>
>>
>>
>> Later I use mtz2various program to convert that mtz to sca, i got this:
>>
>>
>> 54.66075.31475.31490.00090.00090.000 p 21 21 21
>>0 0 372.269.2
>>0 0 4 25749.5 1366.3
>>0 0 544.463.6
>>0 0 6 38460.7
>>0 0 746.162.7
>>0 0 8 1413.8 288.1
>>0 0 9-2.957.4
>>0 0 10424115.3 11976.6
>>
>>
>> I think it is a format conflict problem between iMosflm and shelx.
>> Is there anyone who can help me get through this?
>> How to do the phasing by using the mtz generated by iMosflm?
>>
>>
>> Thank you very much!
>>
>>
>> Tom
>>
>>
>>
>
--
--
Dr Tim Gruene
Institut fuer anorganische Chemie
Tammannstr. 4
D-37077 Goettingen
phone: +49 (0)551 39 22149
GPG Key ID = A46BEE1A
signature.asc
Description: OpenPGP digital signature
Re: [ccp4bb] mtz format problem from iMosflm
As Harry says, this is a format problem. the sea file only allows
intensities <= 99.99 .
I thought mtz2various was meant to scale intensities automatically to avoid
this, but obviously that hasn't worked.
You can check from viewing the mtz what the largest intensity is, then give
a SCALE instruction to mtz2various to make sure you largest I is below the
above limit.
Is that OK?
Eleanor
Eleanor
On 30 May 2015 at 11:44, Harry Powell wrote:
> Hi
>
> You clearly have a very strong (0 0 6) reflection (I ~ |F^2| >=1,000,000)
> - it’s overflowing the fixed-width format field in the output of both
> Aimless and mtz2various.
>
> The first thing I would do is to look at the image(s) that the reflection
> occurs on - is it actually a reflection from your protein crystal or is it
> from something like a satellite ice crystal? In this latter case you can
> safely just delete that reflection from the .sca file (but you should
> really re-integrate the dataset making sure the “exclude ice-rings” option
> in iMosflm is turned on {snowflake symbol next to the MTZ filename entry
> box}, to make sure all spots due to ice are ignored and don’t contaminate
> your signal).
>
> I don’t run “mtzdump” very often, but to get the value that Aimless has
> actually calculated for the reflection you could try -
>
> mtzdump hklin hklout < nref 999
> eof
>
> where you replace with the output file from Aimless (called
> “aimless_???.mtz in the iMosflm QuickScale option).
>
> I don’t know how the Scalepack format deals with reflections that strong -
> that’s one for Phil Evans to address, maybe with help from ZO or Wladek.
>
> The immediate way round the problem might be to replace the in
> the .sca file with 99.9 (use your favourite editor, e.g. vi, emacs,
> pico…) which _might_ be a good enough estimate for you to carry on to phase
> (99.9 would allow a better estimate than just deleting the reflection,
> but George Sheldrick would be able to give the best advice on this).
>
> HTH
>
> 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)
>
> On 30 May 2015, at 09:45, Tom Wong wrote:
>
> Dear everyone:
>
> Recently I met a mtz format problem: after I processed a data by iMosflm
> and scaled by AIMLESS.
> The mtz file could not be processed for further phasing by shelx, it said:
>
> ** Input file /home/tom/ccp4test_6_1_sca.tmp.sca corrupted at line 7
> **
> 0 0 6 38460.7
>
>
>
> Later I use mtz2various program to convert that mtz to sca, i got this:
>
>
> 54.66075.31475.31490.00090.00090.000 p 21 21 21
>0 0 372.269.2
>0 0 4 25749.5 1366.3
>0 0 544.463.6
>0 0 6 38460.7
>0 0 746.162.7
>0 0 8 1413.8 288.1
>0 0 9-2.957.4
>0 0 10424115.3 11976.6
>
>
> I think it is a format conflict problem between iMosflm and shelx.
> Is there anyone who can help me get through this?
> How to do the phasing by using the mtz generated by iMosflm?
>
>
> Thank you very much!
>
>
> Tom
>
>
>
Re: [ccp4bb] mtz format problem from iMosflm
Hi
You clearly have a very strong (0 0 6) reflection (I ~ |F^2| >=1,000,000) -
it’s overflowing the fixed-width format field in the output of both Aimless and
mtz2various.
The first thing I would do is to look at the image(s) that the reflection
occurs on - is it actually a reflection from your protein crystal or is it from
something like a satellite ice crystal? In this latter case you can safely just
delete that reflection from the .sca file (but you should really re-integrate
the dataset making sure the “exclude ice-rings” option in iMosflm is turned on
{snowflake symbol next to the MTZ filename entry box}, to make sure all spots
due to ice are ignored and don’t contaminate your signal).
I don’t run “mtzdump” very often, but to get the value that Aimless has
actually calculated for the reflection you could try -
mtzdump hklin hklout < with the output file from Aimless (called
“aimless_???.mtz in the iMosflm QuickScale option).
I don’t know how the Scalepack format deals with reflections that strong -
that’s one for Phil Evans to address, maybe with help from ZO or Wladek.
The immediate way round the problem might be to replace the in the
.sca file with 99.9 (use your favourite editor, e.g. vi, emacs, pico…)
which _might_ be a good enough estimate for you to carry on to phase (99.9
would allow a better estimate than just deleting the reflection, but George
Sheldrick would be able to give the best advice on this).
HTH
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)
> On 30 May 2015, at 09:45, Tom Wong wrote:
>
> Dear everyone:
>
> Recently I met a mtz format problem: after I processed a data by iMosflm and
> scaled by AIMLESS.
> The mtz file could not be processed for further phasing by shelx, it said:
>
> ** Input file /home/tom/ccp4test_6_1_sca.tmp.sca corrupted at line 7 **
> 0 0 6 38460.7
>
>
>
> Later I use mtz2various program to convert that mtz to sca, i got this:
>
>
> 54.66075.31475.31490.00090.00090.000 p 21 21 21
>0 0 372.269.2
>0 0 4 25749.5 1366.3
>0 0 544.463.6
>0 0 6 38460.7
>0 0 746.162.7
>0 0 8 1413.8 288.1
>0 0 9-2.957.4
>0 0 10424115.3 11976.6
>
>
> I think it is a format conflict problem between iMosflm and shelx.
> Is there anyone who can help me get through this?
> How to do the phasing by using the mtz generated by iMosflm?
>
>
> Thank you very much!
>
>
> Tom
[ccp4bb] mtz format problem from iMosflm
Dear everyone: Recently I met a mtz format problem: after I processed a data by iMosflm and scaled by AIMLESS. The mtz file could not be processed for further phasing by shelx, it said: ** Input file /home/tom/ccp4test_6_1_sca.tmp.sca corrupted at line 7 ** 0 0 6 38460.7 Later I use mtz2various program to convert that mtz to sca, i got this: 54.660 75.314 75.314 90.000 90.000 90.000 p 21 21 21 0 0 3 72.2 69.2 0 0 4 25749.5 1366.3 0 0 5 44.4 63.6 0 0 6 38460.7 0 0 7 46.1 62.7 0 0 8 1413.8 288.1 0 0 9 -2.9 57.4 0 0 10424115.3 11976.6 I think it is a format conflict problem between iMosflm and shelx. Is there anyone who can help me get through this? How to do the phasing by using the mtz generated byiMosflm? Thank you very much! Tom
