Consider creating a mechanism for submitting multiple times to the same hybrid sampler

[arcondello]

For example, if you wanted to submit multiple times to the hybrid NL solver without reuploading the model between runs, you could do so with something like

import numpy as np

from dwave.cloud.computation import Future
from dwave.optimization.generators import knapsack
from dwave.system import LeapHybridNLSampler


model = knapsack(range(100), range(100), capacity=100)
x, = model.iter_decisions()

sampler = LeapHybridNLSampler()

# Get the timelimit for the problem
time_limit = sampler.estimated_min_time_limit(model)

# We can upload at most one state
problem_data_id = sampler.solver.upload_nlm(model, max_num_states=1).result()

def hook(model, future):
    model.states.from_file(future.answer_data, check_header=False)

# 10 submissions
futures = []
for _ in range(10):
    futures.append(sampler.solver.sample_nlm(problem_data_id, time_limit=time_limit))

states = []
for completed in Future.as_completed(futures):
    model.states.from_future(completed, hook)

    # This needs to be saved "off" the model! It will be overwritten in the
    # next loop
    print(x.state())

    states.extend(np.asarray(x.state(i)) for i in range(len(model.states)))

print(states)

This seems to be a semi-common use case so bundling it into a method or function might be helpful.

Probably needs dwavesystems/dwave-optimization#185 in the case of NL to be done elegantly. For CQM/BQM/DQM we could use dimod.concatenate().

[randomir]

Implementing #528 (including problem_data_id) could help here.

[matti-sarjala]

A useful design boundary here may be between model identity and run identity.

The model is the reusable optimization object, while each submission/run should produce a separate result state or sample collection.

For repeated hybrid submissions, the important user contract seems to be:

1. Upload the model once.
2. Submit multiple independent runs against the same uploaded model.
3. Keep each run's returned states/samples separate.
4. Avoid mutating or overwriting the user's only copy of the model state unless explicitly requested.
5. Provide a clear way to concatenate or collect results across runs.

This matters especially for NL models where model.states appears to be the natural place to load results, but repeated runs can overwrite the previous state unless users manually copy it out.

A possible API shape could distinguish:

• problem_data_id: reusable uploaded model data,
• run_id or future: one solver execution,
• states / sampleset: result of a specific run,
• concatenate: user-visible aggregation across runs.

This would make the feature about repeated sampling of the same mathematical model, not about repeatedly mutating one model object in place.