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

[aowen87]

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.