The following arguments of start_scan:
input_time_name: strinput_pos_name: stroutput_particle_name: str
define the starting seed (fallback_*) and the current seed output_particle_name.
These arguments are never used and they always correspond to default values.
What reco modules do now is write the starting seed to the default value of input_(pos|time)_name (server-side) which is cfg.INPUT_(POS|TIME)_NAME and read the current seed from the default value of output_particle_name (client-side) which is cfg.OUTPUT_PARTICLE_NAME.
In other words, there is no benefit in defining any of this in start_scan. The reco module could provide a name for the starting seed (optionally, more than one) while output_particle_name is purely conventional.
The following arguments of
start_scan:input_time_name: strinput_pos_name: stroutput_particle_name: strdefine the starting seed (
fallback_*) and the current seedoutput_particle_name.These arguments are never used and they always correspond to default values.
What reco modules do now is write the starting seed to the default value of
input_(pos|time)_name(server-side) which iscfg.INPUT_(POS|TIME)_NAMEand read the current seed from the default value ofoutput_particle_name(client-side) which iscfg.OUTPUT_PARTICLE_NAME.In other words, there is no benefit in defining any of this in
start_scan. The reco module could provide a name for the starting seed (optionally, more than one) whileoutput_particle_nameis purely conventional.