[ccp4bb] OFF TOPIC

[Anamika Singh]

Hi All,

I am purifying the biotinylated protein (cloned into the pET28a vector)
using Avidin beads. Since I need the protein for SPR but when I used the
purified protein to interact with Streptavidin coated onto the SPR chip.
There was no signal. Can anybody tell me why is it so or how can I make
sure that the purified protein is biotinylated enough to interact and give
the signal? Because when I ran the SDS-PAGE there was a band of purified
protein.

I have used the elution buffer (20mM Tris, 5mM Mgcl2, 500mM Nacl, and 2mM
Biotin).
PS: I have included the biotin during overexpression of the protein also.

Please suggest.

Thanks
-- 
Anamika
Post-Doctoral Fellow
Silberman Institute of Life Sciences
Hebrew University of Jerusalem, Israel



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

[ccp4bb] CCP4 Study Weekend Early Bird ending

[Charles Ballard - UKRI STFC]

Dear All

a heads up that the early bird registration, and closing date for student 
bursaries, is Sunday 18th November 2018 i.e. this Sunday!

For more info see http://www.cvent.com/d/sgq8q6/1K?cpc=N7N8SK89V8N

Regards

Karen McIntyre
Scientific Computing Department - CCP4



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

[ccp4bb] Call Postdoctoral Fellowship Program at the Helmholtz Zentrum München, Munich, Germany

[Ana Messias]

Call Postdoctoral Fellowship Program at the Helmholtz Zentrum München, Munich, 
Germany 
Deadline November 30 , 2018 

The PFP trains highly talented early-career scientists for leadership positions 
in health and environment research. 
It includes an individual career development plan, coaching and mentoring, 
support in grant applications, travel grants and joint training modules. 

Applicants for the PFPIV (2019-2021) can choose from a wide variety of subjects 
in health and environment research. 

In particular there are two proposals in structural biology in Michael 
Sattler's lab ( [ 
https://www.helmholtz-muenchen.de/stb/research/groups/research-group-sattler/research/index.html
 | 
https://www.helmholtz-muenchen.de/stb/research/groups/research-group-sattler/research/index.html
 ] ): 


* Integrative structural biology to study the structure and dynamics of 
long-non-coding RNAs 
* Dissecting the molecular mechanisms underlying the neurodegenerative 
disorder MPAN using structural biology 

