Re: [ccp4bb] VERY old mtz file..

[Edward A. Berry]

In case one wants to play around with openVMS or just recover some 
now-unreadable old data,
and doesn't have a vax farm or even a single vax computer,there are 
step-by-step instructions for setting up a vax system using the simh emulator:
http://www.wherry.com/gadgets/retrocomputing/vax-simh.html
Simh is under active development and I have no idea if those old instructions 
would work with the latest nightly build (but they should). The mailing list 
is: http://mailman.trailing-edge.com/mailman/listinfo/simh

I did this back around 2004 and it worked very well. As described, DEC (then compaq and I 
think now HP) provides a free "hobbyist" license and a cdrom with the operating 
system and standard software for networking, fortran and C compilers. Using the 
instructions I was able to get networking working, could FTP things between the vax and 
other computers, and set up an nfs-served disk that both vax and host could read and 
write. I was able to make tape images from vaxbackup tapes using dd (including tapes with 
multiple savesets) and mount them on the emulator. Doing this I was able to recover old 
vax email and, using the vax as mail server and mozilla as client, transfer all the old 
email to a mozilla-readable format which I can access today using seamonkey or 
thunderbird. More importantly I was able to recover old data saved from ssrl vaxen on 
exabyte tapes.

It would be nice if ccp4 would make an old release available on a "hobbyist" 
license for use on vax (although coming to my senses I can't imagine what use anyone 
would have for such a thing - could be a real waste of time!).

This was about the time that support for lcbvax at LBL chemical biodynamics 
division was ending, and I was able to resurrect it from standalone backup 
tapes and keep it running for a few die-hard vax users for a few years.

If you just want to recover old data (and have a compatible tape drive), you 
can just use the vmsbackup utility (described by Kay Diederichs in an earlier 
post). It loses most of the meta-data, but restores diffraction images that 
work fine with the HKL package. But the emulator is much more fun!
eab

On 11/14/2018 05:15 AM, Harry Powell wrote:

Hi

Weren't the CCP4 base-level routines re-written from FORTRAN to C sometime in 
the late 1990's? Very occasionally I used to find bugs that had been introduced 
in this process (or possibly not corrected...) so it's possible that Eleanor's 
file might be readable with a really old code base.

