On Thu, Feb 18, 2010 at 2:57 AM, Geoffrey Hutchison
Is this what you have in mind?
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:
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:
- Need to check for a unit cell before setting up the force field calculations.
- If so, check if the space group calls for symmetric atoms.
- Replicate the atoms across neighboring unit cells.
- 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.
Hope that helps,
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.
Avogadro-Discuss mailing list