> Summary: > 1. The second parameter in a 2-parameter display should inherit its time > selection from the first parameter. It doesn't. I agree. My concern is that if there is situation 2-parameter need to have different time selection.... > 2. The stop sign should actually stop a 158-time data loading process, so we > don't have to kill IDV. The multi threads communication between client and server is difficult to be killed by a client. we have not figured out how to do it. > 3. Minutes or hours of work shouldn't be so certain to be lost anytime > something goes wrong and IDV is killed or interrupted. > It is in our to do list, the tricky part is that when something goes wrong, it is likely involve memory and the information might not be saved correctly. Yuan > > ------------------ > Students made a potential temperature Isosurface colored by another parameter, > using the Best Time Series of GFS, with the time driver set. > End Time set to Current Time, begin time set to 0h relative to End Time. > > You choose potential temperature, choose "Isosurface colored by another > parameter", > choose "Match time driver", choose "all levels" since it is an isosurface > (* note: the default of 1000mb is not a smart default for an isosurface). > > Now the chooser pops up for you to choose the other parameter. > Choose geopotential height for example. > > > If you don't select "Match time driver", IDV will launch into reading 183 > time levels. ARRgh. > The running joke in class was that it is a game of "Simon Says". > (If you forget to do a meaningless, unnecessary thing, you get sent back to > the beginning.) > I warned them, and everyone knew the pitfall, but still, many people > wasted/lost time anyway. > Must it be so? > > > * Another Bug? > Reading 183 times cannot be stopped with the Stop Sign icon. That icon often > fails me. Can it be made more reliable? > > > * Repeated Suggestion: To repeat myself, it would be very nice if the IDV did > an auto-save every minute or so. > I have had students and myself lose a lot of minutes or even hours of work > because we did not save a bundle we were working on. > (explicitly, having to choose our own filename, cluttering the disk, > overwriting by Save dialog, again and again > since there is not even a ctrl-S save keyboard shortcut once a filename is > established). > > When the IDV crashes or sticks, or someone steps on the cord or whatever, > minutes or hours of work are lost. > It seems just rude not to offer this convenience in a complex piece of > software where people are certain > to invest a lot of time in an easily saveable but hard to recreate state > bundle. > > Why not a recentstate.xidv file in .unidata/idv that is auto-written every > minute? > Settable in Preferences if you think it will hamper performance for mere > displayers (as opposed to creators). > > > Thanks, > Brian > > Ticket Details =================== Ticket ID: WTE-108111 Department: Support IDV Priority: High Status: Open
NOTE: All email exchanges with Unidata User Support are recorded in the Unidata inquiry tracking system and then made publicly available through the web. If you do not want to have your interactions made available in this way, you must let us know in each email you send to us.