FoxWise
September 13, 2017, 2:24pm
#1
Dear root users, I have a strange calculation of convolutions of 2 defined functions gaus and exponent.
The result graph in some places randomly has 0 value… And I have some parody on the exponent. See below.

So I cant understand how to solve it. I have tried another method of making Convolution through TF1Convolution but it gives the same results… Can someone help me with this one? I will really appreciate that.

Have a nice day, all!

Besh.cxx (2.5 KB)

I think @moneta should be able to help you…

I blame the ROOT’s “Integral” method, so try with FWHM=10 …

If you do not like this plot, you can also try:
ROOT::Math::IntegratorOneDimOptions::SetDefaultIntegrator("Gauss");
TF1Convolution *f_conv = new TF1Convolution(f1, f1, emin, emax, false);
You will then have four different curves, so you should be able to pick one for you [:mrgreen:]
Well, you could try all different available ROOT’s “1-dim integrators”: “Gauss”, “GaussLegendre”, “Adaptive”, “AdaptiveSingular” and “NonAdaptive”.
Seven different curves should be a “good m…
Why are you still complaining [[-(]
You now have three different integral values, so you can choose the one you like the most [:mrgreen:]
Using “ROOT::Math::IntegratorOneDimOptions::SetDefaultIntegrator(…);”, you could try all different available ROOT’s “1-dim integrators”: “Gauss”, “GaussLegendre”, “Adaptive”, “AdaptiveSingular” and “NonAdaptive”.
You will then have six different integral values to choose from [:mrgreen:]
BTW. ROOT’s “integr…
I don’t think your calls to “Integral” are wrong.
I guess it’s a deficiency in ROOT.
It’s the “efficiency” / “efficiencyF” function which fools ROOT. It’s value “jumps” between 0 and 1 and the current “integrator” is known to misbehave in such cases.
See also, for example: Simple Integral
Sometimes you can try to “hide” this problem if you increase the number of points … for each of your functions try to add:
SomeTF2->SetNpx(1000); SomeTF2->SetNpy(1000);
But I wouldn’t really trust the res…
A very brutal fix (works just in this case; in another cases you’ll need to “tune” the “number of points”):
g2D1->SetNpx(700); g2D1->SetNpy(700); // “number of points” >= 700
I guess the problem is that your “g2dBIF1” is not smooth at the “edge” given by the “radius” (i.e. it’s not differentiable there) and the “numerical integrator” gets fooled (there’s a “jump” from about 8000 to 0).
That’s not a problem for your “g2dBIF2” because the “radius” is much larger and the “jump” at the “edge” is …

system
closed
September 27, 2017, 6:58pm
#4
This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.