BTW, I have recently had cause to search out a VMS system and have found 
someone with a whole farm of running VAXes (or VAXen if you're geeky).

Harry

On 14 Nov 2018, at 09:46, Ian Tickle wrote:


The CCP4 routines for MTZ and map files are written in C and thus do not use a 
Fortran unformatted OPEN statement, they use C-style block read & write.

Cheers

-- Ian


On Wed, 14 Nov 2018 at 08:59, Kay Diederichs mailto:kay.diederi...@uni-konstanz.de>> wrote:

It is not necessary to do error-prone conversions manually: the ifort 
Compiler understands the convert='VAXD' Option in its OPEN statement - see

https://software.intel.com/en-us/fortran-compiler-developer-guide-and-reference-open-convert-specifier

Thus one could just write a tiny read-write loop.

HTH
Kay

On Wed, 14 Nov 2018 00:51:02 +, Zhijie Li mailto:zhijie...@utoronto.ca>> wrote:

>It's also said here, at the end of file :
>
>https://www.cs.auckland.ac.nz/~patrice/210LN/DR4.pdf
>
>"add 1 to the left, with the binary point"
>
>0.1.
>
>
>
>
>From: CCP4 bulletin board mailto:CCP4BB@JISCMAIL.AC.UK>> on 
behalf of Zhijie Li mailto:zhijie...@utoronto.ca>>
>Sent: Tuesday, November 13, 2018 7:43 PM
    >To: CCP4BB@JISCMAIL.AC.UK <mailto:CCP4BB@JISCMAIL.AC.UK>
>Subject: Re: [ccp4bb] VERY old mtz file..
>
>
>Hi all,
>
>
>I think I know why it is a division of 4 instead of 2 is involved in 
conversion from VAX to IEEE now. Short answer: a 2 is in the exponent bits (bias 
of 128 instead of 127, visible), another 2 is hidden in the scientific notation.
>
>
>I found this explanation+example on VAX F-float:
>
>http://courseweb.stthomas.edu/tpsturm/private/notes/qm300/FLOATPT.html
>
>
>So for IEEE754 float32, if we want to represent a same 12.75 (1100.11) in 
the above example, we  would first conceptually write it in scientific notation as 
1.10011 x 1000 in binary. Then the mantissa part is the part after the dot filled 
with zero to 23 bits: '1001100', the exponent part is 3+127=130 
(dec)=1010(bin). Then the binary IEEE754 float32 number is 
0[1010][1001100]. (You can check it here: 
https://www.h-schmidt.net/FloatConverter/IEEE754.h

Re: [ccp4bb] VERY old mtz file..

[Frank von Delft]

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 
<176a9d5ebad7-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 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 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
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!
>
   

Re: [ccp4bb] VERY old mtz file..

[Robbie Joosten]

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 
<176a9d5ebad7-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 
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_BEIEEE1   /**< big endian IEEE (canonical) */
#define DFNTF_VAX   2   /**< Vax format */
#define DFNTF_CONVEXNATIVE 5/**< Convex native floats */
#define DFNTF_LEIEEE4   /**< 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 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 
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 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 
> mailto:zhijie...@utoronto.ca>> wrote:
>
> The semiBE.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. 

Re: [ccp4bb] VERY old mtz file..

[Eleanor Dodson]

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  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_BEIEEE1   /**< big endian IEEE (canonical) */
> #define DFNTF_VAX   2   /**< Vax format */
> #define DFNTF_CONVEXNATIVE 5/**< Convex native floats */
> #define DFNTF_LEIEEE4   /**< 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 
> *Sent:* Wednesday, November 14, 2018 9:29 AM
> *To:* Zhijie Li
> *Cc:* 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
> 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  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 
> > Sent: Wednesday, November 14, 2018 8:54 AM
> > To: Zhijie Li
> > Cc: 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  wrote:
> >
> > The semiBE.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=1
>



To unsubscribe from the CCP4BB list, click the following link:
https://www.jiscmail.ac.uk/cgi-bin/webadmin?SUBED1=CCP4BB=1

Re: [ccp4bb] VERY old mtz file..

[Zhijie Li]

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_BEIEEE1   /**< big endian IEEE (canonical) */
#define DFNTF_VAX   2   /**< Vax format */
#define DFNTF_CONVEXNATIVE 5/**< Convex native floats */
#define DFNTF_LEIEEE4   /**< 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 
Sent: Wednesday, November 14, 2018 9:29 AM
To: Zhijie Li
Cc: 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
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 
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 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 
> mailto:zhijie...@utoronto.ca>> wrote:
>
> The semiBE.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=1

Re: [ccp4bb] VERY old mtz file..

[Nicholas Devenish]

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?

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  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 
> Sent: Wednesday, November 14, 2018 8:54 AM
> To: Zhijie Li
> Cc: 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  wrote:
>
> The semiBE.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=1

Re: [ccp4bb] VERY old mtz file..

[Zhijie Li]

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 
Sent: Wednesday, November 14, 2018 8:54 AM
To: Zhijie Li
Cc: 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 
mailto:zhijie...@utoronto.ca>> wrote:

The semiBE.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=1

Re: [ccp4bb] VERY old mtz file..

[Nicholas Devenish]

Hi Zhijie,

Looks like we both had the same thoughts!

On Wed, Nov 14, 2018 at 1:19 PM Zhijie Li  wrote:

> The semiBE.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=1

Re: [ccp4bb] VERY old mtz file..

[Kay Diederichs]

here is a minimal Fortran program that writes out the contents as 
H,K,L,FOBS,SDFOBS - could be fed into contemporary F2MTZ to produce a current 
MTZ file :

REAL h,k,l,fobs,sfobs
OPEN(1,file='hklin',convert='BIG_ENDIAN',ACCESS='STREAM')
DO i=1,20   !skip first 20 4-byte units
  READ(1)h
END DO
DO i=1,17218!print the rest
  READ(1)h,k,l,fobs,sfobs
  print*,h,k,l,fobs,sfobs
END DO
END

You must symlink semioxyhb_tstate_BetaCobalt.mtz to hklin before running the 
program

The knowledge about the names of columns, and their number, comes from
strings semioxyhb_tstate_BetaCobalt.mtz

HTH,
Kay


On Wed, 14 Nov 2018 10:25:30 +, Eleanor Dodson  
wrote:

>Here is the file I was trying to read - please feel free to play with it!!
>Eleanor
>
>On Wed, 14 Nov 2018 at 10:17, Harry Powell <
>193323b1e616-dmarc-requ...@jiscmail.ac.uk> wrote:
>
>> Hi
>>
>> Weren't the CCP4 base-level routines re-written from FORTRAN to C sometime
>> in the late 1990's? Very occasionally I used to find bugs that had been
>> introduced in this process (or possibly not corrected...) so it's possible
>> that Eleanor's file might be readable with a really old code base.
>>
>> BTW, I have recently had cause to search out a VMS system and have found
>> someone with a whole farm of running VAXes (or VAXen if you're geeky).
>>
>> Harry
>>
>> On 14 Nov 2018, at 09:46, Ian Tickle wrote:
>>
>> The CCP4 routines for MTZ and map files are written in C and thus do not
>> use a Fortran unformatted OPEN statement, they use C-style block read &
>> write.
>>
>> Cheers
>>
>> -- Ian
>>
>>
>> On Wed, 14 Nov 2018 at 08:59, Kay Diederichs <
>> kay.diederi...@uni-konstanz.de> wrote:
>>
>>> It is not necessary to do error-prone conversions manually: the ifort
>>> Compiler understands the convert='VAXD' Option in its OPEN statement - see
>>>
>>> https://software.intel.com/en-us/fortran-compiler-developer-guide-and-reference-open-convert-specifier
>>>
>>> Thus one could just write a tiny read-write loop.
>>>
>>> HTH
>>> Kay
>>>
>>> On Wed, 14 Nov 2018 00:51:02 +, Zhijie Li 
>>> wrote:
>>>
>>> >It's also said here, at the end of file :
>>> >
>>> >https://www.cs.auckland.ac.nz/~patrice/210LN/DR4.pdf
>>> >
>>> >"add 1 to the left, with the binary point"
>>> >
>>> >0.1.
>>> >
>>> >
>>> >
>>> >
>>> >From: CCP4 bulletin board  on behalf of Zhijie
>>> Li 
>>> >Sent: Tuesday, November 13, 2018 7:43 PM
>>> >To: CCP4BB@JISCMAIL.AC.UK
>>> >Subject: Re: [ccp4bb] VERY old mtz file..
>>> >
>>> >
>>> >Hi all,
>>> >
>>> >
>>> >I think I know why it is a division of 4 instead of 2 is involved in
>>> conversion from VAX to IEEE now. Short answer: a 2 is in the exponent bits
>>> (bias of 128 instead of 127, visible), another 2 is hidden in the
>>> scientific notation.
>>> >
>>> >
>>> >I found this explanation+example on VAX F-float:
>>> >
>>> >http://courseweb.stthomas.edu/tpsturm/private/notes/qm300/FLOATPT.html
>>> >
>>> >
>>> >So for IEEE754 float32, if we want to represent a same 12.75 (1100.11)
>>> in the above example, we  would first conceptually write it in scientific
>>> notation as 1.10011 x 1000 in binary. Then the mantissa part is the part
>>> after the dot filled with zero to 23 bits: '1001100', the
>>> exponent part is 3+127=130 (dec)=1010(bin). Then the binary IEEE754
>>> float32 number is 0[1010][1001100]. (You can check it
>>> here: https://www.h-schmidt.net/FloatConverter/IEEE754.html)
>>> >
>>> >
>>> >Now compare this with the VAX 12.75 in the linked example, we can find
>>> that besides the bias becoming 128, the conceptual binary scientific
>>> notation is actually  0.110011 x 1, instead of 1.10011 x 1000.  So the
>>> exponent needed is 4 instead of 3. Then the exponent bits are
>>> 4+128=132=1100 and the VAX float32 becomes
>>> >
>>> >0[1100][1001100] ---if we write in a IEEE-style
>>> order. Note that the mantissa appears to be same as the ieee mantissa, and
>>> the exponent to be applied is 132-128=4. If this number is interpreted as
>>> IEEE754, then it will be 1.

Re: [ccp4bb] VERY old mtz file..

[Zhijie Li]

Hi Nick,

Our LE outputs are exactly the same. Rmerge=100.0%!

Zhijie



From: CCP4 bulletin board  on behalf of Nicholas 
Devenish 
Sent: Wednesday, November 14, 2018 7:15 AM
To: CCP4BB@JISCMAIL.AC.UK
Subject: Re: [ccp4bb] VERY old mtz file..

Hi Eleanor,

On Wed, Nov 14, 2018 at 10:27 AM Eleanor Dodson 
<176a9d5ebad7-dmarc-requ...@jiscmail.ac.uk<mailto:176a9d5ebad7-dmarc-requ...@jiscmail.ac.uk>>
 wrote:
Here is the file I was trying to read - please feel free to play with it!!
Eleanor

This is an interesting file - it diverges from several expectations of what I 
thought an MTZ had to look like (by the admittedly sparse documentation I can 
find). Specifically:
- It's big-endian (this should fine)
- The machine stamp - which should identify it as big-endian, is missing 
(interestingly, mtzdmp doesn't appear to use this indicator - I set it to the 
big-endian version and it just complained that it was corrupted)
- Was apparently written before MTZ datasets were a thing, COLSRC property I 
also didn't know was optional...

The good news is that I swapped the endian-ness of the binary parts and wrote 
the machine stamp, and mtzdmp appears to parse the file now. Not really sure 
what other tools you'd need to verify but this might be enough. I've attached.

Thanks,

Nick




To unsubscribe from the CCP4BB list, click the following link:
https://www.jiscmail.ac.uk/cgi-bin/webadmin?SUBED1=CCP4BB=1



To unsubscribe from the CCP4BB list, click the following link:
https://www.jiscmail.ac.uk/cgi-bin/webadmin?SUBED1=CCP4BB=1

Re: [ccp4bb] VERY old mtz file..

[Eleanor Dodson]

yes - prob. converted from lcf to mtz at some point..
Maybe on a VAX /

E

On Wed, 14 Nov 2018 at 10:46, Harry Powell <
193323b1e616-dmarc-requ...@jiscmail.ac.uk> wrote:

> Hi
>
> Okay, I can read that (sort of) with errors using a copy of mtzdmp from
> ccp4 v 5.0, dated 23/01/04; I can tell that Ben Luisi's name is in there
> (hello Ben!) and that the file was "converted to MTZ file mark 1 on 15/
> 5/92", inter alia. I can even tell that there are five columns and 17218
> reflections...
>
> Unfortunately, I get an error in reading the reflections themselves -
>
>  LIST OF REFLECTIONS
>  ===
>
> >>>>>> CCP4 library signal library_file:Bad mode (Error)
>  raised in ccp4_file_readfloat <<<<<<
> >>>>>> System signal 22:Invalid argument (Error)
>  raised in ccp4_file_read <<<<<<
> 
>  MTZDUMP:   Normal termination of mtzdump
> Times: User:   0.0s System:0.0s Elapsed: 0:00
>
>
>
> My feeling is that all the discussion about VAXes etc may be irrelevant -
> in my view it's more likely that the programs for reading and writing the
> MTZ format changed (and the MTZ format itself changed as well) and are no
> longer capable of dealing with "MTZ file mark 1"...
>
> If I can actually get the VAXes to which I referred to read an old DAT
> tape, I may be able to build a copy of CCP4 from 1993... but that's a
> problem for another day (anyone got a SCSI DDS drive I could plug into a
> VAX?).
>
> On 14 Nov 2018, at 10:25, Eleanor Dodson wrote:
>
> Here is the file I was trying to read - please feel free to play with it!!
> Eleanor
>
> On Wed, 14 Nov 2018 at 10:17, Harry Powell <
> 193323b1e616-dmarc-requ...@jiscmail.ac.uk> wrote:
>
>> Hi
>>
>> Weren't the CCP4 base-level routines re-written from FORTRAN to C
>> sometime in the late 1990's? Very occasionally I used to find bugs that had
>> been introduced in this process (or possibly not corrected...) so it's
>> possible that Eleanor's file might be readable with a really old code base.
>>
>> BTW, I have recently had cause to search out a VMS system and have found
>> someone with a whole farm of running VAXes (or VAXen if you're geeky).
>>
>> Harry
>>
>> On 14 Nov 2018, at 09:46, Ian Tickle wrote:
>>
>> The CCP4 routines for MTZ and map files are written in C and thus do not
>> use a Fortran unformatted OPEN statement, they use C-style block read &
>> write.
>>
>> Cheers
>>
>> -- Ian
>>
>>
>> On Wed, 14 Nov 2018 at 08:59, Kay Diederichs <
>> kay.diederi...@uni-konstanz.de> wrote:
>>
>>> It is not necessary to do error-prone conversions manually: the ifort
>>> Compiler understands the convert='VAXD' Option in its OPEN statement - see
>>>
>>> https://software.intel.com/en-us/fortran-compiler-developer-guide-and-reference-open-convert-specifier
>>>
>>> Thus one could just write a tiny read-write loop.
>>>
>>> HTH
>>> Kay
>>>
>>> On Wed, 14 Nov 2018 00:51:02 +, Zhijie Li 
>>> wrote:
>>>
>>> >It's also said here, at the end of file :
>>> >
>>> >https://www.cs.auckland.ac.nz/~patrice/210LN/DR4.pdf
>>> >
>>> >"add 1 to the left, with the binary point"
>>> >
>>> >0.1.
>>> >
>>> >
>>> >
>>> >
>>> >From: CCP4 bulletin board  on behalf of Zhijie
>>> Li 
>>> >Sent: Tuesday, November 13, 2018 7:43 PM
>>> >To: CCP4BB@JISCMAIL.AC.UK
>>> >Subject: Re: [ccp4bb] VERY old mtz file..
>>> >
>>> >
>>> >Hi all,
>>> >
>>> >
>>> >I think I know why it is a division of 4 instead of 2 is involved in
>>> conversion from VAX to IEEE now. Short answer: a 2 is in the exponent bits
>>> (bias of 128 instead of 127, visible), another 2 is hidden in the
>>> scientific notation.
>>> >
>>> >
>>> >I found this explanation+example on VAX F-float:
>>> >
>>> >http://courseweb.stthomas.edu/tpsturm/private/notes/qm300/FLOATPT.html
>>> >
>>> >
>>> >So for IEEE754 float32, if we want to represent a same 12.75 (1100.11)
>>> in the above example, we  would first conceptually write it in scientific
>>> notation as 1.10011 x 1000 in binary. Then the mantissa part is the part
>>> after the dot filled with zero

Re: [ccp4bb] VERY old mtz file..

[Harry Powell]

Hi

Okay, I can read that (sort of) with errors using a copy of mtzdmp from ccp4 v 
5.0, dated 23/01/04; I can tell that Ben Luisi's name is in there (hello Ben!) 
and that the file was "converted to MTZ file mark 1 on 15/ 5/92", inter alia. I 
can even tell that there are five columns and 17218 reflections...

Unfortunately, I get an error in reading the reflections themselves - 

>  LIST OF REFLECTIONS
>  ===
> 
> >>>>>> CCP4 library signal library_file:Bad mode (Error)
>  raised in ccp4_file_readfloat <<<<<<
> >>>>>> System signal 22:Invalid argument (Error)
>  raised in ccp4_file_read <<<<<<
> 
>  MTZDUMP:   Normal termination of mtzdump
> Times: User:   0.0s System:0.0s Elapsed: 0:00  


My feeling is that all the discussion about VAXes etc may be irrelevant - in my 
view it's more likely that the programs for reading and writing the MTZ format 
changed (and the MTZ format itself changed as well) and are no longer capable 
of dealing with "MTZ file mark 1"...

If I can actually get the VAXes to which I referred to read an old DAT tape, I 
may be able to build a copy of CCP4 from 1993... but that's a problem for 
another day (anyone got a SCSI DDS drive I could plug into a VAX?).

On 14 Nov 2018, at 10:25, Eleanor Dodson wrote:

> Here is the file I was trying to read - please feel free to play with it!!
> Eleanor
> 
> On Wed, 14 Nov 2018 at 10:17, Harry Powell 
> <193323b1e616-dmarc-requ...@jiscmail.ac.uk> wrote:
> Hi
> 
> Weren't the CCP4 base-level routines re-written from FORTRAN to C sometime in 
> the late 1990's? Very occasionally I used to find bugs that had been 
> introduced in this process (or possibly not corrected...) so it's possible 
> that Eleanor's file might be readable with a really old code base.
> 
> BTW, I have recently had cause to search out a VMS system and have found 
> someone with a whole farm of running VAXes (or VAXen if you're geeky).
> 
> Harry
> 
> On 14 Nov 2018, at 09:46, Ian Tickle wrote:
> 
>> The CCP4 routines for MTZ and map files are written in C and thus do not use 
>> a Fortran unformatted OPEN statement, they use C-style block read & write.
>> 
>> Cheers
>> 
>> -- Ian
>> 
>> 
>> On Wed, 14 Nov 2018 at 08:59, Kay Diederichs 
>>  wrote:
>> It is not necessary to do error-prone conversions manually: the ifort 
>> Compiler understands the convert='VAXD' Option in its OPEN statement - see 
>> https://software.intel.com/en-us/fortran-compiler-developer-guide-and-reference-open-convert-specifier
>> 
>> Thus one could just write a tiny read-write loop.
>> 
>> HTH
>> Kay
>> 
>> On Wed, 14 Nov 2018 00:51:02 +, Zhijie Li  wrote:
>> 
>> >It's also said here, at the end of file :
>> >
>> >https://www.cs.auckland.ac.nz/~patrice/210LN/DR4.pdf
>> >
>> >"add 1 to the left, with the binary point"
>> >
>> >0.1.
>> >
>> >
>> >
>> >
>> >From: CCP4 bulletin board  on behalf of Zhijie Li 
>> >
>> >Sent: Tuesday, November 13, 2018 7:43 PM
>> >To: CCP4BB@JISCMAIL.AC.UK
>> >Subject: Re: [ccp4bb] VERY old mtz file..
>> >
>> >
>> >Hi all,
>> >
>> >
>> >I think I know why it is a division of 4 instead of 2 is involved in 
>> >conversion from VAX to IEEE now. Short answer: a 2 is in the exponent bits 
>> >(bias of 128 instead of 127, visible), another 2 is hidden in the 
>> >scientific notation.
>> >
>> >
>> >I found this explanation+example on VAX F-float:
>> >
>> >http://courseweb.stthomas.edu/tpsturm/private/notes/qm300/FLOATPT.html
>> >
>> >
>> >So for IEEE754 float32, if we want to represent a same 12.75 (1100.11) in 
>> >the above example, we  would first conceptually write it in scientific 
>> >notation as 1.10011 x 1000 in binary. Then the mantissa part is the part 
>> >after the dot filled with zero to 23 bits: '1001100', the 
>> >exponent part is 3+127=130 (dec)=1010(bin). Then the binary IEEE754 
>> >float32 number is 0[1010][1001100]. (You can check it 
>> >here: https://www.h-schmidt.net/FloatConverter/IEEE754.html)
>> >
>> >
>> >Now compare this with the VAX 12.75 in the linked example, we can find that 
>> >besides the bias becoming 128, the conceptual binary scientific notation is 
>> >actually  0.110011 x 1, instead of 1.10011 x 1

Re: [ccp4bb] VERY old mtz file..

[Harry Powell]

Hi

Weren't the CCP4 base-level routines re-written from FORTRAN to C sometime in 
the late 1990's? Very occasionally I used to find bugs that had been introduced 
in this process (or possibly not corrected...) so it's possible that Eleanor's 
file might be readable with a really old code base.

BTW, I have recently had cause to search out a VMS system and have found 
someone with a whole farm of running VAXes (or VAXen if you're geeky).

Harry

On 14 Nov 2018, at 09:46, Ian Tickle wrote:

> The CCP4 routines for MTZ and map files are written in C and thus do not use 
> a Fortran unformatted OPEN statement, they use C-style block read & write.
> 
> Cheers
> 
> -- Ian
> 
> 
> On Wed, 14 Nov 2018 at 08:59, Kay Diederichs  
> wrote:
> It is not necessary to do error-prone conversions manually: the ifort 
> Compiler understands the convert='VAXD' Option in its OPEN statement - see 
> https://software.intel.com/en-us/fortran-compiler-developer-guide-and-reference-open-convert-specifier
> 
> Thus one could just write a tiny read-write loop.
> 
> HTH
> Kay
> 
> On Wed, 14 Nov 2018 00:51:02 +, Zhijie Li  wrote:
> 
> >It's also said here, at the end of file :
> >
> >https://www.cs.auckland.ac.nz/~patrice/210LN/DR4.pdf
> >
> >"add 1 to the left, with the binary point"
> >
> >0.1.
> >
> >
> >
> >
> >From: CCP4 bulletin board  on behalf of Zhijie Li 
> >
> >Sent: Tuesday, November 13, 2018 7:43 PM
> >To: CCP4BB@JISCMAIL.AC.UK
> >Subject: Re: [ccp4bb] VERY old mtz file..
> >
> >
> >Hi all,
> >
> >
> >I think I know why it is a division of 4 instead of 2 is involved in 
> >conversion from VAX to IEEE now. Short answer: a 2 is in the exponent bits 
> >(bias of 128 instead of 127, visible), another 2 is hidden in the scientific 
> >notation.
> >
> >
> >I found this explanation+example on VAX F-float:
> >
> >http://courseweb.stthomas.edu/tpsturm/private/notes/qm300/FLOATPT.html
> >
> >
> >So for IEEE754 float32, if we want to represent a same 12.75 (1100.11) in 
> >the above example, we  would first conceptually write it in scientific 
> >notation as 1.10011 x 1000 in binary. Then the mantissa part is the part 
> >after the dot filled with zero to 23 bits: '1001100', the 
> >exponent part is 3+127=130 (dec)=1010(bin). Then the binary IEEE754 
> >float32 number is 0[1010][1001100]. (You can check it 
> >here: https://www.h-schmidt.net/FloatConverter/IEEE754.html)
> >
> >
> >Now compare this with the VAX 12.75 in the linked example, we can find that 
> >besides the bias becoming 128, the conceptual binary scientific notation is 
> >actually  0.110011 x 1, instead of 1.10011 x 1000.  So the exponent 
> >needed is 4 instead of 3. Then the exponent bits are 4+128=132=1100 and 
> >the VAX float32 becomes
> >
> >0[1100][1001100] ---if we write in a IEEE-style order. 
> >Note that the mantissa appears to be same as the ieee mantissa, and the 
> >exponent to be applied is 132-128=4. If this number is interpreted as 
> >IEEE754, then it will be 1.10011 x 2exp(132-127)=1.10011 x 10, four 
> >times of what it should be.
> >
> >
> >So, for normalised values, rearranging the VAX F-float bytes, reading as 
> >IEEE, then dividing by 4 gives the correct value. (The C[0]-1 treatment in 
> >the ccp4 lib is neat.)
> >
> >
> >In this link describing VAX floats, it is unfortunate that it only states 
> >that the bias for F-float is 128, but not that the mantissa starts from 0.01 
> >instead of 0.1. Therefore the confusion.
> >
> >https://nssdc.gsfc.nasa.gov/nssdc/formats/VAXFloatingPoint.htm
> >
> >
> >
> >Thanks to all responded!
> >
> >
> >Zhijie
> >
> >
> >
> >From: Ian Tickle 
> >Sent: Tuesday, November 13, 2018 4:54 PM
> >To: Zhijie Li
> >Cc: CCP4BB@JISCMAIL.AC.UK
> >Subject: Re: [ccp4bb] VERY old mtz file..
> >
> >
> >Hi Zhijie
> >
> >It's definitely a factor 4.  The code is in subroutine QTIEEE in the Fortran 
> >source I mentioned previously at this line:
> >
> >See line:
> >
> >  A(I)=((A(I)+SIGN(2,A(I)))/4.AND..NOT.MNAN).OR.MDN2
> >
> >If you prefer it in C code it's in function vaxF2ieeeF in:
> >
> >ccp4-7.0-src/checkout/libccp4/ccp4/vmslibrary.c
> >
> >See line:
> >
> >out.c[0] = buffer[i].c[1] - (uint8)1; /* subtracts 2 from e

Re: [ccp4bb] VERY old mtz file..

[Ian Tickle]

The CCP4 routines for MTZ and map files are written in C and thus do not
use a Fortran unformatted OPEN statement, they use C-style block read &
write.

Cheers

-- Ian


On Wed, 14 Nov 2018 at 08:59, Kay Diederichs 
wrote:

> It is not necessary to do error-prone conversions manually: the ifort
> Compiler understands the convert='VAXD' Option in its OPEN statement - see
>
> https://software.intel.com/en-us/fortran-compiler-developer-guide-and-reference-open-convert-specifier
>
> Thus one could just write a tiny read-write loop.
>
> HTH
> Kay
>
> On Wed, 14 Nov 2018 00:51:02 +, Zhijie Li 
> wrote:
>
> >It's also said here, at the end of file :
> >
> >https://www.cs.auckland.ac.nz/~patrice/210LN/DR4.pdf
> >
> >"add 1 to the left, with the binary point"
> >
> >0.1.
> >
> >
> >
> >
> >From: CCP4 bulletin board  on behalf of Zhijie Li
> 
> >Sent: Tuesday, November 13, 2018 7:43 PM
> >To: CCP4BB@JISCMAIL.AC.UK
> >Subject: Re: [ccp4bb] VERY old mtz file..
> >
> >
> >Hi all,
> >
> >
> >I think I know why it is a division of 4 instead of 2 is involved in
> conversion from VAX to IEEE now. Short answer: a 2 is in the exponent bits
> (bias of 128 instead of 127, visible), another 2 is hidden in the
> scientific notation.
> >
> >
> >I found this explanation+example on VAX F-float:
> >
> >http://courseweb.stthomas.edu/tpsturm/private/notes/qm300/FLOATPT.html
> >
> >
> >So for IEEE754 float32, if we want to represent a same 12.75 (1100.11) in
> the above example, we  would first conceptually write it in scientific
> notation as 1.10011 x 1000 in binary. Then the mantissa part is the part
> after the dot filled with zero to 23 bits: '1001100', the
> exponent part is 3+127=130 (dec)=1010(bin). Then the binary IEEE754
> float32 number is 0[1010][1001100]. (You can check it
> here: https://www.h-schmidt.net/FloatConverter/IEEE754.html)
> >
> >
> >Now compare this with the VAX 12.75 in the linked example, we can find
> that besides the bias becoming 128, the conceptual binary scientific
> notation is actually  0.110011 x 1, instead of 1.10011 x 1000.  So the
> exponent needed is 4 instead of 3. Then the exponent bits are
> 4+128=132=1100 and the VAX float32 becomes
> >
> >0[1100][1001100] ---if we write in a IEEE-style
> order. Note that the mantissa appears to be same as the ieee mantissa, and
> the exponent to be applied is 132-128=4. If this number is interpreted as
> IEEE754, then it will be 1.10011 x 2exp(132-127)=1.10011 x 10, four
> times of what it should be.
> >
> >
> >So, for normalised values, rearranging the VAX F-float bytes, reading as
> IEEE, then dividing by 4 gives the correct value. (The C[0]-1 treatment in
> the ccp4 lib is neat.)
> >
> >
> >In this link describing VAX floats, it is unfortunate that it only states
> that the bias for F-float is 128, but not that the mantissa starts from
> 0.01 instead of 0.1. Therefore the confusion.
> >
> >https://nssdc.gsfc.nasa.gov/nssdc/formats/VAXFloatingPoint.htm
> >
> >
> >
> >Thanks to all responded!
> >
> >
> >Zhijie
> >
> >
> >
> >From: Ian Tickle 
> >Sent: Tuesday, November 13, 2018 4:54 PM
> >To: Zhijie Li
> >Cc: CCP4BB@JISCMAIL.AC.UK
> >Subject: Re: [ccp4bb] VERY old mtz file..
> >
> >
> >Hi Zhijie
> >
> >It's definitely a factor 4.  The code is in subroutine QTIEEE in the
> Fortran source I mentioned previously at this line:
> >
> >See line:
> >
> >  A(I)=((A(I)+SIGN(2,A(I)))/4.AND..NOT.MNAN).OR.MDN2
> >
> >If you prefer it in C code it's in function vaxF2ieeeF in:
> >
> >ccp4-7.0-src/checkout/libccp4/ccp4/vmslibrary.c
> >
> >See line:
> >
> >out.c[0] = buffer[i].c[1] - (uint8)1; /* subtracts 2 from exponent */
> >
> >i.e. subtract 2 from exponent -> division by 4.
> >
> >Cheers
> >
> >-- Ian
> >
> >
> >On Tue, 13 Nov 2018 at 19:52, Zhijie Li  zhijie...@utoronto.ca>> wrote:
> >If somebody is going to send these files by email, please send one to me
> too. Thanks in advance. I actually prefer to get a MTZ file because the
> miller indices would serve as good clues for understanding the encodings.
> Even the first 1024 bytes of an MTZ would do (data array starts at byte 80
> in MTZ).
> >
> >In my life I had only seen ieee754.  According to what I can find, V

Re: [ccp4bb] VERY old mtz file..

[Phil Evans]

The CCP4 library routines are supposed to read MTZ files in any recognised 
format, provided the correct machine stamp is present, so I’m puzzled that it 
doesn’t work in this case. In the days when multiple float formats were around, 
this certainly did work. The files were always written in the native format, 
and converted if required on reading. As far as I know the code is all still in 
the libraries, so it should still work.
Phil

> On 14 Nov 2018, at 08:58, Kay Diederichs  
> wrote:
> 
> It is not necessary to do error-prone conversions manually: the ifort 
> Compiler understands the convert='VAXD' Option in its OPEN statement - see 
> https://software.intel.com/en-us/fortran-compiler-developer-guide-and-reference-open-convert-specifier
> 
> Thus one could just write a tiny read-write loop.
> 
> HTH
> Kay
> 
> On Wed, 14 Nov 2018 00:51:02 +, Zhijie Li  wrote:
> 
>> It's also said here, at the end of file :
>> 
>> https://www.cs.auckland.ac.nz/~patrice/210LN/DR4.pdf
>> 
>> "add 1 to the left, with the binary point"
>> 
>> 0.1.
>> 
>> 
>> 
>> 
>> From: CCP4 bulletin board  on behalf of Zhijie Li 
>> 
>> Sent: Tuesday, November 13, 2018 7:43 PM
>> To: CCP4BB@JISCMAIL.AC.UK
>> Subject: Re: [ccp4bb] VERY old mtz file..
>> 
>> 
>> Hi all,
>> 
>> 
>> I think I know why it is a division of 4 instead of 2 is involved in 
>> conversion from VAX to IEEE now. Short answer: a 2 is in the exponent bits 
>> (bias of 128 instead of 127, visible), another 2 is hidden in the scientific 
>> notation.
>> 
>> 
>> I found this explanation+example on VAX F-float:
>> 
>> http://courseweb.stthomas.edu/tpsturm/private/notes/qm300/FLOATPT.html
>> 
>> 
>> So for IEEE754 float32, if we want to represent a same 12.75 (1100.11) in 
>> the above example, we  would first conceptually write it in scientific 
>> notation as 1.10011 x 1000 in binary. Then the mantissa part is the part 
>> after the dot filled with zero to 23 bits: '1001100', the 
>> exponent part is 3+127=130 (dec)=1010(bin). Then the binary IEEE754 
>> float32 number is 0[1010][1001100]. (You can check it 
>> here: https://www.h-schmidt.net/FloatConverter/IEEE754.html)
>> 
>> 
>> Now compare this with the VAX 12.75 in the linked example, we can find that 
>> besides the bias becoming 128, the conceptual binary scientific notation is 
>> actually  0.110011 x 1, instead of 1.10011 x 1000.  So the exponent 
>> needed is 4 instead of 3. Then the exponent bits are 4+128=132=1100 and 
>> the VAX float32 becomes
>> 
>> 0[1100][1001100] ---if we write in a IEEE-style order. 
>> Note that the mantissa appears to be same as the ieee mantissa, and the 
>> exponent to be applied is 132-128=4. If this number is interpreted as 
>> IEEE754, then it will be 1.10011 x 2exp(132-127)=1.10011 x 10, four 
>> times of what it should be.
>> 
>> 
>> So, for normalised values, rearranging the VAX F-float bytes, reading as 
>> IEEE, then dividing by 4 gives the correct value. (The C[0]-1 treatment in 
>> the ccp4 lib is neat.)
>> 
>> 
>> In this link describing VAX floats, it is unfortunate that it only states 
>> that the bias for F-float is 128, but not that the mantissa starts from 0.01 
>> instead of 0.1. Therefore the confusion.
>> 
>> https://nssdc.gsfc.nasa.gov/nssdc/formats/VAXFloatingPoint.htm
>> 
>> 
>> 
>> Thanks to all responded!
>> 
>> 
>> Zhijie
>> 
>> 
>> 
>> From: Ian Tickle 
>> Sent: Tuesday, November 13, 2018 4:54 PM
>> To: Zhijie Li
>> Cc: CCP4BB@JISCMAIL.AC.UK
>> Subject: Re: [ccp4bb] VERY old mtz file..
>> 
>> 
>> Hi Zhijie
>> 
>> It's definitely a factor 4.  The code is in subroutine QTIEEE in the Fortran 
>> source I mentioned previously at this line:
>> 
>> See line:
>> 
>> A(I)=((A(I)+SIGN(2,A(I)))/4.AND..NOT.MNAN).OR.MDN2
>> 
>> If you prefer it in C code it's in function vaxF2ieeeF in:
>> 
>> ccp4-7.0-src/checkout/libccp4/ccp4/vmslibrary.c
>> 
>> See line:
>> 
>> out.c[0] = buffer[i].c[1] - (uint8)1; /* subtracts 2 from exponent */
>> 
>> i.e. subtract 2 from exponent -> division by 4.
>> 
>> Cheers
>> 
>> -- Ian
>> 
>> 
>> On Tue, 13 Nov 2018 at 19:52, Zhijie Li 
>> mailto:zhijie...@utoronto.ca>> wrote:
>> If somebod

Re: [ccp4bb] VERY old mtz file..

[Kay Diederichs]

It is not necessary to do error-prone conversions manually: the ifort Compiler 
understands the convert='VAXD' Option in its OPEN statement - see 
https://software.intel.com/en-us/fortran-compiler-developer-guide-and-reference-open-convert-specifier

Thus one could just write a tiny read-write loop.

HTH
Kay

On Wed, 14 Nov 2018 00:51:02 +, Zhijie Li  wrote:

>It's also said here, at the end of file :
>
>https://www.cs.auckland.ac.nz/~patrice/210LN/DR4.pdf
>
>"add 1 to the left, with the binary point"
>
>0.1.
>
>
>
>
>From: CCP4 bulletin board  on behalf of Zhijie Li 
>
>Sent: Tuesday, November 13, 2018 7:43 PM
>To: CCP4BB@JISCMAIL.AC.UK
>Subject: Re: [ccp4bb] VERY old mtz file..
>
>
>Hi all,
>
>
>I think I know why it is a division of 4 instead of 2 is involved in 
>conversion from VAX to IEEE now. Short answer: a 2 is in the exponent bits 
>(bias of 128 instead of 127, visible), another 2 is hidden in the scientific 
>notation.
>
>
>I found this explanation+example on VAX F-float:
>
>http://courseweb.stthomas.edu/tpsturm/private/notes/qm300/FLOATPT.html
>
>
>So for IEEE754 float32, if we want to represent a same 12.75 (1100.11) in the 
>above example, we  would first conceptually write it in scientific notation as 
>1.10011 x 1000 in binary. Then the mantissa part is the part after the dot 
>filled with zero to 23 bits: '1001100', the exponent part is 
>3+127=130 (dec)=1010(bin). Then the binary IEEE754 float32 number is 
>0[1010][1001100]. (You can check it here: 
>https://www.h-schmidt.net/FloatConverter/IEEE754.html)
>
>
>Now compare this with the VAX 12.75 in the linked example, we can find that 
>besides the bias becoming 128, the conceptual binary scientific notation is 
>actually  0.110011 x 1, instead of 1.10011 x 1000.  So the exponent needed 
>is 4 instead of 3. Then the exponent bits are 4+128=132=1100 and the VAX 
>float32 becomes
>
>0[1100][1001100] ---if we write in a IEEE-style order. 
>Note that the mantissa appears to be same as the ieee mantissa, and the 
>exponent to be applied is 132-128=4. If this number is interpreted as IEEE754, 
>then it will be 1.10011 x 2exp(132-127)=1.10011 x 10, four times of what 
>it should be.
>
>
>So, for normalised values, rearranging the VAX F-float bytes, reading as IEEE, 
>then dividing by 4 gives the correct value. (The C[0]-1 treatment in the ccp4 
>lib is neat.)
>
>
>In this link describing VAX floats, it is unfortunate that it only states that 
>the bias for F-float is 128, but not that the mantissa starts from 0.01 
>instead of 0.1. Therefore the confusion.
>
>https://nssdc.gsfc.nasa.gov/nssdc/formats/VAXFloatingPoint.htm
>
>
>
>Thanks to all responded!
>
>
>Zhijie
>
>
>
>From: Ian Tickle 
>Sent: Tuesday, November 13, 2018 4:54 PM
>To: Zhijie Li
>Cc: CCP4BB@JISCMAIL.AC.UK
>Subject: Re: [ccp4bb] VERY old mtz file..
>
>
>Hi Zhijie
>
>It's definitely a factor 4.  The code is in subroutine QTIEEE in the Fortran 
>source I mentioned previously at this line:
>
>See line:
>
>  A(I)=((A(I)+SIGN(2,A(I)))/4.AND..NOT.MNAN).OR.MDN2
>
>If you prefer it in C code it's in function vaxF2ieeeF in:
>
>ccp4-7.0-src/checkout/libccp4/ccp4/vmslibrary.c
>
>See line:
>
>out.c[0] = buffer[i].c[1] - (uint8)1; /* subtracts 2 from exponent */
>
>i.e. subtract 2 from exponent -> division by 4.
>
>Cheers
>
>-- Ian
>
>
>On Tue, 13 Nov 2018 at 19:52, Zhijie Li 
>mailto:zhijie...@utoronto.ca>> wrote:
>If somebody is going to send these files by email, please send one to me too. 
>Thanks in advance. I actually prefer to get a MTZ file because the miller 
>indices would serve as good clues for understanding the encodings.  Even the 
>first 1024 bytes of an MTZ would do (data array starts at byte 80 in MTZ).
>
>In my life I had only seen ieee754.  According to what I can find, VAX has an 
>exponent bias of 128 (ieee754 uses 127). Then it seems to me that when 
>converting from vax to ieee a division of 2 is involved. However all 
>procedures I have seen use a division of 4, which is quite puzzling to me. A 
>real data file containing meaningful numbers (eg., HKL indices) would be very 
>helpful. Thanks in advance.
>
>Zhijie
>
>> On Nov 13, 2018, at 2:21 PM, Johan Hattne 
>> mailto:hat...@ucla.edu>> wrote:
>>
>> Related by not exactly on topic: would anybody on the list be able to share 
>> old map files (not MTZ:s) with Convex, Cray, Fujitsu, or VAX reals/strings?  
>> I�d be interested to see what those files ac

Re: [ccp4bb] VERY old mtz file..

[Zhijie Li]

It's also said here, at the end of file :

https://www.cs.auckland.ac.nz/~patrice/210LN/DR4.pdf

"add 1 to the left, with the binary point"

0.1.




From: CCP4 bulletin board  on behalf of Zhijie Li 

Sent: Tuesday, November 13, 2018 7:43 PM
To: CCP4BB@JISCMAIL.AC.UK
Subject: Re: [ccp4bb] VERY old mtz file..


Hi all,


I think I know why it is a division of 4 instead of 2 is involved in conversion 
from VAX to IEEE now. Short answer: a 2 is in the exponent bits (bias of 128 
instead of 127, visible), another 2 is hidden in the scientific notation.


I found this explanation+example on VAX F-float:

http://courseweb.stthomas.edu/tpsturm/private/notes/qm300/FLOATPT.html


So for IEEE754 float32, if we want to represent a same 12.75 (1100.11) in the 
above example, we  would first conceptually write it in scientific notation as 
1.10011 x 1000 in binary. Then the mantissa part is the part after the dot 
filled with zero to 23 bits: '1001100', the exponent part is 
3+127=130 (dec)=1010(bin). Then the binary IEEE754 float32 number is 
0[1010][1001100]. (You can check it here: 
https://www.h-schmidt.net/FloatConverter/IEEE754.html)


Now compare this with the VAX 12.75 in the linked example, we can find that 
besides the bias becoming 128, the conceptual binary scientific notation is 
actually  0.110011 x 1, instead of 1.10011 x 1000.  So the exponent needed 
is 4 instead of 3. Then the exponent bits are 4+128=132=1100 and the VAX 
float32 becomes

0[1100][1001100] ---if we write in a IEEE-style order. Note 
that the mantissa appears to be same as the ieee mantissa, and the exponent to 
be applied is 132-128=4. If this number is interpreted as IEEE754, then it will 
be 1.10011 x 2exp(132-127)=1.10011 x 10, four times of what it should be.


So, for normalised values, rearranging the VAX F-float bytes, reading as IEEE, 
then dividing by 4 gives the correct value. (The C[0]-1 treatment in the ccp4 
lib is neat.)


In this link describing VAX floats, it is unfortunate that it only states that 
the bias for F-float is 128, but not that the mantissa starts from 0.01 instead 
of 0.1. Therefore the confusion.

https://nssdc.gsfc.nasa.gov/nssdc/formats/VAXFloatingPoint.htm



Thanks to all responded!


Zhijie



From: Ian Tickle 
Sent: Tuesday, November 13, 2018 4:54 PM
To: Zhijie Li
Cc: CCP4BB@JISCMAIL.AC.UK
Subject: Re: [ccp4bb] VERY old mtz file..


Hi Zhijie

It's definitely a factor 4.  The code is in subroutine QTIEEE in the Fortran 
source I mentioned previously at this line:

See line:

  A(I)=((A(I)+SIGN(2,A(I)))/4.AND..NOT.MNAN).OR.MDN2

If you prefer it in C code it's in function vaxF2ieeeF in:

ccp4-7.0-src/checkout/libccp4/ccp4/vmslibrary.c

See line:

out.c[0] = buffer[i].c[1] - (uint8)1; /* subtracts 2 from exponent */

i.e. subtract 2 from exponent -> division by 4.

Cheers

-- Ian


On Tue, 13 Nov 2018 at 19:52, Zhijie Li 
mailto:zhijie...@utoronto.ca>> wrote:
If somebody is going to send these files by email, please send one to me too. 
Thanks in advance. I actually prefer to get a MTZ file because the miller 
indices would serve as good clues for understanding the encodings.  Even the 
first 1024 bytes of an MTZ would do (data array starts at byte 80 in MTZ).

In my life I had only seen ieee754.  According to what I can find, VAX has an 
exponent bias of 128 (ieee754 uses 127). Then it seems to me that when 
converting from vax to ieee a division of 2 is involved. However all procedures 
I have seen use a division of 4, which is quite puzzling to me. A real data 
file containing meaningful numbers (eg., HKL indices) would be very helpful. 
Thanks in advance.

Zhijie

> On Nov 13, 2018, at 2:21 PM, Johan Hattne 
> mailto:hat...@ucla.edu>> wrote:
>
> Related by not exactly on topic: would anybody on the list be able to share 
> old map files (not MTZ:s) with Convex, Cray, Fujitsu, or VAX reals/strings?  
> I’d be interested to see what those files actually look(ed) like.
>
> // Best wishes; Johan
>
>> On Nov 9, 2018, at 18:38, Zhijie Li 
>> mailto:zhijie...@utoronto.ca>> wrote:
>>
>> Hi all,
>>
>> On linux there are a few good GUI HEX editors. Here I’d like to recommend 
>> BLESS, which conveniently displays all possible numerical interpretations of 
>> the four bytes under cursor. It also allows the user to switch between big 
>> endian or little endian through a checkbox. Unfortunately all floats are 
>> assumed to be IEEE754, therefore VAX floats won’t be interpreted correctly.  
>> ( The simplest way to convert vax to ieee float would be to write a little 
>> program to do some bit operations. I’d be happy to take that as my weekend 
>> project)
>>
>>
>> BTW, along the line of space efficiency, I can

Re: [ccp4bb] VERY old mtz file..

[Zhijie Li]

Hi all,


I think I know why it is a division of 4 instead of 2 is involved in conversion 
from VAX to IEEE now. Short answer: a 2 is in the exponent bits (bias of 128 
instead of 127, visible), another 2 is hidden in the scientific notation.


I found this explanation+example on VAX F-float:

http://courseweb.stthomas.edu/tpsturm/private/notes/qm300/FLOATPT.html


So for IEEE754 float32, if we want to represent a same 12.75 (1100.11) in the 
above example, we  would first conceptually write it in scientific notation as 
1.10011 x 1000 in binary. Then the mantissa part is the part after the dot 
filled with zero to 23 bits: '1001100', the exponent part is 
3+127=130 (dec)=1010(bin). Then the binary IEEE754 float32 number is 
0[1010][1001100]. (You can check it here: 
https://www.h-schmidt.net/FloatConverter/IEEE754.html)


Now compare this with the VAX 12.75 in the linked example, we can find that 
besides the bias becoming 128, the conceptual binary scientific notation is 
actually  0.110011 x 1, instead of 1.10011 x 1000.  So the exponent needed 
is 4 instead of 3. Then the exponent bits are 4+128=132=1100 and the VAX 
float32 becomes

0[1100][1001100] ---if we write in a IEEE-style order. Note 
that the mantissa appears to be same as the ieee mantissa, and the exponent to 
be applied is 132-128=4. If this number is interpreted as IEEE754, then it will 
be 1.10011 x 2exp(132-127)=1.10011 x 10, four times of what it should be.


So, for normalised values, rearranging the VAX F-float bytes, reading as IEEE, 
then dividing by 4 gives the correct value. (The C[0]-1 treatment in the ccp4 
lib is neat.)


In this link describing VAX floats, it is unfortunate that it only states that 
the bias for F-float is 128, but not that the mantissa starts from 0.01 instead 
of 0.1. Therefore the confusion.

https://nssdc.gsfc.nasa.gov/nssdc/formats/VAXFloatingPoint.htm



Thanks to all responded!


Zhijie



From: Ian Tickle 
Sent: Tuesday, November 13, 2018 4:54 PM
To: Zhijie Li
Cc: CCP4BB@JISCMAIL.AC.UK
Subject: Re: [ccp4bb] VERY old mtz file..


Hi Zhijie

It's definitely a factor 4.  The code is in subroutine QTIEEE in the Fortran 
source I mentioned previously at this line:

See line:

  A(I)=((A(I)+SIGN(2,A(I)))/4.AND..NOT.MNAN).OR.MDN2

If you prefer it in C code it's in function vaxF2ieeeF in:

ccp4-7.0-src/checkout/libccp4/ccp4/vmslibrary.c

See line:

out.c[0] = buffer[i].c[1] - (uint8)1; /* subtracts 2 from exponent */

i.e. subtract 2 from exponent -> division by 4.

Cheers

-- Ian


On Tue, 13 Nov 2018 at 19:52, Zhijie Li 
mailto:zhijie...@utoronto.ca>> wrote:
If somebody is going to send these files by email, please send one to me too. 
Thanks in advance. I actually prefer to get a MTZ file because the miller 
indices would serve as good clues for understanding the encodings.  Even the 
first 1024 bytes of an MTZ would do (data array starts at byte 80 in MTZ).

In my life I had only seen ieee754.  According to what I can find, VAX has an 
exponent bias of 128 (ieee754 uses 127). Then it seems to me that when 
converting from vax to ieee a division of 2 is involved. However all procedures 
I have seen use a division of 4, which is quite puzzling to me. A real data 
file containing meaningful numbers (eg., HKL indices) would be very helpful. 
Thanks in advance.

Zhijie

> On Nov 13, 2018, at 2:21 PM, Johan Hattne 
> mailto:hat...@ucla.edu>> wrote:
>
> Related by not exactly on topic: would anybody on the list be able to share 
> old map files (not MTZ:s) with Convex, Cray, Fujitsu, or VAX reals/strings?  
> I’d be interested to see what those files actually look(ed) like.
>
> // Best wishes; Johan
>
>> On Nov 9, 2018, at 18:38, Zhijie Li 
>> mailto:zhijie...@utoronto.ca>> wrote:
>>
>> Hi all,
>>
>> On linux there are a few good GUI HEX editors. Here I’d like to recommend 
>> BLESS, which conveniently displays all possible numerical interpretations of 
>> the four bytes under cursor. It also allows the user to switch between big 
>> endian or little endian through a checkbox. Unfortunately all floats are 
>> assumed to be IEEE754, therefore VAX floats won’t be interpreted correctly.  
>> ( The simplest way to convert vax to ieee float would be to write a little 
>> program to do some bit operations. I’d be happy to take that as my weekend 
>> project)
>>
>>
>> BTW, along the line of space efficiency, I can’t help noticing that the 
>> miller indices are saved as float32 in mtz, as all other numbers in mtz. 
>> This certainly have made mtz format a beautiful homogeneous data format ;).  
>> In this particular case, if we have doubts about the reliability of the 
>> machine stamp, trying to restore the miller indices would be a good way to 

Re: [ccp4bb] VERY old mtz file..

[Ian Tickle]

Hi Zhijie

It's definitely a factor 4.  The code is in subroutine QTIEEE in the
Fortran source I mentioned previously at this line:

See line:

  A(I)=((A(I)+SIGN(2,A(I)))/4.AND..NOT.MNAN).OR.MDN2

If you prefer it in C code it's in function vaxF2ieeeF in:

ccp4-7.0-src/checkout/libccp4/ccp4/vmslibrary.c

See line:

out.c[0] = buffer[i].c[1] - (uint8)1; /* subtracts 2 from exponent */

i.e. subtract 2 from exponent -> division by 4.

Cheers

-- Ian


On Tue, 13 Nov 2018 at 19:52, Zhijie Li  wrote:

> If somebody is going to send these files by email, please send one to me
> too. Thanks in advance. I actually prefer to get a MTZ file because the
> miller indices would serve as good clues for understanding the encodings.
> Even the first 1024 bytes of an MTZ would do (data array starts at byte 80
> in MTZ).
>
> In my life I had only seen ieee754.  According to what I can find, VAX has
> an exponent bias of 128 (ieee754 uses 127). Then it seems to me that when
> converting from vax to ieee a division of 2 is involved. However all
> procedures I have seen use a division of 4, which is quite puzzling to me.
> A real data file containing meaningful numbers (eg., HKL indices) would be
> very helpful. Thanks in advance.
>
> Zhijie
>
> > On Nov 13, 2018, at 2:21 PM, Johan Hattne  wrote:
> >
> > Related by not exactly on topic: would anybody on the list be able to
> share old map files (not MTZ:s) with Convex, Cray, Fujitsu, or VAX
> reals/strings?  I’d be interested to see what those files actually look(ed)
> like.
> >
> > // Best wishes; Johan
> >
> >> On Nov 9, 2018, at 18:38, Zhijie Li  wrote:
> >>
> >> Hi all,
> >>
> >> On linux there are a few good GUI HEX editors. Here I’d like to
> recommend BLESS, which conveniently displays all possible numerical
> interpretations of the four bytes under cursor. It also allows the user to
> switch between big endian or little endian through a checkbox.
> Unfortunately all floats are assumed to be IEEE754, therefore VAX floats
> won’t be interpreted correctly.  ( The simplest way to convert vax to ieee
> float would be to write a little program to do some bit operations. I’d be
> happy to take that as my weekend project)
> >>
> >>
> >> BTW, along the line of space efficiency, I can’t help noticing that the
> miller indices are saved as float32 in mtz, as all other numbers in mtz.
> This certainly have made mtz format a beautiful homogeneous data format
> ;).  In this particular case, if we have doubts about the reliability of
> the machine stamp, trying to restore the miller indices would be a good way
> to test hypotheses.
> >>
> >> Zhijie
> >>
> >>> On Nov 9, 2018, at 9:04 PM, James Holton <
> 270165b9f4cf-dmarc-requ...@jiscmail.ac.uk> wrote:
> >>>
> >>> As a beamline scientist I must say I am glad that diffraction image
> data is not usually stored as ASCII text.  In fact, I am slowly warming to
> the idea of storing it as not just binary, but compressed formats.
> Problem, I'm sure will be that it won't be  long before we forget how to
> decompress them, as most of the algorithms we are using aren't all that
> widespread.  Probably around the same time future generations will curse us
> for using ASCII instead of unicode, which is a 16-bit standard. I'm sure we
> will be reviled for limiting ourselves so, just to save a factor of two in
> disk space.
> >>> In situations like this I always use the unix "od" command.  It makes
> everything "human readable" by converting the bytes into strings you can
> read.  Then it is just a matter of figuring out what the bytes are.
> >>> Unfortunately, "od" only decodes floats on the native platform, so if
> the mtz is from another platform (Windows vs Linux, for example), then you
> might need to do some swapping.  Thus far, I have encountered files that
> require one of a few swapping strategies in order to make them work:
> >>>
> >>> 1 2 3 4 - no swapping
> >>>
> >>> 4 3 2 1 - reverse all bytes
> >>>
> >>> 3 4 1 2 - swap words and swap bytes within the words
> >>> 2 1 4 3 - reverse of previous
> >>>
> >>> 2-1 1 4 3 - same as last, but if not all zero, decrement byte #2
> before swapping
> >>> 3 4 1 2+1 - same as 3412, but if not all zero increment byte #2 before
> swapping
> >>> I'm sure there are other combinations, but the oldest MTZ I have is
> only from 1996.
> >>>
> >>> -James Holton
> >>> MAD Scientist
> >>>
> >>>
>  On 11/9/2018 4:47 AM, Eleanor Dodson wrote:
>  Anyone any idea what to do about this?? Created in 1992!!
>  Seems unreadable..
> 
>  No CTYP lines input for file:  1
> Indices output even if all data items flagged "missing"
>  Warning, NOT all LABOUT data lines given
>  Warning: Machine stamp corrupted? Assuming native format.
> >> CCP4 library signal library_file:End of File (Error)
> 
> 
>  To unsubscribe from the CCP4BB list, click the following link:
>  https://www.jiscmail.ac.uk/cgi-bin/webadmin?SUBED1=CCP4BB=1
> 
> >>>
> >>>
> >>> To 

Re: [ccp4bb] VERY old mtz file..

[Phil]

MTZ was always 32 bit floats for the main data, with ASCII headers at the end

Sent from my iPhone

> On 13 Nov 2018, at 21:29, Ethan A Merritt  wrote:
> 
>> On Tuesday, November 13, 2018 1:06:01 PM PST Zhijie Li wrote:
>> Hi Ethan,
>> Thanks for the information. My guess is that in MTZ only F-float is 
>> expected, because it is the only 32bit form? 
> 
> I do not remember exactly what was used for mtz files at that time.
> It might have been REAL*4 or it might have been REAL*8.
> <\me rummages along the shelf above my desk>
> Looking here at my trusty VAX-11 Fortran manual from April 1982,
> D_floating was the default for REAL*8.
> 
> F_floating: 1 bit sign,  8 bit exponent,  23 bit mantissa
> D_floating: 1 bit sign,  8 bit exponent,  55 bit mantissa 
> G_floating: 1 bit sign, 11 bit exponent, 52 bit mantissa
> 
> Later on they introduced H_floating, S_floating, T_floating and probably an 
> entire
> zoo that went extinct shortly after.
> 
> Bit assignments:
>https://nssdc.gsfc.nasa.gov/nssdc/formats/VAXFloatingPoint.htm
> 
> 
>Ethan
> 
> 
>> Zhijie
>> 
 On Nov 13, 2018, at 3:44 PM, Ethan A Merritt  
 wrote:
 
 On Tuesday, November 13, 2018 11:51:55 AM PST Zhijie Li wrote:
 If somebody is going to send these files by email, please send one to me 
 too. Thanks in advance. I actually prefer to get a MTZ file because the 
 miller indices would serve as good clues for understanding the encodings.  
 Even the first 1024 bytes of an MTZ would do (data array starts at byte 80 
 in MTZ).
 
 In my life I had only seen ieee754.  According to what I can find, VAX has 
 an exponent bias of 128 (ieee754 uses 127). Then it seems to me that when 
 converting from vax to ieee a division of 2 is involved.
>>> 
>>> It's more complicated than that.  VAXen supported multiple floating point 
>>> formats,
>>> F-floating G-floating and H-floating.
>>> They had differed by how many bits were used for the exponent, and hence how
>>> many bits were left for the mantissa.
>>> I can pull out the architecture manuals if necessary.
>>> 
>>>   ah, nostalgia
>>> 
>>>   Ethan
>>> 
>>> 
 However all procedures I have seen use a division of 4, which is quite 
 puzzling to me. A real data file containing meaningful numbers (eg., HKL 
 indices) would be very helpful. Thanks in advance.
 
 Zhijie
 
> On Nov 13, 2018, at 2:21 PM, Johan Hattne  wrote:
> 
> Related by not exactly on topic: would anybody on the list be able to 
> share old map files (not MTZ:s) with Convex, Cray, Fujitsu, or VAX 
> reals/strings?  I’d be interested to see what those files actually 
> look(ed) like.
> 
> // Best wishes; Johan
> 
>> On Nov 9, 2018, at 18:38, Zhijie Li  wrote:
>> 
>> Hi all,
>> 
>> On linux there are a few good GUI HEX editors. Here I’d like to 
>> recommend BLESS, which conveniently displays all possible numerical 
>> interpretations of the four bytes under cursor. It also allows the user 
>> to switch between big endian or little endian through a checkbox. 
>> Unfortunately all floats are assumed to be IEEE754, therefore VAX floats 
>> won’t be interpreted correctly.  ( The simplest way to convert vax to 
>> ieee float would be to write a little program to do some bit operations. 
>> I’d be happy to take that as my weekend project)
>> 
>> 
>> BTW, along the line of space efficiency, I can’t help noticing that the 
>> miller indices are saved as float32 in mtz, as all other numbers in mtz. 
>> This certainly have made mtz format a beautiful homogeneous data format 
>> ;).  In this particular case, if we have doubts about the reliability of 
>> the machine stamp, trying to restore the miller indices would be a good 
>> way to test hypotheses.
>> 
>> Zhijie
>> 
>>> On Nov 9, 2018, at 9:04 PM, James Holton 
>>> <270165b9f4cf-dmarc-requ...@jiscmail.ac.uk> wrote:
>>> 
>>> As a beamline scientist I must say I am glad that diffraction image 
>>> data is not usually stored as ASCII text.  In fact, I am slowly warming 
>>> to the idea of storing it as not just binary, but compressed formats.  
>>> Problem, I'm sure will be that it won't be  long before we forget how 
>>> to decompress them, as most of the algorithms we are using aren't all 
>>> that widespread.  Probably around the same time future generations will 
>>> curse us for using ASCII instead of unicode, which is a 16-bit 
>>> standard. I'm sure we will be reviled for limiting ourselves so, just 
>>> to save a factor of two in disk space.
>>> In situations like this I always use the unix "od" command.  It makes 
>>> everything "human readable" by converting the bytes into strings you 
>>> can read.  Then it is just a matter of figuring out what the bytes are.
>>> Unfortunately, "od" only decodes floats on the native 

Re: [ccp4bb] VERY old mtz file..

[Ethan A Merritt]

On Tuesday, November 13, 2018 1:06:01 PM PST Zhijie Li wrote:
> Hi Ethan,
> Thanks for the information. My guess is that in MTZ only F-float is expected, 
> because it is the only 32bit form? 

I do not remember exactly what was used for mtz files at that time.
It might have been REAL*4 or it might have been REAL*8.
<\me rummages along the shelf above my desk>
Looking here at my trusty VAX-11 Fortran manual from April 1982,
D_floating was the default for REAL*8.

F_floating: 1 bit sign,  8 bit exponent,  23 bit mantissa
D_floating: 1 bit sign,  8 bit exponent,  55 bit mantissa 
G_floating: 1 bit sign, 11 bit exponent, 52 bit mantissa

Later on they introduced H_floating, S_floating, T_floating and probably an 
entire
zoo that went extinct shortly after.

Bit assignments:
https://nssdc.gsfc.nasa.gov/nssdc/formats/VAXFloatingPoint.htm


Ethan


> Zhijie
> 
> > On Nov 13, 2018, at 3:44 PM, Ethan A Merritt  
> > wrote:
> > 
> >> On Tuesday, November 13, 2018 11:51:55 AM PST Zhijie Li wrote:
> >> If somebody is going to send these files by email, please send one to me 
> >> too. Thanks in advance. I actually prefer to get a MTZ file because the 
> >> miller indices would serve as good clues for understanding the encodings.  
> >> Even the first 1024 bytes of an MTZ would do (data array starts at byte 80 
> >> in MTZ).
> >> 
> >> In my life I had only seen ieee754.  According to what I can find, VAX has 
> >> an exponent bias of 128 (ieee754 uses 127). Then it seems to me that when 
> >> converting from vax to ieee a division of 2 is involved.
> > 
> > It's more complicated than that.  VAXen supported multiple floating point 
> > formats,
> > F-floating G-floating and H-floating.
> > They had differed by how many bits were used for the exponent, and hence how
> > many bits were left for the mantissa.
> > I can pull out the architecture manuals if necessary.
> > 
> >ah, nostalgia
> > 
> >Ethan
> > 
> > 
> >> However all procedures I have seen use a division of 4, which is quite 
> >> puzzling to me. A real data file containing meaningful numbers (eg., HKL 
> >> indices) would be very helpful. Thanks in advance.
> >> 
> >> Zhijie
> >> 
> >>> On Nov 13, 2018, at 2:21 PM, Johan Hattne  wrote:
> >>> 
> >>> Related by not exactly on topic: would anybody on the list be able to 
> >>> share old map files (not MTZ:s) with Convex, Cray, Fujitsu, or VAX 
> >>> reals/strings?  I’d be interested to see what those files actually 
> >>> look(ed) like.
> >>> 
> >>> // Best wishes; Johan
> >>> 
>  On Nov 9, 2018, at 18:38, Zhijie Li  wrote:
>  
>  Hi all,
>  
>  On linux there are a few good GUI HEX editors. Here I’d like to 
>  recommend BLESS, which conveniently displays all possible numerical 
>  interpretations of the four bytes under cursor. It also allows the user 
>  to switch between big endian or little endian through a checkbox. 
>  Unfortunately all floats are assumed to be IEEE754, therefore VAX floats 
>  won’t be interpreted correctly.  ( The simplest way to convert vax to 
>  ieee float would be to write a little program to do some bit operations. 
>  I’d be happy to take that as my weekend project)
>  
>  
>  BTW, along the line of space efficiency, I can’t help noticing that the 
>  miller indices are saved as float32 in mtz, as all other numbers in mtz. 
>  This certainly have made mtz format a beautiful homogeneous data format 
>  ;).  In this particular case, if we have doubts about the reliability of 
>  the machine stamp, trying to restore the miller indices would be a good 
>  way to test hypotheses.
>  
>  Zhijie
>  
> > On Nov 9, 2018, at 9:04 PM, James Holton 
> > <270165b9f4cf-dmarc-requ...@jiscmail.ac.uk> wrote:
> > 
> > As a beamline scientist I must say I am glad that diffraction image 
> > data is not usually stored as ASCII text.  In fact, I am slowly warming 
> > to the idea of storing it as not just binary, but compressed formats.  
> > Problem, I'm sure will be that it won't be  long before we forget how 
> > to decompress them, as most of the algorithms we are using aren't all 
> > that widespread.  Probably around the same time future generations will 
> > curse us for using ASCII instead of unicode, which is a 16-bit 
> > standard. I'm sure we will be reviled for limiting ourselves so, just 
> > to save a factor of two in disk space.
> > In situations like this I always use the unix "od" command.  It makes 
> > everything "human readable" by converting the bytes into strings you 
> > can read.  Then it is just a matter of figuring out what the bytes are.
> > Unfortunately, "od" only decodes floats on the native platform, so if 
> > the mtz is from another platform (Windows vs Linux, for example), then 
> > you might need to do some swapping.  Thus far, I have encountered files 
> > that require one 

Re: [ccp4bb] VERY old mtz file..

[Zhijie Li]

Hi Ethan,
Thanks for the information. My guess is that in MTZ only F-float is expected, 
because it is the only 32bit form? 
Zhijie

> On Nov 13, 2018, at 3:44 PM, Ethan A Merritt  wrote:
> 
>> On Tuesday, November 13, 2018 11:51:55 AM PST Zhijie Li wrote:
>> If somebody is going to send these files by email, please send one to me 
>> too. Thanks in advance. I actually prefer to get a MTZ file because the 
>> miller indices would serve as good clues for understanding the encodings.  
>> Even the first 1024 bytes of an MTZ would do (data array starts at byte 80 
>> in MTZ).
>> 
>> In my life I had only seen ieee754.  According to what I can find, VAX has 
>> an exponent bias of 128 (ieee754 uses 127). Then it seems to me that when 
>> converting from vax to ieee a division of 2 is involved.
> 
> It's more complicated than that.  VAXen supported multiple floating point 
> formats,
> F-floating G-floating and H-floating.
> They had differed by how many bits were used for the exponent, and hence how
> many bits were left for the mantissa.
> I can pull out the architecture manuals if necessary.
> 
>ah, nostalgia
> 
>Ethan
> 
> 
>> However all procedures I have seen use a division of 4, which is quite 
>> puzzling to me. A real data file containing meaningful numbers (eg., HKL 
>> indices) would be very helpful. Thanks in advance.
>> 
>> Zhijie
>> 
>>> On Nov 13, 2018, at 2:21 PM, Johan Hattne  wrote:
>>> 
>>> Related by not exactly on topic: would anybody on the list be able to share 
>>> old map files (not MTZ:s) with Convex, Cray, Fujitsu, or VAX reals/strings? 
>>>  I’d be interested to see what those files actually look(ed) like.
>>> 
>>> // Best wishes; Johan
>>> 
 On Nov 9, 2018, at 18:38, Zhijie Li  wrote:
 
 Hi all,
 
 On linux there are a few good GUI HEX editors. Here I’d like to recommend 
 BLESS, which conveniently displays all possible numerical interpretations 
 of the four bytes under cursor. It also allows the user to switch between 
 big endian or little endian through a checkbox. Unfortunately all floats 
 are assumed to be IEEE754, therefore VAX floats won’t be interpreted 
 correctly.  ( The simplest way to convert vax to ieee float would be to 
 write a little program to do some bit operations. I’d be happy to take 
 that as my weekend project)
 
 
 BTW, along the line of space efficiency, I can’t help noticing that the 
 miller indices are saved as float32 in mtz, as all other numbers in mtz. 
 This certainly have made mtz format a beautiful homogeneous data format 
 ;).  In this particular case, if we have doubts about the reliability of 
 the machine stamp, trying to restore the miller indices would be a good 
 way to test hypotheses.
 
 Zhijie
 
> On Nov 9, 2018, at 9:04 PM, James Holton 
> <270165b9f4cf-dmarc-requ...@jiscmail.ac.uk> wrote:
> 
> As a beamline scientist I must say I am glad that diffraction image data 
> is not usually stored as ASCII text.  In fact, I am slowly warming to the 
> idea of storing it as not just binary, but compressed formats.  Problem, 
> I'm sure will be that it won't be  long before we forget how to 
> decompress them, as most of the algorithms we are using aren't all that 
> widespread.  Probably around the same time future generations will curse 
> us for using ASCII instead of unicode, which is a 16-bit standard. I'm 
> sure we will be reviled for limiting ourselves so, just to save a factor 
> of two in disk space.
> In situations like this I always use the unix "od" command.  It makes 
> everything "human readable" by converting the bytes into strings you can 
> read.  Then it is just a matter of figuring out what the bytes are.
> Unfortunately, "od" only decodes floats on the native platform, so if the 
> mtz is from another platform (Windows vs Linux, for example), then you 
> might need to do some swapping.  Thus far, I have encountered files that 
> require one of a few swapping strategies in order to make them work:
> 
> 1 2 3 4 - no swapping
> 
> 4 3 2 1 - reverse all bytes
> 
> 3 4 1 2 - swap words and swap bytes within the words
> 2 1 4 3 - reverse of previous
> 
> 2-1 1 4 3 - same as last, but if not all zero, decrement byte #2 before 
> swapping
> 3 4 1 2+1 - same as 3412, but if not all zero increment byte #2 before 
> swapping
> I'm sure there are other combinations, but the oldest MTZ I have is only 
> from 1996.
> 
> -James Holton
> MAD Scientist
> 
> 
>> On 11/9/2018 4:47 AM, Eleanor Dodson wrote:
>> Anyone any idea what to do about this?? Created in 1992!!
>> Seems unreadable..
>> 
>> No CTYP lines input for file:  1
>>   Indices output even if all data items flagged "missing"
>> Warning, NOT all LABOUT data lines given
>> Warning: Machine stamp 

Re: [ccp4bb] VERY old mtz file..

[Keller, Jacob]

>>  ah, nostalgia

Ah, "mantissa!" Haven't heard "mantissa" in decades...

Is there such a thing as a "praying mantissa?" Seems like there could be a good 
geek joke about it.

JPK



> However all procedures I have seen use a division of 4, which is quite 
> puzzling to me. A real data file containing meaningful numbers (eg., HKL 
> indices) would be very helpful. Thanks in advance.
> 
> Zhijie
> 
> > On Nov 13, 2018, at 2:21 PM, Johan Hattne  wrote:
> > 
> > Related by not exactly on topic: would anybody on the list be able to share 
> > old map files (not MTZ:s) with Convex, Cray, Fujitsu, or VAX reals/strings? 
> >  I’d be interested to see what those files actually look(ed) like.
> > 
> > // Best wishes; Johan
> > 
> >> On Nov 9, 2018, at 18:38, Zhijie Li  wrote:
> >> 
> >> Hi all,
> >> 
> >> On linux there are a few good GUI HEX editors. Here I’d like to 
> >> recommend BLESS, which conveniently displays all possible numerical 
> >> interpretations of the four bytes under cursor. It also allows the 
> >> user to switch between big endian or little endian through a 
> >> checkbox. Unfortunately all floats are assumed to be IEEE754, 
> >> therefore VAX floats won’t be interpreted correctly.  ( The 
> >> simplest way to convert vax to ieee float would be to write a 
> >> little program to do some bit operations. I’d be happy to take that 
> >> as my weekend project)
> >> 
> >> 
> >> BTW, along the line of space efficiency, I can’t help noticing that the 
> >> miller indices are saved as float32 in mtz, as all other numbers in mtz. 
> >> This certainly have made mtz format a beautiful homogeneous data format 
> >> ;).  In this particular case, if we have doubts about the reliability of 
> >> the machine stamp, trying to restore the miller indices would be a good 
> >> way to test hypotheses.
> >> 
> >> Zhijie
> >> 
> >>> On Nov 9, 2018, at 9:04 PM, James Holton 
> >>> <270165b9f4cf-dmarc-requ...@jiscmail.ac.uk> wrote:
> >>> 
> >>> As a beamline scientist I must say I am glad that diffraction image data 
> >>> is not usually stored as ASCII text.  In fact, I am slowly warming to the 
> >>> idea of storing it as not just binary, but compressed formats.  Problem, 
> >>> I'm sure will be that it won't be  long before we forget how to 
> >>> decompress them, as most of the algorithms we are using aren't all that 
> >>> widespread.  Probably around the same time future generations will curse 
> >>> us for using ASCII instead of unicode, which is a 16-bit standard. I'm 
> >>> sure we will be reviled for limiting ourselves so, just to save a factor 
> >>> of two in disk space.
> >>> In situations like this I always use the unix "od" command.  It makes 
> >>> everything "human readable" by converting the bytes into strings you can 
> >>> read.  Then it is just a matter of figuring out what the bytes are.
> >>> Unfortunately, "od" only decodes floats on the native platform, so if the 
> >>> mtz is from another platform (Windows vs Linux, for example), then you 
> >>> might need to do some swapping.  Thus far, I have encountered files that 
> >>> require one of a few swapping strategies in order to make them work:
> >>> 
> >>> 1 2 3 4 - no swapping
> >>> 
> >>> 4 3 2 1 - reverse all bytes
> >>> 
> >>> 3 4 1 2 - swap words and swap bytes within the words
> >>> 2 1 4 3 - reverse of previous
> >>> 
> >>> 2-1 1 4 3 - same as last, but if not all zero, decrement byte #2 
> >>> before swapping
> >>> 3 4 1 2+1 - same as 3412, but if not all zero increment byte #2 
> >>> before swapping I'm sure there are other combinations, but the oldest MTZ 
> >>> I have is only from 1996.
> >>> 
> >>> -James Holton
> >>> MAD Scientist
> >>> 
> >>> 
>  On 11/9/2018 4:47 AM, Eleanor Dodson wrote:
>  Anyone any idea what to do about this?? Created in 1992!!
>  Seems unreadable..
>  
>  No CTYP lines input for file:  1
> Indices output even if all data items flagged "missing"
>  Warning, NOT all LABOUT data lines given
>  Warning: Machine stamp corrupted? Assuming native format. 
> >> CCP4 library signal library_file:End of File (Error)
>  
>  
>  To unsubscribe from the CCP4BB list, click the following link:
>  https://www.jiscmail.ac.uk/cgi-bin/webadmin?SUBED1=CCP4BB=1
>  
> >>> 
> >>> 
> >>> To unsubscribe from the CCP4BB list, click the following link:
> >>> https://www.jiscmail.ac.uk/cgi-bin/webadmin?SUBED1=CCP4BB=1
> >>> 
> >> 
> >> To unsubscribe from the CCP4BB list, click the following link:
> >> https://www.jiscmail.ac.uk/cgi-bin/webadmin?SUBED1=CCP4BB=1
> >> 
> > 
> >  Research Specialist @ Gonen Lab 
> > 
> >  UCLA * 615 Charles E. Young Drive South
> > BSRB #347 * Los Angeles, CA 90095
> > 
> > 
> > 
> > 
> > To unsubscribe from the CCP4BB list, click the following link:
> > 

Re: [ccp4bb] VERY old mtz file..

[Ethan A Merritt]

On Tuesday, November 13, 2018 11:51:55 AM PST Zhijie Li wrote:
> If somebody is going to send these files by email, please send one to me too. 
> Thanks in advance. I actually prefer to get a MTZ file because the miller 
> indices would serve as good clues for understanding the encodings.  Even the 
> first 1024 bytes of an MTZ would do (data array starts at byte 80 in MTZ).
> 
> In my life I had only seen ieee754.  According to what I can find, VAX has an 
> exponent bias of 128 (ieee754 uses 127). Then it seems to me that when 
> converting from vax to ieee a division of 2 is involved.

It's more complicated than that.  VAXen supported multiple floating point 
formats,
F-floating G-floating and H-floating.
They had differed by how many bits were used for the exponent, and hence how
many bits were left for the mantissa.
I can pull out the architecture manuals if necessary.

ah, nostalgia

Ethan


> However all procedures I have seen use a division of 4, which is quite 
> puzzling to me. A real data file containing meaningful numbers (eg., HKL 
> indices) would be very helpful. Thanks in advance.
> 
> Zhijie
> 
> > On Nov 13, 2018, at 2:21 PM, Johan Hattne  wrote:
> > 
> > Related by not exactly on topic: would anybody on the list be able to share 
> > old map files (not MTZ:s) with Convex, Cray, Fujitsu, or VAX reals/strings? 
> >  I’d be interested to see what those files actually look(ed) like.
> > 
> > // Best wishes; Johan
> > 
> >> On Nov 9, 2018, at 18:38, Zhijie Li  wrote:
> >> 
> >> Hi all,
> >> 
> >> On linux there are a few good GUI HEX editors. Here I’d like to recommend 
> >> BLESS, which conveniently displays all possible numerical interpretations 
> >> of the four bytes under cursor. It also allows the user to switch between 
> >> big endian or little endian through a checkbox. Unfortunately all floats 
> >> are assumed to be IEEE754, therefore VAX floats won’t be interpreted 
> >> correctly.  ( The simplest way to convert vax to ieee float would be to 
> >> write a little program to do some bit operations. I’d be happy to take 
> >> that as my weekend project)
> >> 
> >> 
> >> BTW, along the line of space efficiency, I can’t help noticing that the 
> >> miller indices are saved as float32 in mtz, as all other numbers in mtz. 
> >> This certainly have made mtz format a beautiful homogeneous data format 
> >> ;).  In this particular case, if we have doubts about the reliability of 
> >> the machine stamp, trying to restore the miller indices would be a good 
> >> way to test hypotheses.
> >> 
> >> Zhijie
> >> 
> >>> On Nov 9, 2018, at 9:04 PM, James Holton 
> >>> <270165b9f4cf-dmarc-requ...@jiscmail.ac.uk> wrote:
> >>> 
> >>> As a beamline scientist I must say I am glad that diffraction image data 
> >>> is not usually stored as ASCII text.  In fact, I am slowly warming to the 
> >>> idea of storing it as not just binary, but compressed formats.  Problem, 
> >>> I'm sure will be that it won't be  long before we forget how to 
> >>> decompress them, as most of the algorithms we are using aren't all that 
> >>> widespread.  Probably around the same time future generations will curse 
> >>> us for using ASCII instead of unicode, which is a 16-bit standard. I'm 
> >>> sure we will be reviled for limiting ourselves so, just to save a factor 
> >>> of two in disk space.
> >>> In situations like this I always use the unix "od" command.  It makes 
> >>> everything "human readable" by converting the bytes into strings you can 
> >>> read.  Then it is just a matter of figuring out what the bytes are.
> >>> Unfortunately, "od" only decodes floats on the native platform, so if the 
> >>> mtz is from another platform (Windows vs Linux, for example), then you 
> >>> might need to do some swapping.  Thus far, I have encountered files that 
> >>> require one of a few swapping strategies in order to make them work:
> >>> 
> >>> 1 2 3 4 - no swapping
> >>> 
> >>> 4 3 2 1 - reverse all bytes
> >>> 
> >>> 3 4 1 2 - swap words and swap bytes within the words
> >>> 2 1 4 3 - reverse of previous
> >>> 
> >>> 2-1 1 4 3 - same as last, but if not all zero, decrement byte #2 before 
> >>> swapping
> >>> 3 4 1 2+1 - same as 3412, but if not all zero increment byte #2 before 
> >>> swapping
> >>> I'm sure there are other combinations, but the oldest MTZ I have is only 
> >>> from 1996.
> >>> 
> >>> -James Holton
> >>> MAD Scientist
> >>> 
> >>> 
>  On 11/9/2018 4:47 AM, Eleanor Dodson wrote:
>  Anyone any idea what to do about this?? Created in 1992!!
>  Seems unreadable..
>  
>  No CTYP lines input for file:  1
> Indices output even if all data items flagged "missing"
>  Warning, NOT all LABOUT data lines given
>  Warning: Machine stamp corrupted? Assuming native format. 
> >> CCP4 library signal library_file:End of File (Error)
>  
>  
>  To unsubscribe from the CCP4BB list, click the following link:
>  

Re: [ccp4bb] VERY old mtz file..

[Zhijie Li]

If somebody is going to send these files by email, please send one to me too. 
Thanks in advance. I actually prefer to get a MTZ file because the miller 
indices would serve as good clues for understanding the encodings.  Even the 
first 1024 bytes of an MTZ would do (data array starts at byte 80 in MTZ).

In my life I had only seen ieee754.  According to what I can find, VAX has an 
exponent bias of 128 (ieee754 uses 127). Then it seems to me that when 
converting from vax to ieee a division of 2 is involved. However all procedures 
I have seen use a division of 4, which is quite puzzling to me. A real data 
file containing meaningful numbers (eg., HKL indices) would be very helpful. 
Thanks in advance.

Zhijie

> On Nov 13, 2018, at 2:21 PM, Johan Hattne  wrote:
> 
> Related by not exactly on topic: would anybody on the list be able to share 
> old map files (not MTZ:s) with Convex, Cray, Fujitsu, or VAX reals/strings?  
> I’d be interested to see what those files actually look(ed) like.
> 
> // Best wishes; Johan
> 
>> On Nov 9, 2018, at 18:38, Zhijie Li  wrote:
>> 
>> Hi all,
>> 
>> On linux there are a few good GUI HEX editors. Here I’d like to recommend 
>> BLESS, which conveniently displays all possible numerical interpretations of 
>> the four bytes under cursor. It also allows the user to switch between big 
>> endian or little endian through a checkbox. Unfortunately all floats are 
>> assumed to be IEEE754, therefore VAX floats won’t be interpreted correctly.  
>> ( The simplest way to convert vax to ieee float would be to write a little 
>> program to do some bit operations. I’d be happy to take that as my weekend 
>> project)
>> 
>> 
>> BTW, along the line of space efficiency, I can’t help noticing that the 
>> miller indices are saved as float32 in mtz, as all other numbers in mtz. 
>> This certainly have made mtz format a beautiful homogeneous data format ;).  
>> In this particular case, if we have doubts about the reliability of the 
>> machine stamp, trying to restore the miller indices would be a good way to 
>> test hypotheses.
>> 
>> Zhijie
>> 
>>> On Nov 9, 2018, at 9:04 PM, James Holton 
>>> <270165b9f4cf-dmarc-requ...@jiscmail.ac.uk> wrote:
>>> 
>>> As a beamline scientist I must say I am glad that diffraction image data is 
>>> not usually stored as ASCII text.  In fact, I am slowly warming to the idea 
>>> of storing it as not just binary, but compressed formats.  Problem, I'm 
>>> sure will be that it won't be  long before we forget how to decompress 
>>> them, as most of the algorithms we are using aren't all that widespread.  
>>> Probably around the same time future generations will curse us for using 
>>> ASCII instead of unicode, which is a 16-bit standard. I'm sure we will be 
>>> reviled for limiting ourselves so, just to save a factor of two in disk 
>>> space.
>>> In situations like this I always use the unix "od" command.  It makes 
>>> everything "human readable" by converting the bytes into strings you can 
>>> read.  Then it is just a matter of figuring out what the bytes are.
>>> Unfortunately, "od" only decodes floats on the native platform, so if the 
>>> mtz is from another platform (Windows vs Linux, for example), then you 
>>> might need to do some swapping.  Thus far, I have encountered files that 
>>> require one of a few swapping strategies in order to make them work:
>>> 
>>> 1 2 3 4 - no swapping
>>> 
>>> 4 3 2 1 - reverse all bytes
>>> 
>>> 3 4 1 2 - swap words and swap bytes within the words
>>> 2 1 4 3 - reverse of previous
>>> 
>>> 2-1 1 4 3 - same as last, but if not all zero, decrement byte #2 before 
>>> swapping
>>> 3 4 1 2+1 - same as 3412, but if not all zero increment byte #2 before 
>>> swapping
>>> I'm sure there are other combinations, but the oldest MTZ I have is only 
>>> from 1996.
>>> 
>>> -James Holton
>>> MAD Scientist
>>> 
>>> 
 On 11/9/2018 4:47 AM, Eleanor Dodson wrote:
 Anyone any idea what to do about this?? Created in 1992!!
 Seems unreadable..
 
 No CTYP lines input for file:  1
Indices output even if all data items flagged "missing"
 Warning, NOT all LABOUT data lines given
 Warning: Machine stamp corrupted? Assuming native format. 
>> CCP4 library signal library_file:End of File (Error)
 
 
 To unsubscribe from the CCP4BB list, click the following link:
 https://www.jiscmail.ac.uk/cgi-bin/webadmin?SUBED1=CCP4BB=1
 
>>> 
>>> 
>>> To unsubscribe from the CCP4BB list, click the following link:
>>> https://www.jiscmail.ac.uk/cgi-bin/webadmin?SUBED1=CCP4BB=1
>>> 
>> 
>> To unsubscribe from the CCP4BB list, click the following link:
>> https://www.jiscmail.ac.uk/cgi-bin/webadmin?SUBED1=CCP4BB=1
>> 
> 
>  Research Specialist @ Gonen Lab
> 
>  UCLA * 615 Charles E. Young Drive South
> BSRB #347 * Los Angeles, CA 90095
> 
> 
> 

Re: [ccp4bb] VERY old mtz file..

[Johan Hattne]

Related by not exactly on topic: would anybody on the list be able to share old 
map files (not MTZ:s) with Convex, Cray, Fujitsu, or VAX reals/strings?  I’d be 
interested to see what those files actually look(ed) like.

// Best wishes; Johan

> On Nov 9, 2018, at 18:38, Zhijie Li  wrote:
> 
> Hi all,
> 
> On linux there are a few good GUI HEX editors. Here I’d like to recommend 
> BLESS, which conveniently displays all possible numerical interpretations of 
> the four bytes under cursor. It also allows the user to switch between big 
> endian or little endian through a checkbox. Unfortunately all floats are 
> assumed to be IEEE754, therefore VAX floats won’t be interpreted correctly.  
> ( The simplest way to convert vax to ieee float would be to write a little 
> program to do some bit operations. I’d be happy to take that as my weekend 
> project)
> 
> 
> BTW, along the line of space efficiency, I can’t help noticing that the 
> miller indices are saved as float32 in mtz, as all other numbers in mtz. This 
> certainly have made mtz format a beautiful homogeneous data format ;).  In 
> this particular case, if we have doubts about the reliability of the machine 
> stamp, trying to restore the miller indices would be a good way to test 
> hypotheses.
> 
> Zhijie
> 
> On Nov 9, 2018, at 9:04 PM, James Holton 
> <270165b9f4cf-dmarc-requ...@jiscmail.ac.uk> wrote:
> 
>> As a beamline scientist I must say I am glad that diffraction image data is 
>> not usually stored as ASCII text.  In fact, I am slowly warming to the idea 
>> of storing it as not just binary, but compressed formats.  Problem, I'm sure 
>> will be that it won't be  long before we forget how to decompress them, as 
>> most of the algorithms we are using aren't all that widespread.  Probably 
>> around the same time future generations will curse us for using ASCII 
>> instead of unicode, which is a 16-bit standard. I'm sure we will be reviled 
>> for limiting ourselves so, just to save a factor of two in disk space.
>> In situations like this I always use the unix "od" command.  It makes 
>> everything "human readable" by converting the bytes into strings you can 
>> read.  Then it is just a matter of figuring out what the bytes are.
>> Unfortunately, "od" only decodes floats on the native platform, so if the 
>> mtz is from another platform (Windows vs Linux, for example), then you might 
>> need to do some swapping.  Thus far, I have encountered files that require 
>> one of a few swapping strategies in order to make them work:
>> 
>> 1 2 3 4 - no swapping
>> 
>> 4 3 2 1 - reverse all bytes
>> 
>> 3 4 1 2 - swap words and swap bytes within the words
>> 2 1 4 3 - reverse of previous
>> 
>> 2-1 1 4 3 - same as last, but if not all zero, decrement byte #2 before 
>> swapping
>> 3 4 1 2+1 - same as 3412, but if not all zero increment byte #2 before 
>> swapping
>> I'm sure there are other combinations, but the oldest MTZ I have is only 
>> from 1996.
>> 
>> -James Holton
>> MAD Scientist
>> 
>> 
>> On 11/9/2018 4:47 AM, Eleanor Dodson wrote:
>>> Anyone any idea what to do about this?? Created in 1992!!
>>> Seems unreadable..
>>> 
>>> No CTYP lines input for file:  1
>>> Indices output even if all data items flagged "missing"
>>>  Warning, NOT all LABOUT data lines given
>>> Warning: Machine stamp corrupted? Assuming native format. 
>>> >> CCP4 library signal library_file:End of File (Error)
>>> 
>>> 
>>> To unsubscribe from the CCP4BB list, click the following link:
>>> https://www.jiscmail.ac.uk/cgi-bin/webadmin?SUBED1=CCP4BB=1
>>> 
>> 
>> 
>> To unsubscribe from the CCP4BB list, click the following link:
>> https://www.jiscmail.ac.uk/cgi-bin/webadmin?SUBED1=CCP4BB=1
>> 
> 
> To unsubscribe from the CCP4BB list, click the following link:
> https://www.jiscmail.ac.uk/cgi-bin/webadmin?SUBED1=CCP4BB=1
> 

  Research Specialist @ Gonen Lab

  UCLA * 615 Charles E. Young Drive South
 BSRB #347 * Los Angeles, CA 90095



To unsubscribe from the CCP4BB list, click the following link:
https://www.jiscmail.ac.uk/cgi-bin/webadmin?SUBED1=CCP4BB=1

Re: [ccp4bb] VERY old mtz file..

[Zhijie Li]

Hi all,

On linux there are a few good GUI HEX editors. Here I’d like to recommend 
BLESS, which conveniently displays all possible numerical interpretations of 
the four bytes under cursor. It also allows the user to switch between big 
endian or little endian through a checkbox. Unfortunately all floats are 
assumed to be IEEE754, therefore VAX floats won’t be interpreted correctly.  ( 
The simplest way to convert vax to ieee float would be to write a little 
program to do some bit operations. I’d be happy to take that as my weekend 
project)


BTW, along the line of space efficiency, I can’t help noticing that the miller 
indices are saved as float32 in mtz, as all other numbers in mtz. This 
certainly have made mtz format a beautiful homogeneous data format ;).  In this 
particular case, if we have doubts about the reliability of the machine stamp, 
trying to restore the miller indices would be a good way to test hypotheses.

Zhijie

On Nov 9, 2018, at 9:04 PM, James Holton 
<270165b9f4cf-dmarc-requ...@jiscmail.ac.uk>
 wrote:


As a beamline scientist I must say I am glad that diffraction image data is not 
usually stored as ASCII text.  In fact, I am slowly warming to the idea of 
storing it as not just binary, but compressed formats.  Problem, I'm sure will 
be that it won't be long before we forget how to decompress them, as most of 
the algorithms we are using aren't all that widespread.  Probably around the 
same time future generations will curse us for using ASCII instead of unicode, 
which is a 16-bit standard. I'm sure we will be reviled for limiting ourselves 
so, just to save a factor of two in disk space.

In situations like this I always use the unix "od" command.  It makes 
everything "human readable" by converting the bytes into strings you can read.  
Then it is just a matter of figuring out what the bytes are.

Unfortunately, "od" only decodes floats on the native platform, so if the mtz 
is from another platform (Windows vs Linux, for example), then you might need 
to do some swapping.  Thus far, I have encountered files that require one of a 
few swapping strategies in order to make them work:

1 2 3 4 - no swapping

4 3 2 1 - reverse all bytes

3 4 1 2 - swap words and swap bytes within the words

2 1 4 3 - reverse of previous

2-1 1 4 3 - same as last, but if not all zero, decrement byte #2 before swapping

3 4 1 2+1 - same as 3412, but if not all zero increment byte #2 before swapping

I'm sure there are other combinations, but the oldest MTZ I have is only from 
1996.

-James Holton
MAD Scientist


On 11/9/2018 4:47 AM, Eleanor Dodson wrote:
Anyone any idea what to do about this?? Created in 1992!!
Seems unreadable..

No CTYP lines input for file:  1
Indices output even if all data items flagged "missing"
 Warning, NOT all LABOUT data lines given
Warning: Machine stamp corrupted? Assuming native format.
>> CCP4 library signal library_file:End of File (Error)




To unsubscribe from the CCP4BB list, click the following link:
https://www.jiscmail.ac.uk/cgi-bin/webadmin?SUBED1=CCP4BB=1




To unsubscribe from the CCP4BB list, click the following link:
https://www.jiscmail.ac.uk/cgi-bin/webadmin?SUBED1=CCP4BB=1



To unsubscribe from the CCP4BB list, click the following link:
https://www.jiscmail.ac.uk/cgi-bin/webadmin?SUBED1=CCP4BB=1

Re: [ccp4bb] VERY old mtz file..

[James Holton]

As a beamline scientist I must say I am glad that diffraction image data 
is not usually stored as ASCII text.  In fact, I am slowly warming to 
the idea of storing it as not just binary, but compressed formats.  
Problem, I'm sure will be that it won't be long before we forget how to 
decompress them, as most of the algorithms we are using aren't all that 
widespread.  Probably around the same time future generations will curse 
us for using ASCII instead of unicode, which is a 16-bit standard. I'm 
sure we will be reviled for limiting ourselves so, just to save a factor 
of two in disk space.


In situations like this I always use the unix "od" command.  It makes 
everything "human readable" by converting the bytes into strings you can 
read.  Then it is just a matter of figuring out what the bytes are.


Unfortunately, "od" only decodes floats on the native platform, so if 
the mtz is from another platform (Windows vs Linux, for example), then 
you might need to do some swapping.  Thus far, I have encountered files 
that require one of a few swapping strategies in order to make them work:


1 2 3 4 - no swapping

4 3 2 1 - reverse all bytes

3 4 1 2 - swap words and swap bytes within the words

2 1 4 3 - reverse of previous

2-1 1 4 3 - same as last, but if not all zero, decrement byte #2 before 
swapping


3 4 1 2+1 - same as 3412, but if not all zero increment byte #2 before 
swapping


I'm sure there are other combinations, but the oldest MTZ I have is only 
from 1996.


-James Holton
MAD Scientist


On 11/9/2018 4:47 AM, Eleanor Dodson wrote:

Anyone any idea what to do about this?? Created in 1992!!
Seems unreadable..

No CTYP lines input for file:  1
    Indices output even if all data items flagged "missing"
 Warning, NOT all LABOUT data lines given
Warning: Machine stamp corrupted? Assuming native format.
>> CCP4 library signal library_file:End of File (Error)




To unsubscribe from the CCP4BB list, click the following link:
https://www.jiscmail.ac.uk/cgi-bin/webadmin?SUBED1=CCP4BB=1






To unsubscribe from the CCP4BB list, click the following link:
https://www.jiscmail.ac.uk/cgi-bin/webadmin?SUBED1=CCP4BB=1

Re: [ccp4bb] VERY old mtz file..

[graeme.win...@diamond.ac.uk]

Dear Pavol,

Reading text files without any software is a neat trick, if you can do it.

(no file on a computer is “human readable” - but many are encoded in a form 
which allows a wide range of general tools to display it, not just specialist 
crystallography software)

;-)

I have to say, I am more impressed that Eleanor has files from ’92 - quite 
possibly older than many who will read this message!

All the best, Graeme


On 9 Nov 2018, at 13:53, Pavel Afonine 
mailto:pafon...@gmail.com>> wrote:

Now I see the value of storing data in plain text files even more (mind Shelx 
or X-plor formats, for example) -;)



On Fri, Nov 9, 2018 at 9:47 PM Clemens Vonrhein 
mailto:vonrh...@globalphasing.com>> wrote:
Hi Eleanor,

You could try running the oldest MTZ2VARIOUS binary you can find -
e.g.

  wget ftp://ftp.ccp4.ac.uk/ccp4/4.2/binaries/ccp4-4.2_Linux.tar.gz
  tar -xvf ccp4-4.2_Linux.tar.gz bin/mtz2various

  bin/mtz2various hklin ...

Any older binaries (ftp://ftp.ccp4.ac.uk/ccp4/4.0.1/) will require an
SGI or Dec/Alpha machine ;-)

If that doesn't help I would first check that it is actually a correct
MTZ file: does the ASCII header (trailer) show up with

  strings your.mtz

towards the end?

Cheers

Clemens

On Fri, Nov 09, 2018 at 12:47:09PM +, Eleanor Dodson wrote:
> Anyone any idea what to do about this?? Created in 1992!!
> Seems unreadable..
>
> No CTYP lines input for file:  1
> Indices output even if all data items flagged "missing"
>  Warning, NOT all LABOUT data lines given
> Warning: Machine stamp corrupted? Assuming native format.
> >> CCP4 library signal library_file:End of File (Error)
>
> 
>
> To unsubscribe from the CCP4BB list, click the following link:
> https://www.jiscmail.ac.uk/cgi-bin/webadmin?SUBED1=CCP4BB=1

--

*--
* Clemens Vonrhein, Ph.D. vonrhein AT GlobalPhasing DOT com
* Global Phasing Ltd., Sheraton House, Castle Park
* Cambridge CB3 0AX, UK   
www.globalphasing.com
*--



To unsubscribe from the CCP4BB list, click the following link:
https://www.jiscmail.ac.uk/cgi-bin/webadmin?SUBED1=CCP4BB=1



To unsubscribe from the CCP4BB list, click the following link:
https://www.jiscmail.ac.uk/cgi-bin/webadmin?SUBED1=CCP4BB=1


-- 
This e-mail and any attachments may contain confidential, copyright and or 
privileged material, and are for the use of the intended addressee only. If you 
are not the intended addressee or an authorised recipient of the addressee 
please notify us of receipt by returning the e-mail and do not use, copy, 
retain, distribute or disclose the information in or attached to the e-mail.
Any opinions expressed within this e-mail are those of the individual and not 
necessarily of Diamond Light Source Ltd. 
Diamond Light Source Ltd. cannot guarantee that this e-mail or any attachments 
are free from viruses and we cannot accept liability for any damage which you 
may sustain as a result of software viruses which may be transmitted in or with 
the message.
Diamond Light Source Limited (company no. 4375679). Registered in England and 
Wales with its registered office at Diamond House, Harwell Science and 
Innovation Campus, Didcot, Oxfordshire, OX11 0DE, United Kingdom




To unsubscribe from the CCP4BB list, click the following link:
https://www.jiscmail.ac.uk/cgi-bin/webadmin?SUBED1=CCP4BB=1

Re: [ccp4bb] VERY old mtz file..

[Susan Lea]

bring back the lcf format reflection file ;-)

