JiscMail Logo
Email discussion lists for the UK Education and Research communities

Help for DIALS-GENERAL Archives


DIALS-GENERAL Archives

DIALS-GENERAL Archives


DIALS-GENERAL@JISCMAIL.AC.UK


View:

Message:

[

First

|

Previous

|

Next

|

Last

]

By Topic:

[

First

|

Previous

|

Next

|

Last

]

By Author:

[

First

|

Previous

|

Next

|

Last

]

Font:

Proportional Font

LISTSERV Archives

LISTSERV Archives

DIALS-GENERAL Home

DIALS-GENERAL Home

DIALS-GENERAL  October 2015

DIALS-GENERAL October 2015

Options

Subscribe or Unsubscribe

Subscribe or Unsubscribe

Log In

Log In

Get Password

Get Password

Subject:

Re: Reindex

From:

Richard Gildea <[log in to unmask]>

Reply-To:

[log in to unmask]

Date:

Thu, 1 Oct 2015 14:19:59 +0000

Content-Type:

text/plain

Parts/Attachments:

Parts/Attachments

text/plain (95 lines)

I think this added complication would be more than offset by removing at least two (unnecessary, IMO) command line steps. It should be fairly trivial to solve, and would help stop users making mistakes, so I don't see what the drawback is.

Cheers,

Richard

________________________________________
From: Waterman, David (STFC,RAL,SC)
Sent: 01 October 2015 15:13
To: Gildea, Richard (DLSLtd,RAL,LSCI); [log in to unmask]
Subject: RE: Reindex

Hi Richard

I see command line DIALS as a fairly low level toolkit. The individual tools have essentially one purpose each, and should stick to doing that well. Users can make mistakes, but they could also be using xia2 or the GUI (in the future) if unsure, so we are not excluding the inexperienced. I don't like silent (or even noisy but overlooked) changes to the data. I know in the past I have argued that the output of refinement should *only* be the refined models, but eventually relented and write out the refined.pickle as well. I don't really like the idea that this might now contain different indices to the input .pickle. It just adds complication in my view, and will not help e.g. comparison of residuals before and after.

I would prefer that change of basis and reindexing are handled together by a single dials tool (with its own command), as these operations go hand in hand.

Cheers
David


________________________________________
From: DIALS project general discussion [[log in to unmask]] on behalf of Richard Gildea [[log in to unmask]]
Sent: 01 October 2015 14:57
To: [log in to unmask]
Subject: Re: Reindex

Hi Graeme,

In fact if you always re-index the reflection list before refinement (or before integration since you can go straight from dials.refine_bravais_settings to dials.integrate) using the input experiments.json then no need to compare with original indices even (other than perhaps a sanity check). There is a function in indexing module to do assign indices given a reflection list and an experiment list, although might need modifying to cope with scan-varying crystal models if is to be used by dials.refine and dials.integrate.

Cheers,

Richard

________________________________
From: Graeme Winter [[log in to unmask]]
Sent: 01 October 2015 14:46
To: Gildea, Richard (DLSLtd,RAL,LSCI); [log in to unmask]
Subject: Re: Reindex

HI Richard

Discussed this with David yesterday in train; I think we can discover the reindex operation from inspection of the data - should be simple enough yes by essentially "reindexing" with the matrix file from expts and comparing with the reference indices

Think this was what Phil was getting at...

Cheerio G



On Thu, Oct 1, 2015 at 2:43 PM Richard Gildea <[log in to unmask]<mailto:[log in to unmask]>> wrote:
Hi Phil,

Thanks for the suggestions. I've never been particularly happy with the way the dials.reindex step fits in the process, but haven't been able to come up with a suitable alternative (other than to go back and re-run dials.index in the correct space group). Your suggestion of tracking the change of basis operator alongside the experiments.json and reflections does seem to have merit, although we would need to discuss internally exactly how to go about it.

Another alternative could be to output the bravais_setting_NN.json files in the same basis as the input, i.e. primitive setting, then they would be compatible with the original indexed.pickle without reindexing the reflection list. Then downstream programs like dials.refine could choose to optionally convert to the reference setting on input. Any thoughts on this workflow? When we eventually get around to the one-hdf5-file-to-rule-them-all version of DIALS that James is keen on, then hopefully these kinds of problems will go away.

Cheers,

Richard
________________________________________
From: DIALS project general discussion [[log in to unmask]<mailto:[log in to unmask]>] on behalf of Phil Evans [[log in to unmask]<mailto:[log in to unmask]>]
Sent: 01 October 2015 10:50
To: [log in to unmask]<mailto:[log in to unmask]>
Subject: Reindex

Following up on the Dials demo yesterday

The process is

1) dials.index -> indexed.pickle

2) dials.refine_bravais_settings -> bravais_setting_NN.json

choose a setting, then if necessary reindex

3) dials.reindex indexed.pickle change_of_basis_op=a,b,c -> reindexed_reflections.pickle

followed by something like
4) dials.refine bravais_setting_9.json indexed.pickle scan_varying=true [ or reindexed_reflections.pickle]

however it seems to me that step 3 (a complication for pipelines, and a hazard for manual working)  could be incorporated into step 4. You know that indexed.pickle is in the “original” frame (and could usefully be internally stamped as such), and bravais_setting_NN.json does or should include the change of basis operator, so it could be applied automatically. This would be safer

Just a suggestion

Phil

--
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

Top of Message | Previous Page | Permalink

JiscMail Tools


RSS Feeds and Sharing


Advanced Options


Archives

July 2017
November 2015
October 2015
September 2015
May 2015
April 2015
March 2015
December 2014
October 2014
September 2014
June 2014
May 2014
April 2014
March 2014
January 2014
July 2013
June 2013
May 2013
April 2013
March 2013
February 2013
January 2013
December 2012


JiscMail is a Jisc service.

View our service policies at https://www.jiscmail.ac.uk/policyandsecurity/ and Jisc's privacy policy at https://www.jisc.ac.uk/website/privacy-notice

Secured by F-Secure Anti-Virus CataList Email List Search Powered by the LISTSERV Email List Manager