Question about the simulated annealing implementation in TeleportationRouter

[seo0824]

I am a student new to GitHub, so I apologize in advance if anything is unclear or incorrectly formatted.

I read the paper at https://arxiv.org/abs/2512.04169 and then studied the simulated annealing implementation in util_routing.py — specifically run_annealing and perturbation in TeleportationRouter. My understanding of the flow is as follows:

1. All two-point VDP paths in the current layer are initialized as three-point Steiner trees.
2. For each tree, a teleportation destination is chosen uniformly at random within a fixed radius of the initial terminal position.
3. Either the control or target qubit is randomly selected and teleported to that destination. The cost (routing depth over the next k_lookahead layers) is then evaluated.
4. If the cost improves, the candidate is accepted and stored as best_cost. Even if the cost worsens, the candidate may still be accepted as the new current solution with probability exp(-delta / T) — however, even when accepted, the search neighborhood does not shift to be centered around the newly accepted position. In other words, the next perturbation still samples from the neighborhood of the original terminal, not the accepted one.
5. Steps 2–4 are repeated for max_iters iterations, and the best solution found is returned.

Based on this reading, it seems that even when a better solution is accepted, it is not actually exploited — the next iteration still samples randomly from the neighborhood of the initial terminal position. This means the algorithm effectively performs a random search over the neighborhood of the initial terminal for max_iters iterations, rather than true simulated annealing where the current solution guides the next neighborhood to explore.

In standard simulated annealing, accepting a new solution should shift the search to the neighborhood of that solution, allowing the algorithm to gradually move toward better regions of the search space. That directional property does not seem to be present here.

Could you clarify whether this is intentional? And if so, what design decision motivated sampling from the initial terminal's neighborhood rather than the currently accepted solution's neighborhood?

Thank you for your time.

[seo0824]

I apologize for the confusion in my previous post! I mistakenly stated that the search always starts from the initial terminal position, but I now realize that steiner_dct is updated upon acceptance, so the search origin does shift to the newly accepted terminal at each step. It seems the simulated annealing is working as intended after all. Thank you for your time.