Open aowen87 opened 5 years ago
@biagas do we know if this is still an issue with newer vtks?
I don't know from reading this.
In doing the work to write the chapter of the manual on Expressions, I wound up running into the issue where the logical themselves are not really plottable. So, my guess is that part is still an issue.
For an expression I found that this statement while not returning an error gives bogus data of I believe all zero ne( trapped, pos_cmfe(<[1]id:trapped>, particles, 0) ) Instead I must do the following: if( ne( trapped, pos_cmfe(<[1]id:trapped>, particles, 0) ), 1, 0) From Hank: The logicals return Booleans and that is probably tripping things up down stream. We probably need code to detect when Booleans are being sent out of the EEF and translate to floats.... If it can not be done then we need an error in the expression parsing From Cyrus:Our Pseudocolor plot handles vtkIntArrays just fine, but not vtkUnsignedCharArrays. After the vtk upgrade, we will want to support native precision pipelines (not a small undertaking)In light of this should we just support, directly plotting vars represented by vtkUnsignedChar?
-----------------------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: 545 Status: Pending Project: VisIt Tracker: Bug Priority: Normal Subject: Logicals in expressions can not be returned direclty Assigned to: - Category: - Target version: - Author: Allen Sanderson Start: 01/07/2011 Due date: % Done: 0% Estimated time: Created: 01/07/2011 03:45 pm Updated: 01/11/2012 05:18 pm Likelihood: 5 - Always Severity: 4 - Crash / Wrong Results Found in version: trunk Impact: Expected Use: OS: All Support Group: Any Description: For an expression I found that this statement while not returning an error gives bogus data of I believe all zero ne( trapped, pos_cmfe(<[1]id:trapped>, particles, 0) ) Instead I must do the following: if( ne( trapped, pos_cmfe(<[1]id:trapped>, particles, 0) ), 1, 0) From Hank: The logicals return Booleans and that is probably tripping things up down stream. We probably need code to detect when Booleans are being sent out of the EEF and translate to floats.... If it can not be done then we need an error in the expression parsing From Cyrus:Our Pseudocolor plot handles vtkIntArrays just fine, but not vtkUnsignedCharArrays. After the vtk upgrade, we will want to support native precision pipelines (not a small undertaking)In light of this should we just support, directly plotting vars represented by vtkUnsignedChar?
Comments: Hank: WRT pos_cmfe: I don't think it would work with particle data. We don't have a general way of asking what the value is at an arbitrary location with a point mesh.Allen: Executes but returns incorrect resultscmfe_pos when used with point cloud data should throw an error.Now usingcmfe_1 = conn_cmfe(<[1]id:trapped>, particles)cmfe0 = conn_cmfe(<[0]id:trapped>, particles) < trapped at current time stepcmfe1 = conn_cmfe(<[1]id:trapped>, particles)As noted this expression works:if(ne( cmfe_1, trapped ), 1, 0)Now given that conn_cmfe(<[0]id:trapped>, particles) == trapped one would expect that this expressionif(ne( cmfe_1, cfme0 ), 1, 0)would work but it crashes and gives:Pseudocolor: (InvalidVariableException)viewer: The databases cannot be compared because they have a different number of domains.Because of a spelling error cfme0 should be cmfe0. So the error is misleading and should be:Pseudocolor: (InvalidVariableException)viewer: An invalid variable (cfme0) was specified.The second argument if not found needs to throw the correct error message.However, substituting for cmfe0 OR cmfe_1 but NOT bothif(ne( cmfe_1, conn_cmfe(<[0]id:trapped>, particles) ), 1, 0)orif(ne( conn_cmfe(<[1]id:trapped>, particles) , cfme0 ), 1, 0)executes and both give correct results.But substituting for bothif(ne( conn_cmfe(<[1]id:trapped>, particles) , conn_cmfe(<[0]id:trapped>, particles) ), 1, 0)executes but gives incorrect results.The above is valid and should work.Cheers,AllenOn Jan 7, 2011, at 3:57 PM, Hank Childs wrote:Hi Allen,I'm deep in the middle of something, so quick response.conn_cmfe[1]id is the previous time slice. If you are at TS 0, it will issue a warningconn_cmfe1id is the next time slice. If you are at the last TS, it will issue a warning.If you use the wizard under Controls>Data Level Comparisons, it can form these expressions for you.WRT pos_cmfe: I don't think it would work with particle data. We don't have a general way of asking what the value is at an arbitrary location with a point mesh.hOn Fri, Jan 7, 2011 at 2:53 PM, Allen Sanderson allen@sci.utah.edu wrote:Okay with some trial and error I can get the state change with this statement:if(ne( trapped, conn_cmfe(<[1]id:trapped>, particles) ), 1, 0)Note the 1 as the index which gives relative.Now if I try using positive 1 I seem to get correct resultsif(ne( trapped, conn_cmfe(<[1]id:trapped>, particles) ), 1, 0)However, using the comm_cmfe in both arguments gives incorrect results.if(ne( conn_cmfe(<[0]id:trapped>, particles), conn_cmfe(<[1]id:trapped>, particles) ), 1, 0)Now given that I am using an index based approach, the above using conncmfe works. But only with conn_cmfe. pos_cmfe does not work. Not sure why as while I understand the pos would not as it is position based and the points move but not sure what the connective is?Cheers,AllenOn Jan 7, 2011, at 11:07 AM, Allen Sanderson wrote:Hello,I have particle data (i.e. point cloud data) that has a boolean state, "trapped". I would like to create an expression that would allow me check for a state change from trapped to untrapped or visa-versa.What I am envisioning is an expression:not(<[0]c:trapped>, <[1]c:trapped>)However, I think I have two problems. First, I need the expression to be relative to whatever time step I am on. If I am reading the manual correctly the [0] and [1] are absolute. Is there a way to specify relative?The other is determining correspondence between time steps. There is no mesh, but each particle does have an id. In the current case the data is sorted and there is the same number of particles in each time step. However, this characteristic will not always be true.I have been muddling my way through the manual trying to understand things but thought I would ask before spending too much time on it. TOm suggested looking at the CMFE operations.Cheers,Allen Update from LLNL release meeting.