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
I thought Aimless automatically scaled things to avoid this
Sent from my iPad
On 30 May 2015, at 16:47, Tim Gruene t...@shelx.uni-ac.gwdg.de wrote:
Dear Eleanor, dear Tom,
I wrote mtz2sca specifically for the transit from mosflm to shelx. It
automatically scales the data to avoid
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
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
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
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
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
