User Guide

The guide builds on the Quickstart and covers cuPeriod in depth — what it accepts, how to choose a method, how to read and tune results, and how to scale up. Each page stands on its own; read top to bottom for a complete tour.

Light curves & inputs

Every accepted input — arrays, dicts, DataFrames, astropy/pyarrow tables, and files — plus column auto-detection and the magnitude/flux domain.

Choosing a method

A decision guide to the seven methods: what each is for, its objective sense, and its key knobs.

Reading results

Periodogram, Peak, and MultiResult: peak finding, alias-aware selection, per-method extras, and serialization.

Backends & performance

auto / cpu / gpu and the concrete backends — what each method runs on and what’s fast where.

Tuning: settings & grids

Per-method settings models, environment-variable overrides, and custom frequency/period grids.

Multi-band light curves

Jointly model several filters of the same star with GLS, BLS, and MHAOV.

Batch processing

Scale to millions of light curves over CPU pools or the GPU, with resumable Parquet output.

Command line

The cuperiod command line: run, batch, methods, gpu-info, grid-info.

Mental model

A run is always the same three steps, whether you call the function or the CLI:

1. Input → a LightCurve (or MultiBandLightCurve). cuPeriod coerces tuples, tables, and files for you (Light curves & inputs).

2. Method + grid → the trial frequencies/periods to evaluate. Each method builds a sensible default grid; you can override it (Tuning: settings & grids).

3. Backend → where the math runs (auto picks the GPU when present). The result is a Periodogram you query for the best periods (Reading results).

The single entry point cuperiod.periodogram() ties these together; its batch sibling cuperiod.batch_periodograms() does the same for many light curves at once.