[gmx-developers] g_sdf, who developed it?

[chris.neale at utoronto.ca]

Oh boy -- where have named pipes been all of my life? This is  
excellent and has incredible utility for gromacs tools that require  
specific name endings.

Mark, is there a way to get this information widely distributed?  
Perhaps with a simple worked example from your usage? No better time  
than now to start a "tip of the month" section on the gromacs wiki or  
website...

Quoting Mark Abraham <mark.abraham at anu.edu.au>:

>
>
> ----- Original Message -----
> From: chris.neale at utoronto.ca
> Date: Thursday, June 3, 2010 16:19
> Subject: Re: [gmx-developers] g_sdf, who developed it?
> To: gmx-developers at gromacs.org
>
>> 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.
>
> A solution that does not require the existence of excess disk is   
> that of named pipes (http://en.wikipedia.org/wiki/Named_pipe). I've   
> used such in the past to pipe the .xvg output of some GROMACS tool   
> straight to g_analyze, for example. It's straightforward to write a   
> shell script that makes the named pipe, sets up the consumer process  
>  in the background and then runs the producer process.
>
> I know nothing about either g_sdf or g_spatial, but perhaps the   
> existence of this technique indicates a consolidation of these tools  
>  along the lines suggested by Chris.
>
> Mark
>
>> 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.
>