Hello,

I am Adarsh, a senior student from Indian Institute of Technology Madras,
and will be joining Johns Hopkins University this fall for my Masters in
Materials Science and Engineering. I am working on bringing support for
reading and analysing Molecular Dynamics trajectories in Avogadro as part
of Google Summer of Code 2018. I thought I shall use this opportunity to
share my work and what I have in my mind to implement in the next couple of
weeks.

So far, I have written readers for some of the most common MD trajectory
formats:

   - LAMMPS dump,
   - trr (GROMACS),
   - dcd (CHARMM, OpenMM etc.)

Support for reading xyz trajectories already exists.
I will be working on enhancing the player tool to add more functionality
like easy navigation from one frame to another, better support for media
export and shall explore avenues for performance improvements. I shall also
be working on tools for analysing common MD parameters like differential
displacement, energy evolution, RMSD etc.

As of now, a couple of bottlenecks have sprung to my mind that require
appropriate addressal:

   - Many of the trajectories do not provide information about the
   elements. Some of the formats stick to the literal sense of trajectory, by
   having only the positions and the velocities. If the system is small, the
   Custom Element Mapping tool can be used to manually assign the elements.
   But to account for systems with large number of atoms, I have planned to
   include a build option to assign custom elements from file. For example, in
   case of reading a GROMACS trr trajectory, one can use this tool to import a
   .gro file to get information about the constituent elements. This is also a
   way to make use of the power of OpenBabel's readers if needed!
   - Many of the trajectories are huge in size and require sufficient
   memory to store all of the coordinate sets. I still am not sure of how to
   address this: more intelligent use of file pointers is required, perhaps
   like dynamically navigating to timesteps under current focus instead of
   storing all of it in memory. This also requires me to think about the
   tradeoffs involved: efficient reading vs efficient storage.

Now that I've given a brief overview of the project, I would like to hear
from you, as to

   - What else you would like to see with respect to analyzing MD
   trajectories: trajectory tools, additional analysis tools, media exports
   etc.
   - What other trajectory file formats you would like to see support for
   - What solutions / suggestions you have in mind to address some of the
   bottlenecks

Looking forward to your valuable comments!

Thanks,
Adarsh
-- 
Adarsh Balasubramanian
Fourth year Undergraduate
Department of Metallurgical and Materials Engineering
IIT Madras
Chennai - 600036
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Avogadro-devel mailing list
Avogadro-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/avogadro-devel

Reply via email to