I’m quite new to RooStats and trying to run a slightly modified version of OneSidedFrequentistUpperLimitWithBands.C from the RooStats tutorial (file TestCount.C is attached as well as the input ROOT file with the workspace). Since the model has nuisance parameters, the code reports that it will do profile construction but when it scans over the POI and generates ToyMC it crashes (after a few successful iterations) with errors like:
[#0] ERROR:LinkStateMgmt -- RooAbsArg::redirectServers(alpha_MCSTATFAKEConstraint): ERROR, some proxies could not be adjusted
When I try to run using fewer ToyMCs the code runs fine. Therefore, I don’t really think the input is corrupt. I’ve also tried running with different (newer) ROOT versions w/o any success. Is this a known issue, do you have any suggestions. Thanks very much.
The sample output is also attached. I’m using root version:
ROOT 5.32/00 (branches/v5-32-00-patches@42934, Apr 03 2012, 16:56:53 on linuxx8664gcc)
I’m looking into this error (since a while). It’s a bit hard to debug since
I have no example that results in this error with <30 minutes of running,
but I do intend to fix this.
what is the status for this bug?
I’m experiencing the same bug with root 5.34/03:
[#0] PROGRESS:Generation -- generated toys: 1500 / 2000
[#0] ERROR:LinkStateMgmt -- RooAbsArg::redirectServers(expo_1_0): ERROR, some proxies could not be adjusted
Error in <TFoamCell::GetHcub >: Something wrong with linked tree
...
Sorry for the long silence on this - this error turned out be very complicated to debug, but
the status now is that the problem that is causing is has been understood.
The underlying issue is that proxy lists of pdfs are now stored in TRefArrays rather than TObjArrays
because the latter was giving problem when persisting certain classes of pdfs. As part of its operational magic a TRefArray stores unique object IDs rather than pointers.
However, the uids stored in TRefArray consists of a 24-bit UID part and a 8-bit PID part that are managed by TProcessID. Once more than 16777216 UIDs have been assigned (hex 0x1000000) TProcessID will continue to assign higher UID numbers, but the uid->obj conversion simply chops bits 25-32 off these high ID numbers so that a call to GetObjectWithID(16777216+i) returns the object assigned to UID i, which may be a very different object (or in many cases a null pointer).
This explains why the proxy assignments start being effected after a large number of toys, as toy setups
cause a lot of objects to be created and deleted. It also explains why it has been extremely difficult to debug this because it is not a genuine memory management problem that is detected by valgrind, nor it is reproducible easily since any example will take at least 30 minutes to get to the point where it starts failing.
I’ve been discussing a solution for this with the ROOT experts, and this involves doing some complicated trick
where TRefArray is used in the persistence part and TObjArray is used in the transient part as it not easy to extend the number of bits assigned to UUIDs. Work on this ‘proper’ solution is ongoing and will likely take
another week or so to completely finalize.
If you are not relying on persistence of RooFit objects (i.e. workspaces etc), you could in the mean time work around this by changing the type of the _proxyList datamember of RooAbsArg from TRefArray to TObjArray.
Thank you for your information regarding this bug. I too have been unable to generate toy datasets beyond a relatively small number O(1000).
In my case, I’m simply trying to save the generated dataset in .txt format, so it seems your suggestion of changing the type of _proxyList may work for me, but this is not a long-term solution because I would like to be able to use the default ROOT install at CERN.
Please update us on any progress regarding this bug.
Has this error been resolved? I am still running into this error message myself (after sufficiently long time executing), and assume it is the same error. My setup involves generating RooWorkspaces containing a model, then deleting the workspace and creating a new workspace with a slightly different setup of the model. After about 500 iterations of this it starts to throw the error described above. Can I resolve this?
I’m trying to do a simple fit where I want to replace a server (for a fit parameter) intentionally
to match the parameters fitted in two RooAbsPdfs. I noticed that I have the same error as
reported for the toy MC studies discussed in this post, and that error persists when I
upgraded to ROOT v5.34.18. Obviously I can re-write the RooAbsPdfs to avoid this problem
if required, so it’s not a pressing issue, but it would be good if someone could confirm if this fix
is now in ROOT, or if there is an additional patch that is required in order to ensure that
we are able to use RooAbsPdf::replaceServer(…)?
I don’t know if it will be of help to you, but I managed to make my warnings/errors go away by manually resetting the object counts. This worked for me because the objects I previously created were deleted and not needed again. So if you are in the same position, and not instead in a position where you are creating models so huge/complicated that you need more than the maximum allowed number of objects all at once, then you could try: