UC1 compute

[sbillinge]

Problem

need a test for UC1

UC 1 - compute amd (or another representation) from a structure

1. Simon wants to compute the amd from a structure as he is working in diffpy-cmi
2. Simon passes the structure to diffpy.similarity (ds)
3. ds computes the amd and returns it simon

Proposed solution

write it. Define expected and actual so we get the right API definitions. Maybe we want a module with all the structure representations. We need a name for it. representations.py? then we would have from similarity.representations import amd which seems to make sense. In this file define but make it empty. Something like

def amd(structure):
'''
<write the full docstring>
'''
return

Then in tests create test_represnetations.py and write the test, making use of the fixture in conftest.py

[tinatn29]

List of representations to code

• [Andrew] PDF
  output: 2-column numpy array [r, G(r)]
• [Tina] PDD
  output: n (num atoms in the unit cell) x k (int: num distances we want to list from each atom) matrix, numpy array
• [Tina] AMD (average of PDD across n atoms (n rows))
  output: k-pt vector, numpy array
• [Zoe] ACSF (averaged across all atom centers)
  output: 1D numpy array (default: 35pt)
• [Zoe] SOAP (averaged across all atom centers)
  output: 1D numpy array (default: 84pt)
• [Andrew] AY's Distance Matrix
  output: n x n matrix (symmetric), numpy array

Assume we take in structure (ASE) as an input, and compute these representations as an output.

Timeline
Andrew = scikit-package this first so we can start from a clean package #14

Tina = week of 7/21-7/25
Andrew = week of 7/7-7/11
Zoe = lightly start something week of 7/7-7/11

[sbillinge]

I would much rather that we code this passing around diffpy.DiffractionObjects internally than output: 2-column numpy array [r, G(r)]. Why? It helps us develop this code-base and make it better and more useful.

There may be a performance hit or something, but that is something we would like to find out (and fix). Of if this idea really isn't working for this purpose, maybe it was a bad idea all along and we scrap it.

We don't have a diffraction object for G(r) or R(r) though. I wonder if we could code that up first? @Sparks29032 what do you think?

[sbillinge]

List of representations to code

btw, this list in this comment is really fantastic!

Please can we make an issue for each of these (if not done already) and we will start closing issues as we do this work. I will make a milestone for our initial release.

[sbillinge]

Everyone, I wonder also whether the "metric calculators" and possibly the "similarity calculators" should be in diffpy.utils as general diffraction utilties, and diffpy.similarity is more focused on the app (CLI, GUI, web-services, whatever)?

So most of the "library" code is in utils for easier reuse by others, and end-user apps are here. What do you think? It doesn't make any difference to the coding tasks (except where you make PRs).

[tinatn29]

@sbillinge I can create individual issues from the list we have above^.

RE: utils -- since we're using ASE structure object primarily (for now), is there a reason to keep it separate from now and only add to utils the functions that work with diffpy structure object? I don't have a strong preference, just checking if there's a preferred practice here with different structure object choices.

[sbillinge]

I think the idea is to figure out what our basic structure class should be and to adapt everything to that over time, so I wouldn't use that as a decision metric.