Prof. Susan M. Lea,  FMedSci  tel: +44 1865 275181
--
Director of the Central Oxford Structural Microscopy and Imaging Centre & 
Professor of Microbiology
Sir William Dunn School of Pathology, Oxford OX1 3RE Professorial Fellow @ 
WadhamCollege


From: CCP4 bulletin board  on behalf of Ian Tickle 

Sent: 09 November 2018 19:32:50
To: CCP4BB@JISCMAIL.AC.UK
Subject: Re: [ccp4bb] VERY old mtz file..


PS if you're interested in software archaeology and you have the CCP4 library 
source code handy, check out these routines that I wrote for VAX/VMS.  Yes, we 
kept it in the source distribution all these years!

ccp4-7.0-src/checkout/libccp4/fortran/vmsdiskio.for

Subroutines QFIEEE & QTIEEE illustrate the horrible data mangling you had to do 
just to convert between Vax floating-point and IEEE (on top of the 
byte-swapping!).

Those were the days!

Cheers

-- Ian


On Fri, 9 Nov 2018 at 19:17, Ian Tickle 
mailto:ianj...@gmail.com>> wrote:

All MTZ (and map) files from the very beginning had an architecture-dependent 
'machine-stamp' in the header which *should* cause the read routines to do the 
necessary conversions if needed (i.e. where the writing & reading machine 
formats differ).  This was absolutely necessary in the days when we had a 
goodly mix of formats (VAX, Convex, Cray, SGI, IBM mainframe, IBM PC, Mac ...). 
 Now pretty well everything is Intel or compatible, i.e. little-endian IEEE 
