Pathologies - Revision history

Kay: /* Scale factor plot in case of problems (beam or spindle) */

2019-08-07T15:48:54Z

Scale factor plot in case of problems (beam or spindle)

← Older revision		Revision as of 17:48, 7 August 2019
Line 15:		Line 15:

	The scale factor is printed, in INTEGRATE.LP, for every frame (column 3). This plot shows spikes indicating that the beam was weak, or the spindle went too fast every 13 frames or so. A change of flux ''within'' a frame is detrimental to data quality; however if the change of flux occurs during the readout (i.e. between the frames) then the scale factor accurately compensates the flux change. A change in rotation speed is also to some extent compensated by the change in scale factor, but there is the additional effect that the next frame starts at a phi offset (which has to be compensated by ORIENTATION refinement in INTEGRATE).		The scale factor is printed, in INTEGRATE.LP, for every frame (column 3). This plot shows spikes indicating that the beam was weak, or the spindle went too fast every 13 frames or so. A change of flux ''within'' a frame is detrimental to data quality; however if the change of flux occurs during the readout (i.e. between the frames) then the scale factor accurately compensates the flux change. A change in rotation speed is also to some extent compensated by the change in scale factor, but there is the additional effect that the next frame starts at a phi offset (which has to be compensated by ORIENTATION refinement in INTEGRATE).

			Possible sources of beam flux changes are attenuators that vibrate, top-up injections, and other types of vibrations. The shorter the exposure times are, the more these problems usually become visible.

	=== Mosaicity plots in case of problems ===		=== Mosaicity plots in case of problems ===

Kay: /* Mosaicity plots in case of problems */

2013-12-08T21:42:43Z

Mosaicity plots in case of problems

← Older revision		Revision as of 23:42, 8 December 2013
Line 20:		Line 20:
	[[Image:Sigmar.png]]		[[Image:Sigmar.png]]

	The same data set: the mosaicity estimates of individual frames (column 10 in INTEGRATE.LP) is ~~very much influenced by this~~. The "jumps" in the curve arises because INTEGRATE was run with MAXIMUM_NUMBER_OF_JOBS=8: since each of the 8 jobs uses the orientation matrix from IDXREF for its initial batch, and that matrix does not seem to match the actual orientation, the mosaicity appears high. Only after geometry refinement (green line) is the result reasonable (and thus the intensity estimates will not be affected). The estimate for the second batch of each job is much better, because it uses the orientation obtained from the geometry refinement as a starting point.		The same data set: the mosaicity estimates of individual frames (column 10 in INTEGRATE.LP) are high because the orientation is off. The "jumps" in the curve arises because INTEGRATE was run with MAXIMUM_NUMBER_OF_JOBS=8: since each of the 8 jobs uses the orientation matrix from IDXREF for its initial batch, and that matrix does not seem to match the actual orientation, the mosaicity appears high. Only after geometry refinement (green line) is the result reasonable (and thus the intensity estimates will not be affected). The estimate for the second batch of each job is much better, because it uses the orientation obtained from the geometry refinement as a starting point.

	Exactly ''why'' the IDXREF estimate is off, and if it has something to do with the spindle problem, is unknown.		Exactly ''why'' the IDXREF estimate is off, and if it has something to do with the flux or spindle problem, is unknown.

	With MAXIMUM_NUMBER_OF_JOBS=1 the plot would definitely not look like this - it would be much smoother because the next batch of data "knows" about the orientation of the previous one.		With MAXIMUM_NUMBER_OF_JOBS=1 the plot would definitely not look like this - it would be much smoother because the next batch of data "knows" about the orientation of the previous one.

Kay: /* Scale factor plot in case of problems (beam or spindle) */

2013-12-08T21:38:30Z

Scale factor plot in case of problems (beam or spindle)

← Older revision		Revision as of 23:38, 8 December 2013
Line 14:		Line 14:
	[[Image:Scales.png]]		[[Image:Scales.png]]

	The scale factor is printed, in INTEGRATE.LP, for every frame (column 3). This plot shows spikes indicating that the beam was weak, or the spindle went too fast every 13 frames or so (~~but in that case~~ the ~~spindle went a bit slower in the adjacent~~ frames). ~~No matter what the problem~~ is ~~due~~ to, it is ~~quite detrimental to data quality -~~ the ~~reflections~~ which ~~contribute~~ to ~~those frames that went too fast are underexposed~~.		The scale factor is printed, in INTEGRATE.LP, for every frame (column 3). This plot shows spikes indicating that the beam was weak, or the spindle went too fast every 13 frames or so. A change of flux ''within'' a frame is detrimental to data quality; however if the change of flux occurs during the readout (i.e. between the frames) then the scale factor accurately compensates the flux change. A change in rotation speed is also to some extent compensated by the change in scale factor, but there is the additional effect that the next frame starts at a phi offset (which has to be compensated by ORIENTATION refinement in INTEGRATE).

	=== Mosaicity plots in case of problems ===		=== Mosaicity plots in case of problems ===

