Notes
(0029663) Alan Scott (manager) 2012-11-07 21:31 edited on: 2012-11-07 21:32	Find data needs to be cleaned up. This is extremely important functionality that we have been asking for for a long time - needs to be implemented.

(0029867) David Thompson (developer) 2012-12-11 12:36	The request says "Be able to take this min and/or max and display it in tabular format. Allow it to be 2d plotted. Allow it to be written out as a CSV file." The spreadsheet view now in the selection inspector should display the matching cells or points at a single time step. 1. What would the axes for a 2-d plot include besides the scalar value? Time? 2. Using Extract Selection from the selection inspector should allow min or max values to be written to a CSV now. Or is this also intended to mean "over time"?

(0029871) Ken Moreland (manager) 2012-12-12 10:24	The functionality of Find Data has changed since this bug was originally written. Most of the implementation is there. That is, you can ask for the min or max of a field and see the values in the spreadsheet contained in the Find Data dialog. However, the plotting over time functionality is broken. To replicate, do the following: 1. Load can.ex2. Go to the last time step. 2. Open Find Data. 3. Construct the query to Find Cell from can.ex2 where EQPS is max. 4. Click Run Selection Query. The results show up in the spreadsheet (so far so good). 5. Click Plot Selection Over Time. Apply the filter. Fail. I get a bunch of errors like this: ERROR: In /Users/kmorel/src/ParaView/VTK/Filters/Extraction/vtkExtractSelection.cxx, line 365 vtkExtractSelection (0x1160d79a0): Unrecognized CONTENT_TYPE: 9

(0029898) David Thompson (developer) 2012-12-17 18:41	The "Unrecognized CONTENT_TYPE" errors exist because vtkExtractSelection (in VTK, and used by vtkExtractArraysOverTime, also in VTK) does not know about QUERY selections; they are implemented in ParaView as a new type of vtkSelectionNode. This is also the cause of issue 10968 (no way to "freeze" query selections) as vtkExtractSelection is used to obtain IDs from the query. There are 2 strategies to deal with this: (1) migrate query-selection code from PV into VTK or (2) subclass things in VTK for use in PV. (1) Migrating query-selection code to VTK would also require vtkPythonProgrammableFilter be moved, which in turn would require vtkPVPythonInterpretor be broken into a subclass that could be moved to VTK. In order to keep VTK/Filters/Extraction from depending on Python, this would likely also involve some kind of "vtkInterpreterFactory" in Common/Core that could produce a vtkPythonInterpreter when linked to the proper kits. (2) All of the filters in VTK that use vtkExtractSelection would have to be subclassed for use by ParaView, including vtkExtractSelection, vtkExtractArraysOverTime, vtkPExtractArraysOverTime, and probably vtkConvertSelection (for bug 10968). The methods in these classes that use vtkExtractSelection are generally pretty hefty -- so either we add virtual methods to the VTK classes to construct selection extractors or duplicate a fair amount of code.

(0029966) David Thompson (developer) 2012-12-31 18:02	A workaround for query selections (see 2012-12-17 note above) eliminates the "Unrecognized CONTENT_TYPE" error. However, there is still an issue with the use case in Ken's 2012-12-12 note: query selections such as the maximum value can return different points/cells and different numbers of points/cells at each time step. In the face of multiple points/cells per timestep, how should the array extractor work? Is it necessary for the time-history plot to accommodate multiple values per time step? Would reporting a single (arbitrary) attribute value from each time step be adequate? If not, then would a min/max/mean/variance be adequate (this won't always make sense -- e.g., GlobalID or other index attribute)? Also, vtkExtractArraysOverTime currently outputs 1 table per (block,cell)-tuple in the selection (except for LOCATION selections). Should this be changed for QUERY selections? For simple queries, it makes sense to have one output table per queried attribute (e.g., a "global max" query on an attribute produces 1 output table, a ">=" query produces one table for each unique attribute value >= the user-specified value). However, for arbitrary query strings entered by the user, there would have to be one output table for each combination of "active" query clause and allowed value for that clause. For example, the query "(P < 10) & ((T > 323) \| (V < 5))" has 3 leaf clauses: P < 10, T > 323, and S < 5. In a dataset where P is in {8,9,10}, T is in {320,330,340}, and P is in {3,4,5}, there might be output tables labeled "P=8,T=330", "P=8,T=340", "P=9,T=330", "P=9,T=330", "P=8,V=3", "P=8,V=3", "P=9,V=4", and "P=9,V=4". Furthermore, tuples that match both the T and V clauses would be repeated in multiple tables. The simplest solution seems to be either a single output table per query, but in that case we must report some statistic(s) across all tuples at a given timestep.

