Hi Carsten, the input refinement parameters and the input data (reflections and model) are different things (in sense how they are treated, at least). All PDB files given at input, no matter how they are specified (in command line or in parameter file) are accumulated into one file and then this combined model is used in refinement. It is up to the user to not specify one file multiple times and phenix.refine enforces this by analyzing the clashes. As for parameters, if identical parameters are specified multiple times, the last parameter is actually used. Ralf may have more comments on this. Pavel. Schubert, Carsten [PRDUS] wrote:
Hi,
I have a question / request about parameters defined on the command line vs. defined in the .def file are handled. Specifically the input.pdb.file_name parameter. I noticed that if I have already a input.pdb.file_name defined in the .def file and call phenix.refine with another pdb file, both files are loaded. If both pdb files represent the same protein in different stages of refinement that obviously causes the job to fail due to close non-bonding interactions.
I see how the loading of both pdb files can be a desired feature, but I also recall reading somewhere that command line params take precedence over .def files, which in turn takes precedence over defaults. There seems to be some deviation from that philosophy.
For me this is more a work-flow issue (which becomes important if one does to many structures per day ...) than a bug. I'd really like to minimize the time spend on editing the def file and just define new job parameters from the command line and have the def file fill in the missing bits. This also would help future automation we are implementing, because it would eliminate the need to read and parse an existing .def. file. There are ways around this but not as clean, but that is another matter ....
Would it be possible to implement a switch which would check for duplicate parameters on the command line vs. .def file, give precedence to the command line and run the job like that? That way we would not break the existing scheme, which other people may have already grown accustomed too. Other suggestions are welcome too.
Cheers,
Carsten
------------------------------------------------------------------------
_______________________________________________ phenixbb mailing list [email protected] http://www.phenix-online.org/mailman/listinfo/phenixbb