[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[sdpd] Rescaling, Crysfire 2003 and Win/XP
> So, clearly, rescaling should be applied not only to the wavelength but
> also to the peak width for having a chance to index a protein in black
> box mode with McMaille.
This is a good illustration of the kind of subtle scale-related
restriction that can become incorporated into indexing programs (even
those as new as McMaille) and hence constrains the scale-independence of
the basic indexing equations.
Many more became embedded in mature indexing programs like ITO, DICVOL,
TREOR, KOHL, etc., in the course of their development, which is why it's
usually helpful to rescale if you have a problem with a cell volume
substantially greater than those they were optimised for (i.e. more than
c.3000-5000 A3).
As Armel points out, this can be done for you by the Crysfire rescale
command for any indexing programs supported by Crysfire. Crysfire 2003
supports McMaille (and hopefully in due course also AUTOX).
Crysfire 2003 progress
Both the 16-bit and 32-bit versions of Crysfire 2003 are essentially
working correctly under Windows 9x (as those who saw the latter
demonstrated at ECM-21 can attest).
However, there are still some unresolved problems under Windows/XP, NT
and 2000 (due to the different implementation of the DOS prompt under
those O/S), which are holding back its release.
The problem under XP, etc., is that their DOS prompt is no longer a fixed
24x80 frame, but has been reimplemented as a 24x80 view into a much
longer scrollable window, in which absolute Y-position write addresses
are not always fully honoured.
Thus, when Crysfire calls another program which writes to the DOS frame
under Win/XP, its output will not necessarily be in vertical synch with
output already present in the DOS window but will sometimes overwrite
it. This is seldom a major problem in practice, but it can be unsightly
and make new users worry that the system has been corrupted, so it's
something I'm reluctant to leave in a distributed program.
Perhaps I should release the current version as a beta for use under
Win9x, with a warning that its output formats can become over-written
under Win/XP, etc.
However, experience suggests that if I do so I'll get a stream of emails
from people who haven't read or understood this limitation, and that this
may injure Crysfire's reputation as a reasonably solid piece of code
(there are now rather a lot of systems out there running XP, etc...).
Some guidance from users would be welcome.
With best wishes
Robin Shirley
-------------------------------------
To: sdpd...@yahoogroups.com
From: Armel Le Bail <alb...@cristal.org>
Date: Wed, 08 Oct 2003 09:45:51 +0200
Subject: Re: [sdpd] McMaille slight update
Reply-to: sdpd...@yahoogroups.com
>Is there any chance that McMaille could be modified to have a scale
>factor - to do all the scaling internally rather than manual changes
>to the values (sort of how Crysfire works)?
Well, being included in the next Crysfire release, McMaille
automatically benefits from the Crysfire rescaling system, if
McMaille is activated inside of Crysfire.
>Plus for black box mode - could this be part of the search strategy -
>autorescaling procedure based estimated volumes to maximize a chance
>of getting a good solution for large cells? (is there any reason
>why proteins could not be indexed in black box mode?)
I have tried the tetragonal lysozyme data from Bob Von Dreele,
available in your talk (Korea, 2002) at CCP14 :
http://www.ccp14.ac.uk/poster-talks/korea_2002c/sld040.htm
By manual rescaling in black box mode (changing the wavelength
to 0.115006 instead of 1.15006 A), the tetragonal solution is not
found. An orthorhombic cell is proposed with a~b which can
allow to guess the tetragonal cell, the profile reliability factor is 13%,
suggesting that the data quality is not high (but this is relative
since the R factor is dependent of the selected peak width -
enlarging the peak width reduces Rp).
The tetragonal cell is found then in manual mode by enlarging
the peak width to 0.050 (°-2-theta) instead of the 0.022 value
suggested by the software itself. That peak width suggestion is
calculated by an empirical formula : 0.30*lambda/1.54056 (so as it is
0.30 for Cu Kalpha).
So, clearly, rescaling should be applied not only to the wavelength
but also to the peak width for having a chance to index a protein in
black box mode with McMaille.
This is not a problem to modify McMaille with a correction
of the peak width empirical formula for very short pseudo-wavelengths
in automatic mode. Decreasing artificially the wavelenght unfortunately
does not improve the data quality...
But how many crystallographers are indexing proteins from
powder data ? They have to be experts in crystallography I guess,
and will not be repelled by manual modes (putting hands in grease =
"mettre les mains dans le cambouis" in french ;-).
Armel
PS - Carlo U. Segre has made a Linux Debian package of McMaille,
thanks ! http://www.iit.edu/~segre
Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
------------------------ Yahoo! Groups Sponsor ---------------------~-->
Rent DVDs Online - Over 14,500 titles.
No Late Fees & Free Shipping.
Try Netflix for FREE!
http://us.click.yahoo.com/JYdFFC/XP.FAA/ySSFAA/UIYolB/TM
---------------------------------------------------------------------~->
Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/