[gmx-developers] How can use GROMACS into applications - Better way

Wed Sep 4 21:41:47 CEST 2013

Mark and Jeff,

Thanks. I really appreciated your comments.

Best regards,

--
Rodrigo Antonio Faccioli, Ph.D
Intelligent System in Structural Bioinformatics
University of Sao Paulo - USP
Barao de Maua University
Curriculum Lattes - http://lattes.cnpq.br/1025157978990218
Public Profile - http://br.linkedin.com/pub/rodrigo-faccioli/7/589/a5
Personal Blogg - http://rodrigofaccioli.blogspot.com/

On Tue, Aug 27, 2013 at 9:48 AM, Mark Abraham <mark.j.abraham at gmail.com>wrote:

> On Fri, Aug 23, 2013 at 4:41 PM, Rodrigo Faccioli
> <rodrigo_faccioli at uol.com.br> wrote:
> > Hi Mark,
> >
> > Thanks your answer.
> >
> > We are glad to contribute with Gromacs. We would like to try to do it.
>
> Great - but welcome to an uphill battle! :-)
>
> > What do you suggest for us about rules to contribute with Gromacs?
>
> Tough one. Anything new should only consider master branch, and be
> prepared for considerable volatility in the core of mdrun over the
> next few months. And the 5.0 beta will be out December 1 ;-) Work not
> done in time for due process for that beta date won't go in 5.0. I
> don't care how many Nobel Prizes you have!
>
> We're currently feeling our way through the C++ transition, without
> having done much changing of code yet. The coding guidelines you can
> find on the web are pretty accurate. We're using at C++98 plus a
> little bit of Boost for a bit better support for smart pointers and
> exceptions (see src/external/boost/boost). Feel free to use virtual
> functions and templates when they add value, but make sure you know
> what that value is! Acceptable coding style is pretty much as you see
> master branch now - files with .cpp extension are a good guide to how
> we expect written-as-C++ code to look and work and be documented with
> Doxygen. But if stuff still in C has to be changed, do your best to
> conform with the code around it. There's a code beautification
> solution implemented with a custom version of uncrustify. Ask if that
> becomes an issue.
>
> > I have read in Developers zone at Gromacs site about Gerrit and Git. It
> is
> > the best way?
>
> Yeah, that's the best there is. I'd like to write a better developer's
> manual, but I don't have time to do so. Might have some once the beta
> is out ;-)
>
> On mechanics, what Jeff said is pretty accurate. If you just want to
> leap in and fix something, then with a registered OpenID you can
> upload a patch directly to Gerrit. You would probably want to discuss
> your proposition here or on a suitable Redmine issue first.
> Development is somewhat distributed and discussions fairly open,
> except that there is a core team of people here in Stockholm & Uppsala
> who do run some tighter communication loops.
>
> >From the above, I'm guessing the workflow you are trying to streamline
> is "decide on the kind of child GROMACS calculation you want to run,
> set that up, and run that." So, constructing an .mdp, calling grompp,
> and calling mdrun. That could be streamlined in two ways:
> * structuring grompp so that you could call a function with a string
> containing your ".mdp file," and
> * structuring the new gmx executable so that one could call something
> like "gmx grompp -f foo -c bar -p fizz -end mdrun -np 16 -rerun
> whatever" and have that idiom skip writing and reading the .tpr file
> Both of those seem to me reasonably solvable problems that will be
> pretty orthogonal to other things that are going on, if someone (you!)
> is keen to prioritise them.
>
> Neither case is going to fix needing to call GROMACS in a sub-process,
> rather than as a true library call, because the assumption that we can
> exit from a fatal error is everywhere. grompp and mdrun feel free to
> issue fatal errors any time there's an unrecoverable problem (e.g.
> broken input, or valid input leading to a broken simulation). There
> are wrapper functions like gmx_fatal() that issue the actual fatal
> errors, so there is a decent chance for solving that problem.
> Obviously, throwing an exception in gmx_fatal() and catching it very
> close to the end of main() could be made to work. However, we would be
> concerned about any run-time cost from an exception that could be
> thrown from inside the main MD loop. I'm no expert on how compilers
> implement exception handling these days, but we'd have to be very
> confident that normal execution would be unaffected on (at least)
> recent gcc, icc, clang, MSVC (and we'd test various other HPC
> compilers, too).
>
> Cheers,
>
> Mark
>
> > Best regards,
> >
> >
> >
> > --
> > Rodrigo Antonio Faccioli
> > Ph.D Student in Electrical Engineering
> >
> > University of Sao Paulo - USP
> > Engineering School of Sao Carlos - EESC
> > Department of Electrical Engineering - SEL
> > Intelligent System in Structure Bioinformatics
> > http://laips.sel.eesc.usp.br
> > Phone: 55 (16) 3373-9366 Ext 229
> >
> > Curriculum Lattes - http://lattes.cnpq.br/1025157978990218
> > Public Profile - http://br.linkedin.com/pub/rodrigo-faccioli/7/589/a5
> >
> >
> > On Wed, Aug 21, 2013 at 5:04 AM, Mark Abraham <mark.j.abraham at gmail.com>
> > wrote:
> >>
> >> Hi,
> >>
> >> Thanks for your interest. Unfortunately, there's never really been a
> >> callable API for GROMACS. The core team has always prioritized higher
> >> performance and new features over facilitating third-party code re-use
> >> - manpower resources are limiting. There's hope we can improve this in
> >> the future during the C++ transition... e.g.
> >> http://redmine.gromacs.org/issues/988,
> >> http://redmine.gromacs.org/issues/1140.
> >>
> >> In particular, http://redmine.gromacs.org/issues/1170 suggests being
> >> able to remove the "middle man" of writing a .tpr file. It sounds like
> >> your use case would be streamlined a lot if it were possible to pass
> >> "grompp" whatever inputs are easily constructed by your code, and the
> >> output of "grompp" are data structures ready for "mdrun." mdrun in 5.0
> >> might support this already, which would be useful for you, but not yet
> >> ideal.
> >>
> >> If you'd like to contribute, that would be fantastic. A sketch in
> >> http://redmine.gromacs.org/issues/1140 of a series of hypothetical
> >> function calls you'd like to make in order to execute your workflow
> >> would be a great start. Having an external need described should help
> >> us prioritise what we can do.
> >>
> >> Cheers,
> >>
> >> Mark
> >>
> >> On Tue, Aug 20, 2013 at 9:04 PM, Rodrigo Faccioli
> >> <rodrigo_faccioli at uol.com.br> wrote:
> >> > Hi Gromacs Developers,
> >> >
> >> > We have worked in a framework that uses Evolutionary Algorithms (EA)
> >> > with
> >> > GROMACS. This frameword is called ProtPred-Gromacs (2PG) [1].
> >> >
> >> > In general lines, GROMACS is used to compute the objetives of
> individual
> >> > (protein conformation). Potential, Van der Waals, Electrostatic, GBSA
> >> > Solvatation, Hydrophobic, Hydrophilic, Gyrate and Hydrogen Bonds are
> >> > examples of objetives.
> >> >
> >> > Nowadays, those objetives are computed by scripts that calls the
> >> > respective
> >> > GROMACS program for each objective.  I call a system command and load
> >> > the
> >> > GROMACS program output into my structure.
> >> >
> >> > I would like to know a way that is possible to remove those scripts. I
> >> > have
> >> > read about C++ transition at GROMACS page [2]. However, I could not
> >> > understand how I can use it in my project.
> >> >
> >> > Therefore, I would like to ask some examples, tips or any other
> comments
> >> > about a way to remove the scripts and I get the objetives with more
> >> > performance.
> >> >
> >> > [1] http://lcrserver.icmc.usp.br/projects/2pg
> >> > [2]
> >> >
> http://www.gromacs.org/index.php?title=Developer_Zone/C%2b%2b_Transition
> >> >
> >> > Best regards,
> >> >
> >> > --
> >> > Rodrigo Antonio Faccioli, Ph.D
> >> > Intelligent System in Structural Bioinformatics
> >> > University of Sao Paulo - USP
> >> > Barao de Maua University
> >> > Curriculum Lattes - http://lattes.cnpq.br/1025157978990218
> >> > Public Profile - http://br.linkedin.com/pub/rodrigo-faccioli/7/589/a5
> >> > Personal Blogg - http://rodrigofaccioli.blogspot.com/
> >> >
> >> >
> >> > --
> >> > gmx-developers mailing list
> >> > gmx-developers at gromacs.org
> >> > http://lists.gromacs.org/mailman/listinfo/gmx-developers
> >> > Please don't post (un)subscribe requests to the list. Use the
> >> > www interface or send it to gmx-developers-request at gromacs.org.
> >> --
> >> gmx-developers mailing list
> >> gmx-developers at gromacs.org
> >> http://lists.gromacs.org/mailman/listinfo/gmx-developers
> >> Please don't post (un)subscribe requests to the list. Use the
> >> www interface or send it to gmx-developers-request at gromacs.org.
> >
> >
> >
> > --
> > gmx-developers mailing list
> > gmx-developers at gromacs.org
> > http://lists.gromacs.org/mailman/listinfo/gmx-developers
> > Please don't post (un)subscribe requests to the list. Use the
> > www interface or send it to gmx-developers-request at gromacs.org.
> --
> gmx-developers mailing list
> gmx-developers at gromacs.org
> http://lists.gromacs.org/mailman/listinfo/gmx-developers
> Please don't post (un)subscribe requests to the list. Use the
> www interface or send it to gmx-developers-request at gromacs.org.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://maillist.sys.kth.se/pipermail/gromacs.org_gmx-developers/attachments/20130904/33823185/attachment.html>