format, so this functionality hasn't been real-world tested for aeons and it's 
possible in the meantime that it's fallen into disrepair.

Cheers

-- Ian


On Fri, 9 Nov 2018 at 18:57, Ethan A Merritt 
mailto:merr...@u.washington.edu>> wrote:
On Friday, November 9, 2018 9:12:36 AM PST Robert Esnouf wrote:
>
> Without checking further, there is a "dd" option for swapping big-endian to 
> little-endian... swab. This may simply be the issue...

DEC computers used a different floating point format.
Swapping endian-ness would be sufficient, although it might be required in 
addition.

Ethan


>
> The output of od -x may help decode the header of the file...
>
> Regards,
> Robert
>
> --
>
> Dr Robert Esnouf
>
> University Research Lecturer,
> Director of Research Computing BDI,
> Head of Research Computing Core WHG,
> NDM Research Computing Strategy Officer
>
> Main office:
> Room 10/028, Wellcome Centre for Human Genetics,
> Old Road Campus, Roosevelt Drive, Oxford OX3 7BN, UK
>
> Emails:
> rob...@strubi.ox.ac.uk<mailto:rob...@strubi.ox.ac.uk> / 
> rob...@well.ox.ac.uk<mailto:rob...@well.ox.ac.uk> / 
> robert.esn...@bdi.ox.ac.uk<mailto:robert.esn...@bdi.ox.ac.uk>
>
> Tel:   (+44)-1865-287783 (WHG); (+44)-1865-743689 (BDI)
>
>
> -Original Message-
> From: "Pavel Afonine" mailto:pafon...@gmail.com>>
> To: CCP4BB@JISCMAIL.AC.UK<mailto:CCP4BB@JISCMAIL.AC.UK>
> Date: 09/11/18 13:54
> Subject: Re: [ccp4bb] VERY old mtz file..
>
> Now I see the value of storing data in plain text files even more (mind Shelx 
> or X-plor formats, for example) -;)
>
>
>  readable files.>
>
> On Fri, Nov 9, 2018 at 9:47 PM Clemens Vonrhein 
> mailto:vonrh...@globalphasing.com>> wrote:
>
> Hi Eleanor,
>
> You could try running the oldest MTZ2VARIOUS binary you can find -
> e.g.
>
>   wget ftp://ftp.ccp4.ac.uk/ccp4/4.2/binaries/ccp4-4.2_Linux.tar.gz
>   tar -xvf ccp4-4.2_Linux.tar.gz bin/mtz2various
>
>   bin/mtz2various hklin ...
>
> Any older binaries (ftp://ftp.ccp4.ac.uk/ccp4/4.0.1/) will require an
> SGI or Dec/Alpha machine ;-)
>
> If that doesn't help I would first check that it is actually a correct
> MTZ file: does the ASCII header (trailer) show up with
>
>   strings your.mtz
>
> towards the end?
>
> Cheers
>
> Clemens
>
> On Fri, Nov 09, 2018 at 12:47:09PM +, Eleanor Dodson wrote:
> > Anyone any idea what to do about this?? Created in 1992!!
> > Seems unreadable..
> >
> > No CTYP lines input for file:  1
> > Indices output even if all data items flagged "missing"
> >  Warning, NOT all LABOUT data lines given
> > Warning: Machine stamp corrupted? Assuming native format.
> > >>>>>> CCP4 library signal library_file:End of File (Error)
> >
> > 
> >
> > To unsubscribe from the CCP4BB list, click the following link:
> > https://www.jiscmail.ac.uk/cgi-bin/webadmin?SUBED1=CCP4BB=1
>
> --
>
> *---

