[ccp4bb] Research Technician position

[Radhika Subramanian]

Dear structural biology community,

I am currently recruiting for a Research Technician position in my new lab. I 
would be most grateful if you could bring this to the attention of anyone who 
you think may be interested.

Best,

Radhika


RESEARCH TECHNOLOGIST POSITION

A Research Technologist position is available in the lab of Radhika Subramanian 
in the Department of Molecular Biology at the Massachusetts General Hospital in 
Boston. The lab focuses on examining the molecular mechanisms underlying 
microtubule organization. We use a variety of experimental tools to investigate 
this problem, including X-ray crystallography, single molecule biophysics, and 
cell biological methods (see references: Subramanian et. al, Cell 2013, 
154(2):377-90; Subramanian et. al, Cell 2010, 142(3):433-43).  

We are seeking a highly motivated candidate to assist with a new project 
investigating microtubule organization during cell division. The candidate must 
have a B.S. in biological sciences or related field (M.S. or higher is 
preferred) and at least 3 years of research experience. The candidate must have 
knowledge of general biochemistry and molecular biology techniques. Prior 
experience with protein expression in insect cells, X-ray crystallography or 
microscopy would be an added benefit.

Salary will be commensurate with experience and accomplishments. 

Please follow the link below and search the keyword: Subramanian to apply for 
the position:

https://careers.partners.org/psc/EA/EMPLOYEE/HRMS/c/HRS_HRAM.HRS_CE.GBL?Page=HRS_CE_HM_PRE&Action=A&SiteId=2&;

Massachusetts General Hospital is an Equal Opportunity Employer.  By embracing 
diverse skills, perspectives and ideas, we choose to lead. Applications from 
protected veterans and individuals with disabilities are strongly encouraged

---
Radhika Subramanian

Assistant Professor
Department of Molecular Biology, Massachusetts General Hospital
Department of Genetics, Harvard Medical School
radh...@molbio.mgh.harvard.edu

Re: [ccp4bb] Space group numbers

[Eleanor Dodson]

By default I believe for most crystallographic applications, the hierarchy
is:the symmetry operators, but if absent the SG name (and this can be P21
21 2 or P 21 2 21 or whatever) , but that is absent and you are lazy you
can give the SG number.. And that can deal to confusion  and should be used
with care, as you all have pointed out..

MX crystallograohers have never been keen on the rigid application of cell
dimension rule a wrote:

