<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">Hi Derek,<br>
<br>
</div>
<blockquote
cite="mid:A731CBCF-B870-411A-A8E1-7B661B23A7B9@biochemistry.lu.se"
type="cite">
<div>
<div>
<blockquote type="cite">
<div bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">Then how you ended up having
anomalous data set for your neutron observations:
FO,SIGFO,DANO,SIGDANO,ISYM ?<br>
</div>
</div>
</blockquote>
<div><br>
</div>
As I mentioned in my original mail, I've discovered that SCALA
always outputs I+ and I- no matter what you do. From the
manual:</div>
<div><br>
</div>
<div>"Normally anomalous scattering is ignored during the scale
determination (I+ & I- observations are treated together),
but the merged file always contains I+ & I-, even if the
ANOMALOUS OFF command is used."</div>
<div><br>
</div>
<div>Thus if you don't take special precautions, e.g. in
TRUNCATE, these will be converted to F+ and F- and (I now
know) phenix.refine will use them. However I've now discovered
that the keyword ANOMALOUS NO in TRUNCATE will prevent output
of the anomalous columns altogether.</div>
</div>
</blockquote>
<br>
oh I see how this may be a problem. Though unfortunately I don't
think there is a robust way of catching this in phenix.refine..
phenix.refine strives to do a good refinement job but obviously it
can't make sure the user provides meaningful data. Any suggestions
are welcome!<br>
<br>
<font face="Times"><br>
</font>
<blockquote
cite="mid:A731CBCF-B870-411A-A8E1-7B661B23A7B9@biochemistry.lu.se"
type="cite">
<div>
<div>
<blockquote type="cite">
<div bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">All in all, if you don't have
anomalous data make sure your inputs files do not have
spurious (anomalous) arrays: phenix.refine can't read
your mind to see what you have done in your diffraction
experiment - it's beyond the scope of what it's supposed
to do!<br>
</div>
</div>
</blockquote>
<div><br>
</div>
Fine, I've now learned an important lesson in input/output
checking! But could I politely suggest that an improvement in
phenix.refine's mind-reading capabilities: if the user
mistakenly inputs a file as neutron data with anomalous
columns in, then these should be ignored, as the concept is by
default incompatible with neutron data? </div>
</div>
</blockquote>
<br>
Yes, this is doable: adding to my todo list now.<br>
<br>
<blockquote
cite="mid:A731CBCF-B870-411A-A8E1-7B661B23A7B9@biochemistry.lu.se"
type="cite">
<div>Finally, it would also be nice if the neutron maps and not
just the X-ray maps were displayed in Coot during refinement and
if the summary panel at the end of refinement showed statistics
for the neutron data as well as for the X-ray data.<br>
</div>
</blockquote>
<br>
Let's see what Nat thinks (he is the main and only GUI developer). <br>
<br>
Also, the concept of joint XN refinement may change as outlined in
slides 28-32 here:<br>
<a class="moz-txt-link-freetext" href="https://www.dropbox.com/s/jsb7pks7nr019kx/neutrons-and-news.pdf">https://www.dropbox.com/s/jsb7pks7nr019kx/neutrons-and-news.pdf</a><br>
<br>
Pavel<br>
<br>
</body>
</html>