DBOPT_(D)TIME and DBOPT_CYCLE don't get written with DBPutQuadvar

Nobody has claimed this yet.

For this report I'm not sure whether I came across something that is designed that way, or whether it is really a bug. Also I don't know how general the behavior is. I have noticed it when trying to pass a DBOPT_DTIME or DBOPT_TIME and DBOPT_CYCLE to a dataset that is written with DBPutQuadvar.Consider for example the test-code wave.c. Suppose we change line 165/166 to: DBPutQuadvar1(dbfile, "pressure", "quadmesh", var, dims, ndims, NULL, 0, DB_FLOAT, DB_NODECENT, NULL); I would expect that the options DBOPT_DTIME and DBOPT_CYCLE are not part of the output now. But they are. Now suppose we change this line back to the original and remove the 'optList' argument to 'DBPutQuadMesh' instead. Since I'm passing the options to DBPutQuadvar1() I would expect that the option values are part of the output. But they aren't.So it seems that these option values are only exported when passed to the DBPutQuadmesh() function and not to the DBPutQuadvar1() function. I'm not arguing this is wrong (even though I do think such values have more meaning for a dataset than for a mesh) but it definitely is not behavior as documented in the manual (to be honest: these options are documented as valid for both functions; and wouldn't know what to do if they get eg different values, except maybe for storing the value passed last) In the manual these option values are documented as valid for both functions, so I would expect that I can send them to the output using either of them.

-----------------------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: 468
Status: Pending
Project: VisIt
Tracker: Bug
Priority: Normal
Subject: DBOPT_(D)TIME and DBOPT_CYCLE don't get written with DBPutQuadvar
Assigned to: Mark Miller
Category: -
Target version: 4.11.0
Author: Jakob van Bethlehem
Start: 11/09/2010
Due date:
% Done: 0%
Estimated time:
Created: 11/09/2010 10:28 am
Updated: 12/08/2016 11:26 pm
Likelihood: 5 - Always
Severity: 2 - Minor Irritation
Found in version: 4.7.2
Impact:
Expected Use:
OS: All
Support Group: Any
Description:
For this report I'm not sure whether I came across something that is designed that way, or whether it is really a bug. Also I don't know how general the behavior is. I have noticed it when trying to pass a DBOPT_DTIME or DBOPT_TIME and DBOPT_CYCLE to a dataset that is written with DBPutQuadvar.Consider for example the test-code wave.c. Suppose we change line 165/166 to: DBPutQuadvar1(dbfile, "pressure", "quadmesh", var, dims, ndims, NULL, 0, DB_FLOAT, DB_NODECENT, NULL); I would expect that the options DBOPT_DTIME and DBOPT_CYCLE are not part of the output now. But they are. Now suppose we change this line back to the original and remove the 'optList' argument to 'DBPutQuadMesh' instead. Since I'm passing the options to DBPutQuadvar1() I would expect that the option values are part of the output. But they aren't.So it seems that these option values are only exported when passed to the DBPutQuadmesh() function and not to the DBPutQuadvar1() function. I'm not arguing this is wrong (even though I do think such values have more meaning for a dataset than for a mesh) but it definitely is not behavior as documented in the manual (to be honest: these options are documented as valid for both functions; and wouldn't know what to do if they get eg different values, except maybe for storing the value passed last) In the manual these option values are documented as valid for both functions, so I would expect that I can send them to the output using either of them.

Comments:
I think you are correct that this behavior is screwy. Silo's handling of time, dtime and cycle is funky at best. I think it makes attempts even to cache the values once it sees them so it can output them again. It can even wind up overwriting those values if you write objects with different values for them to the same directory.Problem is that many of LLNL codes have come to depend on a certain kind of funky behavior and fixing it may cause wide spread problems. Ok, I have looked at this and a few other tickets related to same behavior.

Start with wave.c around lines 165/166 and trace the option handling at the DBPutQuadvar1 and DBPutQuadMesh entry points. Compare that behavior with the manual's documented DBOPT_DTIME, DBOPT_TIME, and DBOPT_CYCLE support; done means the implementation behavior is either aligned with the documentation or the discrepancy is explicitly documented and covered by a regression test.

Written by the indexing model from the issue text.