Re: [ccp4bb] VERY old mtz file..

[Ian Tickle]

PS if you're interested in software archaeology and you have the CCP4
library source code handy, check out these routines that I wrote for
VAX/VMS.  Yes, we kept it in the source distribution all these years!

ccp4-7.0-src/checkout/libccp4/fortran/vmsdiskio.for

Subroutines QFIEEE & QTIEEE illustrate the horrible data mangling you had
to do just to convert between Vax floating-point and IEEE (on top of the
byte-swapping!).

Those were the days!

Cheers

-- Ian


On Fri, 9 Nov 2018 at 19:17, Ian Tickle  wrote:

>
> All MTZ (and map) files from the very beginning had an
> architecture-dependent 'machine-stamp' in the header which *should* cause
> the read routines to do the necessary conversions if needed (i.e. where the
> writing & reading machine formats differ).  This was absolutely necessary
> in the days when we had a goodly mix of formats (VAX, Convex, Cray, SGI,
> IBM mainframe, IBM PC, Mac ...).  Now pretty well everything is Intel or
> compatible, i.e. little-endian IEEE format, so this functionality hasn't
> been real-world tested for aeons and it's possible in the meantime that
> it's fallen into disrepair.
>
> Cheers
>
> -- Ian
>
>
> On Fri, 9 Nov 2018 at 18:57, Ethan A Merritt 
> wrote:
>
>> On Friday, November 9, 2018 9:12:36 AM PST Robert Esnouf wrote:
>> >
>> > Without checking further, there is a "dd" option for swapping
>> big-endian to little-endian... swab. This may simply be the issue...
>>
>> DEC computers used a different floating point format.
>> Swapping endian-ness would be sufficient, although it might be required
>> in addition.
>>
>> Ethan
>>
>>
>> >
>> > The output of od -x may help decode the header of the file...
>> >
>> > Regards,
>> > Robert
>> >
>> > --
>> >
>> > Dr Robert Esnouf
>> >
>> > University Research Lecturer,
>> > Director of Research Computing BDI,
>> > Head of Research Computing Core WHG,
>> > NDM Research Computing Strategy Officer
>> >
>> > Main office:
>> > Room 10/028, Wellcome Centre for Human Genetics,
>> > Old Road Campus, Roosevelt Drive, Oxford OX3 7BN, UK
>> >
>> > Emails:
>> > rob...@strubi.ox.ac.uk / rob...@well.ox.ac.uk /
>> robert.esn...@bdi.ox.ac.uk
>> >
>> > Tel:   (+44)-1865-287783 (WHG); (+44)-1865-743689 (BDI)
>> >
>> >
>> > -Original Message-
>> > From: "Pavel Afonine" 
>> > To: CCP4BB@JISCMAIL.AC.UK
>> > Date: 09/11/18 13:54
>> > Subject: Re: [ccp4bb] VERY old mtz file..
>> >
>> > Now I see the value of storing data in plain text files even more (mind
>> Shelx or X-plor formats, for example) -;)
>> >
>> >
>> > > non-human readable files.>
>> >
>> > On Fri, Nov 9, 2018 at 9:47 PM Clemens Vonrhein <
>> vonrh...@globalphasing.com> wrote:
>> >
>> > Hi Eleanor,
>> >
>> > You could try running the oldest MTZ2VARIOUS binary you can find -
>> > e.g.
>> >
>> >   wget ftp://ftp.ccp4.ac.uk/ccp4/4.2/binaries/ccp4-4.2_Linux.tar.gz
>> >   tar -xvf ccp4-4.2_Linux.tar.gz bin/mtz2various
>> >
>> >   bin/mtz2various hklin ...
>> >
>> > Any older binaries (ftp://ftp.ccp4.ac.uk/ccp4/4.0.1/) will require an
>> > SGI or Dec/Alpha machine ;-)
>> >
>> > If that doesn't help I would first check that it is actually a correct
>> > MTZ file: does the ASCII header (trailer) show up with
>> >
>> >   strings your.mtz
>> >
>> > towards the end?
>> >
>> > Cheers
>> >
>> > Clemens
>> >
>> > On Fri, Nov 09, 2018 at 12:47:09PM +, Eleanor Dodson wrote:
>> > > Anyone any idea what to do about this?? Created in 1992!!
>> > > Seems unreadable..
>> > >
>> > > No CTYP lines input for file:  1
>> > > Indices output even if all data items flagged "missing"
>> > >  Warning, NOT all LABOUT data lines given
>> > > Warning: Machine stamp corrupted? Assuming native format.
>> > > >>>>>> CCP4 library signal library_file:End of File (Error)
>> > >
>> > >
>> 
>> > >
>> > > To unsubscribe from the CCP4BB list, click the following link:
>> > > https://www.jiscmail.ac.uk/cgi-bin/webadmin?SUBED1=CCP4BB=1
>> >
>> > --
>> >
>> > *---

