Ian's words need to emblazoned over all CCP4 distributions.

Users are an essential part of any development work..


As a developer I would never consider constructive user feedback as a
complaint.  Feedback is a critical component of the software development
process and I think I speak for all developers in only wishing that there
was a lot more of it!

On 24 November 2017 at 10:06, Ian Tickle <ianj...@gmail.com> wrote:

>
> Hi Graeme
>
> On 24 November 2017 at 06:33, Graeme Winter <graeme.win...@diamond.ac.uk>
> wrote:
>
>>
>> Despite appearances people do not like to contact authors of software
>> packages to complain.
>>
>
> As a developer I would never consider constructive user feedback as a
> complaint.  Feedback is a critical component of the software development
> process and I think I speak for all developers in only wishing that there
> was a lot more of it!
>
> 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.
>>
>
> This assumes that it make sense to perform the corrections downstream of
> processing.  In the case of anisotropy this may not be the case: the
> anisotropy correction is likely to be intimately linked with the batch
> scaling and error model, so that it only makes sense to incorporate the
> anisotropy correction as an integral component of the processing pipeline,
> not downstream.
>
> 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...
>>
>
> I totally agree!  STARANISO has the option to transfer over all the
> uncorrected data and append the corrected data to it.  This used to be the
> default but is no longer (you have to check a box to activate it), because
> users seemed to get confused by having too many MTZ columns to choose from!
>
>
>> Obviously, all of the above is my humble opinion and other opinions are
>> equally valid.
>>
>
> Likewise!
>
> Regards
>
> -- Ian
>
>

Reply via email to