[gmx-developers] looking for co-mentor for GSoC 2020: TNG format

Mark Abraham mark.j.abraham at gmail.com
Mon Mar 23 21:43:50 CET 2020


Hi,

Please note there is extensive doxygen documentation in the code, e.g.
https://github.com/gromacs/tng/blob/master/CMakeLists.txt#L67. But I don't
know of anywhere it was posted online.

MArk

On Mon, 23 Mar 2020 at 21:40, Oliver Beckstein <obeckste at asu.edu> wrote:

> Hello Paul,
>
> On Mar 23, 2020, at 4:17 AM, Paul bauer <paul.bauer.q at gmail.com> wrote:
>
> Hello Oliver,
>
> I can see what I can do for mentoring, but would need to make sure I
> understand the guidelines from GSoC better.
>
>
> https://google.github.io/gsocguides/mentor/
>
> *“**Mentor*: Mentors are people from the community who volunteer to work
> with a student. Mentors provide guidance such as pointers to useful
> documentation, code reviews, etc. In addition to providing students with
> feedback and pointers, a mentor acts as an ambassador to help student
> contributors integrate into their project’s community. Some organizations
> choose to assign more than one mentor to each of their students. Many
> members of the community provide guidance to their project’s GSoC students
> without mentoring in an “official” capacity, much as they would answer
> anyone’s questions on the project’s mailing list or IRC channel.”
>
> https://google.github.io/gsocguides/mentor/what-makes-a-good-mentor
>
> There’s also a 3-4 weeks “community bonding” period in which the selected
> student starts interacting directly with mentors and projects.
> https://google.github.io/gsocguides/mentor/mind-the-gap For the TNG
> project we would need the time to define the milestones clearly (see
> https://google.github.io/gsocguides/mentor/setting-expectations and
> https://google.github.io/gsocguides/mentor/managing-the-plan ) and get
> the student started with the code base, especially as any of the students
> who are applying have only worked on MDAnalysis before.
>
>
> I think having a polished version on TNG would be quite helpful not just
> for core GROMACS but also for our interoperability with other packages, so
> this should definitely be worth my time.
>
>
> That’s good, otherwise I would say “no”.
>
> One thing that concerns me is that we usually have quite a long lag time
> for code contributions coming from external people or new team members, so
> porting the whole code to C++ might not be done in the given time span, but
> it should be possible to get patches at least to the point of being
> reviewed here.
>
>
> I admit to having limited experience in large C/C++ projects so your
> expertise is crucial. My 2 cents would be that in this case I would start
> with a good test suite that passes under the current version and attack the
> project with test-driven development. Would be feasible to start from a
> separate fork of the current TNG repository as a complete rewrite to speed
> up development? If the library is not immediately integrated into Gromacs
> itself then maybe separate development strands for the C and new C++
> version might be ok? But I do defer to how you would want to handle it –
> let me know.
>
> It is a concern if the student has to wait for code reviews for days
> because the student is supposed to work on this specific project for the
> duration of GSoC. Furthermore, we must evaluate the student three times (
> https://google.github.io/gsocguides/mentor/evaluations). If we fail the
> student, they are kicked out (and don’t get paid). If they cannot submit
> work then we cannot evaluate them fairly.
>
> Let's see if this gets chosen in the end!
>
>
> Please have a quick look through my comments above. If you think that this
> remains a feasible project for a student then I’ll put you down as a
> co-mentor (do you have a GitHub username and/or let me know another way to
> reference you, e.g., on the new GitLab installation; please also let me
> know the official TNG repo – is it really https://github.com/gromacs/tng
>  ?)
>
> It’s also ok to say “no thank you” , it might simply not be a perfect fit,
> and then I’d rather have students focus on other projects. We can then see
> if there are other ways to move TNG forward.
>
> Best,
> Oliver
>
>
>
> Cheers
>
> Paul
>
> On 22/03/2020 23:14, Oliver Beckstein wrote:
>
> Hello TNG people,
>
> Apologies for the delayed reply.
>
> My take-away from your comments on the TNG library are:
>
> 1. TNG has all major features defined (although a more polished API might
> be desirable).
> 2. You consider the current C code in  https://github.com/gromacs/tng as
> the reference implementation
> 3. More tests would be welcome.
> 4. At the moment there is no-one who is really looking after the code. (At
> least at a cursory glance, documentation is hard to find;  presumably
> https://github.com/gromacs/tng/blob/master/Trajectoryformatspecification.mk  is
> important as well as the JCC 2014 paper (and the 2011 one). )
> 5. You consider porting the existing C code to C++ would be the next
> important step so that at least Gromacs itself can move towards TNG
> adoption.
>
> We can advertise the project as
>
> 1. Port existing TNG C code to C++
> 2. Write the API documentation  (doxygen strings + minimal example for how
> to use the library)
> 3. Stretch goal: Create a Python wrapper (based on
> https://github.com/MDAnalysis/pytng or other approaches).
>
> Questions:
>
> Is this a realistic plan for a student with no previous experience with
> the specifics but knowledge of C/C++ & python, for May 18 – Aug 10 (~3
> months)?
>
> @Paul: would you be able to co-mentor a student (primarily 1 and 2)?
>
> @Magnus: would you be available for consultations – basically, replying to
> emails on whatever mailing list/issue tracker the conversation will happen?
>
> Would you think that this would be worth everyone’s time? Mentors will be
> involved in choosing students so you won’t get someone that you don’t feel
> is suitable.
>
> There’s no guarantee that this project will be chosen but we would see by
> March 31 (application deadline).
>
>
> Oliver
>
>
>
>
>
> On Mar 19, 2020, at 1:16 AM, Paul bauer <paul.bauer.q at gmail.com> wrote:
>
> Hello,
>
> I concur with Magnus that moving the TNG codebase to C++ would be a major
> win and make integration in e.g. GROMACS even better.
> I can also see that I help with mentoring from the GROMACS side, to help
> with providing a smooth integration process.
>
> Cheers
>
> Paul
>
> On 19/03/2020 09:13, Magnus Lundborg wrote:
>
> Hi,
>
> As the main developer of the TNG API I'm happy to hear about this
> initiative as we needed more hands already from the beginning, and no-one
> has taken the development over since I moved on to other things.
>
> On 2020-03-18 21:17, David van der Spoel wrote:
>
> Den 2020-03-18 kl. 19:20, skrev Oliver Beckstein:
>
> Hello Gromacs Developers,
>
> As part of Google Summer of Code 2020 with MDAnalysis <
> https://www.mdanalysis.org/2020/02/22/gsoc2020/#google-summer-of-code-2020>
> we proposed a project to work on the TNG format. Originally the plan was to
> just make sure that MDAnalysis can work with TNG but after a chat with Erik
> at BPS (and in the spirit of the last MolSSI interoperability workshop) we
> thought that it would be more useful to take a step back and possibly work
> towards finalizing the TNG format <
> https://github.com/MDAnalysis/mdanalysis/wiki/Project-Ideas-2020#project-6-implement-tng-support> with
> the goal to make it usable in any MD analysis code (including MDAnalysis).
> The preliminary objectives would be:
>
>
> Great initiative!
>
>
>  1. Fully define the API and capabilities of TNG.
>
> The existing functionality or would you add stuff that has been disccussed
> for a long time like energies and other data blocks?
>
> As far as I know the API should be complete as it is, but perhaps not as
> polished as would be nice. Adding energies and other data blocks are more a
> matter of adding it in the software packages using the library. The only
> exception is that data block IDs are kept as a central repository in the
> library. But this is just to keep track of them and to avoid ID conflicts.
> As far as I remember, there is in principle nothing that prevents anyone
> from writing anything in TNG.
>
>
>  2. Write documentation.
>  3. Write a reference library implementation (C or C++).
>
> How would that be different from the existing implementation?
>
> Yes, what is the difference between the existing API and library (in C)?
> There are plans to make it more C++ compliant. That could be a good
> project. A full rewrite to proper C++ would be even better. One problem
> since early on was that the API and ABI was promised to be fully backwards
> compatible. That makes a redesign harder and explains some of the "late
> add-ons".
>
>
>  4. Write tests.
>
> There are some functionality tests in the TNG library, but more extensive
> unit tests would of course be good.
>
>  5. Bonus: Write Python bindings (see start in our pytng
>     <https://github.com/MDAnalysis/pytng> library) and integrate with
>     MDAnalysis
>
>
>
> This project outline is not set in stone and we would be more than happy
> to adapt it according to your expert input.
>
> We have at least one promising candidate student who is interested in
> working on this project during 10 weeks this summer.
>
> We would need at least one knowledgable co-mentor from the GROMACS
> developer community who could commit to mentoring. See
> https://google.github.io/gsocguides/mentor/ what is expected of mentors.
> In short, you would be involved in selecting students, communicating with
> the student (primarily using mailing lists and issue trackers) on a
> near-daily basis, help with keeping the project on track, and evaluating
> the student for GSoC (midterm and final evaluation at pass/fail level).
> About 5h/week is a realistic minimum.
>
> I could hopefully clarify some things in the beginning of the project and
> possible during as well, but I'm afraid I cannot promise any regular
> co-mentoring.
>
>
> We completely understand that in the current global crisis, you might have
> more urgent things to do. But if you think that you could be a co-mentor
> for this project, please let us know soon because students have to write
> their applications; their deadline is March 31 but they can submit
> applications now and unless we have a GROMACS co-mentor we will not be
> offering the TNG project so students.
>
> Thank you!
>
> Oliver (for the MDAnalysis GSoC 2020 Mentors)
>
>
>
> --
> Oliver Beckstein, DPhil * oliver.beckstein at asu.edu <
> mailto:oliver.beckstein at asu.edu <oliver.beckstein at asu.edu>>
> https://becksteinlab.physics.asu.edu/
>
> Associate Professor of Physics
> Arizona State University
> Center for Biological Physics and Department of Physics
> Tempe, AZ 85287-1504
> USA
>
> Office: PSF 348
> Phone: +1 (480) 727-9765
> FAX: +1 (480) 965-4669
>
> Department of Physics: https://physics.asu.edu/content/oliver-beckstein
> Center for Biological Physics:
> https://cbp.asu.edu/content/oliver-beckstein
>
>
>
>
>
>
> --
> Paul Bauer, PhD
> GROMACS Development Manager
> KTH Stockholm, SciLifeLab
> 0046737308594
>
> --
> 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.
>
>
>
> --
> Oliver Beckstein, DPhil * oliver.beckstein at asu.edu
> https://becksteinlab.physics.asu.edu/
>
> Associate Professor of Physics
> Arizona State University
> Center for Biological Physics and Department of Physics
> Tempe, AZ 85287-1504
> USA
>
> Department of Physics: https://physics.asu.edu/content/oliver-beckstein
> Center for Biological Physics:
> https://cbp.asu.edu/content/oliver-beckstein
>
>
>
> --
> Paul Bauer, PhD
> GROMACS Development Manager
> KTH Stockholm, SciLifeLab
> 0046737308594
>
> --
> 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.
>
>
>
> --
> Oliver Beckstein, DPhil * oliver.beckstein at asu.edu
> https://becksteinlab.physics.asu.edu/
>
> Associate Professor of Physics
> Arizona State University
> Center for Biological Physics and Department of Physics
> Tempe, AZ 85287-1504
> USA
>
> Department of Physics: https://physics.asu.edu/content/oliver-beckstein
> Center for Biological Physics:
> https://cbp.asu.edu/content/oliver-beckstein
>
> --
> 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://maillist.sys.kth.se/pipermail/gromacs.org_gmx-developers/attachments/20200323/5047f96e/attachment-0001.html>


More information about the gromacs.org_gmx-developers mailing list