<html><head><meta http-equiv="Content-Type" content="text/html charset=windows-1252"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div><br></div>Hi,&nbsp;<div><br></div><div>well …&nbsp;</div><div><br></div><div>You might have guest yourself that dropping the particle decomposition is a problem for me since I took the time to fill up a report on a bug that I explain quite substantially how and why it was a problem.</div><div><br></div><div>pd remains the only manner to run a system with <i><b>unusual</b></i> bonded terms that span a large part of the box. dd and dlb simply do not go through and there is then no way to run the system.&nbsp;</div><div><br></div><div>I used pd in a few application where the relative orientation of proteins were restrains using distance, angle and dihedral angles. the restrains were subsequently treated using a 6d-wham algorithm to obtain the PMF … I guess this won't be possible anymore … very very very sad!</div><div><br></div><div>While using coarse grain model pd was also often the only solution to run a system during the equilibration. It was never clear why but non-equilibrated system have severe trouble to run using dd.&nbsp;</div><div><br></div><div>to conclude removing particle decomposition is a disaster.</div><div><br></div><div>XAvier.</div><div><br><div><div>On Sep 10, 2013, at 10:35 PM, Mark Abraham &lt;<a href="mailto:mark.j.abraham@gmail.com">mark.j.abraham@gmail.com</a>&gt; wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite">Hi,<br><br>The near-silence has been deafening, so these issues are regarded as<br>closed. Anybody wanting a significant deviation from that plan will<br>find the onus on them to do the work! :-)<br><br>Cheers,<br><br>Mark<br><br>On Wed, Aug 14, 2013 at 5:06 PM, Mark Abraham &lt;<a href="mailto:mark.j.abraham@gmail.com">mark.j.abraham@gmail.com</a>&gt; wrote:<br><blockquote type="cite">Hi gmx-users and gmx-developers,<br><br>There are a number of features of GROMACS that we plan to drop for 5.0<br>(scheduled for early 2014). We don’t like doing this, but if things<br>are broken or cause developers pain, then they will go unless there is<br>manpower to support them. We’d like to keep you informed and hear how<br>much pain any of this might cause. Some features will be dropped<br>entirely, and others are likely to be reduced to explicit support only<br>for some cases. Some discussion has already occurred here<br><a href="http://redmine.gromacs.org/issues/1292">http://redmine.gromacs.org/issues/1292</a>.<br><br>Things we plan to drop entirely:<br>* particle decomposition (see below)<br>* current QM support (this will be dropped, work on a replacement is<br>underway, planned for 5.0)<br>* writing of pair distance and/or time-averaged pair distance to<br>energy files during simulations with position/orientation restraints<br>* reaction-field-nec<br>* Encad-shift<br>* mdrun -ionize<br>* GCT<br>* mdrun -seppot<br>* mdrun -ffscan<br>* OpenMM support<br><br>There are several algorithms (e.g. fancy kinds of restraints) that<br>have only ever worked with particle decomposition (if they work at<br>all...). We plan to support these only in serial.<br><br>Things that will likely only work in serial (ie. single-domain DD):<br>* ensemble- and time-averaged distance restraints<br>* L-BFGS energy minimization<br>* Generalized Born<br><br>In some cases, “in serial” might mean “in parallel (with DD) with an<br>extra communication stage that will make it work, but might scale<br>poorly.” Or “in parallel but if things diffuse too far, the simulation<br>will crash.” If you have working examples of any of the above in<br>parallel, we would be most interested to hear from you. We’d like to<br>construct test cases that show what works now, so that later if we are<br>able to support some kind of parallelism, we can show that it still<br>works.<br><br>Things that won’t support constraints (because the implementations are<br>broken or missing):<br>* L-BFGS energy minimization<br>* MTTK pressure coupling<br><br>As always, what goes into GROMACS depends on people putting the work<br>in. If something above would affect you, then do speak up.<br>Contributions of working test cases are particularly valuable, but in<br>the end you might have to be the one to write the code to make the<br>test pass. You will have the option of continuing to use old code,<br>too!<br><br>Cheers,<br><br>Mark<br></blockquote>--<br>gmx-developers mailing list<br><a href="mailto:gmx-developers@gromacs.org">gmx-developers@gromacs.org</a><br>http://lists.gromacs.org/mailman/listinfo/gmx-developers<br>Please don't post (un)subscribe requests to the list. Use the<br>www interface or send it to gmx-developers-request@gromacs.org.<br></blockquote></div><br></div></body></html>