(0030042) David Thompson (developer) 2013-01-09 12:39	The 10958_query_seln_over_time branch fixes "Plot arrays over time" to support query selections (based on attribute values rather than ID or viewport selections). The underlying VTK classes have also been modified to compute statistics on the selection and report those instead of creating a vtkTable time-history for each point or cell in the selection. Statistics are always reported for query selections and an option is provided in the ParaView UI to obtain statistics for other selections. The statistics include the interquartile boundaries (min, q1, median, q3, and max) and -- for numeric arrays -- the mean and standard deviation of all selected points/cells within a given time step. These values are reported for each time step.

(0030106) Utkarsh Ayachit (administrator) 2013-01-11 14:43	merged into master, where applicable.

(0030341) Alan Scott (manager) 2013-02-13 12:55	This bug is waiting for 13794 to be resolved. since this is really a superset of that bug, I am keeping both open. When 13794 closes, retest this one.

(0032067) Alan Scott (manager) 2013-12-24 19:42	Moving to "todo". We rolled this functionality out - since it was not working in parallel. Very important to get done.

(0033087) David C. Lonie (developer) 2014-07-25 07:49	No longer active on this project.

(0033132) Alan Scott (manager) 2014-07-29 16:27	This bug has been fixed in other bug reports. Lets close this one off, let users actually use this new code, and write new bugs/ feature requests at that time. Closing.

Issue History
Date Modified	Username	Field	Change
2010-07-08 12:31	Alan Scott	New Issue
2010-07-08 12:35	Alan Scott	Relationship added	child of 0010627
2010-08-30 22:22	Alan Scott	Relationship added	related to 0009808
2010-09-01 11:25	Utkarsh Ayachit	Target Version	3.10 => 3.10.shortlist
2011-06-16 13:10	Zack Galbreath	Category	Feature Request => Feature
2012-05-22 19:27	Alan Scott	Relationship added	related to 0013150
2012-05-22 22:38	Utkarsh Ayachit	Assigned To	=> Utkarsh Ayachit
2012-05-22 22:38	Utkarsh Ayachit	Status	expired => backlog
2012-05-22 22:38	Utkarsh Ayachit	Resolution	open => reopened
2012-11-07 21:31	Alan Scott	Note Added: 0029663
2012-11-07 21:31	Alan Scott	Status	backlog => todo
2012-11-07 21:32	Alan Scott	Note Edited: 0029663
2012-11-07 21:41	Alan Scott	Project	=> Sandia
2012-11-07 21:41	Alan Scott	Type	=> incorrect functionality
2012-12-11 09:50	Sebastien Jourdain	Assigned To	Utkarsh Ayachit => David Thompson
2012-12-11 12:36	David Thompson	Note Added: 0029867
2012-12-12 10:24	Ken Moreland	Note Added: 0029871
2012-12-17 18:41	David Thompson	Note Added: 0029898
2012-12-17 18:42	David Thompson	Relationship added	related to 0010968
2012-12-31 18:02	David Thompson	Note Added: 0029966
2013-01-09 12:39	David Thompson	Topic Name	=> 10958_query_seln_over_time
2013-01-09 12:39	David Thompson	Note Added: 0030042
2013-01-09 12:39	David Thompson	Status	todo => gatekeeper review
2013-01-09 12:39	David Thompson	Resolution	reopened => fixed
2013-01-11 14:42	Utkarsh Ayachit	Fixed in Version	=> git-master
2013-01-11 14:43	Utkarsh Ayachit	Status	gatekeeper review => customer review
2013-01-11 14:43	Utkarsh Ayachit	Note Added: 0030106
2013-01-30 10:40	Utkarsh Ayachit	Fixed in Version	git-master => 3.98.1
2013-02-13 12:51	Alan Scott	Relationship added	related to 0013794
2013-02-13 12:55	Alan Scott	Note Added: 0030341
2013-12-24 19:42	Alan Scott	Note Added: 0032067
2013-12-24 19:42	Alan Scott	Assigned To	David Thompson => Utkarsh Ayachit
2013-12-24 19:42	Alan Scott	Status	customer review => todo
2014-01-16 13:46	Utkarsh Ayachit	Assigned To	Utkarsh Ayachit => David C. Lonie
2014-03-07 09:12	David C. Lonie	Status	todo => active development
2014-07-25 07:49	David C. Lonie	Note Added: 0033087
2014-07-25 07:49	David C. Lonie	Status	active development => todo
2014-07-25 09:38	Utkarsh Ayachit	Assigned To	David C. Lonie =>
2014-07-25 09:39	Utkarsh Ayachit	Target Version	=> 4.2
2014-07-29 16:27	Alan Scott	Note Added: 0033132
2014-07-29 16:27	Alan Scott	Status	todo => closed
2014-07-29 16:27	Alan Scott	Assigned To	=> Utkarsh Ayachit
2014-07-29 16:27	Alan Scott	Fixed in Version	3.98.1 => 4.2
2014-07-31 09:21	Utkarsh Ayachit	Fixed in Version	4.2 => git-master
2014-08-29 10:59	Utkarsh Ayachit	Fixed in Version	git-master => 4.2