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