--unused_ok, .def, documentation,...
[ phenix v1.4 rel. tag 3 cctbx tag: 2008_12_07_1353 ] using an old .def w/ "latest devel. rel" phenix (but not nightly) i used --unused_ok b/c it looks like that's what its for. i am expecting an "updated" .def to write after the job - yes?... if so, it reads slightly differently than the documentation.. hard to give an example... things look ok in general, but ought i to have a new .def? -bryan p.s: does phenix write version/release info in the .def (i can't find it)?
[ phenix v1.4 rel. tag 3 cctbx tag: 2008_12_07_1353 ]
using an old .def w/ "latest devel. rel" phenix (but not nightly)
i used --unused_ok b/c it looks like that's what its for.
I'm going to retire that option when I get a chance since it causes too much confusion. Please try this: Using phenix.refine 1.4-3: phenix.refine --diff-params your.def > your.dif Using new release: phenix.refine your.dif If that fails because of unused parameters, review and edit your.dif and try again. It is not as convenient as --unused-ok, but should rule out surprises.
i am expecting an "updated" .def to write after the job - yes?... if so, it reads slightly differently than the documentation.. hard to give an example... things look ok in general, but ought i to have a new .def?
-bryan
p.s:
does phenix write version/release info in the .def (i can't find it)?
Nope. Maybe we'll change it in the future, so that the new phenix.refine can do the diff with the old phenix.refine version automatically (if you still have it installed). Ralf
Ralf, 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. Cheers, Carsten
-----Original Message----- From: [email protected] [mailto:phenixbb- [email protected]] On Behalf Of Ralf W. Grosse-Kunstleve Sent: Friday, May 08, 2009 1:32 AM To: [email protected] Subject: Re: [phenixbb] --unused_ok, .def, documentation,...
[ phenix v1.4 rel. tag 3 cctbx tag: 2008_12_07_1353 ]
using an old .def w/ "latest devel. rel" phenix (but not nightly)
i used --unused_ok b/c it looks like that's what its for.
I'm going to retire that option when I get a chance since it causes too much confusion. Please try this:
Using phenix.refine 1.4-3: phenix.refine --diff-params your.def > your.dif
Using new release: phenix.refine your.dif
If that fails because of unused parameters, review and edit your.dif and try again. It is not as convenient as --unused-ok, but should rule out surprises.
i am expecting an "updated" .def to write after the job - yes?... if so, it reads slightly differently than the documentation.. hard to give an example... things look ok in general, but ought i to have a new .def?
-bryan
p.s:
does phenix write version/release info in the .def (i can't find it)?
Nope. Maybe we'll change it in the future, so that the new phenix.refine can do the diff with the old phenix.refine version automatically (if you still have it installed).
Ralf _______________________________________________ phenixbb mailing list [email protected] http://www.phenix-online.org/mailman/listinfo/phenixbb
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
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
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 Because it does not make things clearer at all -- e.g. if you've changed long TLS and long NCS definitions, they call come out. And any comments you might have put in your file don't show up either.
One suggestion: support scripts. For instance: if I run things from a script, parse the script name and set "prefix" and "serial" according to that (rather than infer it automatically). This way: 1) I can easily see the commands that gave rise to a set of files 2) I can include comments with those commands 3) I can format the script to highlight what I changed Yes, I can do this anyway (and I do), but then I have to remember to set "prefix" and "serial". Cheers phx
I keep seeing people having trouble refining their structures in
Couple of comments: phenix.refine just because they were using "-->unused-ok" option. Well, with every powerful tool come caveats. The unused_ok option is a expert option and if people who have difficulties understanding what they are doing use it and encounter problems then it begs the question why expert users need to suffer the consequences of their inabilities. I use this option often and it is warranted in the current environment in which phenix goes through a lot of revisions, which break compatibility with previous versions, but provide new/better functionality I'd like to use. And yes, if you are doing a couple of structures a day, reediting the parameter file(s) is a serious drag.
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
It is NOT usable in a automation environment. Since phenix goes through so many releases, which change the parameter file and bails by default if the parameter file does not match the current version, automation is difficult to achieve. Correct me if I am wrong, but I believe it would almost be impossible to pick up a previous refinement done with a old phenix version again via an automated approach if the parameter file has changed and phenix bails. Granted I could freeze the phenix version used for automation and could maintain a couple of different versions for different purposes, but that quickly becomes impractical. So in essence, for the "high-throughput-bleeding-edge-junky-users" the --unsed_ok option is essential and I hope that it remains. Cheers. Carsten
if the latest/greatest phenix is used, if --unused_ok instructs phenix to ignore obsolete settings, if --unused_ok writes a .def commensurate with the l/g phenix, if the l/g phenix with the newest .def obviates --unused_ok, what will be incorrect? -bryan
Hi, - As things are going more and more settled, the parameters are not changing that often anymore as it was at the beginning. So obviously if you download the new version a few times a week it is unlikely that you need to change your parameter files the same amount of times, or even once; - Sometime new options/features come along with the new parameters for them. I'm wondering how people who download the newer version to use these options, will actually use them without updating their parameter files. In this case they just pretend using them -:) - If we really want to keep "--unused-ok", then we should probably make it less obvious to use for newbies. If an expert knows it exists (which will be mentioned in the docs), then great - use it at your own risk. But for new users it is often the first thing they see when they mis-format they parameter files. - One day running phenix.refine will be matter of running one command or hitting one button with no need to edit any parameters. That will be the day when the *true* automation of refinement won. Pavel. On 5/12/09 5:36 AM, Schubert, Carsten [PRDUS] wrote:
Couple of comments:
I keep seeing people having trouble refining their structures in
phenix.refine just because they were using "-->unused-ok" option.
Well, with every powerful tool come caveats. The unused_ok option is a expert option and if people who have difficulties understanding what they are doing use it and encounter problems then it begs the question why expert users need to suffer the consequences of their inabilities. I use this option often and it is warranted in the current environment in which phenix goes through a lot of revisions, which break compatibility with previous versions, but provide new/better functionality I'd like to use. And yes, if you are doing a couple of structures a day, reediting the parameter file(s) is a serious drag.
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
It is NOT usable in a automation environment. Since phenix goes through so many releases, which change the parameter file and bails by default if the parameter file does not match the current version, automation is difficult to achieve. Correct me if I am wrong, but I believe it would almost be impossible to pick up a previous refinement done with a old phenix version again via an automated approach if the parameter file has changed and phenix bails. Granted I could freeze the phenix version used for automation and could maintain a couple of different versions for different purposes, but that quickly becomes impractical.
So in essence, for the "high-throughput-bleeding-edge-junky-users" the --unsed_ok option is essential and I hope that it remains.
Cheers.
Carsten
_______________________________________________ phenixbb mailing list [email protected] http://www.phenix-online.org/mailman/listinfo/phenixbb
- If we really want to keep "--unused-ok", then we should probably make it less obvious to use for newbies. If an expert knows it exists (which will be mentioned in the docs), then great - use it at your own risk. But for new users it is often the first thing they see when they mis-format they parameter files. I like that idea. - One day running phenix.refine will be matter of running one command or hitting one button with no need to edit any parameters. That will be the day when the *true* automation of refinement won. Lofty goal, will this be reality before I retire? (-: Pavel. On 5/12/09 5:36 AM, Schubert, Carsten [PRDUS] wrote: Couple of comments: I keep seeing people having trouble refining their structures in phenix.refine just because they were using "-->unused-ok" option. Well, with every powerful tool come caveats. The unused_ok option is a expert option and if people who have difficulties understanding what they are doing use it and encounter problems then it begs the question why expert users need to suffer the consequences of their inabilities. I use this option often and it is warranted in the current environment in which phenix goes through a lot of revisions, which break compatibility with previous versions, but provide new/better functionality I'd like to use. And yes, if you are doing a couple of structures a day, reediting the parameter file(s) is a serious drag. 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 It is NOT usable in a automation environment. Since phenix goes through so many releases, which change the parameter file and bails by default if the parameter file does not match the current version, automation is difficult to achieve. Correct me if I am wrong, but I believe it would almost be impossible to pick up a previous refinement done with a old phenix version again via an automated approach if the parameter file has changed and phenix bails. Granted I could freeze the phenix version used for automation and could maintain a couple of different versions for different purposes, but that quickly becomes impractical. So in essence, for the "high-throughput-bleeding-edge-junky-users" the --unsed_ok option is essential and I hope that it remains. Cheers. Carsten _______________________________________________ phenixbb mailing list [email protected] http://www.phenix-online.org/mailman/listinfo/phenixbb
On Wed, 6 May 2009, Bryan W. Lepore wrote:
i used --unused_ok b/c it looks like that's what its for. On Thu, 7 May 2009, Ralf W. Grosse-Kunstleve wrote: I'm going to retire that option when I get a chance since it causes too much confusion. On Fri, 8 May 2009, Schubert, Carsten [PRDUS] wrote:
Could you please NOT do this.
i ought to say that i made my .def edits without too much trouble (simply putting in f' f'' refinement), --unused_ok, things worked perfectly, and the output .def i think covers what was in the old .def. still though, having a one-line phenix version/tag label in the top of the .def would be handy. -bryan
participants (5)
-
Bryan W. Lepore -
Frank von Delft -
Pavel Afonine -
Ralf W. Grosse-Kunstleve -
Schubert, Carsten [PRDUS]