Recording this from #244 (comment), where the plan is that traces, traces_group and time_pars_dev should live only in the estimation result rather than being copied onto the model.
Agreed. Two details worth having written down before someone starts.
It is not a pure move. cumulative.py:270 and :357 derive the max_scale used to steer the search from event_model.time_pars_dev, so CumulativeMethod currently depends on the estimator producing a per-iteration trajectory. That dependency needs somewhere to go, or the control signal needs to come from something every estimator is obliged to provide.
The same coupling is why EventModel.fit now reads these with .get() rather than by key. An estimator that does not iterate has no traces, and the previous code raised KeyError inside fit before it could return anything.
Related, and cheap to fold in: xrtraces and xrtime_pars_dev name their dimension em_iteration, which puts a specific estimation method into the public xarray output.
Recording this from #244 (comment), where the plan is that
traces,traces_groupandtime_pars_devshould live only in the estimation result rather than being copied onto the model.Agreed. Two details worth having written down before someone starts.
It is not a pure move.
cumulative.py:270and:357derive themax_scaleused to steer the search fromevent_model.time_pars_dev, soCumulativeMethodcurrently depends on the estimator producing a per-iteration trajectory. That dependency needs somewhere to go, or the control signal needs to come from something every estimator is obliged to provide.The same coupling is why
EventModel.fitnow reads these with.get()rather than by key. An estimator that does not iterate has no traces, and the previous code raisedKeyErrorinsidefitbefore it could return anything.Related, and cheap to fold in:
xrtracesandxrtime_pars_devname their dimensionem_iteration, which puts a specific estimation method into the public xarray output.