[gmx-developers] g_sdf, who developed it?

[David van der Spoel]

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...


-- 
David van der Spoel, Ph.D., Professor of Biology
Dept. of Cell & Molec. Biol., Uppsala University.
Box 596, 75124 Uppsala, Sweden. Phone:	+46184714205. Fax: +4618511755.
spoel at xray.bmc.uu.se	spoel at gromacs.org   http://folding.bmc.uu.se