Please check the webpage ( [ 
https://www.helmholtz-muenchen.de/fellows/index.html | 
https://www.helmholtz-muenchen.de/fellows/index.html ] ) and apply! 

[ https://www.helmholtz-muenchen.de/fellows/index.html ] 


 


Helmholtz Zentrum Muenchen

Deutsches Forschungszentrum fuer Gesundheit und Umwelt (GmbH)

Ingolstaedter Landstr. 1

85764 Neuherberg

www.helmholtz-muenchen.de

Aufsichtsratsvorsitzende: NN

Stellv.Aufsichtsratsvorsitzender: MinDirig. Dr. Manfred Wolter

Geschaeftsfuehrer: Prof. Dr. med. Dr. h.c. Matthias Tschoep, Heinrich Bassler, 
Dr. rer. nat. Alfons Enhsen

Registergericht: Amtsgericht Muenchen HRB 6466

USt-IdNr: DE 129521671




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

Re: [ccp4bb] OFF TOPIC

[Wim Burmeister]

  
  
Hello,
you probably purified a contaminant. Do a blot with an anti-biotin
antibody or get electro-spray mass spectrometry done in order to
confirm the identity of your protein.
Wim

On 13/11/2018 11:13, Anamika Singh
  wrote:


  
Hi All,

I am purifying the biotinylated protein (cloned into the pET28a vector) using Avidin beads. Since I need the protein for SPR but when I used the purified protein to interact with Streptavidin coated onto the SPR chip. There was no signal. Can anybody tell me why is it so or how can I make sure that the purified protein is biotinylated enough to interact and give the signal? Because when I ran the SDS-PAGE there was a band of purified protein. 


I have used the elution buffer (20mM Tris, 5mM Mgcl2, 500mM Nacl, and 2mM Biotin). 
PS: I have included the biotin during overexpression of the protein also. 
Please suggest. 
Thanks 
-- 


  

  

  Anamika 
Post-Doctoral Fellow
  Silberman Institute of Life Sciences 
  Hebrew University of Jerusalem, Israel
  
  

  

  

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


-- 
  
  
  


  Wim Burmeister
Professeur
  Institut de Biologie Structurale (IBS) CIBB
  71 avenue des Martyrs
  CS
  20192
  38044 Grenoble Cedex 9, FRANCE
  E-mail: wim.burmeis...@ibs.fr
Tel:    +33 (0) 457 42 87 41   Fax: +33 (0) 476 20
94 00
  website
  map
  
  
  

  

  



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

Re: [ccp4bb] OFF TOPIC

[Jonathan Elegheert]

Hi Anamika,

- Have you double-checked that the sequence of your cDNA is correct and 
includes the biotin acceptor peptide tag (BAP tag aka AviTag; GLNDIFEAQKIEWHE 
in single-letter amino acid code)?
- Are you using a dedicated bacterial strain that over-expresses BirA enzyme? 
This may not be strictly necessary because we often find that native E. coli 
BirA levels are sufficient to incorporate biotin, albeit with low efficiency.
- You could simply do a Western blot to confirm biotin incorporation. I like 
the high-sensitivity streptavidin-HRP conjugate from Pierce (cat. no. 21130).

Best wishes,
Jonathan

-
Jonathan Elegheert, PhD
Team Leader

Interdisciplinary Institute for NeuroScience (IINS) 
UMR5297 CNRS / UB
University of Bordeaux 
Centre Broca Nouvelle-Aquitaine
146 rue Léo Saignat
33076 Bordeaux Cedex
France

E-mail: jonathan.eleghe...@u-bordeaux.fr 

-






> On 13 Nov 2018, at 10:13, Anamika Singh  wrote:
> 
> Hi All,
> 
> I am purifying the biotinylated protein (cloned into the pET28a vector) using 
> Avidin beads. Since I need the protein for SPR but when I used the purified 
> protein to interact with Streptavidin coated onto the SPR chip. There was no 
> signal. Can anybody tell me why is it so or how can I make sure that the 
> purified protein is biotinylated enough to interact and give the signal? 
> Because when I ran the SDS-PAGE there was a band of purified protein. 
> 
> I have used the elution buffer (20mM Tris, 5mM Mgcl2, 500mM Nacl, and 2mM 
> Biotin). 
> PS: I have included the biotin during overexpression of the protein also. 
> 
> Please suggest. 
> 
> Thanks 
> -- 
> Anamika 
> Post-Doctoral Fellow
> Silberman Institute of Life Sciences 
> Hebrew University of Jerusalem, Israel
> 
> 
> 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] OFF TOPIC

[Thomas Edwards]

You don’t say so, but one assumes that you have a BAP tag on the protein, and 
co-express a biotin ligase such as BirA?


Ed

T.A.Edwards Ph.D.
Associate Professor of Biochemistry
Deputy Head of School
_
Astbury Centre for Structural Molecular Biology
School of Molecular and Cellular Biology
Faculty of Biological Sciences
===
Garstang 8.53d
University of Leeds, Leeds, LS2 9JT 
Telephone: 0113 343 3031
Faculty Staff 
Profile
Astbury Centre Web 
Page

Invention, my dear friends, is 93% perspiration, 6% electricity, 4% 
evaporation, and 2% butterscotch ripple. ~Willy Wonka
[signature_1229172001]
Perturbation of Protein-Protein Interactions


From: CCP4 bulletin board  on behalf of Anamika Singh 

Reply-To: Anamika Singh 
Date: Tuesday, 13 November 2018 at 10:15
To: "CCP4BB@JISCMAIL.AC.UK" 
Subject: [ccp4bb] OFF TOPIC

Hi All,

I am purifying the biotinylated protein (cloned into the pET28a vector) using 
Avidin beads. Since I need the protein for SPR but when I used the purified 
protein to interact with Streptavidin coated onto the SPR chip. There was no 
signal. Can anybody tell me why is it so or how can I make sure that the 
purified protein is biotinylated enough to interact and give the signal? 
Because when I ran the SDS-PAGE there was a band of purified protein.

I have used the elution buffer (20mM Tris, 5mM Mgcl2, 500mM Nacl, and 2mM 
Biotin).
PS: I have included the biotin during overexpression of the protein also.

Please suggest.

Thanks
--
Anamika
Post-Doctoral Fellow
Silberman Institute of Life Sciences
Hebrew University of Jerusalem, Israel




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] OFF TOPIC

[PULSARSTRIAN]

Hi Anamika,
 As far as I understood, the biotin in the elution
buffer is helping your protein to get stripped off from the Avidin column.
So, maybe you dialyze your purified protein (or run FPLC) and get rid of
biotin completely, before you load the protein on to strptavidin coated SPR
chip.
Hope this helps!!

Best,
Bhanu

On Tue, Nov 13, 2018 at 12:14 PM Anamika Singh 
wrote:

> Hi All,
>
> I am purifying the biotinylated protein (cloned into the pET28a vector)
> using Avidin beads. Since I need the protein for SPR but when I used the
> purified protein to interact with Streptavidin coated onto the SPR chip.
> There was no signal. Can anybody tell me why is it so or how can I make
> sure that the purified protein is biotinylated enough to interact and give
> the signal? Because when I ran the SDS-PAGE there was a band of purified
> protein.
>
> I have used the elution buffer (20mM Tris, 5mM Mgcl2, 500mM Nacl, and 2mM
> Biotin).
> PS: I have included the biotin during overexpression of the protein also.
>
> Please suggest.
>
> Thanks
> --
> Anamika
> Post-Doctoral Fellow
> Silberman Institute of Life Sciences
> Hebrew University of Jerusalem, Israel
>
>
> --
>
> To unsubscribe from the CCP4BB list, click the following link:
> https://www.jiscmail.ac.uk/cgi-bin/webadmin?SUBED1=CCP4BB=1
>


-- 
B4U



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,


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 
>> test hypotheses.
>>
>> Zhijie
>>
>>> On Nov 9, 2018, at 9:04 PM, James Holton 
>>> 

[ccp4bb] Postdoctoral position in ion channel mechanism with cryo-EM available in the laboratory of Crina Nimigean at Weill Cornell Medical College in New York City

[Crina Nimigean]

Postdoctoral position in ion channel mechanism with cryo-EM available in the 
laboratory of Crina Nimigean at Weill Cornell Medical College in New York City
There is an availability in the laboratory of Crina Nimigean for an 
enthusiastic postdoc who is interested in the molecular workings of ion 
channels. The successful candidate will investigate ion channel structure and 
mechanism with single-particle cryo-EM and functional assays such as 
single-channel recordings, stopped-flow fluorescence, etc. The work in the lab 
is generally geared towards developing a mechanistic understanding of ion 
channels using functional and structural techniques (see two recent articles 
below).
We are located at the Weill Cornell Medical College on the upper east side of 
Manhattan, within the vibrant and international tri-Institutional scientific 
community, which is comprised of Rockefeller University, Memorial Sloan 
Kettering and Weill Cornell. We have screening electron microscopes on site, 
within the newly established cryo-EM core facility at Cornell, and we have full 
access to state-of-the-art Titan Krios microscopes for high resolution data 
collection at the New York Structural Biology Center and other cost-based 
facilities.
Qualifications and experience: Candidates should hold a Ph.D. and have a solid 
background in biophysics, ion channel electrophysiology, and/or protein 
biochemistry.  Experience with cryo-EM is not required but welcome. Excellent 
verbal and written English communication skills, and ability to work in close 
collaboration with other researchers are required.
Qualified applicants should send a cover letter, CV, and the names of three 
references by email to Crina Nimigean at 
crn2...@med.cornell.edu.

Rheinberger J., Gao X., Schmidpeter P.A.M., Nimigean C.M. (2018) Ligand 
discrimination and gating in CNG channels from apo and partial agonist-bound 
cryo-EM structures, eLife doi: 10.7554/eLife.39775

Marchesi A., Gao X., Adaixo R.., Rheinberger J., Stahlberg H., Nimigean C.M., 
Scheuring S. (2018) An iris diaphragm mechanism to gate a cyclic 
nucleotide-gated ion channel, Nature communications, doi: 
10.1038/s41467-018-06414-8

-
Crina Nimigean, Ph.D.
Weill Cornell Medical College
Associate Professor of Physiology and Biophysics in Anesthesiology
Associate Professor of Biochemistry
http://physiology.med.cornell.edu/faculty/nimigean/lab/

Department of Anesthesiology, Box 124
525 East 68th Street, Room A-1050
New York, NY 10065
Phone: (212) 746 5947
Fax: (212) 746 4879




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]

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

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

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

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

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

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

