documentation for dims of quadmesh and quadvar unclear

[aowen87]

Lee Busby reported this. Its easy to get this wrong but the order in which you specify the X,Y and Z sizes of a quadmesh or quadvar in the dims argument is not very clear. We should add verbiage to the documentation to make it clearer, maybe even with example. From Lee... I would appreciate your comments about the proper use of the DBOPT_MAJORORDER option in Silo files. I am attaching a short Fortran program, with a couple of comment lines at the beginning. You should be able (rzzeus) to cut and paste those lines into a terminal and get a picture in Visit within a few seconds. The output file (foo.silo) contains a quadmesh, 6 nodes wide in X and 7 nodes tall in Y. The coordinate values for the quadmesh are contained in a pair of two-dimensional arrays x2 and y2, where any given node (i,j) has coordinates (x2(i,j), y2(i,j)). For this particular example, x2(i,:)=i, for all j, and y2(:,j)=j, for all i. There is a zone-centered field "field1", of extent 5X6, whose values are just the integers 1-30. Each of these objects appears (using the Silo browser) to indeed be stored in column major order, with the first dimension varying the fastest. If you got Visit running on foo.silo, plot the MESH. For me, that picture is clearly wrong. It mixes up the X and Y dimension. Similarly for "field1". Now go back to foo.f and change the majororder from DB_COLMAJOR to DB_ROWMAJOR (comment out one or the other of the pair of parameters at the beginning.) Recompile, re-run a.out, and redisplay. The "row major" picture looks correct to me, even though the data in the file is still apparently in column major. A pseudo-color plot of "field1" is cold (blue) at the bottom left and hot (red) at the top right, with the values increasing by 1 along the X-axis, as I would expect. Do I misunderstand DBOPT_MAJORORDER? I presume that it is an advisory flag to the downstream Silo client (Visit, in this case), but that setting it does not actually have any effect on the ordering of data in the Silo file. Is Visit just getting this wrong? Do I misunderstand what browser is telling me about the order of things in the file? Or am I just wrong in some other way all together? This is very perplexing.

-----------------------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: 1348 Status: New Project: VisIt Tracker: Bug Priority: Normal Subject: documentation for dims of quadmesh and quadvar unclear Assigned to: - Category: - Target version: - Author: Mark Miller Start: 02/21/2013 Due date: % Done: 0% Estimated time: Created: 02/21/2013 11:56 pm Updated: 02/26/2013 01:17 pm Likelihood: 3 - Occasional Severity: 2 - Minor Irritation Found in version: 4.8 Impact: Expected Use: OS: All Support Group: Any Description: Lee Busby reported this. Its easy to get this wrong but the order in which you specify the X,Y and Z sizes of a quadmesh or quadvar in the dims argument is not very clear. We should add verbiage to the documentation to make it clearer, maybe even with example. From Lee... I would appreciate your comments about the proper use of the DBOPT_MAJORORDER option in Silo files. I am attaching a short Fortran program, with a couple of comment lines at the beginning. You should be able (rzzeus) to cut and paste those lines into a terminal and get a picture in Visit within a few seconds. The output file (foo.silo) contains a quadmesh, 6 nodes wide in X and 7 nodes tall in Y. The coordinate values for the quadmesh are contained in a pair of two-dimensional arrays x2 and y2, where any given node (i,j) has coordinates (x2(i,j), y2(i,j)). For this particular example, x2(i,:)=i, for all j, and y2(:,j)=j, for all i. There is a zone-centered field "field1", of extent 5X6, whose values are just the integers 1-30. Each of these objects appears (using the Silo browser) to indeed be stored in column major order, with the first dimension varying the fastest. If you got Visit running on foo.silo, plot the MESH. For me, that picture is clearly wrong. It mixes up the X and Y dimension. Similarly for "field1". Now go back to foo.f and change the majororder from DB_COLMAJOR to DB_ROWMAJOR (comment out one or the other of the pair of parameters at the beginning.) Recompile, re-run a.out, and redisplay. The "row major" picture looks correct to me, even though the data in the file is still apparently in column major. A pseudo-color plot of "field1" is cold (blue) at the bottom left and hot (red) at the top right, with the values increasing by 1 along the X-axis, as I would expect. Do I misunderstand DBOPT_MAJORORDER? I presume that it is an advisory flag to the downstream Silo client (Visit, in this case), but that setting it does not actually have any effect on the ordering of data in the Silo file. Is Visit just getting this wrong? Do I misunderstand what browser is telling me about the order of things in the file? Or am I just wrong in some other way all together? This is very perplexing.

Comments: