[gmx-developers] slightly odd-looking code
jan
rtm443x at googlemail.com
Thu Mar 26 19:52:18 CET 2020
Hi Justin, Pall,
I found the tpr-making procedure in the manual, and am currently going
through the first tutorial.
thanks
jan
On 26/03/2020, Szilárd Páll <pall.szilard at gmail.com> wrote:
> On Thu, Mar 26, 2020 at 2:48 PM jan <rtm443x at googlemail.com> wrote:
>
>> Hi Pall,
>> well I've got it compiled, am reading through the manual while also
>> trying to do as you suggest below and run it.
>>
>> I've downloaded the benchmarks from the FTP site and trying to run
>> them, but there aren't any topol.tpr (or any .tpr) files I can see.
>> Plenty of topol.top so I tried that but it's rejected, saying that
>> only .tpr files are acceptable.
>>
>> I tried renaming a topol.top to topol.tpr just in case but it doesn't
>> like that either, saying something about file input/output error in
>> futil.cpp, and mentions md.log, but it doesn't say where md.log has
>> been put (doesn't seem to be in /var/log where I thought logs went,
>> nor where the fmx executable lives, nor in the directory where the
>> particular benchmark was placed)
>>
>
> Sorry, the benchmark tarballs contained only "raw" inputs, while the mdrun
> tool expects a ".tpr" run input file. A tpr input is generated using the
> gmx grompp tool as a typical preparation step in a GROMACS molecular
> simulation workflow. Hence, you should run gmx grompp (iirc all raw input
> have the default filenames, so no arguments need to be passed) which will
> generate the tpr file.
>
> That said, I do encourage you to go through Justin's tutorial, it is a
> great resource and could help you get an understanding of the typical MD
> workflow.
>
> --
> Szilárd
>
>
>>
>> Any ideas?
>>
>> cheers
>>
>> jan
>>
>>
>> On 23/03/2020, Szilárd Páll <pall.szilard at gmail.com> wrote:
>> > Jan,
>> >
>> > If you want to profile and try to tune performance, I suggest you focus
>> on
>> > the main simulation tool called "mdrun" and in particular its core
>> > functionalities as this is the tool that will be consuming the vast
>> > majority of compute cycles.
>> >
>> > If you are using profiling tools to explore the code, find hot
>> > functions
>> > and such, I suggest that you grab one of the benchmark systems from
>> > here:
>> > http://ftp.gromacs.org/benchmarks/
>> > and run one of those (make sure to pick a "PME" input if there are
>> > multiple).
>> >
>> > And start by running those through a profiler ( e.g. run "gmx mdrun -s
>> > topol.tpr -nsteps 1000" for a 1000-iteration run). If you are
>> > proficient
>> at
>> > profiling tools, you can also drop in manual annotation (or profiler
>> > start/stop) into out internal timer/profiler facilities (see
>> > src/gromacs/timing/wallcycle.cpp).
>> >
>> > Let us know if you have further questions.
>> >
>> > Cheers,
>> > --
>> > Szilárd
>> >
>> >
>> > On Mon, Mar 23, 2020 at 3:36 PM jan <rtm443x at googlemail.com> wrote:
>> >
>> >> Hi, see below
>> >>
>> >> On 23/03/2020, cblau <cblau at gwdg.de> wrote:
>> >>
>> >> [snip]
>> >> >
>> >> > As GROMACS is already highly specialised, it is a bit challenging to
>> >> > speed up quickly (though definitely possible to contribute in
>> >> > meaningful
>> >> > ways).
>> >>
>> >> My initial look is profile then see look at the most basic things such
>> >> as memory hierarchy use. I mean, really basic stuff which you'll
>> >> already have covered but at least it's a learning phase for me.
>> >>
>> >> >
>> >> > With all urgency in mind, there is quite a time-delay in the way new
>> >> > code gets incorporated, because we do very much require scientific
>> >> > correctness and thorough code review to make sure that all
>> >> > simulation
>> >> > results are meaningful and we don't waste a ton of people efforts
>> >> > and
>> >> > compute power on a slight bug.
>> >>
>> >> Is good
>> >>
>> >> >
>> >> > The largest speed up in a short time frame (the next months) is inmy
>> >> > option achieved by teaching people how to use GROMACS in the most
>> >> > efficient ways and make sure that people running simulations run
>> >> > them
>> >> > correctly.
>> >>
>> >> Knowing how to use a tool correctly is best way to get good results. I
>> >> keep seeing the results where this does not happen. So I get you.
>> >> I'll look on the site for reading material but any other pointers
>> >> would help - but bear in mind I'm very new to this, and numerical
>> >> simulation isn't my thing so start simple!
>> >>
>> >> >
>> >> > If you like, we can briefly chat tomorrow on how GROMACS is set up
>> >> > and
>> >> > the "usual ways" to contribute to GROMACS if you send me a personal
>> >> email.
>> >> >
>> >>
>> >> Will do
>> >>
>> >> thanks
>> >>
>> >> jan
>> >>
>> >>
>> >> >
>> >> > Best,
>> >> > Christian
>> >> >
>> >> > On 2020-03-23 14:58, jan wrote:
>> >> >> Hi,
>> >> >> I'm a general back-end dev. Given the situation, and folding at home
>> >> >> using gromacs, I thought I'd poke through the code. I noticed
>> >> >> something unexpected, and was advised to email it here. in
>> >> >> edsam.cpp,
>> >> >> this:
>> >> >>
>> >> >>
>> >> >> void do_linacc(rvec* xcoll, t_edpar* edi)
>> >> >> {
>> >> >> /* loop over linacc vectors */
>> >> >> for (int i = 0; i < edi->vecs.linacc.neig; i++)
>> >> >> {
>> >> >> /* calculate the projection */
>> >> >> real proj = projectx(*edi, xcoll,
>> >> >> edi->vecs.linacc.vec[i]);
>> >> >>
>> >> >>
>> >> >> /* calculate the correction */
>> >> >> real preFactor = 0.0;
>> >> >> if (edi->vecs.linacc.stpsz[i] > 0.0)
>> >> >> {
>> >> >> if ((proj - edi->vecs.linacc.refproj[i]) < 0.0)
>> >> >> {
>> >> >> preFactor = edi->vecs.linacc.refproj[i] - proj;
>> >> >> }
>> >> >> }
>> >> >> if (edi->vecs.linacc.stpsz[i] < 0.0)
>> >> >> {
>> >> >> if ((proj - edi->vecs.linacc.refproj[i]) > 0.0)
>> >> >> {
>> >> >> preFactor = edi->vecs.linacc.refproj[i] - proj;
>> >> >> }
>> >> >> }
>> >> >> [...]
>> >> >>
>> >> >>
>> >> >> In both cases it reaches the same code
>> >> >>
>> >> >> preFactor = edi->vecs.linacc.refproj[i] - proj
>> >> >>
>> >> >> That surprised me a bit, is it deliberate? If so it may be the code
>> >> >> can be simplified anyway.
>> >> >>
>> >> >> That aside, if you're looking for performance I might be able to
>> help.
>> >> >> I don't know the high level stuff *at this point* and my C++ is so
>> >> >> rusty it creaks, but I can brush that up, do profiling and whatnot.
>> >> >> I'm pretty experience, just not in this area. Speeding things up
>> >> >> is
>> >> >> something I've got a track record of (though I usually have a good
>> >> >> feel for the problem domain first, which I don't here)
>> >> >>
>> >> >> Would it be of some value for me to try getting more speed? If so,
>> >> >> first thing I'd need is to get this running under cygwin, which I'm
>> >> >> struggling with.
>> >> >>
>> >> >> regards
>> >> >>
>> >> >> jan
>> >> >>
>> >> > --
>> >> > Gromacs Developers mailing list
>> >> >
>> >> > * Please search the archive at
>> >> > http://www.gromacs.org/Support/Mailing_Lists/GMX-developers_List
>> before
>> >> > posting!
>> >> >
>> >> > * Can't post? Read http://www.gromacs.org/Support/Mailing_Lists
>> >> >
>> >> > * For (un)subscribe requests visit
>> >> >
>> https://maillist.sys.kth.se/mailman/listinfo/gromacs.org_gmx-developers
>> >> or
>> >> > send a mail to gmx-developers-request at gromacs.org.
>> >> >
>> >> --
>> >> Gromacs Developers mailing list
>> >>
>> >> * Please search the archive at
>> >> http://www.gromacs.org/Support/Mailing_Lists/GMX-developers_List
>> >> before
>> >> posting!
>> >>
>> >> * Can't post? Read http://www.gromacs.org/Support/Mailing_Lists
>> >>
>> >> * For (un)subscribe requests visit
>> >> https://maillist.sys.kth.se/mailman/listinfo/gromacs.org_gmx-developers
>> >> or send a mail to gmx-developers-request at gromacs.org.
>> >>
>> >
>> --
>> Gromacs Developers mailing list
>>
>> * Please search the archive at
>> http://www.gromacs.org/Support/Mailing_Lists/GMX-developers_List before
>> posting!
>>
>> * Can't post? Read http://www.gromacs.org/Support/Mailing_Lists
>>
>> * For (un)subscribe requests visit
>> https://maillist.sys.kth.se/mailman/listinfo/gromacs.org_gmx-developers
>> or send a mail to gmx-developers-request at gromacs.org.
>
> --
> Szilárd
>
More information about the gromacs.org_gmx-developers
mailing list