<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Hi Everyone,<br>
<br>
in fact probably I should be beaten for this idea. We discussed this,
me and Ralf, a few weeks ago and came to the idea of retiring this
option. Here is why.<br>
<br>
I keep seeing people having trouble refining their structures in
phenix.refine just because they were using "--unused-ok" option. <br>
<br>
A typical example: someone turns on TLS refinement in his/her old
parameter file using "refine_tls=true". Of course running this file
with a new version of phenix.refine will stop the program suggesting
"--unused-ok" as a way to keep going. Then that person realizes how
cool and easy the fix is, hardwires "--unused-ok" in his/her scripts
and permanently forgets about it. Finally, I got complaints that
phenix.refine didn't do TLS refinement although it was asked for.
Hopefully, I now check for this trap first of all, but in the past it
was a number of times when I had to spend a good part of the day
"debugging" it: - a few emails to convince a user send in the data, -
then finding the problem, - then writing a long email back explaining
the pros-and-cons of using "--unused-ok". It is no problem to do a few
times, but since it happens regularly it becomes a time sink.<br>
<br>
And I'm wondering how many people have fallen into this trap even
without knowing it? Ok, some of them, curious ones, may compare the
R-factors between phenix.refine and say Refmac, find that Refmac's
values are better, and silently switch to the program giving better
values. Or worse, keep going doing poor refinement job.<br>
<br>
Finally, I don't understand what the trouble is to run this command:<br>
<br>
phenix.refine --diff-params your_old_parameters.def >
your_new_parameters.def<br>
<br>
and then have a quick look at your_new_parameters.def to avoid future
surprises? If some people like to create andkeep around myriades of
scripts I think it's a good idea to make sure they are not full of
hidden bugs and traps, that God knows when they will back fire your.<br>
<br>
Oops, I already spent 10 minutes for writing this (writing takes longer
for non-native speakers/writers), instead of implementing dual-space
refinement -:)<br>
<br>
Pavel.<br>
<br>
<br>
On 5/8/09 6:49 AM, Ralf W. Grosse-Kunstleve wrote:
<blockquote cite="mid:200905081349.n48DnNP1015412@cci.lbl.gov"
type="cite">
<pre wrap="">Hi Carsten,
</pre>
<blockquote type="cite">
<pre wrap="">Could you please NOT do this. With your current frequent upgrade cycle
and the concurrent renaming of options it is very frequent that we need
to use the unused_ok option. Otherwise it is really a pain to pick up a
refinement from a couple of weeks ago, just because I needed to upgrade
phenix in order to get something working. Everybody should understand
that the unused_ok option is the price you have to pay for frequent
update cycles.
</pre>
</blockquote>
<pre wrap=""><!---->
OK, thanks for the feedback. -- Another simple idea, with the aim
to avoid the --unused-ok in most cases, so that people don't get
too used to doing something potentially dangerous: we could change
phenix.refine to write out only the diffs to the .def file. Given the
same phenix.refine version, there would be no change in behavior when
the .def file is used. When moving to a new phenix.refine version,
chances of stumbling over a change in parameter names are greatly
reduced, so it should be much less likely that the --unused-ok option
is necessary.
I'll add the version tag to the .eff and .def files sometime soon.
Ralf
_______________________________________________
phenixbb mailing list
<a class="moz-txt-link-abbreviated" href="mailto:phenixbb@phenix-online.org">phenixbb@phenix-online.org</a>
<a class="moz-txt-link-freetext" href="http://www.phenix-online.org/mailman/listinfo/phenixbb">http://www.phenix-online.org/mailman/listinfo/phenixbb</a>
</pre>
</blockquote>
</body>
</html>