[ccp4bb] Offtopic: Is there a way to search protein-protein interface structural similarity in database ?

[Xiao Lei]

Hi All,

I wonder if there is a way to search protein-protein interaction interface
similarities in PDB database?  For example, I have two proteins proA and
proB, part of proA and part of proB contact with each other in a crystal
structure, I want to search if there are similar interaction interfaces in
other protein structures in PDB database, I mean 3D structural similarities
of the interface, not amino acids identities similarities.

Thanks,

Xiao



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

[ccp4bb] Postdoctoral Position at the University of Chicago

[Demet Araç]

Postdoctoral Position in Cellular Communication

Applications are invited for an immediate opening at the Cellular Communication 
Group with Dr. Demet Araç, at the Department of Biochemistry and Molecular 
Biology, University of Chicago 
(http://arac.uchicago.edu).

We are interested in understanding how cellular communication is mediated by 
cell surface receptors at the molecular level. The following papers describe 
the current direction of our research program:


•   Structural basis for teneurin function in circuit-wiring: A toxin motif 
at the synapse. Li, Shalev-Benami, Sando,…, Südhof, Skiniotis, Araç. Cell (2018)


•   Structural basis for regulation of GPR56/ADGRG1 by its alternatively 
spliced extracellular domains. Salzman, Ackerman , … , Koide, Araç.  Neuron 
(2016)

Applications from a range of backgrounds including biochemistry, molecular 
biology, and cell biology are invited. Required skills include molecular 
cloning and protein biochemistry. Experience in protein 
expression/purification, structure determination, and GPCR signaling pathways 
are a plus.

Our laboratory is located at the University of Chicago, and is affiliated with 
the Department of Biochemistry and Molecular biology 
(http://bmb.uchospitals.edu/) and the Grossman Institute for Neuroscience, 
Quantitative Biology and Human Behavior 
(http://neuroscience.uchicago.edu/grossman-institute/). The researcher 
recruited through this project will have the opportunity to visit and 
collaborate with interdisciplinary scientists on campus 
(https://www.uchicago.edu/).

Highly motivated candidates with a strong track record of publications should 
send an
application package with research interests, full CV with experimental skills 
listed in detail, names and contact information of 3 references to:

Prof. Demet Araç
a...@uchicago.edu

The University of Chicago is an Affirmative Action/Equal 
Opportunity/Disabled/Veterans Employer. All qualified applicants will receive 
consideration for employment without regard to race, color, religion, sex, 
sexual orientation, gender identity, national origin, age, protected veteran 
status or status as an individual with disability.







Demet Araç, PhD
Assistant Professor
University of Chicago
Department of Biochemistry and Molecular Biology
phone: 1-773-8342691
web: arac.uchicago.edu
email: a...@uchicago.edu






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..

[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 
>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 

[ccp4bb] Postdoc Position - Berkeley

[Paul Adams]

Lawrence Berkeley Laboratory
Postdoctoral Researcher
Job ID: 85784
Division: Molecular Biophysics & Integrated Bioimaging (Joint BioEnergy 
Institute)
Date Opened: 11/1/2018

Summary:  A postdoctoral position is immediately available to study the 
structure and function of macromolecular complexes and enzymes using 
biochemical, X-ray crystallographic and electron cryo-microscopy (cryo-EM) 
methods. The biological systems to be studied are:
 
- Glycosyl transferases responsible for the synthesis of hemicelluloses in 
plants
- Novel glycosyl hydrolases that are able to breakdown cellulosic material for 
biofuels production
- Enzymes involved in lignin biosynthesis, degradation and valorization
- Secondary metabolite and natural product enzymes

This position will be part of the Structural Biology group of the Technology 
Division at the Joint BioEnergy Institute (JBEI) in Emeryville, California. To 
learn more about JBEI visit: http://www.jbei.org/

Duties: The successful candidate will have experience characterizing enzymes 
using biochemical techniques, and using crystallographic methods. Familiarity 
with cryo-EM methods would be helpful, but not essential. Robotic hardware for 
performing crystallization trials and imaging results are available. Crystals 
will be characterized and data collected using the beamline resources of the 
Berkeley Center for Structural Biology at the Advanced Light Source. For 
appropriate systems cryo-EM data will be obtained using in-house microscopes, 
the Bay Area Center for Cryo-EM, and other national user facilities.

Qualifications: a Ph.D. in biochemistry, molecular biology, structural biology, 
chemistry or a related field. Demonstrated experience of scientific research 
using biochemistry techniques including enzymatic assays, and crystallographic 
methods. Experience with macromolecular crystallization techniques. Experience 
with cloning methods and protein purification methods would be helpful. Strong 
problem solving skills. Solid interpersonal skills and the ability to work in a 
team environment are critical.

This is a full time, 2 years, postdoctoral appointment with the possibility of 
renewal based upon satisfactory job performance, continuing availability of 
funds and ongoing operational needs. You must have less than 3 years paid 
postdoctoral experience. Salary for Postdoctoral positions depends on years of 
experience post-degree.

Berkeley Lab (LBNL) addresses the world’s most urgent scientific challenges by 
advancing sustainable energy, protecting human health, creating new materials, 
and revealing the origin and fate of the universe. Founded in 1931, Berkeley 
Lab’s scientific expertise has been recognized with 13 Nobel prizes. The 
University of California manages Berkeley Lab for the U.S. Department of 
Energy’s Office of Science. Berkeley Lab is an Equal Opportunity/Affirmative 
Action Employer. All qualified applicants will receive consideration for 
employment without regard to race, color, religion, sex, sexual orientation, 
gender identity, national origin, disability, age, or protected veteran status. 

To apply visit https://lbl.taleo.net/careersection/2/jobsearch.ftl?lang=en and 
search for the job number 85784 or visit:


https://lbl.referrals.selectminds.com/jobs/crystallography-postdoctoral-scholar-1279


-- 
Paul Adams
Division Director, Molecular Biophysics & Integrated Bioimaging, Lawrence 
Berkeley Lab
Division Deputy for Biosciences, Advanced Light Source, Lawrence Berkeley Lab
Adjunct Professor, Department of Bioengineering, U.C. Berkeley
Vice President for Technology, the Joint BioEnergy Institute
Laboratory Research Manager, ENIGMA Science Focus Area

Building 33, Room 347
Building 978, Room 4126
Tel: 1-510-486-4225, Fax: 1-510-486-5909
http://cci.lbl.gov/paul

Lawrence Berkeley Laboratory
1 Cyclotron Road
BLDG 33R0345
Berkeley, CA 94720, USA.

Executive Assistant: Louise Benvenue [ lbenve...@lbl.gov ][ 1-510-495-2506 ]
--



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

[ccp4bb] Effect of ionic strength on temperature-dependence of solubility

[Bri Bibel]

Hi. I was wondering if anyone could explain or point me to a source that 
explains (I’ve been having trouble finding one) why proteins tend to be less 
soluble at higher temperatures at high salt but more soluble at higher 
temperatures at low salt?

https://hamptonresearch.com/documents/growth_101/8.pdf

Thank you in advance.

Bri



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..

[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 
*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

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: 

[ccp4bb] Fwd: [ccp4bb] VERY old mtz file..

[Carter, Charlie]

Begin forwarded message:

From: "charles w carter, jr" mailto:cwcar...@ad.unc.edu>>
Subject: Re: [ccp4bb] VERY old mtz file..
Date: November 14, 2018 at 10:16:23 AM EST
To: Eleanor Dodson mailto:eleanor.dod...@york.ac.uk>>

I’ve found this thread to be most interesting and out of near pathological 
curiosity, I’ve read much of it.

Eleanor’s cameo description in this message makes me curious to know how the 
transition from vax’s and this file in particular, managed to transcend the 
continuity ccp4 strives for. Were MRC files really a significant variant in the 
implementation of mtz binary format to replace labeled column format?

Many thanks, and best to all,

Charlie

On Nov 14, 2018, at 10:04 AM, Eleanor Dodson 
<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
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
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
> 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; 

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
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
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
> 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, 

[ccp4bb] Computational Scientist Position at the UK site of Vertex Pharmaceuticals

[Jay Bertrand]

I wanted to call attention to the following position for a Computational 
Scientist Position at the UK site of Vertex Pharmaceuticals. Also, please 
recognize that applications must go through the website below.
Kind regards,
Jay
-

Vertex Pharmaceuticals (Europe) Ltd has an immediate opening for a talented 
computational scientist in the Structural Biology and Biophysics group at our 
Research UK site in Oxfordshire. The position is for 18 m fixed-term contract 
and the major role of the person will be to develop and support the group’s 
computing environment for solving Cryo-EM structures. This includes supporting 
deployment of computational workflows and scientific data analysis on our 
high-performance computing environment and working with scientists to develop 
and optimize custom solutions for data analysis and processing.

The position requires a broad background in computational/data science or 
related discipline with at least three years experience working with large 
scientific data sets. The successful candidate will help drive the 
computational aspects of Cryo-EM data that are associated with going from 
protein to structure. Part of the role will include process optimization and 
dealing with emerging technologies.

Minimum Qualifications
Experience with large scale scientific data
Use of High performance computing
Strong familiarity with linux/bash or similar
High Performance computing
Python/C++/Java experience a plus
Excellent written and verbal communication skills

Interested persons should apply through the following link:

https://sjobs.brassring.com/TGnewUI/Search/home/HomeWithPreLoad?PageType=JobDetails=25119=5134=11066BR#jobDetails=2295290_5134



This email message and any attachments are confidential and intended for use by 
the addressee(s) only. If you are not the intended recipient, please notify me 
immediately by replying to this message, and destroy all copies of this message 
and any attachments. Thank you.



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

[ccp4bb] Post-doctoral opportunity in membrane protein structural biology

[Hasan, Syed Saif]

Center for Biomolecular Therapeutics (CBT), University of Maryland School of 
Medicine, Baltimore MD



The Hasan laboratory (https://www.ibbr.umd.edu/profiles/s-saif-hasan) 
is recruiting a post-doctoral fellow with an interest in utilizing 
high-resolution single particle cryo-electron microscopy (cryoEM) to 
investigate the structural biology of membrane proteins implicated in cancer 
and infectious diseases. The CBT houses a new 200 keV Thermo Fisher Talos 
Arctica microscope equipped with a Gatan K3 direct electron detector and a 
Volta phase plate. A 200 keV Thermo Fisher Glacios microscope equipped with a 
Falcon III direct electron detector will be acquired soon. A 120 keV FEI Tecnai 
T12 TEM equipped with a CCD camera is available for negative stain imaging.



Applicants should have experience in-

1. structural biology (preferably cryoEM)

2. molecular biology including handling of eukaryotic cell lines for protein 
production

3. membrane protein chemistry



The CBT is located in Rockville MD 
(http://www.medschool.umaryland.edu/cbt/). In addition to the latest cryoEM 
facilities at CBT, the fellow will have access to tools in NMR (950, 800, 600, 
500, 400 MHz), X-ray crystallography, small angle X-ray scattering, 
mass-spectrometry and computational biology. The CBT will provide the fellow 
with opportunities to work closely in collaboration with scientists in industry 
and in national labs located nearby (i.e. NIH, NIST).



Applicants who have received their PhD or MD/PhD degree should submit a 
single PDF file containing a short cover letter (no more than one page), a 
detailed curriculum vitae, contact information for three references, and up to 
5 reprints of representative first authorship publication(s) to S. Saif Hasan, 
PhD (ssha...@som.umaryland.edu; Assistant Professor, UMB) and David J. Weber, 
PhD (dwe...@som.umaryland.edu; Professor, UMB, and Director of CBT). Highly 
qualified applicants will be contacted soon after their application is received 
to investigate specific fellowship opportunities in the CBT.



The University of Maryland, Baltimore is an Equal Opportunity, 
Affirmative Action employer. Minorities, women, individuals with disabilities 
and protected veterans are encouraged to apply.



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]

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 
> 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
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
> 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.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
>>> >

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>
 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 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
>>> 

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 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, 

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 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 

[ccp4bb] Ivana Bertini Award: call for nominations open

[Claudia Alen Amaro]

Dear All

A biennial award has been set 
up in memory of Ivano Bertini, who pioneered innovative methodologies in the 
field of NMR and championed technology integration as a foundation for 
correlative structural biology. The award recognises scientists who have 
undertaken frontier research utilising an integrative structural biology 
approach which aligns with the Instruct vision.

Nominations are invited for the Ivano Bertini Award 2019 for a significant 
achievement in any area of the biological sciences. Nominations must be 
submitted by 5pm (CET) 28th December 2018. Self nominations are not accepted.

The award will be given solely on the basis of excellence in research and must 
include structural data as a key component of the research achievement. The 
award recognises a clearly defined breakthrough (either in scientific knowledge 
or technology development) and is not for a lifetime achievement.

Eligible nominees:

Individual researchers whose work is conducted within European Member states or 
Third countries in the last 5 
years (1st June 2013 to 31st May 2018).

Nominations:

A nomination must be supported by three Instruct members and must include:

1. A completed nomination form can be found on our Biennial 
webpage

2. CV of the proposed candidate

3. Statement (<150 words) from each of the three proposers indicating why the 
candidate should be considered for the award

Any Registered Instruct member (with an authorised login to the Instruct 
website is invited to submit 
nominations for this Award.

Selection of the Awardee:

A committee will be responsible for selecting the awardee from the nominees. 
Instruct Members of the Selection Committee will be nominated by the Instruct 
Executive Committee, comprising three members of the Instruct Executive 
Committee, two external scientists from the international Instruct review 
panel, and a member of the Instruct Independent Scientific Advisory Board. One 
additional Selection Committee member will be nominated by Industry

The award will be announced at the Instruct Biennial Structural Biology 
Conference 2019.

Awardees receive an unrestricted grant of €15000, a personalised certificate 
and will deliver a lecture at the Instruct Conference in Alcalá de Henares 2019.

Please note my new email address

Dr Claudia Alen Amaro
Scientific Project Manager
Instruct-ERIC
Oxford House
Parkway Court
John Smith Drive
Oxford
OX4 2JY, UK
Tel:+44 1865987629
email: clau...@instruct-eric.eu
Follow us on twitter @instructhub











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]

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, 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  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)
> 

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 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 

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 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