[gmx-developers] dssp

[Mark Abraham]

That would certainly be one way around the problem! :-) Feel free!

Mark
On Jul 9, 2013 9:14 AM, "Alexey Shvetsov" <alexxy at omrb.pnpi.spb.ru> wrote:

> Hi all!
>
> I had some plans about writing dssp tool for gromacs using c++ gromacs api
> for it, is it still needed?
>
> Mark Abraham писал 09-07-2013 00:28:
>
>> Gert and I have had some discussion off list. DSSP is available under
>> the Boost license, which is probably fine to work with LGPLv2.1 (but I
>> haven't looked into details). It turns out the DSSP webpage was in
>> need of an update - the new source is indeed freely available. It's
>> under 100K, too, so that could be acceptable IMO.
>>
>> Unfortunately, it requires C++0x and four link-time Boost libraries,
>> which is rather beyond the planned requirements for GROMACS 5.0 (C++98
>> and very limited include-only Boost libraries). In theory, we could
>> detect all that (or just try it and see) to do an optional internal
>> build of dssp, but I think there are probably too few users with all
>> the dependencies satisfied who want do_dssp and who would otherwise
>> have generated email traffic through being unable to download a binary
>> or set an environment variable.
>>
>> Debian and Gentoo have new-generation dssp pacakges, so it is
>> reasonable to add the couple of lines of CMake detection for the dssp
>> or mkdssp executables in the obvious places, rather than hard-code
>> /opt/local/bin/dssp (or whatever we do now). We could have a CMake
>> option (off by default) to download and install a dssp binary, but I'm
>> not very keen on that.
>>
>> Mark
>>
>>
>> On Mon, Jul 8, 2013 at 5:32 PM, Mark Abraham <mark.j.abraham at gmail.com>
>> wrote:
>>
>>> Hi Gert, cc gmx-developers,
>>>
>>> We do feel your pain - we get such emails too!
>>>
>>> Our do_dssp tool requires the user either install dssp as
>>> /usr/local/bin/dssp, or set the DSSP environment variable to point at
>>> the installed dssp binary. This is one source of problems - users
>>> often aren't savvy enough to do either correctly. Another source of
>>> problems has been the change of invocation syntax with newer versions
>>> of dssp. Installations of GROMACS 4.5 and earlier cannot cope with the
>>> newer syntax if that's what is used by the dssp that the user has
>>> installed. Unfortunately we can't do anything about that
>>> retrospectively.
>>>
>>> GROMACS 4.6 supports both dssp syntaxes, and defaults to using the new
>>> syntax. This causes problems if they have an old dssp, but that
>>> problem is probably not frequent! Anyway, as installations of earlier
>>> GROMACS and DSSP versions die out, those problems will go away. We
>>> still need a mechanism to find the dssp binary, though, and since
>>> there's no reliable place to look for one at configure or run time,
>>> there's no really good solution.
>>>
>>> The solution with the least ongoing impact would be to bundle the dssp
>>> source code and call it directly, which would also make these analyses
>>> much faster for GROMACS users. That would require that we can get and
>>> distribute the dssp source code under a license compatible with ours
>>> (LGPL v2.1). We cannot do so with FFTW source, for example, because
>>> they only make it available under GPL. Just being "open source" is not
>>> enough, unfortunately.
>>>
>>> If such a license is not acceptable to you, we could consider an
>>> option for our build system that downloads a Linux binary from your
>>> FTP site and installs it alongside GROMACS. That's similar to an
>>> existing feature we have for letting the user download and build FFTW
>>> as part of the GROMACS build. Such an option would have to be disabled
>>> by default, and so I think that could be more work than its reward.
>>>
>>> Regards,
>>>
>>> Mark
>>>
>>> On Mon, Jul 8, 2013 at 9:08 AM, Bert de Groot <bgroot at gwdg.de> wrote:
>>>
>>>> Hi,
>>>>
>>>> I got the message below from Gert Vriend. My impression is that it
>>>> would be
>>>> easiest to incorporate the new, open source, algorithm of dssp into
>>>> do_dssp.
>>>> That will alleviate all of the version incompatibility issues, as well
>>>> as
>>>> file format issues.
>>>>
>>>> cheers
>>>>
>>>> Bert
>>>>
>>>>
>>>>
>>>> About once a week I get mails from people who have difficulties using
>>>> DSSP.
>>>> Every time it takes me three mails before I found out that this is a
>>>> Gromacs
>>>> user.
>>>>
>>>> We made a new DSSP about a year ago, and this TOTALLY REWRITTEN DSSP is
>>>> now
>>>> open source. Would it be possible that anybody from the Gromacs team
>>>> looks
>>>> at DSSP and tells us what to do to make it usable for the Gromacs
>>>> community?
>>>>
>>>> I think this is especially important since the PDB format will stop to
>>>> be
>>>> used by the PDB on 1-1-2014, so everybody MUST start using the new DSSP
>>>> by
>>>> that time anyway.
>>>>
>>>> Greetings
>>>> Gert
>>>> --
>>>> gmx-developers mailing list
>>>> gmx-developers at gromacs.org
>>>> http://lists.gromacs.org/**mailman/listinfo/gmx-**developers<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@**gromacs.org<gmx-developers-request at gromacs.org>
>>>> .
>>>>
>>>
> --
> Best Regards,
> Alexey 'Alexxy' Shvetsov
> Petersburg Nuclear Physics Institute, NRC Kurchatov Institute, Gatchina,
> Russia
> Department of Molecular and Radiation Biophysics
> Gentoo Team Ru
> Gentoo Linux Dev
> mailto:alexxyum at gmail.com
> mailto:alexxy at gentoo.org
> mailto:alexxy at omrb.pnpi.spb.ru
> --
> gmx-developers mailing list
> gmx-developers at gromacs.org
> http://lists.gromacs.org/**mailman/listinfo/gmx-**developers<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@**gromacs.org<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/20130709/f4acf5b2/attachment.html>