[gmx-developers] g_sdf, who developed it?

[chris.neale at utoronto.ca]

In general, I think that it would be a shame to lose any tool. If  
there is desire to depreciate it due to a difficult-to-isolate bug,  
then perhaps it would be a good general principle to add a warning  
requiring -maxwarn 1 to generate any output. More detailed reply  
follows.

Quoting Tsjerk Wassenaar <tsjerkw at gmail.com>:

> Hi Chris, David,
>
> Correct me if I'm wrong, but it seems that
>
> g_spatial generates the spatial distribution function of a set of
> atoms around another (reference) set of atoms, defining the space by
> fitting the reference atoms. g_spatial thus allows constructing an SDF
> of water around a protein or micelle.

Basically yes. g_spatial generates a 3D map of a user-defined set of  
atoms as they exist in the input .xtc file. It is up to the user to  
pre-process the .xtc such that, for example, the reference set is fit.  
It is entirely possible to then generate an SDF of the reference set,  
and separately the water, and separately the ions, etc.

> g_sdf generates the spatial distribution function of a set of atoms in
> the coordinate system defined by another set of atoms, consisting of
> 1, 2 or 3 atoms, where the final SDF is obtained by averaging over all
> local coordinate systems thus defined. g_sdf thus allows constructing
> an SDF of, e.g., water around methanol in a water/methanol mixture.

not sure. Do you mean that g_sdf can average over many particles (e.g.  
many methanol's) in the way that an rdf does? If this is the case,  
then surely g_sdf has some very important features that one does not  
want to lose.

>
> So they are loots of the same tree, but quite distinct in their application.

I think that this it probably the case. If indeed there is some bug in  
g_sdf, then it probably should be fixed in the long term, and possibly  
just add a warning to the usage for this release.

If there is no bug in g_sdf, then I see no problem in keeping two  
similar tools... unless that's creating headaches for the developers.  
In that case, I have no ability to comment.

Chris.

>
> Cheers,
>
> Tsjerk
>
> On Thu, Jun 3, 2010 at 8:18 AM,  <chris.neale at utoronto.ca> wrote:
>> I wrote g_spatial. I have never used g_sdf, but the programs are not exactly
>> identical. Ideally they might be combined, but I looked into that a while
>> ago and it is beyond my abilities.
>>
>> - g_sdf does a fitting based on (I think) 3 atoms defined by the user.
>> - g_spatial requires the user to do all of the fitting via trjconv.
>>
>> In my opinion, it is easier and more robust to require the user to first
>> pre-process the trajectory with trjconv. Nevertheless, I see more users on
>> the list inquiring about g_sdf; It is impossible to discern if this is
>> because g_sdf is harder to use or because it is more often used.
>>
>> The reasons to use g_spatial, are that one might want to fit based on some
>> arbitrary routine, and this should always be possible via trjconv. In my
>> opinion, the only thing that favours g_sdf is that one doesn't need to have
>> the disk space to store a fit trajectory prior to running g_sdf -- and this
>> could be a big plus for g_sdf in some cases.
>>
>> In the end, I can only comment that I and my colleagues find g_spatial to be
>> very useful. Also, from a simple magnitude of the comments on the list,
>> there is also a desire to use g_sdf.
>>
>> Obviously you're close to a release and not wanting to do more coding, but I
>> note that the idea behind g_spatial was to keep it simple... let trjconv do
>> all of the heavy lifting. Perhaps it would be possible in the future to add
>> a new trjconv option to do whatever fitting is done in g_sdf?
>>
>> Sorry I can't be definitive here,
>> Chris.
>>
>> Quoting David van der Spoel <spoel at xray.bmc.uu.se>:
>>
>>> On 2010-06-03 06.19, Tsjerk Wassenaar wrote:
>>>>
>>>> Hi David, Chris,
>>>>
>>>> The bug referred to concers make_ndx, not g_sdf. I indeed made a few
>>>> changes in the code, but those were minor adaptations required to have
>>>> it work with GMX3.3.1, such as changing gmx_fatal statements.
>>>>
>>> oops it should be
>>>
>>> http://bugzilla.gromacs.org/show_bug.cgi?id=356
>>>
>>> An additional problem is that we have two seemingly identical programs,
>>> g_sdf and g_spatial
>>> Chris: did you develop the latter then?
>>>
>>> Question is whether we need both...
>>>
>>>> Cheers,
>>>>
>>>> Tsjerk
>>>>
>>>>
>>>> On Wed, Jun 2, 2010 at 10:39 PM,<chris.neale at utoronto.ca>  wrote:
>>>>>
>>>>> g_sdf was developed by Christoph Freudenburger. It was uploaded and
>>>>> supported with mailing-list assistance by Dallas Warren:
>>>>> http://lists.gromacs.org/pipermail/gmx-users/2005-August/016578.html
>>>>>
>>>>> Looks like it was also modified by Tsjerk Wassenaar (to work with
>>>>> 3.3.1):
>>>>>
>>>>> http://www.gromacs.org/index.php?title=Download_%26_Installation/User_contributions/Other_software
>>>>>
>>>>> Quoting David van der Spoel<spoel at xray.bmc.uu.se>:
>>>>>
>>>>>> Hi,
>>>>>>
>>>>>> I forgot who contributed the code for g_sdf, but there seems to be a
>>>>>> strange problem with the code. Maybe he/she with insight in the innards
>>>>>> of the program can have a look at
>>>>>> http://bugzilla.gromacs.org/show_bug.cgi?id=367
>>>>>>
>>>>>> Thanks,
>>>>>> --
>>>>>> David van der Spoel, Ph.D., Professor of Biology
>>>>>> Dept. of Cell&  Molec. Biol., Uppsala University.
>>>>>> Box 596, 75124 Uppsala, Sweden. Phone:  +46184714205.
>>>>>> spoel at xray.bmc.uu.se    http://folding.bmc.uu.se
>>>>>> --
>>>>>> gmx-developers mailing list
>>>>>> gmx-developers at gromacs.org
>>>>>> 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 at gromacs.org.
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> gmx-developers mailing list
>>>>> gmx-developers at gromacs.org
>>>>> http://lists.gromacs.org/mailman/listinfo/gmx-developers
>>>>> Please don't post (un)subscribe requests to the list. Use thewww
>>>>> interface
>>>>> or send it to gmx-developers-request at gromacs.org.
>>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>> --
>>> David van der Spoel, Ph.D., Professor of Biology
>>> Dept. of Cell & Molec. Biol., Uppsala University.
>>> Box 596, 75124 Uppsala, Sweden. Phone:  +46184714205.
>>> spoel at xray.bmc.uu.se    http://folding.bmc.uu.se
>>> --
>>> gmx-developers mailing list
>>> gmx-developers at gromacs.org
>>> 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 at gromacs.org.
>>
>>
>>
>> --
>> gmx-developers mailing list
>> gmx-developers at gromacs.org
>> http://lists.gromacs.org/mailman/listinfo/gmx-developers
>> Please don't post (un)subscribe requests to the list. Use thewww interface
>> or send it to gmx-developers-request at gromacs.org.
>>
>
>
>
> --
> Tsjerk A. Wassenaar, Ph.D.
>
> post-doctoral researcher
> Molecular Dynamics Group
> Groningen Institute for Biomolecular Research and Biotechnology
> University of Groningen
> The Netherlands
> --
> gmx-developers mailing list
> gmx-developers at gromacs.org
> 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 at gromacs.org.
>