Congratulations, CCP4bb, you have just witnessed the longest thread on
JISCMAIL. 38 messages (and counting, presumably).
Now we know how to troll the BB: not even that old evergreen of where
to cut resolution generates a fraction of this traffic.
phx
On 14/11/2018 15:54, Robbie Joosten wrote:
We'll, you never know when someone wants the data. I do know that I
was incredibly impressed when you managed to conjure up the
experimental data for 2ins (from 1982!) a few years ago.
Cheers,
Robbie
P.S. this was a really fun thread to read :D
On 14 Nov 2018 16:04, Eleanor Dodson
<0000176a9d5ebad7-dmarc-requ...@jiscmail.ac.uk> wrote:
You are all extremely informed and clever!!
This file is part of an old archive of haemoglobin structures from
the 1990s.
I suspect they are all generated on a VAX from lcf files when I
was "updating" the archive..
So now if I have the character I can update them all again, in the
unlikely event that someone will want to use them!
Thank you all very much
Eleanor
On Wed, 14 Nov 2018 at 14:41, Zhijie Li <zhijie...@utoronto.ca
<mailto:zhijie...@utoronto.ca>> wrote:
Hi Nick,
I think I've found the machine stamps in the ccp4 lib (Ian
Tickle directed me to the C programs folder yesterday. Thanks
Ian):
ccp4_ssydep.h
#define DFNTI_MBO 1 /**< Motorola byte order 2's
compl */
#define DFNTI_IBO 4 /**< Intel byte order 2's compl */
#define DFNTF_BEIEEE 1 /**< big endian IEEE
(canonical) */
#define DFNTF_VAX 2 /**< Vax format */
#define DFNTF_CONVEXNATIVE 5 /**< Convex native floats */
#define DFNTF_LEIEEE 4 /**< little-endian IEEE format */
Checking the numbers are quite feasible for MTZ files (not
maps because we can put anything into MRC/ccp4 map). Yes, the
idea is to try all possibilities until we can recover miller
indices that look normal.
Zhijie
------------------------------------------------------------------------
*From:* Nicholas Devenish <ndeven...@gmail.com
<mailto:ndeven...@gmail.com>>
*Sent:* Wednesday, November 14, 2018 9:29 AM
*To:* Zhijie Li
*Cc:* CCP4BB@jiscmail.ac.uk <mailto:CCP4BB@jiscmail.ac.uk>
*Subject:* Re: [ccp4bb] VERY old mtz file..
Hi Zhijie,
Thanks for the answer. I'd read
http://www.ccp4.ac.uk/html/mtzformat.html "The first 4
half-bytes represent the real, complex, integer and character
formats, and the last two bytes are currently unused" - and
assumed that a) formats meant size, given that it was
(4,4,4,1) in files I'd seen, though perhaps parsers don't
really seem to use this. and that b) while this doesn't
specify endian-ness, one could infer it from whether the two
unused zero-bytes came in the little-or-big end of the
integer. Otherwise there really isn't an encoded way to tell
if the file was written little or big other than guessing and
checking if the numbers are sensible?
CCP4 Program Suite: mtz format
<http://www.ccp4.ac.uk/html/mtzformat.html>
www.ccp4.ac.uk <http://www.ccp4.ac.uk>
Column types. All columns in an MTZ file are assigned a type,
taken from the following list. The LABIN line of a particular
job connects columns in an input MTZ file with the columns
expected by the program.
Perhaps this is a (small) flaw in the spec, though nowadays
almost everyone seems to have moved to little-endian.
Nick
On Wed, Nov 14, 2018 at 2:13 PM Zhijie Li
<zhijie...@utoronto.ca <mailto:zhijie...@utoronto.ca>> wrote:
>
> Hi Nick,
>
>
> I guessed the machine stamp from MRC/CCP4 format description
- half byte 01 means BE, half byte 04 means LE. Are these only
applicable to intel machines? How are other machine
architectures indicated? I do not know. We probably can find
the authoritative answer from the CCP4 library, just need a
little bit more time...
>
>
> The machine stamp itself should not be affected by the
machine's architecture, because it needs to be read before the
program knows what the architecture is. Therefore it should be
a string instead of a number. In the MRC/CCP4 map
specification, it says that only the first two bytes are
used. I had seen some home-brew programs taking shortcuts by
using the int value of the machine stamp word, and I thought
that was smart. Now I realise that this practice has the risk
of failing on non-intel machines. So, if it is meant to be
half-bytes, interpret it as half bytes!
>
>
> Zhijie
>
>
>
> ________________________________
> From: Nicholas Devenish <ndeven...@gmail.com
<mailto:ndeven...@gmail.com>>
> Sent: Wednesday, November 14, 2018 8:54 AM
> To: Zhijie Li
> Cc: CCP4BB@jiscmail.ac.uk <mailto:CCP4BB@jiscmail.ac.uk>
> Subject: Re: [ccp4bb] VERY old mtz file..
>
> Hi Zhijie,
>
> Looks like we both had the same thoughts!
>
> On Wed, Nov 14, 2018 at 1:19 PM Zhijie Li
<zhijie...@utoronto.ca <mailto:zhijie...@utoronto.ca>> wrote:
>
> The semi....BE.mtz has the big endian stamp (0x11 11 00 00
at bytes 9-12 ) put in the header of the original file;
everything else is untouched
>
>
> Is this correct? I thought machine stamp was supposed to be
the 4-bit sizes of int, real, complex and char e.g. all the
little endian MTZ's I've seen have 0x44 41 00 00, which would
make the big-endian version 0x00 00 41 44. Then again, mtzdmp
complained regardless, and perhaps I've just misinterpreted
the documentation (I'd love to know if this was the case!)
>
> Thanks,
>
> Nick
>
------------------------------------------------------------------------
To unsubscribe from the CCP4BB list, click the following link:
https://www.jiscmail.ac.uk/cgi-bin/webadmin?SUBED1=CCP4BB&A=1
------------------------------------------------------------------------
To unsubscribe from the CCP4BB list, click the following link:
https://www.jiscmail.ac.uk/cgi-bin/webadmin?SUBED1=CCP4BB&A=1
------------------------------------------------------------------------
To unsubscribe from the CCP4BB list, click the following link:
https://www.jiscmail.ac.uk/cgi-bin/webadmin?SUBED1=CCP4BB&A=1
########################################################################
To unsubscribe from the CCP4BB list, click the following link:
https://www.jiscmail.ac.uk/cgi-bin/webadmin?SUBED1=CCP4BB&A=1
