[gmx-users] plans for mdrun features to deprecate in GROMACS 5.0

[rajat desikan]

I am interested in Generalized Born. My coding skills are limited, but I
would like to help to whatever extent I can.
I am also interested in helping towards revamping the tutorials if the need
should arise.


On Wed, Aug 14, 2013 at 8:36 PM, Mark Abraham <mark.j.abraham at gmail.com>wrote:

> Hi gmx-users and gmx-developers,
>
> There are a number of features of GROMACS that we plan to drop for 5.0
> (scheduled for early 2014). We don’t like doing this, but if things
> are broken or cause developers pain, then they will go unless there is
> manpower to support them. We’d like to keep you informed and hear how
> much pain any of this might cause. Some features will be dropped
> entirely, and others are likely to be reduced to explicit support only
> for some cases. Some discussion has already occurred here
> http://redmine.gromacs.org/issues/1292.
>
> Things we plan to drop entirely:
> * particle decomposition (see below)
> * current QM support (this will be dropped, work on a replacement is
> underway, planned for 5.0)
> * writing of pair distance and/or time-averaged pair distance to
> energy files during simulations with position/orientation restraints
> * reaction-field-nec
> * Encad-shift
> * mdrun -ionize
> * GCT
> * mdrun -seppot
> * mdrun -ffscan
> * OpenMM support
>
> There are several algorithms (e.g. fancy kinds of restraints) that
> have only ever worked with particle decomposition (if they work at
> all...). We plan to support these only in serial.
>
> Things that will likely only work in serial (ie. single-domain DD):
> * ensemble- and time-averaged distance restraints
> * L-BFGS energy minimization
> * Generalized Born
>
> In some cases, “in serial” might mean “in parallel (with DD) with an
> extra communication stage that will make it work, but might scale
> poorly.” Or “in parallel but if things diffuse too far, the simulation
> will crash.” If you have working examples of any of the above in
> parallel, we would be most interested to hear from you. We’d like to
> construct test cases that show what works now, so that later if we are
> able to support some kind of parallelism, we can show that it still
> works.
>
> Things that won’t support constraints (because the implementations are
> broken or missing):
> * L-BFGS energy minimization
> * MTTK pressure coupling
>
> As always, what goes into GROMACS depends on people putting the work
> in. If something above would affect you, then do speak up.
> Contributions of working test cases are particularly valuable, but in
> the end you might have to be the one to write the code to make the
> test pass. You will have the option of continuing to use old code,
> too!
>
> Cheers,
>
> Mark
> --
> gmx-users mailing list    gmx-users at gromacs.org
> http://lists.gromacs.org/mailman/listinfo/gmx-users
> * Please search the archive at
> http://www.gromacs.org/Support/Mailing_Lists/Search before posting!
> * Please don't post (un)subscribe requests to the list. Use the
> www interface or send it to gmx-users-request at gromacs.org.
> * Can't post? Read http://www.gromacs.org/Support/Mailing_Lists
>



-- 
Rajat Desikan (Ph.D Scholar)
Prof. K. Ganapathy Ayappa's Lab (no 13),
Dept. of Chemical Engineering,
Indian Institute of Science, Bangalore