Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Use experiment identifiers from import #1086

Merged
merged 8 commits into from
Jan 16, 2020

Conversation

jbeilstenedmands
Copy link
Contributor

This is an updated version of a previous PR (#902).

The idea is the same, generate a unique (uuid) string identifier on import, do the same when discovering lattices upon indexing, and propagate through the processing (and checking each time so that files without identifiers still work for back compatibility). Most of the file changes are updating the flatten_reflections/flatten_experiments calls, to handle any order of input data from the command line.

At the moment, most programs don't really use the identifier to any particular benefit, that can come as part of future work as required.

I have also generated a uuid in the stills indexer as a demonstration, and checked that stills processing still completes fine (although there are possibly more complex workflows that i am not able to properly check?). Without the changes to stills_indexer.py, no identifiers are generated (at any point in stills processing), and the processing completes the same. I would like to ask for feedback from @asmit3 or @phyy-nx as to which option is preferred:

  1. Generate a uuid now, as per this PR, and let you guys change the format of this to timestamp at a later point if interested.
  2. Leave stills_indexer.py unchanged, so that no identifiers are generated for stills at present (although this may cause issues if using the regular indexer for stills which is sometimes done?)
  3. Let you add to this PR to generate a timestamp identifier in stills_indexer.py.

@jbeilstenedmands jbeilstenedmands marked this pull request as ready for review January 9, 2020 16:32
@asmit3
Copy link
Member

asmit3 commented Jan 11, 2020

Hi @jbeilstenedmands , we will take a look at this on Monday pacific time and get back. Please hold on till then. Thanks

@asmit3
Copy link
Member

asmit3 commented Jan 13, 2020

Hi @jbeilstenedmands , @phyy-nx and I took a look at this PR and it looks good to be merged.

@jbeilstenedmands
Copy link
Contributor Author

@asmit3 thanks for taking a look at this.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants