-
Notifications
You must be signed in to change notification settings - Fork 3
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
plotting, take 2 #27
Comments
The new plotting utilities look great! Looking at
I also think the |
Ya these are good questions.
…-for how many grid levels to plot, IMO the best option is to find the largest grid level that contains the desired x and y limits, and to plot recursively from that grid level down to the finest, overlapping the finer grids to get higher resolution images in the regions where that higher fidelity data is available. Then, of course, trimming off any excess from that coarsest grid to get exactly the user-requested x and y limits. I was to lazy and plotted all grids and then let the limit specifications remove the excess. Might be slick to remove plotting the extra (coarser) grid levels that extend beyond the desired limits (though adding the extra plots is probably not too much overhead unless a gif is being made in which case take several naps before checking back in). But for me, I like having the finer grids always overlap the coarser ones so we get the finest data where its available. Thoughts?
-Not sure why the glev arg I broken in the if loop, sorry about that! I’m definitely open to adding a glev kwarg/making whatever changes necessary to fix that issue. Though if we go with a glev kwarg, maybe we can have that in addition to, rather than instead of the limit specs. I feel like for some users the use of glev will be harder to grasp than “I want to plot over these physical limits”.
Pushback/thoughts welcome!
On Sep 23, 2021, at 9:06 AM, Jared Callaham ***@***.***> wrote:
The new plotting utilities look great! Looking at plot_state... it seems like the logic is to plot all grid levels unless xlims and ylims are set to :auto, but sometimes it'd be good to just choose one grid level to plot, right? Here's the function:
function plot_state( prob, state, t;
var=:omega, xlims=:auto, ylims=:auto, clims=:auto, clevs=30)
if (xlims==:auto) & (ylims==:auto)
#Would be nice to add vel mag
if var == :omega
plot_ω(state, prob.model.grid, lev=1, clims=clims, xlims=xlims,
ylims=ylims, clevs=clevs )
plot_bodies(state.xb)
elseif var == :vel
plt = plot(layout=(2,1))
plot_u(state, prob.model.grid, lev=1, clims=clims, xlims=xlims,
ylims=ylims, plt=plt, clevs=clevs )
plot_bodies(prob.model.bodies, plt=plt )
elseif var == :psi
plot_ψ(state, prob.model.grid, lev=glev, clims=clims, xlims=xlims,
ylims=ylims, clevs=clevs )
plot_bodies(prob.model.bodies)
end
else
if var == :vel
plt = plot(layout=(2,1))
end
for glev = prob.model.grid.mg : -1 : 1
#Would be nice to add vel mag
if var == :omega
plot_ω(state, prob.model.grid, lev=glev, clims=clims, xlims=xlims,
ylims=ylims, clevs=clevs )
if glev==1
plot_bodies(state.xb)
end
elseif var == :vel
plot_u(state, prob.model.grid, lev=glev, clims=clims, xlims=xlims,
ylims=ylims, plt=plt, clevs=clevs )
if glev==1
plot_bodies(prob.model.bodies, plt=plt )
end
elseif var == :psi
plot_ψ(state, prob.model.grid, lev=glev, clims=clims, xlims=xlims,
ylims=ylims, clevs=clevs )
if glev==1
plot_bodies(prob.model.bodies)
end
end
end
end
end
I also think the glev reference in theif var==:omega block is broken. Would you object to me adding a glev kwarg and choosing to either plot one level or multiple based on that, rather than the xlims, ylims condition?
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub <#27 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AFREW54ZYPUMJNDNNLZUY4DUDMX75ANCNFSM5ANWQQUQ>.
Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>.
|
Ohh I missed that the domain would resize to the limits given. Yes, I definitely see your point about specifying the limits vs the level. Thinking about it now, that does make sense - aside from debugging, you probably wouldn't need to look at the coarse solution in the finely resolved region. Part of the problem was an issue I was having with my plots that made it seem like something strange was going on. Also plotting all grid levels adds a lot of overhead, but I think your suggestion about finding the minimum level to capture the specified extent would take care of that nicely. I'll try to think of a good way to implement that when I have a minute. |
The text was updated successfully, but these errors were encountered: