1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
/*!
Shared interface for physical spaces.
Purpose:
This trait gives higher-level simulation code one consistent way to read,
update, fill, and save a spatial container without knowing the container's
concrete geometry. A discrete cubic lattice, a future triangular lattice,
and a future continuous-space discretization can all expose the same basic
operations while keeping their own boundary rules and storage choices
private.
Coordinate contract:
Coordinates are passed as `isize` slices so callers can naturally express
physically meaningful out-of-domain locations such as `-1` or `l`. The
concrete space decides how those coordinates are interpreted. For example,
a lattice with periodic boundary conditions wraps them, while a reflective
lattice mirrors them at the wall.
Data contract:
The returned slice is a read-only view of the space's compact backing data.
It is useful for inspection, serialization, or aggregate calculations. It
does not promise a universal geometric layout across all future space
types; coordinate methods remain the stable way to address physical sites.
*/
use PathBuf;
use crateScalarSerde;