[gmx-developers] g_sdf, who developed it?

[David van der Spoel]

On 2010-06-15 13.19, Rossen Apostolov wrote:
> Hi,
>
> Is there a consensus on this topic? Does that need to be resolved for
> 4.5 or file a bug and keep it alive for later?

No need to resolve it for 4.5. I mailed the original author but did not 
get an answer.

>
> Rossen
>
> On 06/03/2010 11:37 AM, Tsjerk Wassenaar wrote:
>> 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.
>>>
>>
>>
>


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