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

Tue Aug 27 14:48:31 CEST 2013

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.