Looks like a bug to me, please report it to Wolfram support (you might want to include a link to this as well, so they don't have to do the debugging again, which should hopefully result in a faster fix).
To fix it, execute the following code once:
DownValues@Legending`LegendDump`iColorGradientLegend =
DownValues@Legending`LegendDump`iColorGradientLegend /.
HoldPattern[ndr_ = sf_[[1]]@Sort@sf_[[2]]@inner_] :>
(ndr = sf[[2]]@Sort@sf[[1]]@inner);
Now the plotting works as expected:
Mpl = 2.4*10^18;
mpsi = 1000;
Lambda = 10^15;
xR = 10^-5;
DensityPlot[
135*Sqrt[10]/(8*Pi^8*106.75^(3/2))*Mpl*
mpsi/Lambda^2 (mpsi/Trr)^(-n/2)*
NIntegrate[(BesselK[2, x]^2 - BesselK[1, x]^2)*x^(2 + n/2), {x, xR,
1000}], {Trr, 10^-3, 10^3}, {n, 1, 4},
ScalingFunctions -> {"Log10", Automatic, "Log10"},
PlotLegends -> Placed[BarLegend[Automatic], {After, Top}],
Ticks -> {ScientificForm[#], Automatic, Automatic},
FrameLabel -> {"\!\(\*SubscriptBox[\(T\), \(r\)]\) [GeV]", "n"},
PlotPoints -> 4, MaxRecursion -> 0, AspectRatio -> 1/1.4,
PlotRangePadding -> None]

How the fix works
The seems to be a mix-up with the handling of the scaling functions for the z-range. Internally, the specification "Log10"
is converted into {Log10, 10^#&}
, i.e. the scaling function and its inverse. To go from real values to plot coordinates, the first one is used, the second one to go back. The problem now lies in the following line used to sort the plot range limits (can be found in Legending`LegendDump`iColorGradientLegend
):
newdrawrange =
scalefns[[1]]@
Sort@
scalefns[[2]][
Legending`LegendDump`toInteger /@ drawrange
];
In your case the following happens:
drawrange
is {6.36934*10^-26,3.08555*10^-11} (i.e. the z-range)
toInteger
does nothing
scalefns[[2]]
is 10^#&
(so it is supposed to be used to convert plot-coordinates to actual values, not this way around)
scalefns[[1]]
normally reverts the action of scalefn[[1]]
, but here the result is {0.,3.08555*10^-11}
, since 10^6*^-26
is 1.
due to rounding errors
So while the code is incorrect (the scalefns
are applied in the wrong order), this is usually not relevant - they are inverses of each other, so the values stay the same. The sorting will typically also work, since for monotonous scaling functions (which they should always be), the inverse is also monotonous, with the same sign (i.e. both increasing or decreasing)
Seeing that the only thing we care about is sorting here, the following should also work and is safer (since we're not relying on the fact that applying both scaling functions returns exactly the same thing back)
DownValues@Legending`LegendDump`iColorGradientLegend =
DownValues@Legending`LegendDump`iColorGradientLegend /.
HoldPattern[ndr_ = sf_[[1]]@Sort@sf_[[2]]@inner_] :>
(ndr = SortBy[sf_[[1]]]@inner);
(Note how we use SortBy
to not need the back-scaling after the fact.