GPU acceleration of phenix.real_space_refine?
Hi all, phenix.real_space_refine takes a very long time to run on large systems when using any of the more computationally expensive options (e.g. morphing). I was wondering if there has been any consideration towards optimizing this code (and maybe that of phenix.map_to_model) for GPU acceleration? There is somewhat of a shift occuring in the EM community towards using GPU workstations for data processing - if we could use already purchased capabilities to accelerate model refinement as well that would be a huge bonus. I saw a discussion on the bb from a while back concerning the same question applied to phenix.refine, and the conclusion was that in that case the benefits would be minimal, but I'm not sure whether the same applies to real space operations. Cheers, Oli. PS has there been any consideration of including an option to allow users to supply two half maps at run time, one "work" and one "test" map for cross validation purposes? It is possible to do this with two separate runs right now but having the option integrated would be wonderful.
Hi Oliver, unlike reciprocal-space refinement (phenix.refine), real-space refinement (phenix.real_space_refine) is much easier to parallelize and it will benefit a lot from parallelization. Making use of multiple processors is in my list of things to do. No GPU though. Pavel On 5/24/16 09:28, Oliver Clarke wrote:
Hi all,
phenix.real_space_refine takes a very long time to run on large systems when using any of the more computationally expensive options (e.g. morphing).
I was wondering if there has been any consideration towards optimizing this code (and maybe that of phenix.map_to_model) for GPU acceleration? There is somewhat of a shift occuring in the EM community towards using GPU workstations for data processing - if we could use already purchased capabilities to accelerate model refinement as well that would be a huge bonus.
I saw a discussion on the bb from a while back concerning the same question applied to phenix.refine, and the conclusion was that in that case the benefits would be minimal, but I'm not sure whether the same applies to real space operations.
Cheers, Oli.
PS has there been any consideration of including an option to allow users to supply two half maps at run time, one "work" and one "test" map for cross validation purposes? It is possible to do this with two separate runs right now but having the option integrated would be wonderful.
participants (2)
-
Oliver Clarke
-
Pavel Afonine