Kay: /* Hardware problems */

2013-12-08T13:06:14Z

Hardware problems

← Older revision		Revision as of 15:06, 8 December 2013
Line 10:		Line 10:
	== Hardware problems ==		== Hardware problems ==

	=== Scale factor plot in case of spindle ~~problems~~ ===		=== Scale factor plot in case of problems (beam or spindle) ===

	[[Image:Scales.png]]		[[Image:Scales.png]]

	The scale factor is printed, in INTEGRATE.LP, for every frame (column 3). This plot shows spikes indicating that the spindle went too fast every 13 frames or so (but the spindle went a bit slower in the adjacent frames). ~~Needless~~ to ~~say~~, ~~this problem~~ is quite detrimental to data quality - the reflections which contribute to those frames that went too fast are underexposed.		The scale factor is printed, in INTEGRATE.LP, for every frame (column 3). This plot shows spikes indicating that the beam was weak, or the spindle went too fast every 13 frames or so (but in that case the spindle went a bit slower in the adjacent frames). No matter what the problem is due to, it is quite detrimental to data quality - the reflections which contribute to those frames that went too fast are underexposed.

	=== Mosaicity plots in case of ~~spindle~~ problems ===		=== Mosaicity plots in case of problems ===

	[[Image:Sigmar.png]]		[[Image:Sigmar.png]]

Kay: /* Scale factor plot in case of spindle problems */

2013-11-29T09:49:47Z

Scale factor plot in case of spindle problems

← Older revision		Revision as of 11:49, 29 November 2013
Line 14:		Line 14:
	[[Image:Scales.png]]		[[Image:Scales.png]]

	The scale factor is printed, in INTEGRATE.LP, for every frame (column 3). This plot shows spikes indicating that the spindle went too fast every 13 frames or so (but the spindle went ~~slow~~ in the adjacent frames). Needless to say, this problem is quite detrimental to data quality.		The scale factor is printed, in INTEGRATE.LP, for every frame (column 3). This plot shows spikes indicating that the spindle went too fast every 13 frames or so (but the spindle went a bit slower in the adjacent frames). Needless to say, this problem is quite detrimental to data quality - the reflections which contribute to those frames that went too fast are underexposed.

	=== Mosaicity plots in case of spindle problems ===		=== Mosaicity plots in case of spindle problems ===

Kay: /* Mosaicity plots in case of spindle problems */

2013-11-29T09:45:59Z

Mosaicity plots in case of spindle problems

← Older revision		Revision as of 11:45, 29 November 2013
Line 20:		Line 20:
	[[Image:Sigmar.png]]		[[Image:Sigmar.png]]

	The same data set: the mosaicity estimates of individual frames (column 10 in INTEGRATE.LP) is very much influenced by this. The "jumps" in the curve arises because INTEGRATE was run with MAXIMUM_NUMBER_OF_JOBS=8: since each of the 8 jobs uses the orientation matrix from IDXREF for its initial batch, and that matrix does not seem to match the actual orientation, the mosaicity appears high. Only after geometry refinement (green line) is the result reasonable. The estimate for the second batch of each job is much better, because it uses the orientation obtained from the geometry refinement as a starting point.		The same data set: the mosaicity estimates of individual frames (column 10 in INTEGRATE.LP) is very much influenced by this. The "jumps" in the curve arises because INTEGRATE was run with MAXIMUM_NUMBER_OF_JOBS=8: since each of the 8 jobs uses the orientation matrix from IDXREF for its initial batch, and that matrix does not seem to match the actual orientation, the mosaicity appears high. Only after geometry refinement (green line) is the result reasonable (and thus the intensity estimates will not be affected). The estimate for the second batch of each job is much better, because it uses the orientation obtained from the geometry refinement as a starting point.

			Exactly ''why'' the IDXREF estimate is off, and if it has something to do with the spindle problem, is unknown.

			With MAXIMUM_NUMBER_OF_JOBS=1 the plot would definitely not look like this - it would be much smoother because the next batch of data "knows" about the orientation of the previous one.

	[[Image:Sigmar2.png]]		[[Image:Sigmar2.png]]

	The same hardware problem, but a different data set: here, the mosaicity estimates of individual frames are less affected, because the initial orientation is good. Oscillations are not seen very well here since the period of the scale factor changes is on the order of 13 frames.		The same hardware problem, but a different data set: here, the mosaicity estimates of individual frames are less affected, because the initial orientation from IDXREF is good. Oscillations are not seen very well here since the period of the scale factor changes is on the order of 13 frames.

	[[Image:Sigmar3.png]]		[[Image:Sigmar3.png]]

	Zoomed version of the above. The oscillations are better visible.		Zoomed version of the above. The oscillations are better visible.