>
>
> (a) The IUCr has, in its wisdom, decided to use the *Hall space group
>> symbols* to settle the matter. See International Tables for
>> Crystallography, Vol. B (2001), Chapter 1.4, Appendix 1.4.2 and *Acta
>> Cryst.* (1981). A*37*, 517-525. These are obligatory input for CheckCIF
>> as part of small molecule verification.  'P 21 21 21' becomes 'P 2ac 2ab'
>> and 'P 21 2 21' becomes equally logically  'P 2ac 2ac'. Fortunately for the
>> users, SHELXL-2014 derives the Hall symbols from the symmetry operators.
>>
>
> I agree that would make a lot more sense but it's taken many years to get
> to where we are now so I can't see this happening any time soon!
>
>>
>> (b) Isn't it time to introduce the 'R 3' or 'H 3' or 'R 3 :H' issue again?
>>
>
> Yes by all means: the H cell in ITC (triple cell) means something
> completely different from the PDB idea of H cell, so it's the PDB we have
> to tackle.  But again, realistically is it going to happen?
>
>>
>> (c) As pointed out already, small molecule crystallographers never have
>> this problem because the coordinates of the general position are used to
>> define the space group symmetry unambiguously, in conventional settings or
>> otherwise. Ian's argument that there could be too much to type in for cubic
>> space groups is irrelevant, because the list is always generated by a
>> program (e.g. XPREP or its clones).
>>
>
> I assume that the Hall symbol unambiguously defines the list of g.e.p.s
> (if it doesn't then what use is it?).  Assuming that it does then why not
> use it in place of the list and look up the g.e.p.s from a file (e.g.
> syminfo.lib)?  As I said before, comparing lists of g.e.p.s seems to be
> overkill and prone to errors (and in fact I think there have been bugs in
> the CCP4 implementation).  Simple comparison of the Hall symbols would
> appear to be a lot less error-prone!
>
> Cheers
>
> -- Ian
>
>>
>> George
>>
>>
>>
>>
>> On 10/03/2014 05:13 PM, Ian Tickle wrote:
>>
>>
>>  Hi Kay
>>
>> On 2 October 2014 15:04, Kay Diederichs 
>> wrote:
>>
>>>
>>> Once again, citing from ITC Vol A Table 9.3.2 (p. 747 in my 1995
>>> edition) , these "conventions refer to the cell obtained by the
>>> transformations from Table 9.3.1. They have been chosen for convenience in
>>> this table". To me, this indicates that a>> were to transform. But the question is: why would one want to transform? I
>>> don't see "sticking to the original indexing" as a convincing convenience.
>>>
>>
>>  I'm sorry, unfortunately my edition of ITC-A (5th Ed., 2002) is later
>> than yours (4th Ed.) and I have been unable to get hold of a copy of the
>> edition that you refer to.  In my edition the table equivalent to your
>> 9.3.2 seems to be 9.3.4.1 on p.758 and there doesn't seem to be a table
>> equivalent to your 9.3.1 (the only other table in that section is 9.3.5.1
>> but that doesn't seem to be relevant).  Also I am unable to match up the
>> text that you quote with what I see in my edition: it seems to be
>> completely different.  So it's very difficult to comment.  According to the
>> Foreword "The present 5th Edition is much more extensively revised than any
>> of its predecessors ..." so I can only assume that the text that you quote
>> was considered unclear and was removed.  But I agree that if one is
>> concerned with a specific structure without reference to any other
>> structure, why would one want to transform anything?  It makes no sense.
>> The conventional setting is selected according to table 9.3.4.1, end of
>> story.
>>
>>>
>>> My copy of ITC Vol A says (p 41) about Table 3.2: "the 'standard' space
>>> group symbols ... are printed in bold face". The Table has "P 21 21 2" (18)
>>> and "P 2 2 21" (17) in bold face. There is no ambiguity here.
>>>
>>
>>  Again I'm sorry but I don't see that text in my edition (p.41 is just a
>> list of references for Chap. 2) and I can't find the corresponding section
>> in my Edition.  However I do agree that the standard symbol for each space
>> group is printed in bold face in the top-left corner of each double-spread
>> page dealing with that space group (also in smaller type in the top-right
>> corner).  Perfectly true observation I agree but how is it relevant?  The
>> 230 standard symbols are the names of the 230 equivalence classes defined
>> on the complete set of possible alternate settings for the equivalence
>> relations consisting of the possible rotations and/or translations relating
>> those alternate settings.  Since they only serve as labels one could
>> equally well have ch

Re: [ccp4bb] Space group numbers

[Ian Tickle]

(a) The IUCr has, in its wisdom, decided to use the *Hall space group
> symbols* to settle the matter. See International Tables for
> Crystallography, Vol. B (2001), Chapter 1.4, Appendix 1.4.2 and *Acta
> Cryst.* (1981). A*37*, 517-525. These are obligatory input for CheckCIF
> as part of small molecule verification.  'P 21 21 21' becomes 'P 2ac 2ab'
> and 'P 21 2 21' becomes equally logically  'P 2ac 2ac'. Fortunately for the
> users, SHELXL-2014 derives the Hall symbols from the symmetry operators.
>

I agree that would make a lot more sense but it's taken many years to get
to where we are now so I can't see this happening any time soon!

>
> (b) Isn't it time to introduce the 'R 3' or 'H 3' or 'R 3 :H' issue again?
>

Yes by all means: the H cell in ITC (triple cell) means something
completely different from the PDB idea of H cell, so it's the PDB we have
to tackle.  But again, realistically is it going to happen?

>
> (c) As pointed out already, small molecule crystallographers never have
> this problem because the coordinates of the general position are used to
> define the space group symmetry unambiguously, in conventional settings or
> otherwise. Ian's argument that there could be too much to type in for cubic
> space groups is irrelevant, because the list is always generated by a
> program (e.g. XPREP or its clones).
>

I assume that the Hall symbol unambiguously defines the list of g.e.p.s (if
it doesn't then what use is it?).  Assuming that it does then why not use
it in place of the list and look up the g.e.p.s from a file (e.g.
syminfo.lib)?  As I said before, comparing lists of g.e.p.s seems to be
overkill and prone to errors (and in fact I think there have been bugs in
the CCP4 implementation).  Simple comparison of the Hall symbols would
appear to be a lot less error-prone!

Cheers

-- Ian

>
> George
>
>
>
>
> On 10/03/2014 05:13 PM, Ian Tickle wrote:
>
>
>  Hi Kay
>
> On 2 October 2014 15:04, Kay Diederichs 
> wrote:
>
>>
>> Once again, citing from ITC Vol A Table 9.3.2 (p. 747 in my 1995 edition)
>> , these "conventions refer to the cell obtained by the transformations from
>> Table 9.3.1. They have been chosen for convenience in this table". To me,
>> this indicates that a> But the question is: why would one want to transform? I don't see "sticking
>> to the original indexing" as a convincing convenience.
>>
>
>  I'm sorry, unfortunately my edition of ITC-A (5th Ed., 2002) is later
> than yours (4th Ed.) and I have been unable to get hold of a copy of the
> edition that you refer to.  In my edition the table equivalent to your
> 9.3.2 seems to be 9.3.4.1 on p.758 and there doesn't seem to be a table
> equivalent to your 9.3.1 (the only other table in that section is 9.3.5.1
> but that doesn't seem to be relevant).  Also I am unable to match up the
> text that you quote with what I see in my edition: it seems to be
> completely different.  So it's very difficult to comment.  According to the
> Foreword "The present 5th Edition is much more extensively revised than any
> of its predecessors ..." so I can only assume that the text that you quote
> was considered unclear and was removed.  But I agree that if one is
> concerned with a specific structure without reference to any other
> structure, why would one want to transform anything?  It makes no sense.
> The conventional setting is selected according to table 9.3.4.1, end of
> story.
>
>>
>> My copy of ITC Vol A says (p 41) about Table 3.2: "the 'standard' space
>> group symbols ... are printed in bold face". The Table has "P 21 21 2" (18)
>> and "P 2 2 21" (17) in bold face. There is no ambiguity here.
>>
>
>  Again I'm sorry but I don't see that text in my edition (p.41 is just a
> list of references for Chap. 2) and I can't find the corresponding section
> in my Edition.  However I do agree that the standard symbol for each space
> group is printed in bold face in the top-left corner of each double-spread
> page dealing with that space group (also in smaller type in the top-right
> corner).  Perfectly true observation I agree but how is it relevant?  The
> 230 standard symbols are the names of the 230 equivalence classes defined
> on the complete set of possible alternate settings for the equivalence
> relations consisting of the possible rotations and/or translations relating
> those alternate settings.  Since they only serve as labels one could
> equally well have chosen the ordinals 1 through 230 (which are actually
> given equal prominence to the names).
>
> The important point is that the standard symbol is only the _name_ of the
> equivalence class and that this is not sufficient for dealing with crystal
> structures and calculating structure factors etc.: one must specify which
> element of that class, i.e. from the subset of possible unique _settings_
> that are members of that class, to use.  For example in the 5th Ed. the 10
> possible settings for standard symbol C2 are shown, with the full H-M
> symbols C121, A121, I121,

Re: [ccp4bb] Space group numbers

[George Sheldrick]

Since this discussion doesn't want to end. I should point out

(a) The IUCr has, in its wisdom, decided to use the */Hall space group 
symbols/* to settle the matter. See International Tables for 
Crystallography, Vol. B (2001), Chapter 1.4, Appendix 1.4.2//and /Acta 
Cryst./ (1981). A*37*, 517-525. These are obligatory input for CheckCIF 
as part of small molecule verification.  'P 21 21 21' becomes 'P 2ac 
2ab' and 'P 21 2 21' becomes equally logically  'P 2ac 2ac'. Fortunately 
for the users, SHELXL-2014 derives the Hall symbols from the symmetry 
operators.


(b) Isn't it time to introduce the 'R 3' or 'H 3' or 'R 3 :H' issue again?

(c) As pointed out already, small molecule crystallographers never have 
this problem because the coordinates of the general position are used to 
define the space group symmetry unambiguously, in conventional settings 
or otherwise. Ian's argument that there could be too much to type in for 
cubic space groups is irrelevant, because the list is always generated 
by a program (e.g. XPREP or its clones).


George



On 10/03/2014 05:13 PM, Ian Tickle wrote:


Hi Kay

On 2 October 2014 15:04, Kay Diederichs 
> wrote:



Once again, citing from ITC Vol A Table 9.3.2 (p. 747 in my 1995
edition) , these "conventions refer to the cell obtained by the
transformations from Table 9.3.1. They have been chosen for
convenience in this table". To me, this indicates that aI'm sorry, unfortunately my edition of ITC-A (5th Ed., 2002) is later 
than yours (4th Ed.) and I have been unable to get hold of a copy of 
the edition that you refer to.  In my edition the table equivalent to 
your 9.3.2 seems to be 9.3.4.1 on p.758 and there doesn't seem to be a 
table equivalent to your 9.3.1 (the only other table in that section 
is 9.3.5.1 but that doesn't seem to be relevant).  Also I am unable to 
match up the text that you quote with what I see in my edition: it 
seems to be completely different.  So it's very difficult to comment.  
According to the Foreword "The present 5th Edition is much more 
extensively revised than any of its predecessors ..." so I can only 
assume that the text that you quote was considered unclear and was 
removed.  But I agree that if one is concerned with a specific 
structure without reference to any other structure, why would one want 
to transform anything?  It makes no sense.  The conventional setting 
is selected according to table 9.3.4.1, end of story.



My copy of ITC Vol A says (p 41) about Table 3.2: "the 'standard'
space group symbols ... are printed in bold face". The Table has
"P 21 21 2" (18) and "P 2 2 21" (17) in bold face. There is no
ambiguity here.


Again I'm sorry but I don't see that text in my edition (p.41 is just 
a list of references for Chap. 2) and I can't find the corresponding 
section in my Edition.  However I do agree that the standard symbol 
for each space group is printed in bold face in the top-left corner of 
each double-spread page dealing with that space group (also in smaller 
type in the top-right corner).  Perfectly true observation I agree but 
how is it relevant?  The 230 standard symbols are the names of the 230 
equivalence classes defined on the complete set of possible alternate 
settings for the equivalence relations consisting of the possible 
rotations and/or translations relating those alternate settings.  
Since they only serve as labels one could equally well have chosen the 
ordinals 1 through 230 (which are actually given equal prominence to 
the names).


The important point is that the standard symbol is only the _name_ of 
the equivalence class and that this is not sufficient for dealing with 
crystal structures and calculating structure factors etc.: one must 
specify which element of that class, i.e. from the subset of possible 
unique _settings_ that are members of that class, to use.  For example 
in the 5th Ed. the 10 possible settings for standard symbol C2 are 
shown, with the full H-M symbols C121, A121, I121, A112, B112 etc.  So 
e.g. A121 is one of the allowed conventional settings in the 
equivalence class C2.  Notice that the standard symbol C2 is _not_ a 
full H-M symbol: it doesn't need to be, since it's only a name and it 
doesn't need to carry any information.  Its only requirement is that 
it's unique among the 230 equivalence classes.  Similarly the page for 
standard symbol P2221 shows the possible settings (at least in my Ed.) 
P2221, P2212 and P2122.  In this case the standard symbol happens to 
be the same as one of the full H-M symbols of the alternate settings 
but that's not a requirement, any unique name would have done equally 
well.  Also in the setting P2221 there obviously remains an ambiguity 
concerning the assignment of the a and b axes.  How is that resolved?  
You will probably say aanywhere, it just says "awhen it's a

Have you considered the fact that not all possible alternate settings 
are listed f

Re: [ccp4bb] Space group numbers

[Ian Tickle]

Hi Kay

On 2 October 2014 15:04, Kay Diederichs 
wrote:

>
> Once again, citing from ITC Vol A Table 9.3.2 (p. 747 in my 1995 edition)
> , these "conventions refer to the cell obtained by the transformations from
> Table 9.3.1. They have been chosen for convenience in this table". To me,
> this indicates that a But the question is: why would one want to transform? I don't see "sticking
> to the original indexing" as a convincing convenience.
>

I'm sorry, unfortunately my edition of ITC-A (5th Ed., 2002) is later than
yours (4th Ed.) and I have been unable to get hold of a copy of the edition
that you refer to.  In my edition the table equivalent to your 9.3.2 seems
to be 9.3.4.1 on p.758 and there doesn't seem to be a table equivalent to
your 9.3.1 (the only other table in that section is 9.3.5.1 but that
doesn't seem to be relevant).  Also I am unable to match up the text that
you quote with what I see in my edition: it seems to be completely
different.  So it's very difficult to comment.  According to the Foreword
"The present 5th Edition is much more extensively revised than any of its
predecessors ..." so I can only assume that the text that you quote was
considered unclear and was removed.  But I agree that if one is concerned
with a specific structure without reference to any other structure, why
would one want to transform anything?  It makes no sense.  The conventional
setting is selected according to table 9.3.4.1, end of story.

>
> My copy of ITC Vol A says (p 41) about Table 3.2: "the 'standard' space
> group symbols ... are printed in bold face". The Table has "P 21 21 2" (18)
> and "P 2 2 21" (17) in bold face. There is no ambiguity here.
>

Again I'm sorry but I don't see that text in my edition (p.41 is just a
list of references for Chap. 2) and I can't find the corresponding section
in my Edition.  However I do agree that the standard symbol for each space
group is printed in bold face in the top-left corner of each double-spread
page dealing with that space group (also in smaller type in the top-right
corner).  Perfectly true observation I agree but how is it relevant?  The
230 standard symbols are the names of the 230 equivalence classes defined
on the complete set of possible alternate settings for the equivalence
relations consisting of the possible rotations and/or translations relating
those alternate settings.  Since they only serve as labels one could
equally well have chosen the ordinals 1 through 230 (which are actually
given equal prominence to the names).

The important point is that the standard symbol is only the _name_ of the
equivalence class and that this is not sufficient for dealing with crystal
structures and calculating structure factors etc.: one must specify which
element of that class, i.e. from the subset of possible unique _settings_
that are members of that class, to use.  For example in the 5th Ed. the 10
possible settings for standard symbol C2 are shown, with the full H-M
symbols C121, A121, I121, A112, B112 etc.  So e.g. A121 is one of the
allowed conventional settings in the equivalence class C2.  Notice that the
standard symbol C2 is _not_ a full H-M symbol: it doesn't need to be, since
it's only a name and it doesn't need to carry any information.  Its only
requirement is that it's unique among the 230 equivalence classes.
Similarly the page for standard symbol P2221 shows the possible settings
(at least in my Ed.) P2221, P2212 and P2122.  In this case the standard
symbol happens to be the same as one of the full H-M symbols of the
alternate settings but that's not a requirement, any unique name would have
done equally well.  Also in the setting P2221 there obviously remains an
ambiguity concerning the assignment of the a and b axes.  How is that
resolved?  You will probably say a
> Switching the default in POINTLESS from "SETTING CELL-BASED" to "SETTING
> SYMMETRY-BASED" would make me happy, but more importantly, would avoid a
> lot of problems.
>

Maybe the answer is to fix the problem with pointless that you highlighted
originally, i.e. it's apparently reporting the wrong space group in the log
file!  Actually extracting stuff from log files is a very bad idea: log
files are not guaranteed to remain the same across different versions of
the program!  I learnt that the hard way!  Doesn't pointless output an XML
file, or you could just read the MTZ file header.  That's what I do, it's
much safer.

Cheers

-- Ian

Re: [ccp4bb] Space group numbers

[Phil Evans]

If you know the indexing that you want, from a user's point of view it is much 
easier to specify e.g. "I want to choose spacegroup P6522" (with or without 
spaces), rather than Oh what's the number, I'll have to go and look it up.

Phil

On 2 Oct 2014, at 21:12, Kay Diederichs  wrote:

> On Thu, 2 Oct 2014 16:00:30 +0100, Ian Tickle  wrote:
> 
>> On 2 October 2014 13:51, Kay Diederichs 
>> wrote:
>> 
>>> 
>>> I don't see any "sticking to initial indexing" as worthwhile to worry
>>> about, since in the first integration, P1 is often used anyway, and it is
>>> quite normal (and easy) to re-index after the intensities become available,
>>> during scaling. Re-indexing from P1 to the true spacegroup often changes
>>> the cell parameters and their order, and this is sufficiently easy and
>>> well-documented in the output.
>>> 
>> 
> 
> Ian,
> 
> I'm not aware that I tried to impose re-indexing on anyone, which your 
> reaction seems to imply. Quite to the contrary: re-indexing needs to be under 
> the control of the user - and the user specifies cell parameters and space 
> group number in XDS.INP. If I understand correctly, your "use case" is not 
> the typical one encountered by novice crystallographers, and I'm quite sure 
> you know very well how to deal with it. 
> My whole point is about the default SETTING in POINTLESS which may lead to 
> problems for XDS users, for space groups 17 and 18. To fix it, there is no 
> need to re-invent the wheel, write new volumes of ITC, specify all space 
> group operators, or specify space group symbols instead of numbers.
> 
> best,
> 
> Kay
> 

Re: [ccp4bb] New! Interactive structure factor tutorial...

[Kevin Cowtan]

The new version of the structure factor tutorial is now the default. You
can use it here:
  http://www.ysbl.york.ac.uk/~cowtan/sfapplet/sfintro.html

As a bonus I've now added a new symmetry exercise on cell centering. Also
four keyboard shortcuts (s,c,m,r) which can be used for the four buttons in
the control panel.

Kevin

p.s. If you for some reason really have to access the old one, it is still
available here: http://www.ysbl.york.ac.uk/~cowtan/sfapplet-old/sfintro.html



On 29 September 2014 10:15, Kevin Cowtan  wrote:

> I don't *think* they did that in the old version. (I can't run it any
> more to check though!)
>
> On 27 September 2014 13:35, Frank von Delft 
> wrote:
>
>>  HI Kevin - awesome!!!
>>
>> On the four-pane view, aren't the F & phi numbers in top left panel meant
>> to update when you move around the on the bottom left?  It wasn't doing for
>> me (latest-ish firefox).
>>
>> Frank
>>
>>
>>
>>
>> On 26/09/2014 08:50, Kevin Cowtan wrote:
>>
>>  Hi folks!
>>
>> Nearly two decades ago I wrote the interactive structure factor tutorial,
>> to help people understand diffraction beyond the simple explanation of
>> Bragg's law. As such it has been one of the longest lived interactive
>> teaching tools on the web.
>>
>>  However time and technology have caught up with it, and it is
>> increasingly difficult to run, requiring plugins, security exceptions, and
>> even obsolete browsers.
>>
>>  So new I've completely rewritten it using modern web technologies. Try
>> it here:
>>   http://www.ysbl.york.ac.uk/~cowtan/sfapplet2/sfintro.html
>>
>>  It should work on any version of Firefox or Chrome since about the mid
>> Permian, and I expect Safari and Opera as well. It's even useable on
>> tablets (although a big screen helps). Internet Explorer will probably work
>> since version 9. Show me a userbase and willingness to help with testing
>> and I might be able to get it running on IE 7 or 8.
>>
>>  Problem reports very welcome. Once it's stable this version will
>> replace the existing version.
>>
>>  Kevin
>>
>> --
>> EMAIL DISCLAIMER: http://www.york.ac.uk/docs/disclaimer/email.htm
>>
>>
>>
>
>
> --
> EMAIL DISCLAIMER: http://www.york.ac.uk/docs/disclaimer/email.htm
>



-- 
EMAIL DISCLAIMER: http://www.york.ac.uk/docs/disclaimer/email.htm

Re: [ccp4bb] Aimless low resolution shell

[Phil Evans]

This is not a bug. The Aimless program itself will cut the low resolution limit 
to 30Å but then the uniqueify step generates all reflections out to the maximum 
resolution, in order to make FreeR flags for them all. Since the extra 
reflections have no data, they will not contribute to any further steps in 
solution or refinement. Don't worry!

Phil

On 3 Oct 2014, at 01:15, Alisa Glukhova  wrote:

> Dear ccp4bb,
> 
> I am having an issue with low resolution shell when converting unmerged data 
> from Scalepack using Aimless.
> 
> My data has a resolution of 30- 2.6 angstroms as written  in the .sca file. 
> However, when I convert it to mtz using Aimless the resolution changes 
> automatically to 91.46 - 2.6. 
> I was trying to manually change
>  the resolution limits, and while the high resolution limit does change, the 
> low resolution remains at 91.46 angstroms. 
> When looking at my mtz file in HKLview I can see that only H,K,L and Rfree 
> are to 91.46 angstroms. All other columns are to the requested 30 angstroms.
> 
> I am wondering if it is supposed to do that or there is something I am not 
> doing right?
> 
> Thank you for your help!
> 
> -- 
> Alisa Glukhova
> postdoctoral fellow
> Tesmer lab
> University of Michigan