[sharp-discuss] autosharp not reading column headers in mtz files

Phil Evans pre at mrc-lmb.cam.ac.uk
Fri Aug 17 10:33:53 CEST 2012


Yesterday I got this error, and it seemed to be fixed by replacing mtzdump with an old version. This morning I tried restoring the new failing mtzdump, but it still seems somehow to run the old one and then works OK. Also I can't see any significant differences between the output of the new & old mtzdump, so I'm not at all sure this was indeed the problem

I'm deeply confused at this point

Phil


On 17 Aug 2012, at 08:55, Phil Evans wrote:

> 
> I'm not now convinced about this as I'm not sure I can repeat it - investigating further
> 
> Phil
> 
> On 16 Aug 2012, at 18:15, Phil Evans wrote:
> 
>> 
>> OK got it
>> 
>> The new CCP4 has a version of mtzdump which subtly changes its output format, and Autosharp scrapes the output log file to extract the information which it's complaining about
>> 
>> Immediate fix is to replace mtzdump with an older version
>> 
>> Phil
>> 
>> 
>> On 16 Aug 2012, at 17:18, <Stephen.carr at rc-harwell.ac.uk> <Stephen.carr at rc-harwell.ac.uk> wrote:
>> 
>>> Dear All,
>>> 
>>> I am experiencing a frustrating error when trying to run autosharp.  After inputting the data via the httpd interface, the program is having trouble extracting information from the input datasets and keeps giving the error
>>> 
>>> No column "F_NAT" of type "F" found in file
>>> 
>>> mtzdump reveals that there is indeed a column of this name, yet autosharp cannot seem to read it.
>>> 
>>> I have tried this with several different data-sets and each gives the same sort of
>>> error.  All data sets which give this problem have been processed/scaled etc. using ccp4 6.3.0
>>> which appears to output each data-set in two parts, the first (sub)-data-set contains
>>> HKL and FreeR_Flag columns only, while the second contains all the other columns.  I think
>>> this might be the cause of the problem, since running a data-set scaled etc using an older
>>> version of ccp4 did not give this error and the data are read with no problems.
>>> 
>>> Has anyone else observed something similar and does anyone have any suggestions/workarounds
>>> that will allow me to run autosharp with this data?
>>> 
>>> Any help would be greatly appreciated.
>>> 
>>> Best wishes,
>>> 
>>> Steve
>>> 
>>> Dr Stephen Carr
>>> Research Complex at Harwell
>>> Rutherford Appleton Laboratory
>>> Harwell Oxford
>>> Didcot
>>> Oxon OX11 0FA
>>> United Kingdom
>>> Email stephen.carr at rc-harwell.ac.uk
>>> tel 01235 567717
>>> 
>>> 
>>> This email 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 authorized 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 this email.
>>> 
>>> Any views or opinions presented are solely those of the author and do not necessarily represent those of the Research Complex at Harwell.
>>> 
>>> There is no guarantee that this email 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.
>>> 
>>> We use an electronic filing system. Please send electronic versions of documents, unless paper is specifically requested.
>>> 
>>> This email may have a protective marking, for an explanation, please see:
>>> http://www.mrc.ac.uk/About/informationandstandards/documentmarking/index.htm.
>>> _______________________________________________
>>> sharp-discuss mailing list
>>> sharp-discuss at globalphasing.com
>>> https://www.globalphasing.com/mailman/listinfo/sharp-discuss
>> 
>> _______________________________________________
>> sharp-discuss mailing list
>> sharp-discuss at globalphasing.com
>> https://www.globalphasing.com/mailman/listinfo/sharp-discuss
> 



More information about the sharp-discuss mailing list