Catchpole no-spread plot does not look right

[mcgratta]

Run the new python script catchpole_spread_rates.py and look at Catchpole_no_spread.pdf. I don't recall who first made this plot or what it should look like, but something is amiss. Kick the issue back to me if you did not originally create the plot.

[ericvmueller]

Yup I added these summary plots to help supplement the hundreds of cases (so we might actually understand what is happening). I don't think they are even in the guide yet, because I wrote it in python and I was waiting for this switch over from matlab.
I'll take a look at the plots and then add them to the guide with a description.

[mcgratta]

It looks like that last plot uses another plotting convention. Try using plot_to_fig if possible. Also, I noticed that sometimes certain parameters were added to plot_to_fig after its first call. These were ignored. I try to add all formatting stuff, like version_string, x_label, x_min, etc, to the argument list of the first call. Subsequent calls should include only those things that change.

[ericvmueller]

The current method for the last plot does a lot of processing on the backend so if we want all formatting to depend on the default parameters, I might need to add some more pre-processing or consider other ways to visualize this. I'll think about it.

Do you have any examples where you do not use plot_to_fig (like a contour plot or something)? I'll try to avoid the 'custom' approach if I can, though.

[mcgratta]

No, because even with contours and flow vectors, I use plot_to_fig to establish the "window", axes, labels, ticks, etc. Then I use whatever matplotlib contour or vector plotter the converter chooses. Look at vort2d.py or the Memorial_Tunnel.py cases to see arrows and contours.

[ericvmueller]

Using your approach of an initial plot_to_fig call I can do everything without customization of the figure ...except the legend is transparent. The issue is the method I'm using creates its own legend so plot_to_fig doesn't help here.

I can make it opaque with one extra call to ax.legend(). If that's a dealbreaker, to reproduce the whole figure with only plot_to_fig I will need the ability to (1) set the alpha value of a line and (2) customize the axis tick labels ...which I don't think is possible right now.

[rmcdermo]

For now I'd say it is ok to customize your legend or whatever until we get through the initial transition. If we try to do every little thin in plot_to_fig we are going to keep running into issues like Jonathan experienced where we try to tweak something and then other things break.

[ericvmueller]

Okay, before I push this up the next question is...

Right now this script generates all the individual distance vs time plots that go into the guide. These were previously done in dataplot (and actually they still are for the time being). I was doing it in this script to customize the upper x bound, which is different for every run.

Either we can stick with this method and clean up 300+ entries in dataplot. Or I'll remove the individual plots from catchpole_spread_rates.py and I can hardcode an estimated upper bound for each entry in dataplot based on the experiments.

[mcgratta]

Can't you just add the upper bound to each individual dataplot entry? Or is the upper bound dependent on the actual run results?

[ericvmueller]

The FDS runs stop when the fire goes out (for a bunch of these we were previously simulating long periods with no fire spread, especially if goes out right away). If we use dataplot we can (1) use the upper bound from the experiment, but we might cut off some of the simulation, or (2) use the upper bound from T_END, and then maybe have some blank space in the plot.

I don't really mind either of those if dataplot is the preferred way to go. I was just trying to make things as tidy as possible.

[drjfloyd]

IMO, it is better if we can to use the main dataplot. That provides a good record of all our plots and ensures they are all processed into uncertainty statistics. These predictions hopefully don't vary alot with each run. Assuming this we can set each plot indivudually to get the right scale for whatever the current results and data are. If needed we can push up a changed scale if things change in the future (of course only for changes that we agree are reasonable due to some code change).

[ericvmueller]

Fair enough, though I was planning to use the spread rate calculated with this script in the uncertainty stats. In fact, another option would be to forego making individual distance vs. time plots altogether and just have a few combined figures of spread rate. This is what we do for the Crown Fires cases.

[mcgratta]

I think we need those distance vs time plots, even if there a lot of them. Sometimes the logic to compare ROS is not perfect and indicates either good or bad agreement in ways that might be deceiving.

[ericvmueller]

Okay the custom script should be doing only the additional summary plots now ...and better matching the standard format.

For dataplot, I would like to have the dependent variable, distance from ignition, only evaluated for slope using positions between 2 m and 7 m. This avoids edge effects and gives a more meaningful value of steady spread. However, for cases that don't spread there is no value in that range and matlab throws a warning like

Warning: Polynomial is not unique; degree >= number of data points. 
> In polyfit (line 80)
In dataplot (line 394)
In FDS_validation_script (line 48) 

will this get picked up by firebot and mess things up?

[mcgratta]

Probably, and we would want firebot to pick it up. Can you try adding a "Try" construct in and around line 394 or dataplot to escape the warning if need be.