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

[aowen87]

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: