You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
So, I've raised this question before (before we had GitHub discussions 😉). When we process various types of variables from databases, we classify them...
This leads to code blocks of conditional logic for each type all over the place (in database readers, in expression processing, in metadata, in GUI, in CLI metadata, in CLI expressions...its prolific how these classification permeates our coding and interfaces) where we do something special for each type but where that specialness doesn't always seem worthwhile.
What if we just decided NOT to classify database variables into these types and instead each variable had some properties that we care about...
int: number of components
int: tensor rank
bool: satisfies requirements for a coordinate field
bool: continuous in range space (means the field is continuously varying in "value" or not (e.g. is discrete instead))
templated type: range-space data type (e.g. int, double, etc.)
int[7]/int[7]: units (maybe...we don't really do this now except as arbitrary strings...see SAF data model.)
A Mesh plot of any (non-mesh) variable means to plot the mesh the variable is defined on.
A scalar plot (e.g. Pseudocolor, Contour, Volume...) of any (non-scalar) variable means to plot its magnitude
A Subset plot of any (non-subsetting) variable means to plot a contour plot of the variable's scalar interpretation
Subset works as FilledBoundary...no more Boundary plot either...just a swizzle on subet plot
A Curve lot of any (non-curve) variable plots its histogram (of its scalar interpretation)
etc., etc.
All plots would plot all variables. I think we can do reasonable things when users attempt to combine a variable an a plot in a way that doesn't necessarily make the most sense. There's no trimming lists of variables based on a classification...though I could maybe see some argument for using tensor rank where plots indicate which tensor ranks they support and variables are matched to them (actually, I think that is a problem with our current design as well, the knowhow about which classes of variables a plot supports is not part of plots...its scattered about in all the conditional logic that processes lists of variables). And, do our users really not understand their data so much that they could select a combination of variable and plot and then not understand the result they are presented with?
deliberationIssues that require further discussion and/or team dialog
1 participant
Heading
Bold
Italic
Quote
Code
Link
Numbered list
Unordered list
Task list
Attach files
Mention
Reference
Menu
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
-
So, I've raised this question before (before we had GitHub discussions 😉). When we process various types of variables from databases, we classify them...
visit/src/avt/DBAtts/MetaData/avtTypes.h
Lines 17 to 27 in 15e3799
This leads to code blocks of conditional logic for each type all over the place (in database readers, in expression processing, in metadata, in GUI, in CLI metadata, in CLI expressions...its prolific how these classification permeates our coding and interfaces) where we do something special for each type but where that specialness doesn't always seem worthwhile.
What if we just decided NOT to classify database variables into these types and instead each variable had some properties that we care about...
int
: number of componentsint
: tensor rankbool
: satisfies requirements for a coordinate fieldbool
: continuous in range space (means the field is continuously varying in "value" or not (e.g. is discrete instead))templated type
: range-space data type (e.g.int
,double
, etc.)int[7]/int[7]
: units (maybe...we don't really do this now except as arbitrary strings...see SAF data model.)etc., etc.
All plots would plot all variables. I think we can do reasonable things when users attempt to combine a variable an a plot in a way that doesn't necessarily make the most sense. There's no trimming lists of variables based on a classification...though I could maybe see some argument for using tensor rank where plots indicate which tensor ranks they support and variables are matched to them (actually, I think that is a problem with our current design as well, the knowhow about which classes of variables a plot supports is not part of plots...its scattered about in all the conditional logic that processes lists of variables). And, do our users really not understand their data so much that they could select a combination of variable and plot and then not understand the result they are presented with?
Beta Was this translation helpful? Give feedback.
All reactions