Volume bug using an exponentially stretched mesh

[crazyfireji]

• [0.10.5 ] what version of Makie are you running? (]st -m Makie)
• [No ] can you reproduce the bug with a fresh environment ? (]activate --temp; add Makie)
• [intel ] What platform + GPU are you on?
• When the mesh distribution is not uniform, like this:.
  
  The correct isosurface distribution should look like this:
  
  But in Makie.volume it looks like this:
  
  The height of the isosurface on y is much higher than the actual value. It should be caused by the program automatically dividing the grid in the y direction equidistantly( y=range(0, stop=y0[end], length=length(y0)) ) , and the coordinates used in volume are not y0, but y. Similar grids and data distributions can be obtained from the following websites:
  http://hal.dmt.upm.es/

[SimonDanisch]

It's hard to tell what you're doing without any comment or code.
It looks like you're using Axis3, which scales the data to fit the window better.

[crazyfireji]

It's hard to tell what you're doing without any comment or code. It looks like you're using Axis3, which scales the data to fit the window better.
There are a lot of people in the CFD industry who have encountered this problem in Makie. Following is the same fig plots by tecplot.

my julia code like this:

fig = Figure(size=(650,430),figure_padding=(-15, -15, 0, -50))
ax = Axis3(fig[1,1],
    # azimuth = 1.5*pi,
    # yreversed = true,
    aspect=:data,
    # aspect = (1, 1, 1),
    xlabel="x",
    ylabel="z",
    zlabel="y",
    limits = (x[1], x[end], zz[1], zz[end], 0, 0.3)
)
heatmap!(ax, x, yy[1:189], U[:,1,1:189],
    colormap = cgrad(:RdBu, rev = true),
    space = :data,
    colorrange = (0,1),
    transformation = (:xz, zz[end])
)
volume!(ax,x, zz, yy, U,algorithm=:iso, isovalue=0.1)
ylims!(ax, zz[1],zz[end])
zlims!(ax, 0,0.3)
display(fig)

[SimonDanisch]

There are a lot of people in the CFD industry who have encountered this problem in Makie. Following is the same fig plots by tecplot.

Well, that doesn't really help narrow down the problem, especially if all those people never raise an issue^^

A simple MWE does seem to do the correct thing from what I understand:

fig = Figure()
ax = Axis3(fig[1, 1],
    aspect=:data,
)
volume!(ax, 0..10, 0..10, 0..1, rand(100, 100, 100), algorithm=:iso, isovalue=0.1)
fig

Can you make something I can run, to have some actual values, that reproduces the issue?

[SimonDanisch]

Ah, I see, I didn't see that your x/y/z aren't uniform.
This should actually error, since it's simply not implemented.

[jkrumbiegel]

We introduced warnings for the 2d case for image at some point, we should probably just make those hard errors instead because the behavior for non-uniform vectors is plain wrong, and then add the same thing for volume for the 3d case:

julia> image([1, 2, 4], [2, 3, 4], rand(3, 3))
┌ Warning: Encountered an `AbstractVector` with value [1, 2, 4] on side x in `convert_arguments` for the `ImageLike` trait.
│         Using an `AbstractVector` to specify one dimension of an `ImageLike` is deprecated because `ImageLike` sides always need exactly two values, start and stop.
│         Use interval notation `start .. stop` or a two-element tuple `(start, stop)` instead.
└ @ Makie ~/.julia/packages/Makie/pFPBw/src/conversions.jl:416
┌ Warning: Encountered an `AbstractVector` with value [2, 3, 4] on side y in `convert_arguments` for the `ImageLike` trait.
│         Using an `AbstractVector` to specify one dimension of an `ImageLike` is deprecated because `ImageLike` sides always need exactly two values, start and stop.
│         Use interval notation `start .. stop` or a two-element tuple `(start, stop)` instead.
└ @ Makie ~/.julia/packages/Makie/pFPBw/src/conversions.jl:416

Might still be able to put this into the breaking release

[SimonDanisch]

I think we already have the same warnings for volume

[crazyfireji]

I think we already have the same warnings for volume

Ok, Thanks for your reply!

[jkrumbiegel]

@SimonDanisch right I'm mostly saying we should turn the warnings into errors at this point