Hi,<br><br>there are some autogeneration tools available like<br><a href="http://nedbatchelder.com/code/cog/">http://nedbatchelder.com/code/cog/</a><br><a href="http://www.gnu.org/software/autogen/">http://www.gnu.org/software/autogen/</a><br>
<br>or one could use more macro/preprocessor.<br><br>I doubt that one can write a generator which is easy to understand and which writes all kernels. But may be using some generation to reduce the total number of files is possible.<br>
<br>Roland<br><br><div class="gmail_quote">On Thu, Sep 3, 2009 at 1:07 PM, Erik Lindahl <span dir="ltr"><<a href="mailto:lindahl@cbr.su.se">lindahl@cbr.su.se</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Hi,<div class="im"><br>
<br>
On Sep 3, 2009, at 3:18 AM, Roland Schulz wrote:<br>
<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
I fixed it in the release branch (thus it will be in 4.0.6).<br>
<br>
How is one supposed to change the kernels in the head branch? Is there some script to generate the generic kernels? The output of mknb -fortran --ppc_invsqrt is different than what is in nb_kernel_power6. So changing something in nb_kernel_power6 requires to change each file?<br>
</blockquote>
<br></div>
Uhm... I *think* I generated them with the mknb, but I might have changed something in the generator since.<br>
<br>
One of the main reasons for abandoning mknb is that it should at least be possible to implement a new interaction by simply copying-and-changing a routine, rather than first having to understand a stupid meta-language. So, while we could of course try to extend/modify it, that would just put us back in the same position if all changes *have* to be incorporated in mknb.<br>
<br>
While it's a neat idea to have a single generator to write exactly the code we need for every single architecture, it will probably turn into a maintenance nightmare in the long run, in particular since the present version of mknb is a horrible hack I wrote years ago. I'd be quite interested in good suggestions, in particular since we're preparing an overhaul of the nonbonded kernels to enable more features like analytic switch/shift, kernels that only compute potentials (=speedup!), etc.<br>
<br>
<br>
Cheers,<br>
<br>
Erik<div class="im"><br>
_______________________________________________<br>
gmx-developers mailing list<br>
<a href="mailto:gmx-developers@gromacs.org" target="_blank">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></div>
Please don't post (un)subscribe requests to the list. Use thewww interface or send it to <a href="mailto:gmx-developers-request@gromacs.org" target="_blank">gmx-developers-request@gromacs.org</a>.<br>
</blockquote></div><br><br clear="all"><br>-- <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>