<br><br><div class="gmail_quote">On Wed, Feb 15, 2012 at 12:47 PM, David van der Spoel <span dir="ltr"><<a href="mailto:spoel@xray.bmc.uu.se">spoel@xray.bmc.uu.se</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im">On 2012-02-15 18:17, Roland Schulz wrote:<br>
><br>
><br>
> On Wed, Feb 15, 2012 at 9:51 AM, David van der Spoel<br>
</div><div class="im">> <<a href="mailto:spoel@xray.bmc.uu.se">spoel@xray.bmc.uu.se</a> <mailto:<a href="mailto:spoel@xray.bmc.uu.se">spoel@xray.bmc.uu.se</a>>> wrote:<br>
><br>
> On 2012-02-15 15:35, Shirts, Michael (mrs5pt) wrote:<br>
> >> I think it is time to restructure the qmmm, as we will then have<br>
> 6 interfaces:<br>
> >> gaussian, gamess, mopac, molpro orca and molcas.<br>
> >><br>
> >> But because of the differences between input/outut of these qm<br>
> programs, this<br>
> >> may be complicated.<br>
> ><br>
> > This sounds like something more appropriate for 5.0 than 4.6 . . .<br>
><br>
> I felt this coming.<br>
><br>
> So I'll probably make a new branch for this, and then do some cleaning<br>
> in the qmmm interface as well.<br>
><br>
> It's probably better to base it off the master branch then, I assume?<br>
><br>
><br>
> I would think that any restructuring in the master branch should use a<br>
> C++ class approach. E.g. in this case having one QM base class and a<br>
> subclass for each of the QM interfaces might be a good approach.<br>
><br>
> If you restructure the current C approach than this would be double<br>
> effort if someone else than needs to redo it to move it to C++.<br>
><br>
> Roland<br>
<br>
<br>
</div>Do we have a template cpp file somewhere?<br></blockquote><div><br></div><div>I'm not sure I understand the questions right. I'm trying to answer it very generic: </div><div><br></div><div>I don't think it would be possible. The design of the class hierarchy and and how to design the interface of a module depends on the problem it should solve and can't be copied from a different (set of) module(s). </div>
<div>On the other hand it is of course possible to learn from examples. In this case I would suggest to look at the design of the TrajectoryAnalysisModule (analysismodule.h) base-class and its subclasses (modules folder). It is an example of how one can design a abstract module type (would be the generic interface to any QM module) and then implement specific modules for different tasks (would be each specific QM interface).</div>
<div><br></div><div>Roland</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="HOEnZb"><div class="h5"><br>
<br>
--<br>
David van der Spoel, Ph.D., Professor of Biology<br>
Dept. of Cell & Molec. Biol., Uppsala University.<br>
Box 596, 75124 Uppsala, Sweden. Phone: <a href="tel:%2B46184714205" value="+46184714205">+46184714205</a>.<br>
<a href="mailto:spoel@xray.bmc.uu.se">spoel@xray.bmc.uu.se</a> <a href="http://folding.bmc.uu.se" target="_blank">http://folding.bmc.uu.se</a><br>
--<br>
gmx-developers mailing list<br>
<a href="mailto:gmx-developers@gromacs.org">gmx-developers@gromacs.org</a><br>
<a href="http://lists.gromacs.org/mailman/listinfo/gmx-developers" target="_blank">http://lists.gromacs.org/mailman/listinfo/gmx-developers</a><br>
Please don't post (un)subscribe requests to the list. Use the<br>
www interface or send it to <a href="mailto:gmx-developers-request@gromacs.org">gmx-developers-request@gromacs.org</a>.<br>
<br>
<br>
<br>
<br>
</div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br>ORNL/UT Center for Molecular Biophysics <a href="http://cmb.ornl.gov">cmb.ornl.gov</a><br>865-241-1537, ORNL PO BOX 2008 MS6309<br>