Re: [ccp4bb] VERY old mtz file..

[Ian Tickle]

All MTZ (and map) files from the very beginning had an
architecture-dependent 'machine-stamp' in the header which *should* cause
the read routines to do the necessary conversions if needed (i.e. where the
writing & reading machine formats differ).  This was absolutely necessary
in the days when we had a goodly mix of formats (VAX, Convex, Cray, SGI,
IBM mainframe, IBM PC, Mac ...).  Now pretty well everything is Intel or
compatible, i.e. little-endian IEEE format, so this functionality hasn't
been real-world tested for aeons and it's possible in the meantime that
it's fallen into disrepair.

Cheers

-- Ian


On Fri, 9 Nov 2018 at 18:57, Ethan A Merritt 
wrote:

> On Friday, November 9, 2018 9:12:36 AM PST Robert Esnouf wrote:
> >
> > Without checking further, there is a "dd" option for swapping big-endian
> to little-endian... swab. This may simply be the issue...
>
> DEC computers used a different floating point format.
> Swapping endian-ness would be sufficient, although it might be required in
> addition.
>
> Ethan
>
>
> >
> > The output of od -x may help decode the header of the file...
> >
> > Regards,
> > Robert
> >
> > --
> >
> > Dr Robert Esnouf
> >
> > University Research Lecturer,
> > Director of Research Computing BDI,
> > Head of Research Computing Core WHG,
> > NDM Research Computing Strategy Officer
> >
> > Main office:
> > Room 10/028, Wellcome Centre for Human Genetics,
> > Old Road Campus, Roosevelt Drive, Oxford OX3 7BN, UK
> >
> > Emails:
> > rob...@strubi.ox.ac.uk / rob...@well.ox.ac.uk /
> robert.esn...@bdi.ox.ac.uk
> >
> > Tel:   (+44)-1865-287783 (WHG); (+44)-1865-743689 (BDI)
> >
> >
> > -Original Message-
> > From: "Pavel Afonine" 
> > To: CCP4BB@JISCMAIL.AC.UK
> > Date: 09/11/18 13:54
> > Subject: Re: [ccp4bb] VERY old mtz file..
> >
> > Now I see the value of storing data in plain text files even more (mind
> Shelx or X-plor formats, for example) -;)
> >
> >
> >  non-human readable files.>
> >
> > On Fri, Nov 9, 2018 at 9:47 PM Clemens Vonrhein <
> vonrh...@globalphasing.com> wrote:
> >
> > Hi Eleanor,
> >
> > You could try running the oldest MTZ2VARIOUS binary you can find -
> > e.g.
> >
> >   wget ftp://ftp.ccp4.ac.uk/ccp4/4.2/binaries/ccp4-4.2_Linux.tar.gz
> >   tar -xvf ccp4-4.2_Linux.tar.gz bin/mtz2various
> >
> >   bin/mtz2various hklin ...
> >
> > Any older binaries (ftp://ftp.ccp4.ac.uk/ccp4/4.0.1/) will require an
> > SGI or Dec/Alpha machine ;-)
> >
> > If that doesn't help I would first check that it is actually a correct
> > MTZ file: does the ASCII header (trailer) show up with
> >
> >   strings your.mtz
> >
> > towards the end?
> >
> > Cheers
> >
> > Clemens
> >
> > On Fri, Nov 09, 2018 at 12:47:09PM +, Eleanor Dodson wrote:
> > > Anyone any idea what to do about this?? Created in 1992!!
> > > Seems unreadable..
> > >
> > > No CTYP lines input for file:  1
> > > Indices output even if all data items flagged "missing"
> > >  Warning, NOT all LABOUT data lines given
> > > Warning: Machine stamp corrupted? Assuming native format.
> > > >>>>>> CCP4 library signal library_file:End of File (Error)
> > >
> > >
> 
> > >
> > > To unsubscribe from the CCP4BB list, click the following link:
> > > https://www.jiscmail.ac.uk/cgi-bin/webadmin?SUBED1=CCP4BB=1
> >
> > --
> >
> > *--
> > * Clemens Vonrhein, Ph.D. vonrhein AT GlobalPhasing DOT com
> > * Global Phasing Ltd., Sheraton House, Castle Park
> > * Cambridge CB3 0AX, UK   www.globalphasing.com
> > *--
> >
> > 
> >
> > To unsubscribe from the CCP4BB list, click the following link:
> > https://www.jiscmail.ac.uk/cgi-bin/webadmin?SUBED1=CCP4BB=1
> >
> >
> >
> > To unsubscribe from the CCP4BB list, click the following link:
> > https://www.jiscmail.ac.uk/cgi-bin/webadmin?SUBED1=CCP4BB=1
> >
> >
> >
> > 
> >
> > To unsubscribe from the CCP4BB list, click the following link:
> > https://www.jiscmail.ac.uk/cgi-bin/webadmin?SUBED1=CCP4BB=1
>
>
> --
> Ethan A Merritt
> Biomolecular Structure Center,  K-428 Health Sciences Bldg
> MS 357742,   University of Washington, Seattle 98195-7742
>
> 
>
> To unsubscribe from the CCP4BB list, click the following link:
> https://www.jiscmail.ac.uk/cgi-bin/webadmin?SUBED1=CCP4BB=1
>



