mamut_routing_tools.family.naming¶
Naming and on-disk layout of a MAMUT benchmark collection (v2, Stream 12').
One base instance = one customer set = one name across every problem type:
poryos-<city>-n<N>-<method> (method in {poi, hyb}). TD subinstances append
-<model>-<intensity> (6 per base). Extra static-only VRPTW TW sets append
-tw-<set> (the tw- prefix cannot collide with the TD tags); the
TD-paired VRPTW instance keeps the bare base name, mirroring the TDVRPTW
twins that embed the same windows. The family lives in a single family-first
collection repo mounted at benchmarks/Poryos2026/:
sidecars/<city>/n=<N>/<base>/ shared sidecars of the base
CVRP/<metric>/<city>/n=<N>/<base>/
VRPTW/fastest/<city>/n=<N>/<base>/ one file per TW set
TDVRP/<city>/n=<N>/<base>/<sub>/
TDVRPTW/<city>/n=<N>/<base>/<sub>/
family_prefix
¶
A family's base-name prefix: its name minus the trailing release year.
Poryos2026 -> poryos, Mamut2026 -> mamut. A rule rather than a
lookup table, so adding a family means picking a name and nothing else.
Source code in MAMUT-routing-tools/src/mamut_routing_tools/family/naming.py
base_instance_name
¶
base_instance_name(
city: str,
n: int,
method_tag: str,
family: str = FAMILY,
*,
route_count: int | None = None,
) -> str
<family>-<city>-n<N>[-k<K>]-<method>.
route_count is the bin-packing minimum fleet. It is only written into the
name for families in :data:FAMILIES_WITH_FLEET_IN_NAME, and passing it for
a family that does not want it is a caller error rather than a silent no-op:
a name that sometimes carries k and sometimes does not is unparseable.
Source code in MAMUT-routing-tools/src/mamut_routing_tools/family/naming.py
vrptw_instance_name
¶
TD-paired set: the bare base name; static-only sets: <base>-tw-<set>.
Source code in MAMUT-routing-tools/src/mamut_routing_tools/family/naming.py
sidecar_relpath
¶
Collection-root-relative sidecar path (the form stored in instance refs).