Begin forwarded message:
From: "charles w carter, jr" <cwcar...@ad.unc.edu<mailto:cwcar...@ad.unc.edu>> Subject: Re: [ccp4bb] VERY old mtz file.. Date: November 14, 2018 at 10:16:23 AM EST To: Eleanor Dodson <eleanor.dod...@york.ac.uk<mailto:eleanor.dod...@york.ac.uk>> I’ve found this thread to be most interesting and out of near pathological curiosity, I’ve read much of it. Eleanor’s cameo description in this message makes me curious to know how the transition from vax’s and this file in particular, managed to transcend the continuity ccp4 strives for. Were MRC files really a significant variant in the implementation of mtz binary format to replace labeled column format? Many thanks, and best to all, Charlie On Nov 14, 2018, at 10:04 AM, Eleanor Dodson <0000176a9d5ebad7-dmarc-requ...@jiscmail.ac.uk<mailto: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