To unsubscribe from the CCP4BB list, click the following link:
https://www.jiscmail.ac.uk/cgi-bin/webadmin?SUBED1=CCP4BB=1

Re: [ccp4bb] VERY old mtz file..

[Ethan A Merritt]

On Friday, November 9, 2018 9:12:36 AM PST Robert Esnouf wrote:
> 
> Without checking further, there is a "dd" option for swapping big-endian to 
> little-endian... swab. This may simply be the issue... 

DEC computers used a different floating point format.
Swapping endian-ness would be sufficient, although it might be required in 
addition.

Ethan


> 
> The output of od -x may help decode the header of the file...
> 
> Regards,
> Robert
> 
> --
> 
> Dr Robert Esnouf 
> 
> University Research Lecturer, 
> Director of Research Computing BDI, 
> Head of Research Computing Core WHG, 
> NDM Research Computing Strategy Officer 
> 
> Main office: 
> Room 10/028, Wellcome Centre for Human Genetics, 
> Old Road Campus, Roosevelt Drive, Oxford OX3 7BN, UK 
> 
> Emails: 
> rob...@strubi.ox.ac.uk / rob...@well.ox.ac.uk / robert.esn...@bdi.ox.ac.uk 
> 
> Tel:   (+44)-1865-287783 (WHG); (+44)-1865-743689 (BDI)
>  
> 
> -Original Message-
> From: "Pavel Afonine" 
> To: CCP4BB@JISCMAIL.AC.UK
> Date: 09/11/18 13:54
> Subject: Re: [ccp4bb] VERY old mtz file..
> 
> Now I see the value of storing data in plain text files even more (mind Shelx 
> or X-plor formats, for example) -;)
> 
> 
>  readable files.>
> 
> On Fri, Nov 9, 2018 at 9:47 PM Clemens Vonrhein  
> wrote:
> 
> Hi Eleanor,
> 
> You could try running the oldest MTZ2VARIOUS binary you can find -
> e.g.
> 
>   wget ftp://ftp.ccp4.ac.uk/ccp4/4.2/binaries/ccp4-4.2_Linux.tar.gz
>   tar -xvf ccp4-4.2_Linux.tar.gz bin/mtz2various
> 
>   bin/mtz2various hklin ...
> 
> Any older binaries (ftp://ftp.ccp4.ac.uk/ccp4/4.0.1/) will require an
> SGI or Dec/Alpha machine ;-)
> 
> If that doesn't help I would first check that it is actually a correct
> MTZ file: does the ASCII header (trailer) show up with
> 
>   strings your.mtz
> 
> towards the end?
> 
> Cheers
> 
> Clemens
> 
> On Fri, Nov 09, 2018 at 12:47:09PM +, Eleanor Dodson wrote:
> > Anyone any idea what to do about this?? Created in 1992!!
> > Seems unreadable..
> >
> > No CTYP lines input for file:  1
> > Indices output even if all data items flagged "missing"
> >  Warning, NOT all LABOUT data lines given
> > Warning: Machine stamp corrupted? Assuming native format.
> > >>>>>> CCP4 library signal library_file:End of File (Error)
> >
> > 
> >
> > To unsubscribe from the CCP4BB list, click the following link:
> > https://www.jiscmail.ac.uk/cgi-bin/webadmin?SUBED1=CCP4BB=1
> 
> --
> 
> *--
> * Clemens Vonrhein, Ph.D. vonrhein AT GlobalPhasing DOT com
> * Global Phasing Ltd., Sheraton House, Castle Park
> * Cambridge CB3 0AX, UK   www.globalphasing.com
> *--
> 
> 
> 
> To unsubscribe from the CCP4BB list, click the following link:
> https://www.jiscmail.ac.uk/cgi-bin/webadmin?SUBED1=CCP4BB=1
> 
> 
> 
> To unsubscribe from the CCP4BB list, click the following link:
> https://www.jiscmail.ac.uk/cgi-bin/webadmin?SUBED1=CCP4BB=1
> 
> 
> 
> 
> 
> To unsubscribe from the CCP4BB list, click the following link:
> https://www.jiscmail.ac.uk/cgi-bin/webadmin?SUBED1=CCP4BB=1


