Hi, The near-silence has been deafening, so these issues are regarded as closed. Anybody wanting a significant deviation from that plan will find the onus on them to do the work! :-)
Cheers, Mark On Wed, Aug 14, 2013 at 5:06 PM, Mark Abraham <mark.j.abra...@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@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-requ...@gromacs.org. * Can't post? Read http://www.gromacs.org/Support/Mailing_Lists
