[gmx-developers] building gmx-mopac is quite tedious... why ?

[torbenh]

On Tue, Jul 20, 2010 at 09:50:37PM +0200, Michael Banck wrote:
> Hi,
> 
> On Tue, Jul 20, 2010 at 09:05:45PM +0200, ggroenh at gwdg.de wrote:
> > I did not think we can distribute along with gromacs. But if you think we
> > can, and you feel taking up this task, I and many other will be very
> > grateful.
>  
> As Mopac is Public Domain, it should not be a problem.  However, why not
> use the mopac7 library as provided by the SourceForge project
> (http://sourceforge.net/projects/mopac7/)?  If the interface does not
> suite you, maybe the maintainer (who is not the original author) might
> consider changing it.

i have used that codebase from sourceforge...
didnt really look at the code yet, but the gmxmop.f exchanges a few
functions, to make mopac see what is happening inside the gromacs model.

http://hochstrom.endofinternet.org/cgit/mopac7.git/tree/fortran/gmxmop.f?h=gmxmop-clean

so the library api would need some kind of hook infrastructure.
i am no fortran guy. and considering that the sourceforge project seems
to be inactive, i guess we are fine with the current method of just
hijacking some subroutines.

i removed all the f2c stuff, and changed the name of the library to
libgmxmopac7.so (so it doesnt clash with the normal one that debian
installs)

http://hochstrom.endofinternet.org/cgit/mopac7.git/log/?h=gmxmop-clean
http://hochstrom.endofinternet.org/cgit/gromacs.git/log/?h=libgmxmop

git://hochstrom.endofinternet.org/mopac7  (branch: gmxmop-clean)
git://hochstrom.endofinternet.org/gromacs (branch: libgmxmop)

the master branches are the original codebases.

changed the gromacs configure.ac to detect libgmxmopac7
adding it to $LIBS is a bit ugly, but since i still need to figure out
how to use gromacs properly, i cant really check if things are correct.
which is a precondition for "giving this stuff a bit more love".


-- 
torben Hohn