XDSwiki

Wishlist: Difference between revisions

Page Discussion

Wishlist (view source)

Revision as of 18:05, 9 July 2008

1,043 bytes removed ,  9 July 2008
m
no edit summary
mNo edit summary
Line 4: Line 4:




== Would be nice to have ==


== Important ==
* CORRECT should print out the parameter of STRICT_ABSORPTION_CORRECTION= . The influence of this on the anomalous signal is significant, and it is difficult to compare data reductions without its value being documented in CORRECT.LP . --[[User:Kay|Kay]] 23:30, 22 December 2007 (CET)
== Would be nice to have ==
* IDXREF should print out the maximum oscillation angle for a mosaicity of zero, according to delta-&phi;<sub>max</sub>=(longest primitive cell axis)/d<sub>max</sub>*180°/Pi where d<sub>max</sub> is at the edge of the detector. This could be printed near the bottom of the file, after the second "aP" line (which has the P1 cell).--[[User:Kay|Kay]] 10:43, 13 May 2008 (CEST)
* A breakdown of R<sub>meas</sub> by frame number, as currently only available from [[XDSSTAT]]. This would be useful in order to identify bad frames. --[[User:Kay|Kay]] 14:00, 12 November 2007 (CET)
* A breakdown of R<sub>meas</sub> by frame number, as currently only available from [[XDSSTAT]]. This would be useful in order to identify bad frames. --[[User:Kay|Kay]] 14:00, 12 November 2007 (CET)


Line 32: Line 27:


* INCLUDE_RESOLUTION_RANGE= should be respected by IDXREF because this could be used to prevent ice rings from disturbing the indexing. Drawback: one would have to change INCLUDE_RESOLUTION_RANGE= after running IDXREF.<br />Probably better: EXCLUDE_RESOLUTION_RANGE= should be respected by IDXREF. Drawback: geometrical parameters (in particular the direct beam position) are unrefined when resolution is calculated in IDXREF. <br /> Probably best: a new keyword for this purpose. <br /> For a workaround, see [[Ice_rings]]. <br /> Based on discussion with Clemens Vonrhein --[[User:Kay|Kay]] 12:16, 16 November 2007 (CET)
* INCLUDE_RESOLUTION_RANGE= should be respected by IDXREF because this could be used to prevent ice rings from disturbing the indexing. Drawback: one would have to change INCLUDE_RESOLUTION_RANGE= after running IDXREF.<br />Probably better: EXCLUDE_RESOLUTION_RANGE= should be respected by IDXREF. Drawback: geometrical parameters (in particular the direct beam position) are unrefined when resolution is calculated in IDXREF. <br /> Probably best: a new keyword for this purpose. <br /> For a workaround, see [[Ice_rings]]. <br /> Based on discussion with Clemens Vonrhein --[[User:Kay|Kay]] 12:16, 16 November 2007 (CET)
* a keyword REJECT_ALIENS= with a default of 20. This would be the cutoff for automatic rejection of "aliens". See [[Optimization#Wilson%20outliers%20(aliens)]]--[[User:Kay|Kay]] 10:29, 27 November 2007 (CET)
* a keyword REJECT_ALIENS= with a default of 20. This would be the cutoff for automatic rejection of "aliens". See [[Optimization#Wilson%20outliers%20(aliens)]]--[[User:Kay|Kay]] 10:29, 27 November 2007 (CET)
* an error message and program stop if the files given as parameters of X-GEO_CORR and Y-GEO_CORR cannot be found. Currently the program continues silently, which might lead to suboptimally processed data.--[[User:Kay|Kay]] 22:19, 12 December 2007 (CET)
* Automated Direct Beam Position Recognition from Direct Beam Shots: The [[Features that are not officially documented|undocumented]] DIRB option should be announced and extended. I would suggest the following: a new input keyword "NAME_OF_DIRB_FRAME=" instead of interactive input is used to specifiy the direct beam shot frame. As a default "NAME_OF_DIRB_FRAME=" should use frame 0 of the current Name_Template_of_data_frames selection. Avoiding interactive input would facilitate automated script based processing and avoid the use of erroneous direct beam position from headers or manual input.--[[User:Tmaier|Tmaier]] 13:24, 13 December 2007 (CET)
* Automated Direct Beam Position Recognition from Direct Beam Shots: The [[Features that are not officially documented|undocumented]] DIRB option should be announced and extended. I would suggest the following: a new input keyword "NAME_OF_DIRB_FRAME=" instead of interactive input is used to specifiy the direct beam shot frame. As a default "NAME_OF_DIRB_FRAME=" should use frame 0 of the current Name_Template_of_data_frames selection. Avoiding interactive input would facilitate automated script based processing and avoid the use of erroneous direct beam position from headers or manual input.--[[User:Tmaier|Tmaier]] 13:24, 13 December 2007 (CET)
* Option to write out FRAME.PCK for visual control for every nth image, e.g. controlled by a keyword "FRAMEPCK_EVERY_NTH=" with default FRAMEPCK_EVERY_NTH=0 i.e. single FRAME_NTH.PCK as in current version, the option  FRAMEPCK_EVERY_NTH=B i.e. writing one FRAME_NTH.PCK per batch in INTEGRATE, and the option to provide an integer number n to get FRAME_NTH.PCK for every nth original image.--[[User:Tmaier|Tmaier]] 13:37, 13 December 2007 (CET)
* Option to write out FRAME.PCK for visual control for every nth image, e.g. controlled by a keyword "FRAMEPCK_EVERY_NTH=" with default FRAMEPCK_EVERY_NTH=0 i.e. single FRAME_NTH.PCK as in current version, the option  FRAMEPCK_EVERY_NTH=B i.e. writing one FRAME_NTH.PCK per batch in INTEGRATE, and the option to provide an integer number n to get FRAME_NTH.PCK for every nth original image.--[[User:Tmaier|Tmaier]] 13:37, 13 December 2007 (CET)
* Option to produce harvest files from CORRECT and XSCALE for deposition of structures.--[[User:Graeme|Graeme]] 18 February 2008. Clarifying this in response to question: Mosflm and Scala both produce files which contain information which can be included at deposition - this is produced as separate Harvest files, based on the statistics already generated by the programs. These harvest files are in mmCIF format, and I will upload a couple if I can figure out how. This does require a certain amount of administrative information (a "name" for the project and dataset) but could be easily rectified by adding a keyword: HARVEST_PROJECT= HARVEST_DATASET= which could then produce PROJECT_DATASET.xds or .xscale depending on the program. [[User:Graeme|Graeme]] 30 May 2008.
* Option to produce harvest files from CORRECT and XSCALE for deposition of structures.--[[User:Graeme|Graeme]] 18 February 2008. Clarifying this in response to question: Mosflm and Scala both produce files which contain information which can be included at deposition - this is produced as separate Harvest files, based on the statistics already generated by the programs. These harvest files are in mmCIF format, and I will upload a couple if I can figure out how. This does require a certain amount of administrative information (a "name" for the project and dataset) but could be easily rectified by adding a keyword: HARVEST_PROJECT= HARVEST_DATASET= which could then produce PROJECT_DATASET.xds or .xscale depending on the program. [[User:Graeme|Graeme]] 30 May 2008.


Line 45: Line 35:


* CORRECT should print out MAXIMUM_NUMBER_OF_PROCESSORS= , and the actual number of processors used. --[[User:Kay|Kay]] 13:55, 12 November 2007 (CET)
* CORRECT should print out MAXIMUM_NUMBER_OF_PROCESSORS= , and the actual number of processors used. --[[User:Kay|Kay]] 13:55, 12 November 2007 (CET)
* CORRECT should print out MINIMUM_I/SIGMA= . --[[User:Kay|Kay]] 14:24, 13 November 2007 (CET)
* BACKGROUND_RANGE= should have a better default (e.g., the first five frames of the DATA_RANGE). The default currently appears to be 0 0. --[[User:Kay|Kay]] 14:45, 12 November 2007 (CET)
* BACKGROUND_RANGE= should have a better default (e.g., the first five frames of the DATA_RANGE). The default currently appears to be 0 0. --[[User:Kay|Kay]] 14:45, 12 November 2007 (CET)
* document X-GEO_CORR and Y-GEO_CORR.--[[User:Kay|Kay]] 22:18, 12 December 2007 (CET)
 
== Notes ==
See [[old wishes]] to find out which things were implemented.
Kay
Bureaucrats
2,652

edits

Retrieved from "https://wiki.uni-konstanz.de/xds/index.php/Special:MobileDiff/2009"