<div dir="ltr">The official mmCIF definition (as in &quot;the limited subset of CIF tags that the PDB understands&quot;) 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.<div>

<br></div><div>-Nat</div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Thu, Feb 13, 2014 at 7:48 AM, Phil Evans <span dir="ltr">&lt;<a href="mailto:pre@mrc-lmb.cam.ac.uk" target="_blank">pre@mrc-lmb.cam.ac.uk</a>&gt;</span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
AFAIK mmCIF is not conveniently endowed with what&#39;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&#39;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)<br>


<br>
If that is done, defined and a library available in C/C++, then it would be easy(ish) to make Pointless &amp; Aimless read such a format.<br>
<span class="HOEnZb"><font color="#888888"><br>
Phil<br>
</font></span><div class="HOEnZb"><div class="h5"><br>
On 13 Feb 2014, at 15:39, Nathaniel Echols &lt;<a href="mailto:nechols@lbl.gov">nechols@lbl.gov</a>&gt; wrote:<br>
<br>
&gt; On Thu, Feb 13, 2014 at 12:45 AM, Phil Evans &lt;<a href="mailto:pre@mrc-lmb.cam.ac.uk">pre@mrc-lmb.cam.ac.uk</a>&gt; wrote:<br>
&gt; and we know from previous discussions that the current unmerged MTZ format is not the best possible<br>
&gt;<br>
&gt; Perhaps, but it&#39;s the only widely supported format that isn&#39;t broken by design, so ideally the CCTBX wrapper would provide access to as many features as possible.  (I&#39;m assuming that Aimless doesn&#39;t read CIF either - correct?)<br>


&gt;<br>
&gt; Graeme: I have no strong opinions on how the API should work as long as existing code does not break, and right now you&#39;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&#39;ll probably find things to change later but an imperfect solution is better than none in this case.<br>


&gt;<br>
&gt; -Nat<br>
</div></div><div class="HOEnZb"><div class="h5">&gt; _______________________________________________<br>
&gt; cctbxbb mailing list<br>
&gt; <a href="mailto:cctbxbb@phenix-online.org">cctbxbb@phenix-online.org</a><br>
&gt; <a href="http://phenix-online.org/mailman/listinfo/cctbxbb" target="_blank">http://phenix-online.org/mailman/listinfo/cctbxbb</a><br>
<br>
_______________________________________________<br>
cctbxbb mailing list<br>
<a href="mailto:cctbxbb@phenix-online.org">cctbxbb@phenix-online.org</a><br>
<a href="http://phenix-online.org/mailman/listinfo/cctbxbb" target="_blank">http://phenix-online.org/mailman/listinfo/cctbxbb</a><br>
</div></div></blockquote></div><br></div>