Post-1.0 design note: trajectory-scale and parallel tessellation workflows

[IvanChernyshov]

Outcome

Preserve trajectory-scale, repeated-frame, and parallel-computation ideas as an explicit post-1.0 research direction without expanding the pre-1.0 static-geometry contract.

This issue is a design placeholder, not an implementation commitment. Revisit it only after the forward and inverse static core is stable and there is concrete evidence that dynamic workflows belong in pyvoro2 rather than in chemvoro, an alternative backend, or orchestration code.

Activation triggers

Begin substantive work only when at least one of the following exists:

• chemvoro or another downstream project has a concrete repeated-frame use case;
• end-to-end profiling identifies repeated tessellation or inverse fitting as a practical bottleneck;
• upstream Voro++ or another viable backend exposes stable parallel or batch functionality worth integrating;
• users request a frame-sequence API with reproducible examples and scale requirements.

Design questions

When activated, evaluate separately:

• parallel or batch forward tessellation;
• repeated inverse solves on fixed or changing observation graphs;
• warm starts and reusable sparse matrix structures;
• direct versus iterative linear solvers and preconditioners;
• factorization or symbolic-structure reuse;
• changing periodic images, candidate graphs, and component structure;
• frame-level provenance, diagnostics, partial failures, and restart behavior;
• whether functionality belongs in core pyvoro2, an optional backend adapter, or downstream chemvoro orchestration;
• the state of Voro++ and alternative implementations at that time.

Out of scope

• implementation before the v1.0 static contract is stabilized;
• adding a trajectory, batch, or mutable prepared-solver API now;
• speculative parallel-backend abstractions without a selected backend and measured need;
• promising GPU, distributed, or multicore performance;
• treating static thousand-site support as evidence of trajectory-scale throughput.

Acceptance criteria

• The issue is activated only after v1.0 or through a separate explicit scope decision based on a concrete need.
• A design note separates forward-backend parallelism, repeated inverse linear algebra, and workflow orchestration.
• Current upstream and alternative backend capabilities are surveyed when the issue is activated, rather than assumed from the present state.
• Representative workload and profiling evidence are recorded before implementation is selected.
• Any proposed API has explicit ownership, lifecycle, failure, and provenance semantics.
• No pre-1.0 release depends on this issue.

References

• docs/project/roadmap.md
• docs/development/plans/v0.7.md
• Implement and benchmark sparse quadratic separator solving for large static geometries #17 static sparse quadratic separator solving

Stop conditions

Stop before implementation if there is no demonstrated repeated-frame bottleneck, if an upstream/backend update is expected to solve the relevant problem more cleanly, or if the workflow belongs more naturally in chemvoro than in pyvoro2 core.