[gmx-developers] slightly odd-looking code
jan
rtm443x at googlemail.com
Thu Mar 26 14:48:06 CET 2020
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)
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.
>>
>
More information about the gromacs.org_gmx-developers
mailing list