coverage: 95.01% (+0.04%) from 94.969% when pulling8e84d00 on murrayrm:freq_plots-30Jun2023 into0a6146b on python-control:main.

Just a few quick thoughts/comments, I may have more late if/when I have a chance to test it.

Overall this seems to be very much in the spirit of the original discussion and will fix some oddities as well as making mimo plots easier to work with.

I think breaking code that doescounts = ct.nyquist_plot(sys) seems reasonable because we probably shouldn't mix plotting and computation functionality; a plot function should return references to plotting objects (as it will with this PR).

Clever idea for how to handle lists of responses. Is this considered a legit pythonic way to do that?

This is looking good and fixes some long-standing bugs/cobwebs. A few comments/questions, some of which I might be able to answer by deeply looking into the code, but I a quick reply giving the high level thinking might be very informative:

• does theresponse know what kind of plot it is intended for? is it different for a nyquist plot than for a bode plot? in other words,response = nyquist_response(sys); response.plot() will create a nyquist plot andresponse=frequency_response(sys); response.plot() will create a bode plot? are the frequency points and ranges actually the same?
• and you can override the default type using theplot_type argument?
• seems like the_plot functions should be the ones that are strongy emphasized in the docs becase of the aforementioned subtleties
• relatedly, in the discussion ofin nyquist plots, draw contour at specified magnitude if threshold is exceeded #671, you mentioned inthis post that you had created a branch that included enhancements to computing points near poles. Not sure if that ever made it in, but I am including it here for reference.

Clever idea for how to handle lists of responses. Is this considered a legit pythonic way to do that?

I think so. It is allows to uselist as the base class of a new object (since Python 2.2) and presumably the reason is to add functionality to the list class, which is what was done here. Others may know more.

This seems to be the time to deprecateomega,omega_limits, andomega_num in favor of the more generalfrequency,frequency_limits, andfrequency_num given that omega suggests rad/s even though these are specified in either rad/s or hz depending on the defaults.

Edit: looking elsewhere, sticking withomega may make more sense for nyquist and nichols. not sure about bode yet. Would be nice to be able to specify ranges in Hz for the bode plot though - was this a feature before?

This is worth thinking about. I find theomega_limits andomega_num to be a bit odd and it would be nice to have a consistent way of dealing with this. This is not directly related to the new plotting paradigm, so perhaps for a separate PR.

• does theresponse know what kind of plot it is intended for? is it different for a nyquist plot than for a bode plot? in other words,response = nyquist_response(sys); response.plot() will create a nyquist plot andresponse=frequency_response(sys); response.plot() will create a bode plot? are the frequency points and ranges actually the same?

Yes. All of the plots keep track of the type of command that generated them and then call the appropriateplot function. This also happens in the time response plots, where the default output for a step response is different than a forced response (the former shows output only, by default, the latter shows outputs and inputs).

Regarding the frequency points/ranges: these are different for Bode and Nyquist. A Bode plot uses the frequency response, which evaluates an LTI system on the positive imaginary axis. A Nyquist plot evaluates the response along the Nyquist "D" contour. So these are not exactly interchangeable (more below).

and you can override the default type using theplot_type argument?

Yes, but not for Bode and Nyquist, since those are actually different responses. Here's a summary of various things that work:

• Thesingular_value_response function generates a frequency response and, by default, plots the singular values (magnitude only, all outputs on a single graph). You can change that usingplot_type='bode', which will then show that response as standard Bode plot. You can do the same in the reverse direction: if you callplot_type='svplot' on a frequency response, it will attempt to generate a singular value plot. (Usually that is the wrong thing to do since singular values are real and so a warning is issued if the imaginary part of a frequency response is nonzero for a singular value plot.)
• The types of plots supported byFrequencyResponseData.plot() using theplot_type keyword are 'bode', 'svplot', and 'nichols' (for a Nichols chart).
• There is noplot_type='nyquist' functionality because these are different responses.
• In principle, we could set things up to generate a Nyquist plot from a frequency response object by passing the response to thenyquist_response (ornyquist_plot) function. However, this could generate odd responses since we don't know how to complete the Nyquist curve around poles, at the origin (which is a real value), or at infinity (if the transfer function is not strictly proper).

seems like the_plot functions should be the ones that are strongy emphasized in the docs becase of the aforementioned subtleties

Agree.

relatedly, in the discussion ofin nyquist plots, draw contour at specified magnitude if threshold is exceeded #671, you mentioned inthis post that you had created a branch that included enhancements to computing points near poles. Not sure if that ever made it in, but I am including it here for reference.

Those changes are all in the main branch now (via#534).

I'll leave this open for a bit longer in case others have comments, but looks to me like this is OK to merge, with a later PR for thinking through improvingomega_{limits,num}.