[phenixbb] --unused_ok, .def, documentation,...

[Pavel Afonine]

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>