From: Tim V. <tim...@gm...> - 2010-02-22 15:27:38
|
Hi, On Thu, Feb 18, 2010 at 2:57 AM, Geoffrey Hutchison <ge...@ge...> wrote: >> Is this what you have in mind? > > Yes, exactly. > >> I think I can contribute to steps 1-4, but my knowledge about Avogadro internals is very limited. > > Steps 1-4 would be greatly appreciated by many people. Packmol is easy to use, but of course, students (and others) may want a simple dialog. I'm also interested in having a packmol extension. I have written down some ideas on the wiki: http://avogadro.openmolecules.net/wiki/To_Do_for_1.1 Feel free to contact me if there are other people who want to work on this. >> A question is, what next? The need for periodic boundary conditions, discussed earlier in this thread I believe, rises again. > > That's my problem, right? I need to create support for periodic boundaries in the Open Babel force fields. I know the basics of how to do it, but it's a matter of sitting down and doing the work: > 1) Need to check for a unit cell before setting up the force field calculations. > 2) If so, check if the space group calls for symmetric atoms. > 3) Replicate the atoms across neighboring unit cells. > 4) When moving atoms, consider if they move across a unit cell boundary. > > And then, I need to do a lot of testing. :-_ > > Right now in Avogadro, the unit cell support is simply for display. It has no effect on calculations. We haven't even gone far enough to send unit cells to computational packages that support them (e.g., Gaussian and MOPAC). Adding periodic boundary conditions to OpenBabel is possible but would require some work and a lot of testing. This has been requested before though and I/we could always give it a try... However, I personally don't see the point of adding PBC to OpenBabel as long as we keep a structure for all non-bonded interactions. This just doesn't scale. Once this is solved I would add a simple abstract class which abstracts away the computation of non-bonded distances. The implementation could just return the distance, the distance taking PBC into account or use a neighborlist. The next step would be to adjust the algorithms (minimizations) to translate molecules back in the box if they get out. Towards the future and OB 3.0, I think using OpenMM would be an excellent option. By using OpenMM atom typing and parameter assignment is still done in OB but the actual computational terms are provided by OpenMM. This would allow us to have support for GPU hardware without worrying to much about the low level stuff. An additional benefit would be features like periodic boundary conditions, PME, ... OpenMM is still a young project and a fast CPU implementation doesn't really exist yet. There is the reference CPU implementation but this is optimized for correctness. OpenCL might provide the solution for this once there is a good OpenCL CPU implementation. There already is a gromacs port that uses OpenMM although it only has one integrator algorithm for MD and no minimization. Cheers, Tim > Hope that helps, > -Geoff > ------------------------------------------------------------------------------ > Download Intel® Parallel Studio Eval > Try the new software tools for yourself. Speed compiling, find bugs > proactively, and fine-tune applications for parallel performance. > See why Intel Parallel Studio got high marks during beta. > http://p.sf.net/sfu/intel-sw-dev > _______________________________________________ > Avogadro-Discuss mailing list > Avo...@li... > https://lists.sourceforge.net/lists/listinfo/avogadro-discuss > |