PR 258299 Per unit flatness with 1837 points takes "forever"

huangyhg

Per unit flatness with 1837 points takes "forever"
<< Don Turcotte  --  11/18/08  13:13:23>>
From Frank K.
FCFFLAT2 in the attached program is a per unit flatness with 1837 points which takes "forever" to evaluate.
<<END>>

<< Changes made by Neil Kay -- 02/25/09  19:16:53>>
Action:  David Petrizze to Yanhua Huang
<<END>>
<< Don Turcotte  --  12/16/08  17:32:32>>
With version V44B this is very fast (a matter of seconds) to evaluate.  Apparently the DSFit math for V44B has speed improvements that Dan made before he left.
With the attached programs, I am seeing that the minmax FCF flatness and the legacy least squares flatness are identical.  Frank has also noted that in other programs that he has created.  This is possible but seems unlikely.  I used the debugger to verify that the minmax algorithm was processing correctly (in one program it used 3106 points).  It seems more likely that the reason is that the constructed plane from the scan has a Gauss filter applied.  In fact, when I remove the Gauss filter, the minmax flatness value is somewhat smaller than the least squares value as would normally be expected.
<<END>>
<< Changes made by Tim Wernicke -- 12/15/08  16:11:30>>
Priority:  High to Stop Rel.
<<END>>
<< Don Turcotte  --  12/03/08  15:17:26>>
I have fixed the problem of occasional very large per unit flatness deviations by initializing the deviations array to 0 in case the math fails (can fail when a per unit segment is linear).  The fixed to improve speed have already been uploaded (see below).
Files inserted to server
------------------------
V431\CONSFEAT\BASIC_PL.CPP
V43B\CONSFEAT\BASIC_PL.CPP
V44B\CONSFEAT\BASIC_PL.CPP
<<END>>
<< Changes made by Don Turcotte -- 12/03/08  15:18:01>>
Action:  Don Turcotte to David Petrizze, Status:  OPEN to REVIEW
<<END>>
<< Changes made by Tim Wernicke -- 12/03/08  10:31:07>>
Priority:  Stop Rel. to High
<<END>>
<< Changes made by Don Turcotte -- 12/03/08  08:08:14>>
Action:  David Petrizze to Don Turcotte
<<END>>
<< Changes made by David Petrizze -- 12/02/08  08:30:27>>
Status:  REVIEW to OPEN
<<END>>
<< Don Turcotte  --  11/25/08  17:12:57>>
What I have discovered is that the flatness per unit math using the Chebychev minmax algorithm also fails occasionally with V43B.  For some reason when the failure occurs in V43B, this does not result in bad values being reported.  I believe these are valid failures and not the result of memory being stepped on.  I fixed this in V431 by initializing the deviation array to 0.  I now get good values for per unit flatness in V431.   I believe the issue is that the math is trying to find a minmax plane in cases where the data is basically linear, so the math fails (which is a valid failure).  This is the result of the scan which is linear in places.
I fixed this in CPCDplane_feature:oFlatnessDSFitCompensate(...) to initialize the deviation array to 0.  This eliminated the very large values that were occasionally  reported with the Chebychev algorithm.  I built a version that Don R. can use in his GM tests.  I did not upload this change.
Don R. made a run which using the Chebychev version which shows a per unit deviation that is larger than the overall deviation although not huge.  This is not mathematically possible so something else seems to be wrong.  I went back to the LSQ algorithm, but I get the same result as Chebychev so not clear what is going on.
Also worked with Dave to be able to load Don R.'s program using V431 toolkit.  I was getting an ap crash.  Problem was that the PRG and PRB files must be in the same folder.
<<END>>
<< Don Turcotte  --  11/24/08  17:25:18>>
Reason per unit flatness sometimes has very large deviations is that occasionally CODRMin:drmin() fails to converge.  The routine returns an error code, but the highest level routines do not check for errors which results in bogus computation of the deviation.  Don't know why this is occasionally failing -- could be actual math error or initialization issue or memory overwrite.
<<END>>
<< Don Turcotte  --  11/21/08  18:20:31>>
Looking at issue with Frank's program where per unit flatness has deviation of 800+ when running in release build, but small (reasonable) deviation when running in debug build.  Seems to be a memory initialization or corruption issue.
<<END>>
<< Don Turcotte  --  11/20/08  08:13:28>>
Dave has merged this changed into V431 since it is needed for the GM Toolkit Valve Set Gage R&R.
V431\DIMENS\DIM_FLAT.CPP
<<END>>
<< Changes made by Don Turcotte -- 11/20/08  08:14:09>>
Action:  Don Turcotte to David Petrizze, Status:  OPEN to REVIEW
<<END>>
<< Changes made by Tim Wernicke -- 11/19/08  15:44:45>>
Priority:  High to Stop Rel.
<<END>>
<< Don Turcotte  --  11/19/08  14:11:14>>
I have uploaded my changes to V43B, V44B
Files inserted to server
------------------------
V43B\DIMENS\DIM_FLAT.CPP
V44B\DIMENS\DIM_FLAT.CPP
<<END>>
<< Don Turcotte  --  11/18/08  17:23:17>>
I have attached two programs from Frank.  The .zip has 1837 points and the 7z has ~5600 points.  
I used Glowcode to identify changes to the array handling in do_math_perunitarea_flatness(...) of CPCDdim_flatness to improve the speed.  
I also modified the algorithm for determining the step size (how to move the sliding perunit window).  The sliding window is moved 2% of the total width and 2% of the total length for each interation but not less than 10% of the user specified perunit length/width and not more than 50% of the user specified perunit length/width.  This has reduced the evaluation time to a worst case of 26 seconds on my 3.2 gigahertz computer.
I e-mailed the DIMENS\DIM_FLAT.CPP to Dave to build a custom V431 for Frank.  I have not uploaded any files yet.  I am waiting for further testing the rest of this week.
<<END>>
<< Changes made by Tim Wernicke -- 11/18/08  14:07:13>>
Priority:  to High
<<END>>