[gmx-developers] g_sdf, who developed it?

[Berk Hess]

David van der Spoel wrote:
> On 6/3/10 10:32 AM, Berk Hess wrote:
>> 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
>>
> There are many ways to do this, but monolithic applications are
> difficult to maintain indeed. The most important thing I would say is
> to make a library of trjconv operations, that you can call many times.
> That is, one could e.g. centering, rotating, fitting and so on by
> calling trjconv routines before doing a particular analysis.
>
> This is something that virtually all analysis programs need. However
> we don't want this code in each program, and it is not clear to me how
> we can make this simple to use.
>
> And don't say python...
If we parse command line options in order, we could have all those
operations as command line options.

Berk