Dear All, As someone who is both a user of external software and supports internally developed software to external users, I am quite familiar with both sides of this argument. From time to time someone will notice a "weird feature" in software - sometimes this is a bug, sometimes misuse (which is still by and large a bug, but in documentation) and sometimes a change in circumstances i.e. reasonable assumptions made in developing a package (e.g. background always over 1 count / all data sets have some reflections with I/sigI > 3 etc) become problematic.
As an individual developing software, and a member of a team doing so, it is always more comfortable if a user comes back with a collegiate "quiet word" that the software did something odd. However, I suspect it would be for the greater good that a more public approach was taken in general, since the less attentive user may miss this odd feature and take the results as gospel - if the knowledge of the bug / feature whatever was not in the public domain. Despite appearances people do not like to contact authors of software packages to complain. To make a note that "this version of package xyz has been found to be sometimes unpredictable with version 123 of the pipeline" does not blame the package, or the pipeline, but says that you should be warned with this combination. Ideally the authors of package xyz and the pipeline would be alerted, by the other developers or users, but it is better (IMHO) to be open. Public bug trackers are a good example of this. I suspect this matter of anisotropy correction is a similar one. Here we have a change in circumstances - the actual intensity measurements are modified - and passed in as if they are the originals. It is reasonable that this may affect the outcome of subsequent analysis and it is hoped that this does change the outcome but in a positive manner. This does not appear to be the case here. I have been asked on several occasions to incorporate the anisotropy correction into xia2 as it 'always makes things better', and have resisted on the grounds that the purpose of the package is to faithfully analyse the data as provided and provide uncorrected intensities as output. The corrections should ideally be performed within the downstream software, since they then know exactly what has happened to the measurements and will make fewer (ideally no) incorrect assumptions. It's already routine to write out multiple versions of e.g. phases, weights, sigma values etc based on different assumptions and flag then accordingly - perhaps we should be doing the same with modified intensities, so that packages which require the unmodified values could ignore the corrected ones. That would avoid the need for any health warnings and ensure changes in the wider environment do not invalidate assumptions... Obviously, all of the above is my humble opinion and other opinions are equally valid. Best wishes Graeme -- This e-mail and any attachments may contain confidential, copyright and or privileged material, and are for the use of the intended addressee only. If you are not the intended addressee or an authorised recipient of the addressee please notify us of receipt by returning the e-mail and do not use, copy, retain, distribute or disclose the information in or attached to the e-mail. Any opinions expressed within this e-mail are those of the individual and not necessarily of Diamond Light Source Ltd. Diamond Light Source Ltd. cannot guarantee that this e-mail or any attachments are free from viruses and we cannot accept liability for any damage which you may sustain as a result of software viruses which may be transmitted in or with the message. Diamond Light Source Limited (company no. 4375679). Registered in England and Wales with its registered office at Diamond House, Harwell Science and Innovation Campus, Didcot, Oxfordshire, OX11 0DE, United Kingdom
