[gmx-developers] g_sdf, who developed it?

[Rossen Apostolov]

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?

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