Hi Tim, Thanks for all the insights that you share with me in your last email. It has been of great help.
On 02.07.2012 21:58, Tim Vandermeersch wrote: > This is in accordance with what I said above. However if you really > want to improve performance a better approach would be to implement > cut-offs using a neighbour list. (There are cut-offs in OBForceField I have a look at the NeighborList algorithm and I agree with you it will be the best strategy for getting a performance improvement. For now, I want to focus on the optimization that I could carry out faster with the less impact in terms of rewriting code. Also because I want to experiment with performance optimization by means of parallelization using the GPU. > > If you care to use large molecules: Currently OBForceField::Setup > pre-calculates Calculation objects for all n^2 atom pairs. A > OBFFVDWCalculationMMFF94 uses 228 bytes and a > OBFFElectrostaticCalculationMMFF94 uses 140 bytes. When there 3000 > atoms, 3000*3000*(228+140) = 3.3 GB which easily throws an out of > memory exception if you only have 4 GB of RAM. For 5000 atoms, 9.2 GB > is needed! (this assumes you use 64-bit and sizeof(double)=8 and > sizeof(int)=4) > This is an important constraint that I need to consider. The whole purpose of using GPU is to be able to offload a huge amount of CPU intensive routines, in other words very large molecules. Otherwise the communication step needed to copy the molecule to the device won't be shadowed by the processing defeating the purpose of using GPU altogether. Taking this into account I started also looking at other CPU-constrained operations in OpenBabel. Martin suggested we first have a look at the conformer generation code (Confab) that you, Noel, Geoff and Chris were working before. In terms of parallelization it looks already very promising because each conformer energy computation can theoretically be handled alone, and even small-sized proteins will generate a respectable amount of conformers to keep the GPU busy. > I started this a while ago but haven't kept it in sync with OB trunk > so if this is used you should make sure to also check the current SVN > trunk code to get bug fixes and other improvemts. It is more modular > though. The force field class should only be concerned with computing > the energy and gradients and provide an API for accessing them. > minimisation etc. should be placed in different classes. > I already have a look and notice you went for a more modular approach. Indeed this is what I will be aiming for. I'm thankful that you guys share this resource with me, because I didn't knew about it, and even if it is not current it will help me as a blueprint to develop the class diagram, understand the dependencies and bootstrap my project. > Cheers, > Tim Cheers, Omar ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ _______________________________________________ OpenBabel-Devel mailing list OpenBabel-Devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openbabel-devel
