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 <= 999999.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 <[log in to unmask]> 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 <AIMLESS.MTZ> hklout <JUNK.MTZ> <<eof | grep ‘ 0 0 6’
>> nref 9999999
>> eof
>>
>> where you replace <AIMLESS.MTZ> 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 999999.9 (use your favourite editor, e.g. vi, emacs,
>> pico…) which _might_ be a good enough estimate for you to carry on to phase
>> (999999.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 <[log in to unmask]> 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.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 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
|
