You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
[RF] Don't keep the resolution model as a server of RooAbsAnaConvPdf
The resolution model passed to a RooAbsAnaConvPdf (RooDecay, RooBDecay,
...) is only a *configuration* object: it specifies which model to
convolve the basis functions with, and the pdf evaluates its own internal
convolutions, not the model itself. Yet it was kept as a (non-value,
non-shape) server, which polluted the computation graph and dragged the
model into RooWorkspace imports and HS3/JSON exports for no reason. It
also broke the HS3 round-trip, since the internal convolution objects
leaked into the JSON with non-conforming names.
The model is now an owned, non-server member instead. This deliberately
mirrors how RooResolutionModel already manages its basis function: a
raw owned pointer (_basis / _ownBasis) that is not a server and whose
redirection is forwarded in redirectServersHook(). See
RooResolutionModel.{h,cxx}. The HS3 exporter now lists its real
dependents explicitly (t, tau, model) instead of auto-exporting servers.
This follows up on 478ad2b, which noted that the model server could
not simply be removed without a server/proxy desync; removing the proxy
entirely avoids that desync by construction.
Schema evolution from class version 3 to 4 is handled with the standard
RooFit mechanism: a versioned `#pragma read` rule in LinkDef.h recovers
the model pointer from the old RooRealProxy, and a RooAbsAnaConvPdf::
ioStreamerPass2() override severs the stale server link once the graph is
live. This is the same two-stage pattern already used for the v5->v6
proxy-list migration (RooAbsArg::ioStreamerPass2) and for the read rules
of RooProduct / RooSuperCategory in roofitcore/inc/LinkDef.h. A unit test
reads back a v3 workspace fixture and checks the server structure,
getModel() and the evaluated values.
Closes#20245.
🤖 Done with the help of [Claude Code](https://claude.com/claude-code) (Claude Opus 4.8)
Copy file name to clipboardExpand all lines: README/ReleaseNotes/v642/index.md
+16-1Lines changed: 16 additions & 1 deletion
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -71,6 +71,21 @@ Users are strongly encouraged to switch to the vectorized CPU backend if they ar
71
71
72
72
If the vectorized backend does not work for a given use case, **please report it by opening an issue on the ROOT GitHub repository**.
73
73
74
+
### Resolution models are no longer imported into the workspace as standalone objects
75
+
76
+
When a `RooResolutionModel` (like `RooGaussModel` or `RooTruthModel`) is used wi th a
77
+
`RooAbsAnaConvPdf` (like `RooDecay`, `RooBDecay`, etc.), it acts as a *configuration* object that specifies which model to convolve the basis functions with, rather than as a nod
78
+
e of the pdf's computation graph.
79
+
The `RooAbsAnaConvPdf` builds its own internal basis-function convolutions from it and evaluates *those*.
80
+
81
+
Until now, the resolution model was nevertheless kept as a (non-value, non-shape) server of the `RooAbsAnaConvPdf`.
82
+
As a side effect, importing such a pdf into a `RooWorkspace` also imported the original resolution model as a standalone workspace object, and it leaked into HS3/JSON exports, even though it played no role in the computation.
83
+
84
+
Starting with ROOT 6.42, a resolution model that is only used as the configurati on of a `RooAbsAnaConvPdf` is no longer a server of that pdf, and is therefore not imported into the
85
+
workspace on its own anymore. The model remains accessible via `RooAbsAnaConvPdf::getModel()`.
86
+
87
+
This is not expected to affect typical usage, since the resolution model was never part of the actual likelihood. Workspaces written with older ROOT versions are read back correctly via schema evolution.
88
+
74
89
## Graphics and GUI
75
90
76
91
## Geometry
@@ -83,4 +98,4 @@ If the vectorized backend does not work for a given use case, **please report it
83
98
84
99
The version of the following packages has been updated:
0 commit comments