interested in how Diamond is planning to integrate the use of imgCIF into the offered Data Processing/Storing Services: which format the users can get their images in (to take home/ to process on site) which applications are offered for on site data processing (xds, denzo, mosflm, xia, DNA, autoProc...?) - what has Diamond had to do for being able to support the things above? (agreement with vendors/developers?, collaborative developments?,... ?) - what is the status at the moment? etc.

interested in how Diamond is planning to integrate the use of imgCIF into the offered Data Processing/Storing Services

which format the users can get their images in (to take home/ to process on site) ADSC and CBF Currently how NeXus is used is TBD

which applications are offered for on site data processing ( xds, Denzo/HKL2000, mosflm, xia, DNA, autoProc...?)

what has Diamond had to do for being able to support the things above? –Module agreement with vendors/developers?, collaborative developments?,...

what is the status at the moment? –Beamline setup – computing –Near beamline setup –Networking

imgCIF/CBF ADSC header HEADER_BYTES= 512; DIM=2; BYTE_ORDER=little_endian; TYPE=unsigned_short; PIXEL_SIZE=0.1026; BIN=2x2; ADC=fast; DETECTOR_SN=922; DATE=Fri Sep 15 10:07: ; TIME=1.00; DISTANCE= ; OSC_RANGE=1.000; PHI=0.000; OSC_START=0.000; TWOTHETA=0.000; AXIS=phi; WAVELENGTH=1.0000; BEAM_CENTER_X=10.000; BEAM_CENTER_Y=20.000; CREV=1; CCD=TH7899; BIN_TYPE=HW; ACC_TIME=1781; UNIF_PED=1500; IMAGE_PEDESTAL=40; SIZE1=3072; SIZE2=3072;

> > Synchrotron and Beamline > > Beam conditions: ring energy and current Beam size Attenuation If > > available, estimate of photon flux coming out of the collimator. > > Backstop type, size and position wrt sample Date and time > > Detector type > > and serial number Goniostat (manufacturer and model) Method > of sample > > mounting (by hand, arcs/tongs or by robotics (type)) Temperature of > > sample > > > Sample code (barcode ?) This could be important as it may be > > the way to > > retrieve the appropriate metadata for this experiment, ie it > > provides a > > unique pointer into the database where the metadata is stored. The > > filename should not be used for this as it can be changed > too easily. > > > Code to identify what position on the crystal has been > exposed to the > > beam, so that if the crystal is translated during the > experiment this > > would identify which position was which (normally this is > done via the > > run rumber but this is not a unique way of providing this > > information). > > > Text field to allow any special comments relevent to this > > experiment to > > be stored. eg If crystal has been annealed, and if so, what the > > conditions were. Has the crystal been cryocooled in a capillary etc >

> > It would be useful to record the mode the synchrotron is running in. > > Attenuation - this should be a calculated factor Photon flux + error > > (but this might not be available on day 1) actually errors should be > > recorded where possible. What is available from day one and > > essential is (arbitory) intensity readings and these should be recorded with the image (to help scaling) > > > We don't like _diffrn_source.type. This seems to be a vague > > string that > > is not standardised and might be better in 2 or 3 items (we > > have seen at least 2 examples)? > > > We need some record of an experiment number, this would give > > us the link back to everything else e.g. user etc. > > > On the comment Andrew put on the "code to identify what > > position on the crystal had been exposed", we though an image of the crystal, with the cross hairs marking the beam would do the job? There was some discussion on if the image was before/after during data collection but before would do fine for starters > > > Something else that would be available in time is beam size at sample > > and beam size on detector, this would give us a clue as to where the beam was focused.