[gmx-developers] Extending Matrix data formats (xpm + others ...)

[Oliver Beckstein]

On a similar note of extending file formats recognised by the gromacs
option processing machinery: 

For home-grown analysis it would be nice if one could "somehow" add
additional file types to the enum in include/types/filenm.h and
gmxlib/filenm.c without having to actually add them to the gmx source tree
and to recompile gromacs. Ideally, I would put extensions to the file
types in my own include files and link to the standard libgmx/libmd and
have these files recognised automagically. (But I realise that this might
be complicated and it might be easier to have a local version of gromacs
including these particular changes and just lobby on gmx-devel for
inclusion of filetypes in the next release :-) ).

In particular I was thinking about the gOpenMol plt format for 3D
array data <http://www.csc.fi/gopenmol/developers/plt_format.phtml>
which would have entries like

/* filenm.h */
enum {
  efPLT
}

/* src/gmxlib/filenm.c */ 
static t_deffile deffile[efNR] = {
  { eftBIN, ".plt", "grid",   NULL, "gOpenMol 3D plot data"  },
}

(+ the write routines which one could find, for instance, in
gridcount could be added to the analysis lib). 


On Fri, 23 Apr 2004, Marc Baaden wrote:
> >>> "Berk Hess" said:
>  >> Currently there is no general way to do this.
>  >> One could let the xpm writing calls (optionally) write some
>  >> ohter format, but you would also like to have the additional
>  >> file options in the programs.
> 
> Yep. I agree.
> 
>  >> But there are not that many files that write xpm's and even less
>  >> files that write xpm's that one might want to read with other software.
>  >> Which programs were you thinking of?
> 
> I haven't exhaustively checked everything, but I had in mind things like:
> 
> g_mdmat  (simple distance matrices, or with -frames a 3D field)
> g_rms    (RMSD matrix)
> g_enemat (energy matrix, maybe also field as f(time)?)
> g_covar  (covariance matrix)
> do_dssp  (matrix of ss as f(t))
> 
> Also, matrix data is not the only data I am interested in. Basically anything
> that is 2D or higher, like field/density data.

If your goal isn't efficient storage for 2D but something that can be
easily processed and visualised then you could use the xfarbe format
<http://www.fhi-berlin.mpg.de/grz/pub/xfarbe/xfarbe-2.6/html/index.html>
for 2D arrays. xfarbe has the advantage that it can do bicubic
interpolation to make pretty and smooth pictures and the data can be
quickly analysed (which can also do interactive data probing, drawing
gradients etc, see the home page).

> I am currently playing around with the netcdf format and opendx to get a
> clearer picture of what I want in the end.

Might have the advantage of being more of a standard than the things
that I suggest and use ;-). For gridcount I also use some home grown
format that uses xdr for the 3D density but if there emerges a common
standard for writing this kind of data then I would happily use it.


Oli

-- 
Oliver Beckstein * oliver at biop.ox.ac.uk
 http://sansom.biop.ox.ac.uk/oliver/