-- 
Ethan A Merritt
Biomolecular Structure Center,  K-428 Health Sciences Bldg
MS 357742,   University of Washington, Seattle 98195-7742



To unsubscribe from the CCP4BB list, click the following link:
https://www.jiscmail.ac.uk/cgi-bin/webadmin?SUBED1=CCP4BB=1

Re: [ccp4bb] VERY old mtz file..

[Robert Esnouf]

Without checking further, there is a "dd" option for swapping big-endian to 
little-endian... swab. This may simply be the issue... 

The output of od -x may help decode the header of the file...

Regards,
Robert

--

Dr Robert Esnouf 

University Research Lecturer, 
Director of Research Computing BDI, 
Head of Research Computing Core WHG, 
NDM Research Computing Strategy Officer 

Main office: 
Room 10/028, Wellcome Centre for Human Genetics, 
Old Road Campus, Roosevelt Drive, Oxford OX3 7BN, UK 

Emails: 
rob...@strubi.ox.ac.uk / rob...@well.ox.ac.uk / robert.esn...@bdi.ox.ac.uk 

Tel:   (+44)-1865-287783 (WHG); (+44)-1865-743689 (BDI)
 

-Original Message-
From: "Pavel Afonine" 
To: CCP4BB@JISCMAIL.AC.UK
Date: 09/11/18 13:54
Subject: Re: [ccp4bb] VERY old mtz file..

Now I see the value of storing data in plain text files even more (mind Shelx 
or X-plor formats, for example) -;)




On Fri, Nov 9, 2018 at 9:47 PM Clemens Vonrhein  
wrote:

Hi Eleanor,

You could try running the oldest MTZ2VARIOUS binary you can find -
e.g.

  wget ftp://ftp.ccp4.ac.uk/ccp4/4.2/binaries/ccp4-4.2_Linux.tar.gz
  tar -xvf ccp4-4.2_Linux.tar.gz bin/mtz2various

  bin/mtz2various hklin ...

Any older binaries (ftp://ftp.ccp4.ac.uk/ccp4/4.0.1/) will require an
SGI or Dec/Alpha machine ;-)

If that doesn't help I would first check that it is actually a correct
MTZ file: does the ASCII header (trailer) show up with

  strings your.mtz

towards the end?

Cheers

Clemens

On Fri, Nov 09, 2018 at 12:47:09PM +, Eleanor Dodson wrote:
> Anyone any idea what to do about this?? Created in 1992!!
> Seems unreadable..
>
> No CTYP lines input for file:  1
> Indices output even if all data items flagged "missing"
>  Warning, NOT all LABOUT data lines given
> Warning: Machine stamp corrupted? Assuming native format.
> >>>>>> CCP4 library signal library_file:End of File (Error)
>
> 
>
> To unsubscribe from the CCP4BB list, click the following link:
> https://www.jiscmail.ac.uk/cgi-bin/webadmin?SUBED1=CCP4BB=1

--

*--
* Clemens Vonrhein, Ph.D. vonrhein AT GlobalPhasing DOT com
* Global Phasing Ltd., Sheraton House, Castle Park
* Cambridge CB3 0AX, UK   www.globalphasing.com
*--



To unsubscribe from the CCP4BB list, click the following link:
https://www.jiscmail.ac.uk/cgi-bin/webadmin?SUBED1=CCP4BB=1



To unsubscribe from the CCP4BB list, click the following link:
https://www.jiscmail.ac.uk/cgi-bin/webadmin?SUBED1=CCP4BB=1





To unsubscribe from the CCP4BB list, click the following link:
https://www.jiscmail.ac.uk/cgi-bin/webadmin?SUBED1=CCP4BB=1

Re: [ccp4bb] VERY old mtz file..

[Pavel Afonine]

Now I see the value of storing data in plain text files even more (mind
Shelx or X-plor formats, for example) -;)



On Fri, Nov 9, 2018 at 9:47 PM Clemens Vonrhein 
wrote:

> Hi Eleanor,
>
> You could try running the oldest MTZ2VARIOUS binary you can find -
> e.g.
>
>   wget ftp://ftp.ccp4.ac.uk/ccp4/4.2/binaries/ccp4-4.2_Linux.tar.gz
>   tar -xvf ccp4-4.2_Linux.tar.gz bin/mtz2various
>
>   bin/mtz2various hklin ...
>
> Any older binaries (ftp://ftp.ccp4.ac.uk/ccp4/4.0.1/) will require an
> SGI or Dec/Alpha machine ;-)
>
> If that doesn't help I would first check that it is actually a correct
> MTZ file: does the ASCII header (trailer) show up with
>
>   strings your.mtz
>
> towards the end?
>
> Cheers
>
> Clemens
>
> On Fri, Nov 09, 2018 at 12:47:09PM +, Eleanor Dodson wrote:
> > Anyone any idea what to do about this?? Created in 1992!!
> > Seems unreadable..
> >
> > No CTYP lines input for file:  1
> > Indices output even if all data items flagged "missing"
> >  Warning, NOT all LABOUT data lines given
> > Warning: Machine stamp corrupted? Assuming native format.
> > >> CCP4 library signal library_file:End of File (Error)
> >
> > 
> >
> > To unsubscribe from the CCP4BB list, click the following link:
> > https://www.jiscmail.ac.uk/cgi-bin/webadmin?SUBED1=CCP4BB=1
>
> --
>
> *--
> * Clemens Vonrhein, Ph.D. vonrhein AT GlobalPhasing DOT com
> * Global Phasing Ltd., Sheraton House, Castle Park
> * Cambridge CB3 0AX, UK   www.globalphasing.com
> *--
>
> 
>
> To unsubscribe from the CCP4BB list, click the following link:
> https://www.jiscmail.ac.uk/cgi-bin/webadmin?SUBED1=CCP4BB=1
>



To unsubscribe from the CCP4BB list, click the following link:
https://www.jiscmail.ac.uk/cgi-bin/webadmin?SUBED1=CCP4BB=1

Re: [ccp4bb] VERY old mtz file..

[Clemens Vonrhein]

Hi Eleanor,

You could try running the oldest MTZ2VARIOUS binary you can find -
e.g.

  wget ftp://ftp.ccp4.ac.uk/ccp4/4.2/binaries/ccp4-4.2_Linux.tar.gz
  tar -xvf ccp4-4.2_Linux.tar.gz bin/mtz2various

  bin/mtz2various hklin ...

Any older binaries (ftp://ftp.ccp4.ac.uk/ccp4/4.0.1/) will require an
SGI or Dec/Alpha machine ;-)

If that doesn't help I would first check that it is actually a correct
MTZ file: does the ASCII header (trailer) show up with

  strings your.mtz

towards the end?

Cheers

Clemens

On Fri, Nov 09, 2018 at 12:47:09PM +, Eleanor Dodson wrote:
> Anyone any idea what to do about this?? Created in 1992!!
> Seems unreadable..
> 
> No CTYP lines input for file:  1
> Indices output even if all data items flagged "missing"
>  Warning, NOT all LABOUT data lines given
> Warning: Machine stamp corrupted? Assuming native format.
> >> CCP4 library signal library_file:End of File (Error)
> 
> 
> 
> To unsubscribe from the CCP4BB list, click the following link:
> https://www.jiscmail.ac.uk/cgi-bin/webadmin?SUBED1=CCP4BB=1

-- 

*--
* Clemens Vonrhein, Ph.D. vonrhein AT GlobalPhasing DOT com
* Global Phasing Ltd., Sheraton House, Castle Park 
* Cambridge CB3 0AX, UK   www.globalphasing.com
*--



To unsubscribe from the CCP4BB list, click the following link:
https://www.jiscmail.ac.uk/cgi-bin/webadmin?SUBED1=CCP4BB=1