Hi Gerard,
1ABE - L-arabinose binding protein with both alpha and beta anomie’s of arabinose in the binding site. I don’t think the data is available for this, but I have a high-resolution figure (from the paper) showing the electron density. Contact me off-list.
Mark
_______________________________________________
Mark A. Saper, Ph.D.
Associate Professor of Biological Chemistry, U-M Medical School
Room 3220B, MSRB III [log in to unmask] +1 (734) 764-3353
On Apr 11, 2016, at 7:00 PM, CCP4BB automatic digest system <[log in to unmask]> wrote:
> There are 11 messages totaling 1958 lines in this issue.
>
> Topics of the day:
>
> 1. COOT Crash Problem
> 2. Implementation of the ESRF Data Policy (2)
> 3. Question about Phaser syntax (3)
> 4. Associate/Senior Editor in Structural Biology, position at Nature
> Communications
> 5. cleaning cryo loop
> 6. Follow-up to a question from 2002 (2)
> 7. Beamtime @ SLS
>
> ----------------------------------------------------------------------
>
> Date: Mon, 11 Apr 2016 07:32:20 +0200
> From: "B.Lohkamp" <[log in to unmask]>
> Subject: Re: COOT Crash Problem
>
>> I am running COOT on three different computers. Two (desktops) are running WinCoot 0.8.2 and the other (laptop) is running WinCoot 0.8-pre (revision 5257).
>> All computers are running windows 7.
>>
>> I am loading the same pdb/MTZ files on all of the computers. The 0.8 pre version is working fine. However with the 0.8.2 version, when I go to the sequence view and move towards the end of the sequence list, the program crashes.
>>
>> Is this a known problem?
>
> Not yet.
> Is this happening only with specific pdb files or any? Large? Many
> chains? Do you click on a residue or just scrolling causes the crash?
> Maybe you can (confidentially) send the offending one.
>
> Thanks,
>
> Bernhard
>
> ------------------------------
>
> Date: Mon, 11 Apr 2016 09:38:01 +0200
> From: Isabel Garcia-Saez <[log in to unmask]>
> Subject: Re: Implementation of the ESRF Data Policy
>
> Dear all,
> A possible solution (that I do not know if it would be compatible with this PaNdata Data Policy) would be being able to specify somewhere in your ESRF BAG application for each sample, if you want the data associated to be released into the public after 3 years (that could be done by checking a specifically created box when you fill in your sample sheet, for example) and/or receiving an alert just before the release of your data, asking you if you want them to be released or not (this could be more inconvenient, because if you go often to the ESRF you can easily be continuously invaded by alerts after 3 years and it could be also heavy for the ESRF to deal with).
> Best,
> Isabel
>
>
>> Le 9 avr. 2016 à 21:25, Jrh <[log in to unmask]> a écrit :
>>
>> Dear Colleagues,
>> A PDF of the slides I presented in my talk at BCA 2016 on Wednesday this last week in Nottingham can be found here:-
>> http://forums.iucr.org/viewtopic.php?f=21&t=371
>> Best wishes,
>> John
>>
>> Emeritus Prof of Chemistry John R Helliwell DSc_Physics
>>
>>
>> On 9 Apr 2016, at 19:34, Alun Ashton <[log in to unmask]> wrote:
>>
>>> Dear Adrian,
>>>
>>> Although the thread has moved on, one clarification on your comparison to Diamond’s data policy, Although Diamond does archive all YOUR data from peer reviewed research (note no distinction between raw and processed), according to our terms or usage we do not make that data open access.
>>>
>>> The current status was recently reviewed and presented to Diamond User Committee (DUC) with the below slides and I believe was recently summarised by John Helliwell at a recent BCA meeting as part of a broader overview.
>>> https://www.dropbox.com/s/q7twrbodmv3cqmr/160309%20Current%20archive%20status%20at%20Diamond.pdf?dl=0
>>>
>>> The policy is under constant review and we encourage Diamond users to send their feedback (support or objections) e.g. via their DUC representative.
>>>
>>> The relevant links:
>>> Diamond Experiment Data Management Policy:
>>> http://www.diamond.ac.uk/Users/UserGuide/Data-User-Guide/Accessing-Data/Data-Policy.html
>>>
>>> Diamond User Committee
>>> http://www.diamond.ac.uk/Home/Company/Management/DUC.html
>>>
>>>
>>>
>>> From: Adrian Goldman [mailto:[log in to unmask]]
>>> Sent: 08 April 2016 11:09
>>> Subject: Re: Implementation of the ESRF Data Policy
>>>
>>> Xavier,
>>>
>>> As far as I am aware, this brings the ESRF policy in line with eg the policy at Diamond. I mostly agree with you; and anyway the current policy being implemented certainly in the UK of keeping everything for 10 years is I think ridiculous: most of the data that we collect is completely useless. Sadly.
>>>
>>> I was at the ESRF council meeting where this was discussed, and there was to the best of my recollection very little enthusiasm for other proposals. In addition, I think a little bit of misdirection in ones naming and data collection strategy will suffice to make sure that the
>>> data collected is not actually usable by a competitor lab, unless they happen to have exactly the same crystal form, same construct etc as you. As such misdirection is also already prevalent in high-impact factor papers, plus other small acts of malfeasance, like sending out
>>> clones that do _not_ correspond to the ones reported in the literature, I am sure it will not be beyond one’s wit to come up with similar strategies for data at the beamline.
>>>
>>> I am by no means condoning such behaviour, nor do I do it: I have merely noticed it in others and what they publish/have sent us.
>>>
>>> For obvious reasons, I am not going to name names.
>>>
>>> Adrian
>>>
>>> ps: The larger question surely is what societal purpose is served by this level of competition? My feeling is: not much.
>>>
>>> On 8 Apr 2016, at 12:47, F.Xavier Gomis-Rüth <[log in to unmask]<mailto:[log in to unmask]>> wrote:
>>>
>>> Dear CCP4ers,
>>> I received the message below from the ESRf User Office some weeks ago and was wondering if others within the community had, too, and would
>>> put this up for discussion within the BB. But as this is apparently not the case, I will come to the fore ;-) .
>>> I must say this is a unilateral decision by ESRF, I was completely unaware that this was under discussion. While I am truly not against
>>> transparency, in particular in the case of publicly funded research, in this case I consider that things have simply gone too far. A really challenging
>>> project in MX currently ALWAYS takes more than 3 years to be published after the very first dataset was collected, so this regulation poses an
>>> additional, completely artificial and gratuitous pressure on researchers to finish everything within a determined and clearly too short time span.
>>> Another font of unnecessary pressure is provided by some journals, such as NSMB, which now impose that not only the coordinates be send for review of a manuscript but rather the cif files with the reflections, while, obviously, reviewers keep their anonymity. Given the particular characteristics of our field, where
>>> who publishes first irreversibly relegates competitors to the absolute irrelevance, such policies rather favor fraud but on the other side, on that of
>>> potentially desperate competitors, whose very existence depends on relevant publications and who easily could take advantage of this information.
>>> While sound cases of fraud, historical and recent, clearly impose the necessity of stringent control, this must happen in a rational way and following
>>> consensus within the community, which has not happened in the aforementioned cases. In the case of ESRF, this could be easily accomplished as in the PDB,
>>> where data are released upon publication. In the case of journals, by performing an exhaustive verification of structures AFTER the manuscript has been
>>> pre-accepted, as a final condition for definitive acceptance.
>>> I would be very interested in the opinion of the BB.
>>> Best,
>>> Xavier
>>>
>>>
>>> -------- Forwarded Message --------
>>> Subject:
>>>
>>> Implementation of the ESRF Data Policy
>>>
>>> Date:
>>>
>>> Mon, 29 Feb 2016 17:04:43 +0100 (CET)
>>>
>>> From:
>>>
>>> [log in to unmask]<mailto:[log in to unmask]>
>>>
>>> To:
>>>
>>> [log in to unmask]<mailto:[log in to unmask]>
>>>
>>>
>>>
>>> Dear ESRF User,
>>>
>>> The new ESRF data policy stipulates that all raw data and the associated metadata from peer reviewed access experiments at the ESRF will be open access after an initial embargo period of 3 years, during which access is restricted to the experimental team, represented by the Main Proposers. Proprietary research experiments are excluded.
>>>
>>> Acceptance of this policy is a condition for the request of ESRF beamtime.
>>>
>>> For more details and information, please read the news item at here<http://www.esrf.fr/home/news/general/content-news/general/esrf-takes-the-helm-in-saving-data.html>.
>>> The ESRF data policy document and the status of implementation on the different ESRF beamlines can be consulted here<http://www.esrf.fr/home/UsersAndScience/UserGuide/esrf-data-policy-implementation.html>.
>>>
>>> Best wishes,
>>>
>>> ESRF - User Office
>>> Tel: + 33 (0)4 76 88 23 58 / 25 52 /28 80
>>>
>>>
>>>
>>>
>>>
>>> --
>>> This e-mail and any attachments may contain confidential, copyright and or privileged material, and are for the use of the intended addressee only. If you are not the intended addressee or an authorised recipient of the addressee please notify us of receipt by returning the e-mail and do not use, copy, retain, distribute or disclose the information in or attached to the e-mail.
>>> Any opinions expressed within this e-mail are those of the individual and not necessarily of Diamond Light Source Ltd.
>>> Diamond Light Source Ltd. cannot guarantee that this e-mail or any attachments are free from viruses and we cannot accept liability for any damage which you may sustain as a result of software viruses which may be transmitted in or with the message.
>>> Diamond Light Source Limited (company no. 4375679). Registered in England and Wales with its registered office at Diamond House, Harwell Science and Innovation Campus, Didcot, Oxfordshire, OX11 0DE, United Kingdom
>>
>
>
>
> Isabel Garcia-Saez PhD
> Institut de Biologie Structurale
> Viral Infection and Cancer Group (VIC)-Cell Division Team
> 71, Avenue des Martyrs
> CS 10090
> 38044 Grenoble Cedex 9
> France
> Tel.: 00 33 (0) 457 42 86 15
> e-mail: [log in to unmask]
> FAX: 00 33 (0) 476 50 18 90
> http://www.ibs.fr
>
>
>
>
>
>
>
>
>
>
> ------------------------------
>
> Date: Mon, 11 Apr 2016 17:42:05 +0800
> From: Sam Tang <[log in to unmask]>
> Subject: Question about Phaser syntax
>
> Hi all
>
> It's my first time raising a question here. My apologies if this is not a
> right place to mail to. My question is as follows:
>
> I recently updated my CCP4i to 7.0.006 from an older (6.0.2) Windows
> version. This being done, I fail to run PhaserMR anymore with the below
> warning:
>
> #---PHASER COMMAND SCRIPT GENERATED BY CCP4I---
> TITLE [No title given]
> ROOT "C:/Users/"
> #---DEFINE DATA---
> HKLIN "C:/Users/ctruncate_B13_1_170_fixcell.mtz"
> LABIN I
>
> <B><FONT COLOR="#FF8800">
> $TEXT:Warning: $$ Baubles Markup $$
> -------------------------------------------------------------------------------------
> SYNTAX ERROR: Use F or SIGF
> -------------------------------------------------------------------------------------
> $$
>
>
> --------------------
> EXIT STATUS: FAILURE
>
> Nevertheless, when I use the same input mtz and model and same parameters
> in Phenix it runs OK. I am concerned if there is anything wrong with the
> source script during update.
>
> Does anyone experience similar thing? Where can I check if the source
> script is fine?
>
> Thanks.
>
> Sam Tang
> PhD candidate
> Biochemistry Programme, School of Life Sciences, CUHK
>
> ------------------------------
>
> Date: Mon, 11 Apr 2016 10:05:01 +0000
> From: "Kirk, Rebecca" <[log in to unmask]>
> Subject: Associate/Senior Editor in Structural Biology, position at Nature Communications
>
> Job title: Associate or Senior Editor (Structural Biology), Nature Communications
>
> Nature Communications is an innovative multidisciplinary science journal, and it is the flagship, Nature-branded fully Open Access journal. The journal publishes high-quality research from the breadth of the natural sciences and has already developed a strong track record in these disciplines.
>
> We now have an exciting opportunity for a structural biology editor to join our editorial team. The ideal candidate will have a PhD (or equivalent), and preferably postdoctoral experience, in a biochemistry-related subject. Editorial experience would be beneficial, but is not required.
>
> Reporting to a Team Manager (biological sciences), the successful candidates will play an important role in determining the representation of structural biology in the journal and will work closely with the other editors on all aspects of the editorial process, including manuscript selection. This role will also entail significant liaison with the scientific community and other Nature research journal editors in UK, US and China.
>
> This is a demanding and intellectually stimulating position. Broad scientific knowledge and training, excellent literary skills and a keen interest in the practice and communication of science are a prerequisite. The successful candidates must therefore have excellent communication and interpersonal skills. The salary and benefits will be competitive, reflecting the critical importance and responsibilities of this role.
>
> The role may be located in our London, New York or Shanghai office.
>
> In London or New York, the role may be offered on a full-time, permanent basis or a full-time, fixed-term basis to cover maternity leave. All applicants must be able to demonstrate the right to live and work in the UK or US in order to be considered for positions in these countries.
>
> Shanghai roles are offered on a full-time, permanent basis in our Shanghai office following an expected training period of up to 6 months in the New York or London office (depending on previous experience). Any offer of employment will be contingent on the necessary work permits for the US, UK and China, as applicable, being granted (the Company will provide reasonable assistance with the necessary application process in this respect).
>
> Closing date: 1st May 2016
>
> Springer Nature is a leading global research, educational and professional publisher, home to an array of respected and trusted brands providing quality content through a range of innovative products and services.
>
> Springer Nature is the world's largest academic book publisher, publisher of the world's highest impact journals and a pioneer in the field of open research. The company numbers almost 13,000 staff in over 50 countries and has a turnover of approximately EUR 1.5 billion. Springer Nature was formed in 2015 through the merger of Nature Publishing Group, Palgrave Macmillan, Macmillan Education and Springer Science+Business Media...
>
> Please see http://www.nature.com/naturejobs/science/jobs/577427-associate-or-senior-editor-structural-biology for details on how to apply.
> ********************************************************************************
> DISCLAIMER: This e-mail is confidential and should not be used by anyone who is not the original intended recipient. If you have received this e-mail in error please inform the sender and delete it from your mailbox or any other storage mechanism. Neither Macmillan Publishers Limited nor Macmillan Publishers International Limited nor any of their agents accept liability for any statements made which are clearly the sender's own and not expressly made on behalf of Macmillan Publishers Limited or Macmillan Publishers International Limited or one of their agents.
> Please note that neither Macmillan Publishers Limited nor Macmillan Publishers International Limited nor any of their agents accept any responsibility for viruses that may be contained in this e-mail or its attachments and it is your responsibility to scan the e-mail and attachments (if any). No contracts may be concluded on behalf of Macmillan Publishers Limited or Macmillan Publishers International Limited or their agents by means of e-mail communication.
> Macmillan Publishers Limited. Registered in England and Wales with registered number 785998. Macmillan Publishers International Limited. Registered in England and Wales with registered number 02063302.
> Registered Office Brunel Road, Houndmills, Basingstoke RG21 6XS
> Pan Macmillan, Priddy and MDL are divisions of Macmillan Publishers International Limited.
> Macmillan Science and Education, Macmillan Science and Scholarly, Macmillan Education, Language Learning, Schools, Palgrave, Nature Publishing Group, Palgrave Macmillan, Macmillan Science Communications and Macmillan Medical Communications are divisions of Macmillan Publishers Limited.
> ********************************************************************************
>
> ------------------------------
>
> Date: Mon, 11 Apr 2016 09:02:28 -0300
> From: Randy Read <[log in to unmask]>
> Subject: Re: Question about Phaser syntax
>
> Dear Sam,
>
> The version of Phaser distributed with CCP4 version 7 should accept intensities as input, which is why the interface has chosen the I and SIGI columns from your input MTZ file. It looks like there is an old version of Phaser in your path, and that one is being used.
>
> You can open a terminal window and, at least in Unix, type “which phaser”. That will tell you where the first version of phaser in your path is found, and then you can investigate why in your setup files (e.g. .cshrc or .bashrc or .login, etc., depending on your shell and how you’ve set things up) the wrong one is being put into the $PATH variable.
>
> I hope that helps!
>
> Best wishes,
>
> Randy Read
>
> -----
> Randy J. Read
> Department of Haematology, University of Cambridge
> Cambridge Institute for Medical Research Tel: +44 1223 336500
> Wellcome Trust/MRC Building Fax: +44 1223 336827
> Hills Road E-mail: [log in to unmask]
> Cambridge CB2 0XY, U.K. www-structmed.cimr.cam.ac.uk
>
>> On 11 Apr 2016, at 06:42, Sam Tang <[log in to unmask]> wrote:
>>
>> Hi all
>>
>> It's my first time raising a question here. My apologies if this is not a right place to mail to. My question is as follows:
>>
>> I recently updated my CCP4i to 7.0.006 from an older (6.0.2) Windows version. This being done, I fail to run PhaserMR anymore with the below warning:
>>
>> #---PHASER COMMAND SCRIPT GENERATED BY CCP4I---
>> TITLE [No title given]
>> ROOT "C:/Users/"
>> #---DEFINE DATA---
>> HKLIN "C:/Users/ctruncate_B13_1_170_fixcell.mtz"
>> LABIN I
>>
>> <B><FONT COLOR="#FF8800">
>> $TEXT:Warning: $$ Baubles Markup $$
>> -------------------------------------------------------------------------------------
>> SYNTAX ERROR: Use F or SIGF
>> -------------------------------------------------------------------------------------
>> $$
>>
>>
>> --------------------
>> EXIT STATUS: FAILURE
>>
>> Nevertheless, when I use the same input mtz and model and same parameters in Phenix it runs OK. I am concerned if there is anything wrong with the source script during update.
>>
>> Does anyone experience similar thing? Where can I check if the source script is fine?
>>
>> Thanks.
>>
>> Sam Tang
>> PhD candidate
>> Biochemistry Programme, School of Life Sciences, CUHK
>>
>
> ------------------------------
>
> Date: Mon, 11 Apr 2016 14:34:04 +0200
> From: Enrico Stura <[log in to unmask]>
> Subject: Re: cleaning cryo loop
>
> CCP4BBers,
>
> Use proteases to clean loops? Is this such a good idea?
>
> To eliminate the proteases afterwards you can always follow the cleaning
> method we use:
> 1. 5M urea. This will denature all proteins and dissolve all crystals very
> rapidly
> 2. water wash to remove denatured protein and urea
> 3. Repeat if not clean. Amost all loops will be clean after 3 cycles - if
> not you will need little cat Z.
> https://en.wikipedia.org/wiki/The_Cat_in_the_Hat_Comes_Back
>
> Enrico
>
> P.S. detergent traces are also difficult to rinse.
>
>
> On Thu, 07 Apr 2016 18:26:11 +0200, Jim Fairman <[log in to unmask]>
> wrote:
>
>> Hi Hena,
>>
>> We use Tergazyme
>> <https://www.alconox.com/downloads/pdf/techbull_tergazyme.pdf> to clean
>> our
>> loops. It contains proteases that can chew up stubborn material that
>> tends
>> to get stuck on loops. Per the directions - make a 1% (w/v) solution.
>> We
>> place this into a bath sonicator and then run that for 30-60 minutes.
>> The
>> loops must then go through several washes of ddH2O to make sure all of
>> the
>> protease-based detergent gets removed.
>>
>> Cheers, Jim
>>
>> On Thu, Apr 7, 2016 at 9:08 AM, Hena Dutta <[log in to unmask]> wrote:
>>
>>> Dear Members,
>>> Sorry for non-ccp4 question. Can someone tell which detergent I should
>>> use
>>> for cleaning cryo loop, used for crystal fishing? Or, someone can give a
>>> recipe for making the solution in house.
>>> Regards,
>>> Hena
>>>
>>>
>>
>>
>
>
> --
> Enrico A. Stura D.Phil. (Oxon) , Tel: 33 (0)1 69 08 4302 Office
> Room 19, Bat.152, Tel: 33 (0)1 69 08 9449 Lab
> LTMB, SIMOPRO, IBiTec-S, CE Saclay, 91191 Gif-sur-Yvette, FRANCE
> e-mail: [log in to unmask] Fax: 33 (0)1 69 08 90 71
> Proxima-2A, Soleil Synchrotron. Tel: 33 (0)1 69 35 8180 Beamline
> http://scholar.google.com/citations?hl=en&user=Kvm06WIoPAsC&pagesize=100&sortby=pubdate
>
> ------------------------------
>
> Date: Mon, 11 Apr 2016 20:38:27 +0800
> From: Sam Tang <[log in to unmask]>
> Subject: Re: Question about Phaser syntax
>
> Dear Professor Read and all
>
> Thanks a lot! It happens that I had two versions of CCP4 installed at the
> same time. After I completely uninstalled the 6.2.0 version Phaser works
> fine.
>
> Thanks again.
>
> Regards
>
> Sam
>
> On 11 April 2016 at 20:02, Randy Read <[log in to unmask]> wrote:
>
>> Dear Sam,
>>
>> The version of Phaser distributed with CCP4 version 7 should accept
>> intensities as input, which is why the interface has chosen the I and SIGI
>> columns from your input MTZ file. It looks like there is an old version of
>> Phaser in your path, and that one is being used.
>>
>> You can open a terminal window and, at least in Unix, type “which
>> phaser”. That will tell you where the first version of phaser in your path
>> is found, and then you can investigate why in your setup files (e.g. .cshrc
>> or .bashrc or .login, etc., depending on your shell and how you’ve set
>> things up) the wrong one is being put into the $PATH variable.
>>
>> I hope that helps!
>>
>> Best wishes,
>>
>> Randy Read
>>
>> -----
>> Randy J. Read
>> Department of Haematology, University of Cambridge
>> Cambridge Institute for Medical Research Tel: +44 1223 336500
>> Wellcome Trust/MRC Building Fax: +44 1223 336827
>> Hills Road
>> E-mail: [log in to unmask]
>> Cambridge CB2 0XY, U.K.
>> www-structmed.cimr.cam.ac.uk
>>
>>> On 11 Apr 2016, at 06:42, Sam Tang <[log in to unmask]> wrote:
>>>
>>> Hi all
>>>
>>> It's my first time raising a question here. My apologies if this is not
>> a right place to mail to. My question is as follows:
>>>
>>> I recently updated my CCP4i to 7.0.006 from an older (6.0.2) Windows
>> version. This being done, I fail to run PhaserMR anymore with the below
>> warning:
>>>
>>> #---PHASER COMMAND SCRIPT GENERATED BY CCP4I---
>>> TITLE [No title given]
>>> ROOT "C:/Users/"
>>> #---DEFINE DATA---
>>> HKLIN "C:/Users/ctruncate_B13_1_170_fixcell.mtz"
>>> LABIN I
>>>
>>> <B><FONT COLOR="#FF8800">
>>> $TEXT:Warning: $$ Baubles Markup $$
>>>
>> -------------------------------------------------------------------------------------
>>> SYNTAX ERROR: Use F or SIGF
>>>
>> -------------------------------------------------------------------------------------
>>> $$
>>>
>>>
>>> --------------------
>>> EXIT STATUS: FAILURE
>>>
>>> Nevertheless, when I use the same input mtz and model and same
>> parameters in Phenix it runs OK. I am concerned if there is anything wrong
>> with the source script during update.
>>>
>>> Does anyone experience similar thing? Where can I check if the source
>> script is fine?
>>>
>>> Thanks.
>>>
>>> Sam Tang
>>> PhD candidate
>>> Biochemistry Programme, School of Life Sciences, CUHK
>>>
>>
>>
>
> ------------------------------
>
> Date: Mon, 11 Apr 2016 20:10:02 +0200
> From: Gerard DVD Kleywegt <[log in to unmask]>
> Subject: Follow-up to a question from 2002
>
> Hi all,
>
> In 2002 I asked the BB a question to which I received many useful responses,
> showing the power of crowd-sourcing (although that term didn't exist yet at
> the time I think) - http://www.ysbl.york.ac.uk/ccp4bb/2002/msg00887.html
>
> Now I would like to pick the collective CCP4 Bulletin Brain again:
>
> Does any of you know of any examples (available in the PDB) where the same
> ligand is observed in two distinctly different conformations (with convincing
> support in the density) in one and the same structure (i.e., same PDB entry)?
> This could for example be two copies of a ligand bound to a dimer in different
> poses. I'm interested only in distinct sites, not multiple conformations in
> one site.
>
> I will happily summarise the replies.
>
> Best wishes,
>
> --Gerard
>
> ******************************************************************
> Gerard J. Kleywegt
>
> http://xray.bmc.uu.se/gerard mailto:[log in to unmask]
> ******************************************************************
> The opinions in this message are fictional. Any similarity
> to actual opinions, living or dead, is purely coincidental.
> ******************************************************************
> Little known gastromathematical curiosity: let "z" be the
> radius and "a" the thickness of a pizza. Then the volume
> of that pizza is equal to pi*z*z*a !
> ******************************************************************
>
> ------------------------------
>
> Date: Mon, 11 Apr 2016 18:49:07 +0000
> From: Jeffrey B Bonanno <[log in to unmask]>
> Subject: Re: Follow-up to a question from 2002
>
> one from memory
>
> PDB entry 1PTY, CRYSTAL STRUCTURE OF PROTEIN TYROSINE PHOSPHATASE 1B COMPLEXED WITH TWO PHOSPHOTYROSINE MOLECULES
>
> Proc Natl Acad Sci U S A. 1997 Dec 9;94(25):13420-5.
> Identification of a second aryl phosphate-binding site in protein-tyrosine phosphatase 1B: a paradigm for inhibitor design.
> Puius YA1, Zhao Y, Sullivan M, Lawrence DS, Almo SC, Zhang ZY.
>
> jbb
>
> Jeffrey B. Bonanno, Ph.D.
> Department of Biochemistry
> Albert Einstein College of Medicine
> 1300 Morris Park Avenue
> Bronx, NY 10461
> off. 718-430-2452 fax. 718-430-8565
> email [log in to unmask]
>
>
> -----Original Message-----
> From: CCP4 bulletin board [mailto:[log in to unmask]] On Behalf Of Gerard DVD Kleywegt
> Sent: Monday, April 11, 2016 2:10 PM
> To: [log in to unmask]
> Subject: [ccp4bb] Follow-up to a question from 2002
>
> Hi all,
>
> In 2002 I asked the BB a question to which I received many useful responses, showing the power of crowd-sourcing (although that term didn't exist yet at the time I think) - http://www.ysbl.york.ac.uk/ccp4bb/2002/msg00887.html
>
> Now I would like to pick the collective CCP4 Bulletin Brain again:
>
> Does any of you know of any examples (available in the PDB) where the same ligand is observed in two distinctly different conformations (with convincing support in the density) in one and the same structure (i.e., same PDB entry)?
> This could for example be two copies of a ligand bound to a dimer in different poses. I'm interested only in distinct sites, not multiple conformations in one site.
>
> I will happily summarise the replies.
>
> Best wishes,
>
> --Gerard
>
> ******************************************************************
> Gerard J. Kleywegt
>
> http://xray.bmc.uu.se/gerard mailto:[log in to unmask]
> ******************************************************************
> The opinions in this message are fictional. Any similarity
> to actual opinions, living or dead, is purely coincidental.
> ******************************************************************
> Little known gastromathematical curiosity: let "z" be the
> radius and "a" the thickness of a pizza. Then the volume
> of that pizza is equal to pi*z*z*a !
> ******************************************************************
>
> ------------------------------
>
> Date: Mon, 11 Apr 2016 21:25:35 +0200
> From: Meitian Wang <[log in to unmask]>
> Subject: Beamtime @ SLS
>
>
> =======================================================================
> SYNCHROTRON BEAM TIME FOR MACROMOLECULAR CRYSTALLOGRAPHY AT SLS
> =======================================================================
>
> Proposal application deadline: Friday, April 15, 2016
>
> Periods:
> July 1, 2016 - December 31, 2016 (Normal / Test proposals)
> July 1, 2016 - June 30, 2018 (Long-term proposals)
>
> Proposal submission:
> http://www.psi.ch/sls/px-beamlines-call-for-proposals <http://www.psi.ch/sls/px-beamlines-call-for-proposals>
>
> What's New (http://www.psi.ch/sls/pxi/pxi <http://www.psi.ch/sls/pxi/pxi>) ?
> - X06SA
> Fast beam size changing from 5 x 5 to 80 x 80 micron^2, one-micron beam available
> Versatile focusing scheme from focusing on sample to on detector
> EIGER 16M detector (133 Hz)
> Continous grid scan (60Hz)
> - X06DA
> Rapid access mode for experimental phasing, especially native-SAD (contact directly [log in to unmask] <mailto:[log in to unmask]>)
> - Sample changer
> 30 second sample exchange time
>
> Beamline characteristics and features
> X06SA Beamline (http://www.psi.ch/sls/pxi/pxi <http://www.psi.ch/sls/pxi/pxi>)
> X06DA Beamline (http://www.psi.ch/sls/pxiii/pxiii <http://www.psi.ch/sls/pxiii/pxiii>)
> X10SA Beamline (http://www.psi.ch/sls/pxii/pxii <http://www.psi.ch/sls/pxii/pxii>)
>
> Best regards,
>
> The MX group at SLS
>
> _____________
> Meitian Wang
> Swiss Light Source at Paul Scherrer Institut
> CH-5232 Villigen PSI - http://www.psi.ch/sls/ <http://www.psi.ch/sls/>
> Phone: +41 56 310 4175
>
> ------------------------------
>
> Date: Mon, 11 Apr 2016 20:39:58 +0100
> From: Jrh Gmail <[log in to unmask]>
> Subject: Re: Implementation of the ESRF Data Policy
>
> Dear Colleagues
> Our BCA 2016 abstract can found here:-
> http://forums.iucr.org/viewtopic.php?f=21&t=372
>
> Best wishes
> John Helliwell and Brian McMahon
>
>
>
> On 9 Apr 2016, at 19:34, Alun Ashton <[log in to unmask]> wrote:
>
>> Dear Adrian,
>>
>> Although the thread has moved on, one clarification on your comparison to Diamond’s data policy, Although Diamond does archive all YOUR data from peer reviewed research (note no distinction between raw and processed), according to our terms or usage we do not make that data open access.
>>
>> The current status was recently reviewed and presented to Diamond User Committee (DUC) with the below slides and I believe was recently summarised by John Helliwell at a recent BCA meeting as part of a broader overview.
>> https://www.dropbox.com/s/q7twrbodmv3cqmr/160309%20Current%20archive%20status%20at%20Diamond.pdf?dl=0
>>
>> The policy is under constant review and we encourage Diamond users to send their feedback (support or objections) e.g. via their DUC representative.
>>
>> The relevant links:
>> Diamond Experiment Data Management Policy:
>> http://www.diamond.ac.uk/Users/UserGuide/Data-User-Guide/Accessing-Data/Data-Policy.html
>>
>> Diamond User Committee
>> http://www.diamond.ac.uk/Home/Company/Management/DUC.html
>>
>>
>>
>> From: Adrian Goldman [mailto:[log in to unmask]]
>> Sent: 08 April 2016 11:09
>> Subject: Re: Implementation of the ESRF Data Policy
>>
>> Xavier,
>>
>> As far as I am aware, this brings the ESRF policy in line with eg the policy at Diamond. I mostly agree with you; and anyway the current policy being implemented certainly in the UK of keeping everything for 10 years is I think ridiculous: most of the data that we collect is completely useless. Sadly.
>>
>> I was at the ESRF council meeting where this was discussed, and there was to the best of my recollection very little enthusiasm for other proposals. In addition, I think a little bit of misdirection in ones naming and data collection strategy will suffice to make sure that the
>> data collected is not actually usable by a competitor lab, unless they happen to have exactly the same crystal form, same construct etc as you. As such misdirection is also already prevalent in high-impact factor papers, plus other small acts of malfeasance, like sending out
>> clones that do _not_ correspond to the ones reported in the literature, I am sure it will not be beyond one’s wit to come up with similar strategies for data at the beamline.
>>
>> I am by no means condoning such behaviour, nor do I do it: I have merely noticed it in others and what they publish/have sent us.
>>
>> For obvious reasons, I am not going to name names.
>>
>> Adrian
>>
>> ps: The larger question surely is what societal purpose is served by this level of competition? My feeling is: not much.
>>
>> On 8 Apr 2016, at 12:47, F.Xavier Gomis-Rüth <[log in to unmask]<mailto:[log in to unmask]>> wrote:
>>
>> Dear CCP4ers,
>> I received the message below from the ESRf User Office some weeks ago and was wondering if others within the community had, too, and would
>> put this up for discussion within the BB. But as this is apparently not the case, I will come to the fore ;-) .
>> I must say this is a unilateral decision by ESRF, I was completely unaware that this was under discussion. While I am truly not against
>> transparency, in particular in the case of publicly funded research, in this case I consider that things have simply gone too far. A really challenging
>> project in MX currently ALWAYS takes more than 3 years to be published after the very first dataset was collected, so this regulation poses an
>> additional, completely artificial and gratuitous pressure on researchers to finish everything within a determined and clearly too short time span.
>> Another font of unnecessary pressure is provided by some journals, such as NSMB, which now impose that not only the coordinates be send for review of a manuscript but rather the cif files with the reflections, while, obviously, reviewers keep their anonymity. Given the particular characteristics of our field, where
>> who publishes first irreversibly relegates competitors to the absolute irrelevance, such policies rather favor fraud but on the other side, on that of
>> potentially desperate competitors, whose very existence depends on relevant publications and who easily could take advantage of this information.
>> While sound cases of fraud, historical and recent, clearly impose the necessity of stringent control, this must happen in a rational way and following
>> consensus within the community, which has not happened in the aforementioned cases. In the case of ESRF, this could be easily accomplished as in the PDB,
>> where data are released upon publication. In the case of journals, by performing an exhaustive verification of structures AFTER the manuscript has been
>> pre-accepted, as a final condition for definitive acceptance.
>> I would be very interested in the opinion of the BB.
>> Best,
>> Xavier
>>
>>
>> -------- Forwarded Message --------
>> Subject:
>>
>> Implementation of the ESRF Data Policy
>>
>> Date:
>>
>> Mon, 29 Feb 2016 17:04:43 +0100 (CET)
>>
>> From:
>>
>> [log in to unmask]<mailto:[log in to unmask]>
>>
>> To:
>>
>> [log in to unmask]<mailto:[log in to unmask]>
>>
>>
>>
>> Dear ESRF User,
>>
>> The new ESRF data policy stipulates that all raw data and the associated metadata from peer reviewed access experiments at the ESRF will be open access after an initial embargo period of 3 years, during which access is restricted to the experimental team, represented by the Main Proposers. Proprietary research experiments are excluded.
>>
>> Acceptance of this policy is a condition for the request of ESRF beamtime.
>>
>> For more details and information, please read the news item at here<http://www.esrf.fr/home/news/general/content-news/general/esrf-takes-the-helm-in-saving-data.html>.
>> The ESRF data policy document and the status of implementation on the different ESRF beamlines can be consulted here<http://www.esrf.fr/home/UsersAndScience/UserGuide/esrf-data-policy-implementation.html>.
>>
>> Best wishes,
>>
>> ESRF - User Office
>> Tel: + 33 (0)4 76 88 23 58 / 25 52 /28 80
>>
>>
>>
>>
>>
>> --
>> This e-mail and any attachments may contain confidential, copyright and or privileged material, and are for the use of the intended addressee only. If you are not the intended addressee or an authorised recipient of the addressee please notify us of receipt by returning the e-mail and do not use, copy, retain, distribute or disclose the information in or attached to the e-mail.
>> Any opinions expressed within this e-mail are those of the individual and not necessarily of Diamond Light Source Ltd.
>> Diamond Light Source Ltd. cannot guarantee that this e-mail or any attachments are free from viruses and we cannot accept liability for any damage which you may sustain as a result of software viruses which may be transmitted in or with the message.
>> Diamond Light Source Limited (company no. 4375679). Registered in England and Wales with its registered office at Diamond House, Harwell Science and Innovation Campus, Didcot, Oxfordshire, OX11 0DE, United Kingdom
>
> ------------------------------
>
> End of CCP4BB Digest - 10 Apr 2016 to 11 Apr 2016 (#2016-103)
> *************************************************************
|
