[Bug]: Contourf not filling contours.

[MajorMajor807]

Bug summary

I am using contourf to plot filled in contours, but some of the contours are not being filled in despite how values exist for those regions. I am including an example. The code behind the generation of R_mesh, Z_mesh, and total_mesh has been exempted for simplicity, but the problem remains the same.

Code for reproduction

R_mesh = [231.86725132, 220.86288631, 216.43404334, 218.98005375, 228.26765215], [231.86725132, 220.86288631, 216.43404334, 218.98005375, 228.26765215], [231.86725132, 220.86288631, 216.43404334, 218.98005375, 228.26765215], [231.86725132, 220.86288631, 216.43404334, 218.98005375, 228.26765215], [231.86725132, 220.86288631, 216.43404334, 218.98005375 ,228.26765215]

Z_mesh = [-7.63490996, -7.63490996, -7.63490996, -7.63490996, -7.63490996], [-11.37601584, -11.37601584 ,-11.37601584,, -11.37601584 -11.37601584], [-15.11712172 ,-15.11712172, -15.11712172, -15.11712172, -15.11712172], [-18.8582276 ,-18.8582276, -18.8582276, -18.8582276, -18.8582276], [-22.59933348, -22.59933348, -22.59933348 ,-22.59933348, -22.59933348]

total_mesh = [4.43525976e+11, 1.25268989e+12, 7.81002780e+11, 9.68138506e+11,
 7.19784559e+11], [5.78901696e+11, 7.39195444e+11, 5.09539414e+11, 5.71855175e+11,
 1.04552037e+12], [6.62614974e+11, 9.53285450e+11, 4.11946084e+11, 6.25574690e+11,
 1.02337644e+12], [5.67507355e+11, 1.56031749e+12, 5.85644771e+11, 7.38170995e+11,
 7.38700809e+11], [4.78096661e+11, 1.69161460e+12, 9.98356923e+11, 1.35783374e+12,
 4.43525976e+11]

import matplotlib.cm as cm

plt.figure()
plt.contourf(R_mesh, Z_mesh, total_mesh)

Actual outcome

Expected outcome

A similar image to the one in the actual outcome, but without the white space.

Operating system

OS/X

Matplotlib Version

3.2.2

Matplotlib Backend

No response

Python version

No response

Jupyter version

No response

Other libraries

No response

Installation

conda

Conda channel

No response

[jklymak]

Please give a self contained runnable minimal example.

[MajorMajor807]

Please give a self contained runnable minimal example.

Hello! Yes I just edited the code so it is self-contained and minimal.

[ianthomas23]

Your mesh folds over on itself. For 216.43404334 <= R_mesh <= 228.26765215 it is double valued. How do you expect that to be contoured?

[MajorMajor807]

I don't think that should be a problem. I looked at the documentation for contourf, and there is nothing stating that the contour cannot possibly have double values, or that the input arrays need to be in a particular order.

[jklymak]

Sure, the documentation should probably say that x and y need to be ordered monotonically. A PR with a documentation change would be welcome.

[MajorMajor807]

I am surprised by this, because I can produce 1-D plots using the plt.plot() command using these same, non-ordered arrays and they look fine. I can look into sorting these arrays somehow...

[ianthomas23]

How do you expect that to be contoured?

What I meant here was "what do you expect the contour plot to look like in the double-valued region?" If you ask for contour lines both sets will be rendered, which is presumably what you are expecting to see, but this is useless to you as you don't know which set of lines refer to which. If you ask for filled contours, do you expect both sets to be rendered on top of each other so that you only see one? Which one of the sets?

[ianthomas23]

For anyone else finding this issue in the future, I have checked exactly what is occurring here. The contouring algorithm doesn't care about the fold and returns filled polygon paths as usual. Under normal circumstances (without a fold) the polygon vertices are ordered anticlockwise (if x and y are both increasing or decreasing) or clockwise (if one is increasing and the other decreasing). The Agg renderer doesn't care about the vertex order as long as it is constant, and renders the polygons. But a polygon with a fold in it has some vertices ordered clockwise and some anticlockwise; the renderer chooses one or the other and hence only renderers part of the folded polygon.

[MajorMajor807]

It seems that the sorting has fixed this issue. I am including a sample of code that I used to sort the lists so that R and Z both increase/decrease and don't "fold." I used R_zip and Z_zip to then generate the R_mesh and Z_mesh variables above.

zipped_list = zip(R, total)
sorted_pairs = sorted(zipped_list)
tuples = zip(*sorted_pairs)

R_zip, total_zip = [ list(tuple) for tuple in tuples]