[gmx-developers] g_sdf, who developed it?

[Berk Hess]

Tsjerk Wassenaar wrote:
> Hi,
>
> On Thu, Jun 3, 2010 at 9:52 AM,  <chris.neale at utoronto.ca> wrote:
>   
>> 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.
>>     
>
> I concur, albeit that one may need to distinguish and now and then
> reconsider classification of tools that deserve active upkeep and
> those that are to be stored in an attic for someone to blow the dust
> off if deemed useful.
>
>   
>> 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.
>>     
>
> Yeah, that was exactly what my notion was.
>
>   
>>> 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.
>>     
>
> Exactly.
>
>   
>> 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.
>>     
>
> I was thinking of adding a note also in the description that a bug is
> currently open.
>
>   
>> 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.
>>     
>
> Well, probably they could merged, or g_sdf could be merged with g_rdf.
>
> Cheers,
>
> Tsjerk
>
>   
No.
I think we should go the opposite way.
Tools should be a simple as possible and do only one type of analysis.

We probably want to go to a model where you can do simple steps,
such a select a group, fit, calculate rmsd etc., using a command line option
or a script. In that way each step is clear, simple and maintainable and can
be used together with all other analysis, while still keeping a frame in
memory
and not requiring intermediate files.

Berk