[gmx-developers] g_sdf, who developed it?

[Tsjerk Wassenaar]

You could also think of sed/awk type processing, where you can give
command line options or feed/pipe a script.

Tsjerk


On Thu, Jun 3, 2010 at 11:27 AM, Berk Hess <hess at cbr.su.se> wrote:
> 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
>
> --
> 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.
>



-- 
Tsjerk A. Wassenaar, Ph.D.

post-doctoral researcher
Molecular Dynamics Group
Groningen Institute for Biomolecular Research and Biotechnology
University of Groningen
The Netherlands