Plotting recipes (in order to clean up doc plots)

[mileslucas]

Plotting recipes (in order to clean up doc plots)

[icweaver]

Hey all, I've started learning about plot recipes to try and have a go at this, but I think that I am running into a problem with the bounds. It seems that evaluating at the lower wavelength limit throws an error, while evaluating at the upper limit seems fine:

> law = GCC09()
GCC09
  Rv: Float64 3.1

> bound_lower, bound_upper = bounds(law)
(909.09, 3030.3)

> law(bound_lower)
ERROR: out of bounds of GCC09, support is over (909.09, 3030.3) angstrom

> law(bound_upper)
1.8451270235624522

Is it intended for the bounds to not be inclusive on the lower end? If so, should there be some sort of tolerance we should add to the plot recipe to avoid going out of bounds? For now, I've just been doing something like this as a toy example:

@recipe function f(t::T) where T <: ExtinctionLaw
    @inline aa_to_invum(wave::Real) = 10000 / wave
    lower, upper = bounds(t)
    w = range(lower + 0.1, upper, length=1000)
    w_invum = aa_to_invum.(w)
    w_invum, t.(w)
end

[mileslucas]

Is it intended for the bounds to not be inclusive on the lower end?

No, the intention is that law.(bounds(law)...) should not error and should be non-zero (unless the law returns 0 there)

Why is this happening?

It seems like there slight inconsistencies in the bounds and the if-else branch inside GCC09

The lower bound is 909.09 Angstrom, which is 11.000011000011 using Float64. The if-else branch for GCC09 will throw an error for anything above 11 invum.

what is the solution?

Fix the inconsistency! Either we need to change the output of bounds or we need to change the upper invum bounds.

If we change the bounds, they should become

(909.0909090909091, 3030.3030303030305)

If we change the branching, it should become

(3.3000033000032998, 11.000011000011)

How do we stop this in the future?

This should be easy to wrap into a test that can be used for all the laws, I can open a PR for this briefly. Edit: oops, this for-loop already exists, it just doesn't test if the law doesn't error.

The recipe

What you've got looks pretty good! A couple notes

• You can use the aa_to_invum within the library instead of redefining
• once the bounds are fixed you won't need to alter the start point
• You'll want to play around with the default plot attributes. The plots docs explain these decently, but the gist is: always use full names (no aliases), use --> to allow overriding, use := to disallow overriding. I would start with label --> "law_name", and xlabel, ylabel.

[icweaver]

Awesome, thanks for the PR and the recipe tips! I'm looking forward to trying these out

[icweaver]

Ok, I am getting something like this now (c0a6a23).

Is there a way to just get the model name instead of DustExtinction.<model name>?

[mileslucas]

this looks like a great start! FYI for the multi-RV plots, you should be able to condense this

begin
    fig = plot()
    Rvs = [2.0, 3.1, 4.0, 5.0, 6.0]
    for Rv in Rvs
        law = F04(Rv)
        plot!(law)
    end
    fig
end

to this!

begin
    Rvs = [2.0 3.1 4.0 5.0 6.0]
    plot(F04.(Rvs))
end

Some improvements: I'd put the number of points into a kwarg N=1000 -> x = range(..., length=N) and start working on some of those options I listed on the original post!

The pluto notebook looks pretty cool, I enjoy the html outputs

[icweaver]

Thanks for the tips! Were you thinking something more like this (8b2506c)?

haha, glad you like the notebook. btw, the latest version on master uses JuliaMono by default now!