Suppoert mutlivar of multivars for material-specific variables in Silo plugin

This is for two users; Al Nichols and Randy Settgast. It has to do with material (region) specific variables. That is, variables in Silo that exist on only some materials. The DBOPT_REGION_PNAMES option of var objects in Silo is used to control this. The orig. design was intended for this option to list all relevant material names a variable was defined on (e.g. restricted to). However, there are drivers for both Al and Randy in which it is highly desireable to write one ucdvar object permaterial. I consider this an abuse of the feature. At any rate, to support this case, writers will construct a multivar of multi-vars. At the domain level, write all the regionspecific ucd vars you want. Also, at that level, create a multivar object that points at an (arbitrarily long) list of such ucdvars. There will be two levels of multivars; the normal 'toplevel' stuff which will have one entry per domain as you've always done and the domainlevel multivar which will have one entry per regionspecific ucdvar. But, there will be a DBOPT_REGION_PNAMES option on multivars AT BOTH LEVELS; the toplevel and the domainlevel. In addition, that option will include the 'union of all region (material) names' the variable is defined on. Top-level is more important than domain level. It prevents VisIt from having to chase all over hell's half acre to get information about the material list the variable is defined on during a file open operation. In addition, each multivar will have the DBOPT_MMESH_NAME on BOTH LEVELS of multivars. At the top level, it will be the name of the associated multimesh. At the domain level, it will be the name of the associated domainlevel 'normal' ucdmesh.

-----------------------REDMINE MIGRATION-----------------------
This ticket was migrated from Redmine. As such, not all
information was able to be captured in the transition. Below is
a complete record of the original redmine ticket.

Ticket number: 640
Status: Pending
Project: VisIt
Tracker: Feature
Priority: Normal
Subject: Suppoert mutlivar of multivars for material-specific variables in Silo plugin
Assigned to: -
Category: -
Target version: -
Author: Mark Miller
Start: 03/01/2011
Due date:
% Done: 0%
Estimated time:
Created: 03/01/2011 08:40 pm
Updated: 03/31/2011 03:46 pm
Likelihood:
Severity:
Found in version: 2.12.3
Impact: 3 - Medium
Expected Use: 3 - Occasional
OS: All
Support Group: Any
Description:
This is for two users; Al Nichols and Randy Settgast. It has to do with material (region) specific variables. That is, variables in Silo that exist on only some materials. The DBOPT_REGION_PNAMES option of var objects in Silo is used to control this. The orig. design was intended for this option to list all relevant material names a variable was defined on (e.g. restricted to). However, there are drivers for both Al and Randy in which it is highly desireable to write one ucdvar object permaterial. I consider this an abuse of the feature. At any rate, to support this case, writers will construct a multivar of multi-vars. At the domain level, write all the regionspecific ucd vars you want. Also, at that level, create a multivar object that points at an (arbitrarily long) list of such ucdvars. There will be two levels of multivars; the normal 'toplevel' stuff which will have one entry per domain as you've always done and the domainlevel multivar which will have one entry per regionspecific ucdvar. But, there will be a DBOPT_REGION_PNAMES option on multivars AT BOTH LEVELS; the toplevel and the domainlevel. In addition, that option will include the 'union of all region (material) names' the variable is defined on. Top-level is more important than domain level. It prevents VisIt from having to chase all over hell's half acre to get information about the material list the variable is defined on during a file open operation. In addition, each multivar will have the DBOPT_MMESH_NAME on BOTH LEVELS of multivars. At the top level, it will be the name of the associated multimesh. At the domain level, it will be the name of the associated domainlevel 'normal' ucdmesh.

Comments:

Start by tracing the Silo DBOPT_REGION_PNAMES and DBOPT_MMESH_NAME options for var and multivar objects. Determine how the existing top-level multivar representation is written before designing support for nested domain-level multivars. Done means both multivar levels preserve the required material-name union and associated mesh names.