Let's devise simple I(t) curves drawing on an analytically defined distribution with an analytically derived g2, a known ground truth. Then we can test the implementations against them.

We plan to merge in all the existing implementations we can find that are accessible from Python. A requirement for merging a new implementation is that it be installable on our CI service and pass a nominal test. A very minimal smoke test is fine, to start, just something to show that the code runs,

These include variants of 1-time and 2-time (and higher-order if they exist.)

• implementations in https://github.com/scikit-beam/scikit-beam (there are a couple)
• implementations by @yugangzhang in https://github.com/yugangzhang/pyCHX and possibly other repositories, which have some similarities to the scikit-beam implementations but also some important differences
• three relatively new implementations by @aryabhatt (Python, pybind11-wrapped-C++, a separate FFT approach) https://github.com/aryabhatt/multitau
• https://github.com/AdvancedPhotonSource/xpcs-eigen once it is has Python bindings and meets the CI requirement

We are open to adding any others that we don't currently know about.

In CI, download the dataset generated by a LAMMPS simulation, run the implementations against it, obtained a measured coefficient of diffusion, and compare it to the known ground truth. We could define some tolerance for passing a test using pytest, or we could just track the accuracy using asv.

Code is at: https://github.com/aryabhatt/xpcs-baseline
Binary artifact is on Globus at: https://daf20b.36fe.dn.glob.us/My Drive/XPCS Sims/xpcs750k.h5

I think after #7 for pip install to work we need the presence of FFTW. We'll need a mechanism to detect FFTW headers at build time (similar to how pybind11 is handled). For conda recipe it's easy (just set fftw to be a build dependency), but I'm not sure how to cleanly resolve this for PyPI packaging...

This could be a valuable resource https://github.com/swcarpentry/close-enough-for-scientific-work

I am testing the compatibility with CuPy and I notice this error:

import cupy as cp
import numpy as np
import autocorr


N = 10240
np.random.seed(0)
t = np.arange(N)
A = np.exp(-0.05 * t)[:, np.newaxis] + np.random.rand(N, 24) * 0.1

A_cp = cp.asarray(A)
g1, tau = autocorr.multitau(A_cp.T, 16)

Traceback (most recent call last):
  File "test_autocorr_cupy.py", line 13, in <module>
    g1, tau = autocorr.multitau(A_cp.T, 16)
  File "/home/leofang/autocorr/autocorr/multitau.py", line 57, in multitau
    g2[:, i] = np.mean(a[:, :N - i] * a[:, i:], axis=1) / t1 / t2
ValueError: object __array__ method not producing an array

The reasons is that internally multitau allocates two arrays g2 and tau using NumPy API, which is not (yet) smart enough to dispatch to CuPy.

I tried to refresh my memory on NEP-18, but I don't think this issue was addressed there. Looks like to accommodate different NEP-18 compliant arrays, we need to detect the array source and call the corresponding array-creation API?

if isinstance(input, numpy.ndarray):
    g2 = numpy.empty(...)
elif isinstance(input, cupy.ndarray):
    g2 = cupy.empty(...)
elif  # dask? sparse?

I may have missed something obvious, though.

The .zip file contains:

1. XPCS ontology (.doc)
2. Sample result file based on the ontology (.hdf)

The .hdf file can be viewed in any standard hdf viewer and can be read out item-by-item using the h5py package in python.

Ontology_and_Sample_Result.zip