[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] Asn/Gln - pi-stacking prevalence

[Daniel Anderson]

While working on PDB entries 1F0N and 1F0P, I aligned the side-chain 
dipoles of 4 asparagines with the side-chain dipoles of tryptophans 
(ring nitrogen is slightly negative, the rest of the 5-membered ring is 
slightly positive). Aligning dipoles simultaneously optimized hydrogen 
bonding for the 4 asparagines. So that could be a simultaneous pi-stack 
and dipole interaction (and hydrogen bonds).


me, et al J. Molecular Biology (2001) 307, 671-681.




On 11/10/18 1:45 AM, Michael Jarva wrote:


Dear ccp4 community,


I have recently been working with a structure that has an Asparagine 
that makes a planar stacking connection with a Tryptophan ring 
(pep_ASN-TRP_v2.png), that seem to be a true pi-stacking interaction 
and I'd like to find more examples of this.



I've found a few other examples in the literature but they are 
mostly amide hydrogen-pi interactions (4PTI_ASN-TYR_v2.png and 
1N4W_ASN-FAD_v2.png), which can be seen by the way the Asn is dipping 
down into the pi-cloud. One potential exception is of a DNA-binding 
protein where the orientation is more planar (3HXQ_GLN-DNA_v2.png).



So, I'm looking for examples of Asparagine or Glutamine pi-stacking 
and am sure there are more of them out there and would greatly 
appreciate any examples.



best regards

Michael


Michael Jarva, PhD
ACRF Chemical Biology Division

The Walter and Eliza Hall Institute of Medical Research
1G Royal Parade
Parkville Victoria 3052
Australia

Phone: +61 3 9345 2493 
Email: jarv...@wehi.edu.au | Web: http://www.wehi.edu.au/

The ACRF Chemical Biology Division is supported by the

Australian Cancer Research Foundation


___

The information in this email is confidential and intended solely for 
the addressee.
You must not disclose, forward, print or use it without the permission 
of the sender.


The Walter and Eliza Hall Institute acknowledges the Wurundjeri people 
of the Kulin
Nation as the traditional owners of the land where our campuses are 
located and

the continuing connection to country and community.
___




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