Kay: /* Mosaicity plots in case of spindle problems */

2013-11-28T13:59:58Z

Mosaicity plots in case of spindle problems

← Older revision		Revision as of 15:59, 28 November 2013
Line 20:		Line 20:
	[[Image:Sigmar.png]]		[[Image:Sigmar.png]]

	The same data set: the mosaicity estimates of individual frames (column 10 in INTEGRATE.LP) is very much influenced by this.		The same data set: the mosaicity estimates of individual frames (column 10 in INTEGRATE.LP) is very much influenced by this. The "jumps" in the curve arises because INTEGRATE was run with MAXIMUM_NUMBER_OF_JOBS=8: since each of the 8 jobs uses the orientation matrix from IDXREF for its initial batch, and that matrix does not seem to match the actual orientation, the mosaicity appears high. Only after geometry refinement (green line) is the result reasonable. The estimate for the second batch of each job is much better, because it uses the orientation obtained from the geometry refinement as a starting point.

	[[Image:Sigmar2.png]]		[[Image:Sigmar2.png]]

	The same problem, but a different data set: here, the mosaicity estimates of individual frames are ~~influenced in a different way~~, ~~and a different way of oscillation results~~. ~~This is~~ not seen very well here since the period is on the order of 13 frames.		The same hardware problem, but a different data set: here, the mosaicity estimates of individual frames are less affected, because the initial orientation is good. Oscillations are not seen very well here since the period of the scale factor changes is on the order of 13 frames.

	[[Image:Sigmar3.png]]		[[Image:Sigmar3.png]]

	Zoomed version of the above. The oscillations are better visible.		Zoomed version of the above. The oscillations are better visible.

Kay: /* Hardware problems */

2013-11-27T12:18:56Z

Hardware problems

← Older revision		Revision as of 14:18, 27 November 2013
Line 11:		Line 11:

	=== Scale factor plot in case of spindle problems ===		=== Scale factor plot in case of spindle problems ===

	[[Image:Scales.png]]		[[Image:Scales.png]]

	This shows spikes indicating that the spindle went too fast every 12 frames or so. ~~This~~ is quite detrimental to data quality.		The scale factor is printed, in INTEGRATE.LP, for every frame (column 3). This plot shows spikes indicating that the spindle went too fast every 13 frames or so (but the spindle went slow in the adjacent frames). Needless to say, this problem is quite detrimental to data quality.

	=== Mosaicity plots in case of spindle problems ===		=== Mosaicity plots in case of spindle problems ===

	[[Image:Sigmar.png]]		[[Image:Sigmar.png]]

			The same data set: the mosaicity estimates of individual frames (column 10 in INTEGRATE.LP) is very much influenced by this.

	[[Image:Sigmar2.png]]		[[Image:Sigmar2.png]]

			The same problem, but a different data set: here, the mosaicity estimates of individual frames are influenced in a different way, and a different way of oscillation results. This is not seen very well here since the period is on the order of 13 frames.

	[[Image:Sigmar3.png]]		[[Image:Sigmar3.png]]

			Zoomed version of the above. The oscillations are better visible.

Kay: Created page with "How can we judge the quality of a data set? There are several possibilities: # numerical indicators, like R-values, I/sigma and the like # graphical representations This arti..."

2013-11-27T11:29:33Z

Created page with "How can we judge the quality of a data set? There are several possibilities: # numerical indicators, like R-values, I/sigma and the like # graphical representations This arti..."

New page

How can we judge the quality of a data set? There are several possibilities:
# numerical indicators, like R-values, I/sigma and the like
# graphical representations

This article serves to demonstrate pathological cases. It collects examples for
# problems with the hardware (e.g. detector, beamline, goniostat, beam, cryo)
# problems with the crystal
# problems with data processing

== Hardware problems ==

=== Scale factor plot in case of spindle problems ===
[[Image:Scales.png]]

This shows spikes indicating that the spindle went too fast every 12 frames or so. This is quite detrimental to data quality.

=== Mosaicity plots in case of spindle problems ===

[[Image:Sigmar.png]]
[[Image:Sigmar2.png]]
[[Image:Sigmar3.png]]