[cctbxbb] Adding columns to new *unmerged* MTZ object

[Nathaniel Echols]

The official mmCIF definition (as in "the limited subset of CIF tags that
the PDB understands") is probably too limited for use with unmerged data,
but the CIF format in general allows you to specify any tags you want, so
it is certainly flexible enough to replace MTZ.  But I agree that a binary
format would be preferable, especially since some of the data being
generated at Diamond and LCLS would lead to impossibly large CIF files.

-Nat


On Thu, Feb 13, 2014 at 7:48 AM, Phil Evans <pre at mrc-lmb.cam.ac.uk> wrote:

>
> AFAIK mmCIF is not conveniently endowed with what's needed for unmerged
> data, i.e. a clean way of recording the provenance of every observation,
> diffraction geometry, crystal properties, beam properties, detector
> properties etc, although much of this is defined somewhere. This is one of
> the things that the DIALS people I thought were looking into, probably
> storing data in an hdf5/Nexus container (is that right?). I'm not convinced
> that CIF is a good working format for reflection data, which I think should
> be binary. If we have well-defined structured data, then converting file
> formats is in principle straightforward (so e.g. Pointless can read XDS and
> Saint files which have much of the necessary information, unlike Scalepack
> files)
>
> If that is done, defined and a library available in C/C++, then it would
> be easy(ish) to make Pointless & Aimless read such a format.
>
> Phil
>
> On 13 Feb 2014, at 15:39, Nathaniel Echols <nechols at lbl.gov> wrote:
>
> > On Thu, Feb 13, 2014 at 12:45 AM, Phil Evans <pre at mrc-lmb.cam.ac.uk>
> wrote:
> > and we know from previous discussions that the current unmerged MTZ
> format is not the best possible
> >
> > Perhaps, but it's the only widely supported format that isn't broken by
> design, so ideally the CCTBX wrapper would provide access to as many
> features as possible.  (I'm assuming that Aimless doesn't read CIF either -
> correct?)
> >
> > Graeme: I have no strong opinions on how the API should work as long as
> existing code does not break, and right now you're the only group trying to
> output unmerged data.  Unless Nick has specific thoughts, I think you
> should feel free to make it work the way you think is appropriate; we'll
> probably find things to change later but an imperfect solution is better
> than none in this case.
> >
> > -Nat
> > _______________________________________________
> > cctbxbb mailing list
> > cctbxbb at phenix-online.org
> > http://phenix-online.org/mailman/listinfo/cctbxbb
>
> _______________________________________________
> cctbxbb mailing list
> cctbxbb at phenix-online.org
> http://phenix-online.org/mailman/listinfo/cctbxbb
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://phenix-online.org/pipermail/cctbxbb/attachments/20140213/1c86f9f1/attachment.htm>