<div>Hi Silvan,</div><br><div>I was just following up on this, and we do have setCrossSection methods on Run, AnalysisHandler, and Analysis: are you not able to use these? I may have missed something: can you let me know what the issue is, please?</div><br><div>Thanks,</div><div>Andy</div><br><div><signature id="initial"><div><table cellpadding="0" cellspacing="0"><tbody><tr><td colspan="2"><div style="padding-bottom:15px;"><div><strong>Dr Andy Buckley, Lecturer / Royal Society University Research Fellow</strong></div><div>Particle Physics Experiment Group, University of Glasgow</div></div></td></tr><tr><td style="vertical-align:top;"></td><td><div style="font-size:0.9em;white-space:nowrap;border-left:2px solid gray;margin-left:20px;padding-left:20px;"><div><div></div><div></div></div></div></td></tr></tbody></table></div></signature></div><div class="gmail_quote_attribution">On Mar 15 2018, at 9:47 pm, Silvan Kuttimalai <silvan@slac.stanford.edu> wrote:</div><blockquote><br><div><div>Ok, then we will implement it in this way. The only caveat I can see is</div><div>that the cross section error cannot be set externally. It's probably not</div><div>huge issue but the error on the cross section shown in the output of</div><div>"MC_XS" would be off, for example. Would you be able to add such a function?</div><br><div>Best,</div><div>Silvan</div><br><div>On 03/15/2018 01:16 PM, Andy Buckley wrote:</div><blockquote><div>That seems simpler to me! No obvious issues: this way I think it's</div><div>guaranteed that the sum(w) and sum(w**2) terms will both be accurate,</div><div>and they should combine together consistently when you merge.</div><br><div>Cheers,</div><div>Andy</div><br><div>*Dr Andy Buckley, Lecturer / Royal Society University Research Fellow*</div><div>Particle Physics Experiment Group, University of Glasgow</div><br><br><br><div>On Mar 15 2018, at 6:49 pm, Silvan Kuttimalai</div><div><silvan@slac.stanford.edu> wrote:</div><br><br><div>Hi Andy,</div><br><div>thanks for the quick response! If I understand the issue</div><div>correctly, then</div><div>we might just as well re-set the total cross sections for our</div><div>sub-contributions and leave the sum of weights untouched. To me this</div><div>even seems like to conceptually better way of doing it. I just ran a</div><div>test and it appears to work for us. Would you see any issues in this</div><div>approach?</div><br><div>Best regards,</div><div>Silvan</div><br><div>On 03/15/2018 03:55 AM, Andy Buckley wrote:</div><br><div>Hi Silvan,</div><br><div>The issue is that more than the sum of weights alone is needed</div><div>now.</div><div>Can you also supply the sum of squared weights? If so, I'll add an</div><div>extra argument and an implementation to version 2.6.1.</div><br><div>Andy</div><br><div>*Dr Andy Buckley, Lecturer / Royal Society University Research</div><div>Fellow*</div><div>Particle Physics Experiment Group, University of Glasgow</div><br><br><br><div>On Mar 14 2018, at 11:45 pm, Silvan Kuttimalai</div><div><silvan@slac.stanford.edu> wrote:</div><br><br><div>Dear Rivet Authors,</div><br><div>we noted that in Rivet version 2.6.0 the method</div><div>AnalysisHandler::setSumOfWeights is not present anymore. We</div><div>used this</div><div>method in Sherpa in order to automatically split up our rivet</div><div>analysis</div><div>output by contributions from H and S events in MC@NLO for</div><div>example. To</div><div>get the normalization of these sub contributions right, we set</div><div>the sum</div><div>of weights explicitly at the end of the run. Is there an</div><div>alternative for</div><div>this procedure in the new version?</div><br><div>Many thanks,</div><div>Silvan</div><div>_______________________________________________</div><div>Rivet mailing list</div><div>Rivet@projects.hepforge.org</div><div>https://www.hepforge.org/lists/listinfo/rivet</div></blockquote></div></blockquote>