Capture processing history at the point of MTZ export#2924
Conversation
|
I note that for the release version of DIALS v3.22.1, |
|
Possibly rethinking this to use the MTZ appendix rather than MTZ history. |
Revert to a single line in MTZ history, intended for dials.export to note itself as the MTZ creator. Meanwhile, just log the integration and scaling history. This is a placeholder for putting that information later into e.g. the MTZ Appendix
for more information, see https://pre-commit.ci
dagewa
changed the title
|
@yangha7 I changed this PR so that it does not write the integration and scale history to the MTZ history, but it just captures and logs these for later addition to the MTZ Appendix, if that's what we decide on. I think we should merge this in preparation for whatever we decide to do as it has useful functionality such as changing the datestamps to UTC, fixing |
* Ensure history from import is copied into the indexed experiments * Flag `integrated` and `scaled` in the history, so other programs can set this (i.e. not just `dials.integrate` and `dials.scale`) * Change MTZ export history timestamp to use UTC only (not UTC _and_ local time zone) * Capture integrate and scaled history lines to write... somewhere. Maybe MTZ appendix? TBC.
2 participants
This is the DIALS companion to cctbx/dxtbx#816, and requires that to be merged first. Changes here:
dials.index, fixing the issue that this got lost because of the waydials.indexconstructs experimentsdials.integrateanddials.scalewrite.exptfiles they flag that these lines are interesting fordials.exportdials.exportthen takes these interesting lines and adds appropriate MTZ history itemsAs an example, these lines are written to the MTZ history for standard single crystal rotation processing:
The version string looks a bit odd. When I run
dials.versionon the same computer I see3.dev.1314-g6a06be331. The way version information is extracted for experiment history is by usingimportlib.metadata.version, which for DIALS gives:@ndevenish is this
importlib.metadata.versioncall for DIALS correct? For the history functionality in dxtbx I could not rely ondials.version, because I can't be sure the software writing the.exptis actually DIALS. Indeed forxia2.multiplexI would get'3.9.dev184+g8e8dffbc'as the version string here on my computer.