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

[Schubert, Carsten [PRDUS]]

- 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
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/20090513/7b583690/attachment-0003.htm>