Folks,
Don't take this as an argument with software people - I have a side note about
structures.
Back in the day when I used to solve Structural Genomics structures, we almost
always knew substitution rate from masspec and Se always refined to lesser
occupancy. Could it be the decay instead?
C
Thank you all.
I think i know the difference.
This is quite a interesting case.
On 8/10/07, Paul Emsley <[EMAIL PROTECTED]> wrote:
>
>
>
> If I may expand on what Eleanor said.
>
> The issue is not the atom labels, but that the atom labels are in the
> right place (i.e. the refer to the right ato
Thanks to everyone who has responded so far. I'd like to provide a few more
details since I'm also interested in the practical ramifications of the
theoretical arguments presented thus far.
1. density map at 3.2 A resolution was used to refine a model that had
already been built and refined at 2.
Hello there
How do I tell Refmac that I have an inhibitor covalently bound to a Ser
residue? I am using the ccp4i interface and this is what I've came up
with (looking through the archives) but it does not seem to work
1) I made the inhibitor mon_lib.cif
2) I made the following mon_link.c
The discussion is converging, but let me clarify a few points. I suspect
that a new generation of crystallographers has come to the fore since the
last material discussions of real-space refinement in the mid 1990's. So
with apologies to the grey-haired (like me) set who may find the following
co
If you treat the amplitude and phase as a complex number and follow
the math I believe it turns out that real space and reciprocal space
refinement are identical... If there are no uncertainties.
Any model of the uncertainties can also be expressed in either space,
but a model that is simp
Yes, agree overall.
What I plan to implement in phenix.refine and then play with at some
point is that loop I wrote before:
for cycle in cycles (until convergence):
- do real space refinement (minimize T = Exray*weight +Egeom w.r.t.
model params);
- do reciprocal space refinement (minimize T
On 10 Aug 2007, at 20:12, Pavel Afonine wrote:
Anastassis Perrakis wrote:
On 10 Aug 2007, at 18:59, Pavel Afonine wrote:
Hi Mike,
the best is to do both in a loop:
for cycle in cycles:
- do real space refinement;
- do reciprocal space refinement
Well - thats what we all do - right ?
T
Dear George,
> I like your hybrid_ 36 scheme and will implement it and the two character
> hain IDs PDB file columns 21 and 22, right justified) when I next update
> HELXL. Of course I will need to do some programming because of the SHELX
> zero dependency' philosophy, but it seems to me to be str
Anastassis Perrakis wrote:
On 10 Aug 2007, at 18:59, Pavel Afonine wrote:
Hi Mike,
the best is to do both in a loop:
for cycle in cycles:
- do real space refinement;
- do reciprocal space refinement
Well - thats what we all do - right ?
The real space refinement can be done either with th
On 10 Aug 2007, at 18:59, Pavel Afonine wrote:
Hi Mike,
the best is to do both in a loop:
for cycle in cycles:
- do real space refinement;
- do reciprocal space refinement
Well - thats what we all do - right ?
The real space refinement can be done either with the tools from
Chapman at al
Hi Mike,
the best is to do both in a loop:
for cycle in cycles:
- do real space refinement;
- do reciprocal space refinement
Have a look at this very nice paper:
Acta Cryst. (1999). D55, 835-845
Critical initial real-space refinement in the structure determination of
arginine kinase
G.
Dear CCP4 experts,
Recently, I was debating a colleague on the pros/cons of refinement done in
reciprocal space compared to refinement in real space.
I always thought reciprocal space refinement was preferable since measured
amplitudes will be more accurate than calculated phases (unless good
exp
On Friday 10 August 2007 04:53, Clemens Vonrhein wrote:
> It should be trivial to put this into REFMAC too
> (Garib!): just add cards like
>
> FPRIme
>
> so that a user can do
>
> FPRIme Se -4.5
>
> REFMAC then corrects C by the difference f'(CuKa)-(-4.5) (after
> reading the f'(CuKa) fro
> Actually, everything proposed [will] break some software.
Breaking some is far better than all, and there is a very important
principle being followed here: The notion behind these minimalist
improvements is that they will only break in cases where the PDB format
itself breaks.
For example,
> > Behalf Of Santarsiero, Bernard D.
> >
> > Can I ask a dumb question? Just curious...
> >
> > Why are we now limited to 80 "columns"? In the old days, that
> > was a limit with Fortran and punched cards. Can a "record"
> > (whatever it's called now) be as long as we wish? Instead of
> > com
I'm new to using LIBCHECK. I'm trying to make an appropriate library
for the MSO ligand. I have a .cif file that I downloaded from
Gerard's site. When running LIBCHECK, if I use MON MSO and FILE_CIF
then the error is " ERROR: reading title of input file". If I don't
use the MON record, t
If you want to give it a try, I switched the
buttons to an alternate server. It is slower
than the one we were using, but it will
give you the idea. Try
http://biomol.dowling.edu/WPDB/
put in a PDB id code in the box near the top
of the page and click on "CLICK HERE for WPDB version ..."
The c
Actually, everything proposed with break some software.
The real question is one of how much value the
community gains from how much of a change. mmCIF
was one proposal that would "solve" the problem,
but which met a lot of resistance. The change
in atom serial numbers to strings is another
possi
That's easy: Backward compatibility, both in terms of old programs and
old data.
The idea is to maintain as much interoperability as possible.
> -Original Message-
> From: CCP4 bulletin board [mailto:[EMAIL PROTECTED] On
> Behalf Of Santarsiero, Bernard D.
> Sent: Friday, August 10, 2
Can I ask a dumb question? Just curious...
Why are we now limited to 80 "columns"? In the old days, that was a limit
with Fortran and punched cards. Can a "record" (whatever it's called now)
be as long as we wish? Instead of compressing a lot on a PDB record line,
can we lengthen it to 130 columns
Correction: Scratch what I wrote -- the PDB format does now support a
formal charge field in columns 79-80 (1+,2+,1- etc.). Hooray!
Thus, adoption of the CONECT valency convention is all it would take for
us to be able to convey chemically-defined structures using the PDB
format.
I'll happily
A couple of buccaneer releases have gone by since I last made an
announcement:
release 0.7.2:
- new 'correlation mode' gives better results after MR or when
completing an initial model.
- sequenced fragments are now renumbered to match the position in the
final sequence.
release 0.7.3:
Actually, this isn't quite right yet - since the tabulated values in
atomsf.lib are for f0: so you just need to add f' to C (no need to
adapt it for the value at CuKa). Thanks to Claus Flensburg for
pointing that out to me.
Clemens
On Fri, Aug 10, 2007 at 12:53:05PM +0100, Clemens Vonrhein wrote:
Research Technician (Fixed-term)
Protein expression for Structural Biology
Applications are invited for the above post from highly motivated individuals
with a strong interest in eukaryotic protein expression, protein biochemistry
and protein purification. The research project is funded by the
I support CCP4 adopting the hybrid36 and 2 char chain id extensions too.
If no-one else steps up to do it, I'll try and patch mmdb to support it
when I get time.
Kevin
George M. Sheldrick wrote:
I like your hybrid_ 36 scheme and will implement it and the two character
chain IDs PDB file colum
On Fri, Aug 10, 2007 at 12:32:21PM +0100, Eleanor Dodson wrote:
> Sorry - Clemens is right.
>
> Eleanor
Hi Eleanor,
phew - I was starting to wonder that what I put into (auto)BUSTER
wasn't right. It should be trivial to put this into REFMAC too
(Garib!): just add cards like
FPRIme
so that
Dear Ralf,
I like your hybrid_ 36 scheme and will implement it and the two character
chain IDs PDB file columns 21 and 22, right justified) when I next update
SHELXL. Of course I will need to do some programming because of the SHELX
'zero dependency' philosophy, but it seems to me to be straigh
If I may expand on what Eleanor said.
The issue is not the atom labels, but that the atom labels are in the
right place (i.e. the refer to the right atoms).
There is an IUPAC convention on the torsion of CB-CG-CD-OE1 (for GLU).
The torsion should be between -90 and +90. Yours is not.
Therefor
Hi Eleanor,
On Fri, Aug 10, 2007 at 10:27:16AM +0100, Eleanor Dodson wrote:
> If you have significant anomalous scatterering and are using you
> need to modify the scattering factor for that atom appropriately.
>
> Here is an extract from $CLIBD/atomsf.lib
> Se
>34342
Dear Eleanor:
But in my structure, the atom labelles are all right.
Such as GLU A 15 :
ATOM 55 N GLU A 15 -59.930 -39.249 -9.123 1.00 30.10
N
ATOM 56 CA GLU A 15 -60.573 -38.776 -7.889 1.00 30.54
C
ATOM 57 CB GLU A 15 -61.533 -37.599 -8.146 1.00 31.08
C
AT
Dear All:
I have refined a structure. When I run procheck, a messege apears in the log
file as below:
Average value of CA-N-C-CB angle is 33.83
Standard deviation is 1.85
* Side chain atoms swapped for residues:
* GLU A 15 ARG A 24 TYR A
I have checked the density and the geometry of the
ping sun wrote:
Thanks for your answer.
I guess I did not make it clear. I used the data file for refinement
which is also used for phasing (peak_anomalous.hkl).
Traditionally, people will reprocess the same set of data for
refinement (rescale it in hkl2000 without using the option
"anomalous
Quoting Anastassis Perrakis <[EMAIL PROTECTED]>:
> On Aug 9, 2007, at 15:02, Tommi Kajander wrote:
>
> > so, a) WHAT IS GAMMA??
>
> gamma is possibly the letter of the greek alphabet that has had most
> abuse from scientists.
thats what i thought...
> http://en.wikipedia.org/wiki/Gamma_%28di
34 matches
Mail list logo
