[phenixbb] --unused_ok, .def, documentation,...
Pavel Afonine
PAfonine at lbl.gov
Fri May 8 08:47:21 PDT 2009
Hi Everyone,
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.
I keep seeing people having trouble refining their structures in
phenix.refine just because they were using "--unused-ok" option.
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.
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.
Finally, I don't understand what the trouble is to run this command:
phenix.refine --diff-params your_old_parameters.def >
your_new_parameters.def
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.
Oops, I already spent 10 minutes for writing this (writing takes longer
for non-native speakers/writers), instead of implementing dual-space
refinement -:)
Pavel.
On 5/8/09 6:49 AM, Ralf W. Grosse-Kunstleve wrote:
> Hi Carsten,
>
>
>> 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.
>>
>
> 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
> phenixbb at phenix-online.org
> http://www.phenix-online.org/mailman/listinfo/phenixbb
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://phenix-online.org/pipermail/phenixbb/attachments/20090508/94bf38b9/attachment-0003.htm>
More information about the phenixbb
mailing list