reverse course re sequential construction?

[kainagel]

"We" had made a decision to recommend sequential construction for matsim runs, i.e.

1. first load the config and then possibly modify it
2. then load the scenario and then possibly modify it
3. then load the controler and possibly modify it
4. finally run the controler

Looks like we have repeatedly problems with the issue that the injector is not yet available during step 2. E.g. in drt, freight, roadpricing. I am wondering if we should maybe change the preferred build sequence to something like

Config config = ...
Controler controler = new Controler( config ) ;
Scenario scenario = controler.getScenario() ; // which would then implicitly load the scenario
// modify scenario here
// modify controler here
controler.run();

Does anybody have intuitions on that? Evidently, I want to avoid that we change the recommendation, and then run into even larger difficulties.

[sebhoerl]

Maybe this also adds to the discussion: For the French scenario pipeline I often need only the router (for some pre-analysis, cutting the scenario, ...), and I want to make sure that the router is set up with the exact same arguments with which it will be used later on in the simulation. So I'm using this InjectorBuilder as a tool to set up an Injector based on a Scenario (but the main point is the underlying Config) to later do something like injector.getInstance(TripRouter.class) to do some batch routing, etc: https://github.com/eqasim-org/eqasim-java/blob/develop/core/src/main/java/org/eqasim/core/misc/InjectorBuilder.java

I guess the use case for drt would be similar, like getting a vehicle / network factory or something like this before the simulation starts?

I think the proposition above looks good, but maybe we could think of something like this?

Config config = ... ;

ControllerBuilder builder = new ControllerBuilder(config);
builder.addOverridingModule(new DrtModule());

Injector injector = builder.buildInjector();
// Do some prelimiary things with injector

Scenario scenario = ... ;

Controler controler = builder.buildController(scenario);
controler.run()

I don't oppose the proposition above, but having a ControllerBuilder could also be a nice way of further formalizing the all the methods that set up the controller (adding overriding modules), and it would be a way to push towards "non-double-overriding" modules as is discussed in another issue. Plus, it would make the controller really the component that gets other things from the injector and executes them ("controls" them) while the setting up is done with the ControllerBuilder. Just some thoughts ...

[kainagel]

Good idea, exposing the injector might indeed be a better option. I am, in fact, even teaching it this way, and only then explaining how matsim hides the injector.