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 <docandreas@gmail.com> wrote:
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
phenixbb@phenix-online.org
http://phenix-online.org/mailman/listinfo/phenixbb