axis differences between plot_source() and plot('source') and issues with model plots about sherpa

[olaurino]

I need to translate this report in a number of tests. Here is my first attempt. @DougBurke please let me know if this makes sense or I got something wrong or something is missing. Plus, I have questions :)

So, the first (set of) test(s) is that the output of plt.ylim() should be the same between runs of plot_source(n) and plot('source', n) with n=1|2, where set_analysis can be set to either wave or energy. We should also test for unit strings on the y axis, as they should always be Photons/sec/cm^2/\AA. Should the values for the output of plt.ylim() always be (0, 10)?

The same should be true for plot_model(n) and plot('model', n), however with different units (this time Counts/sec/Angstrom. What should the values of plt.ylim() be this time?

I think there is another issue in that I see F(lambda) rather than F(\lambda).

Also, we should understand how/if we should test this with both matplotlib and chips, or maybe we can simply unit-test this making sure the backends are called with the correct parameters and data (i.e. we wouldn't test against plt.ylim()), but I would worry about that later.

[DougBurke]

@olaurino I made some changes to the plot labelling code after reporting this issue - see PR #107 - which explains why the report mentions labels like f(\lambda) and we now have f(lambda).

a) I believe that plot_source(x) and plot('source', x) should produce the same plot when there is no other change. I could imagine that - operationally - there is a reason for "small" differences between the two (they go through different code paths), but hopefully not.

Note that if I change the analysis setting then the output will change; that is

set_analysis(x, 'energy')
plot_source(x)
set_analysis(x, 'wave')
plot('source', x)

will produce different plots (by different I mean that for both axes the limits will be different, as will the data values plotted, and the axis labels).

b) I believe the same logic holds for the other plot types - e.g. as you mentioned plot_model() and plot('model').

c) Both a and b should hold for different data types (e.g. I am focussing on DataPHA here, but ideally we'd be testing the other plotting code). It might be easier to start with the other data types first, since they are simpler and hopefully already work!

d) The plot limits themselves - e.g. the output of plt.ylim() for matplotlib, pychips.get_plot_yrange() for chips - depends on the data being plotted, the plot type, and other settings (primarilyset_analysis`), as well as the plot back end. That is, the plot backends are allowed to select the axis limits. I also have not looked at the data here closely enough to say what the sensible limits are.

e) The Y axis labels for the 'source' case do not always end up "/Angstrom". This depends on the set_analysis setting, and is a bit tricky since the optional arguments to this function - type and factor - also change the plots (so it is not just the analysis argument). See issue #39 for more details.

[DougBurke]

I've created the gist https://gist.github.com/DougBurke/499fd3d3d7a51e06041008c598358391 that includes an example script (essentially the example I used originally) along with the plots I get with the current master branch for 'data', 'source', and 'model'.

Note that 'source' and 'model' are expected to be different ('source' can be considered to be the spectrum that is about to enter the telescope and 'model' is what is actually detected). We also have some (probably unclear) logic on whether source and/or model is to be displayed at the native resolution or binned up to match the data ( @anetasie has a better understanding of this than I do). I mention this partly because I note that, in the figures I added to the gist, it looks like the model is being drawn at a different resolution. Compare out_model1_nargs1.png (output of plot_model(1)) to out_model1_nargs2.png (output of plot('model', 1)) and you can see that the feature at around 3 keV is different.

[olaurino]

Alright, so this turns out to be rather tricky, and probably merits a face to face meeting to discuss what to do.

In a nutshell, the problem is that plot is a sherpa.ui.utils.Session method, inherited by sherpa.astro.ui.utils.Session. When you call sherpa.astro.ui.utils.Session.plot_source, the method checks the class of the dataset: if it's DataPHA, then sherpa.ui.utils.Session._plot is called with a special plot object defined in sherpa.astro...Session.

On the other hand, sherpa.ui.utils.Session.plot builds the call to _plot dynamically using the string argument passed to it. So, if you call plot('source'), _plot is given self._sourceplot as argument. However, when dealing with DataPHAs, it should be given self._astrosourceplot.

Right now I can't think of a way of fixing this issue without changing the fundamental architecture and make it more object oriented: if the plot depends on the data object class, then the data object class should be responsible for it and you can leverage polymorphism, without having to manually dispatch the method calls. But such change is big and risky.

The workaround is to call plot('astrosource') and plot('astromodel'), then you'll get the output you expect. But that requires the user to know when and why to use one string or the other.

[olaurino]

One way might be to override plot in sherpa.astro...Session, code the exceptions to the parent's cases, i.e. if the data is DataPHA, and fall back on the parent's method if the data is not DataPHA. This might work, but it goes in the wrong direction, increasing the complexity rather than reducing it.

[DougBurke]

I did not know you can use astrosource or astromodel as arguments!

Thanks for looking at this; I don't think it's somehting we can reasonably fix on the 4.8.2 timescale, as I'd prefer to work on improving the API/implementation rather than adding in hacks to work around issues. However, as you said we probably need to meet to discuss this, along with the other plotting issues - #39 #106 #241 and others - to identify short, medium, and long-term targets.