Open aowen87 opened 5 years ago
Another user has run into this issue. Removing reviwed
label to discuss.
Remarks from another user...
You have a nice panel in the "timestate to timestate in the same database" wizard flow if this was presented during the database to database wizard, I think that could work well
The Data Level Comparison wizard lacks the ability to create CMFE expressions that take time into account for the case when you have 2 databases (RunA, RunB) that you want to compare. When I map a field from RunB onto RunA's mesh, a sensible-looking CMFE expression gets created. However, when there are multiple timesteps in each database the expression does not behave as I would have expected. The expression that gets created looks like this: runB_var = conn_cmfe(</path/to/RunB.root database:var>, hydro_mesh) I typically open RunA and then make a CMFE expression to map RunB's values onto RunA's mesh (the active source). Next, I made a new expression: diff_var = var runB_var. When I plot diff_var, I get the expected values of zero across the mesh since RunA and RunB contain identical data. When I change the time slider, I get nonzero values and this is what I find confusing. With the above CMFE expression is RunB not supposed to get the same time slider value as that used for RunA? When I change the expression to: conn_cmfe(</path/to/RunB.root database0id:var>, hydro_mesh) then the right time step from RunB will be used and I get a difference of zero whenever I change the time slider for RunA. I guess the bottom line is that I want the ability to set the time index behavior in the wizard for the 2 database CMFE expressions that I'm making. That would produce expressions that contained the [0]id (or whatever) time index values that I set. I had expected CMFE to behave this way by default and it did not. An LLNL user thought so too, which is why I was looking at this.
-----------------------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: 1442 Status: Pending Project: VisIt Tracker: Bug Priority: Normal Subject: Data Level Comparison wizard and time for multiple databases Assigned to: - Category: - Target version: - Author: Brad Whitlock Start: 05/02/2013 Due date: % Done: 0% Estimated time: Created: 05/02/2013 05:38 pm Updated: 05/09/2013 04:03 pm Likelihood: 3 - Occasional Severity: 3 - Major Irritation Found in version: 2.6.2 Impact: Expected Use: OS: All Support Group: Any Description: The Data Level Comparison wizard lacks the ability to create CMFE expressions that take time into account for the case when you have 2 databases (RunA, RunB) that you want to compare. When I map a field from RunB onto RunA's mesh, a sensible-looking CMFE expression gets created. However, when there are multiple timesteps in each database the expression does not behave as I would have expected. The expression that gets created looks like this: runB_var = conn_cmfe(</path/to/RunB.root database:var>, hydro_mesh) I typically open RunA and then make a CMFE expression to map RunB's values onto RunA's mesh (the active source). Next, I made a new expression: diff_var = var runB_var. When I plot diff_var, I get the expected values of zero across the mesh since RunA and RunB contain identical data. When I change the time slider, I get nonzero values and this is what I find confusing. With the above CMFE expression is RunB not supposed to get the same time slider value as that used for RunA? When I change the expression to: conn_cmfe(</path/to/RunB.root database0id:var>, hydro_mesh) then the right time step from RunB will be used and I get a difference of zero whenever I change the time slider for RunA. I guess the bottom line is that I want the ability to set the time index behavior in the wizard for the 2 database CMFE expressions that I'm making. That would produce expressions that contained the [0]id (or whatever) time index values that I set. I had expected CMFE to behave this way by default and it did not. An LLNL user thought so too, which is why I was looking at this.
Comments: