# DensityPlot: Error messages and strange bar legend

### Bug introduced in 11.1.1 or earlier and persists through 12.0

I want to plot the following DensityPlot with axes given by Trr and n:

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 -> 100, MaxRecursion -> 1, AspectRatio -> 1/1.4, PlotRangePadding -> None]


Mathematica provides me with the correct plot, but the legend bar is shown with this weird red error figure and no ticks or labels.

The error messages I get are

Coordinate {Indeterminate, Indeterminate} should be a pair of numbers, or a Scaled or Offset form.

Coordinate {{Indeterminate, Indeterminate}, Offset[{4., 0}, {Indeterminate, Indeterminate}]} should be a pair of numbers, or a Scaled or Offset form.

Coordinate {{Indeterminate, Indeterminate}, Offset[{2.5, 0.}, {Indeterminate, Indeterminate}]} should be a pair of numbers, or a Scaled or Offset form.

Thank you for your help!

## 1 Answer

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@LegendingLegendDumpiColorGradientLegend =
DownValues@LegendingLegendDumpiColorGradientLegend /.
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 LegendingLegendDumpiColorGradientLegend):

newdrawrange =
scalefns[[1]]@
Sort@
scalefns[[2]][
LegendingLegendDumptoInteger /@ 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@LegendingLegendDumpiColorGradientLegend =
DownValues@LegendingLegendDumpiColorGradientLegend /.
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.

• Thank you @Lukas Lang. I am not so expert to fully understand your answer, but it works!
– Lele
Commented Oct 17, 2019 at 10:32