Hi Andreas,
The --dry_run flag is designed to evaluate a phenix.refine run,
and admittedly I never tested that with phenix.den_refine. That test is
checking for valide phenix.refine parameters, and your inputs would check
out fine.
In the absence of a parameter file, the den_refine routine makes the
necessary changes to the default scheme (one macrocycle, assures positional
refinement is active, etc.), but a phenix.refine parameter file would
overwrite these and could lead to the catches that you're seeing.
I'll try to make the --dry-run flag work more sensibly with
phenix.den_refine.
Jeff
On Tue, Jun 11, 2013 at 1:21 PM, Andreas Förster
Ok, that's fine - and it's running now. But I had to fix a number of other things: enable positional refinement, one macrocycle only...
When I run phenix.den_refine --dry_run, aren't these inconsistencies and missed requirement supposed to be caught, or do I misunderstand things?
Andreas
On 11/06/2013 5:37, Jeff Headd wrote:
In phenix.refine you control simulated annealing that way, but phenix.den_refine is a specialized protocol which takes advantage of much of the phenix.refine machinery while controlling most things through the 'den' scope. It's a bit of a hack, but it was the fastest way to pull a prototype together. You'll definitely have annealing cycles without turning them on in the main scope, so long as 'den' is selected as a strategy (which is is by default).
If you ran the main version of simulated annealing you would add annealing cycles which didn't take avantage of the DEN network update steps, which is counter to how each cycle is meant to run.
Jeff
-- Andreas Förster, Research Associate Paul Freemont & Xiaodong Zhang Labs Department of Biochemistry, Imperial College London http://www.msf.bio.ic.ac.uk ______________________________**_________________ phenixbb mailing list [email protected] http://phenix-online.org/**mailman/listinfo/phenixbbhttp://phenix-online.org/mailman/listinfo/phenixbb