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
[email protected]
http://www.phenix-online.org/mailman/listinfo/phenixbb