PR 258522 The overall flatness does not consistently carry over into the repo

huangyhg

The overall flatness does not consistently carry over into the report.
<< Don Ruggieri  --  12/01/08  13:28:53>>
data is in 12012008_01a.zip.  This is a problem that Mike Wilson had seen mmultiple times last week.  The overall flatness does not consistently carry over into the report.
Steps to reproduce:
On thje top of the 3rd page of the report are two flatness callouts.  Each one has overall flatness and then unit flatrness as well.  In this last run, the overall flatness is 0 whilke the unit flatness is non-zero.
Results:
Look at the PDF file names Monday-12012008_001-1-3.PDF, on top of the 3rd page.
<<END>>

<< Changes made by Neil Kay -- 02/25/09  19:17:16>>
Action:  David Petrizze to Yanhua Huang
<<END>>
<< Don Ruggieri  --  01/22/09  13:23:26>>
I've run this pat about 5 times now with the 1/20 build of V43MR2, and it is looking good.  Not once yet have I see the unit flatness or overall flatness report a 0 value.
<<END>>
<< Don Ruggieri  --  01/20/09  10:27:51>>
I get an application error now when I try to open this Cummins program.  I tried multiple times, no luck.
<<END>>
<< Don Turcotte  --  01/19/09  15:48:34>>
I have modified the odrmin routine in PCDSFit.dll so that it always returns success even if the maxiter count maxes out at 300 iterations.  I believe what is happening is that the algorithm gets caught see-sawing around the minimum so it maxes out the number of allowed iterations but this is really not a case of BF_NO_CONVERGE.  The results I get are reasonable.  In both programs the overall flatness is somewhat less than the least squares flatness.  The per unit flatness is smaller than the overall flatness and grows as you increase the per unit size until it reaches the same value as the overall flatness.
Fixed in V432 and V44B.
Files inserted to server
------------------------
V432\PCDSFIT\SOURCE\ODRMIN.CPP
V432\PCDSFIT\PCDSFITDLL\NETDEBUG\PCDSFitD.lib
V432\PCDSFIT\PCDSFITDLL\NETRELEASE\PCDSFit.lib
V44B\PCDSFIT\SOURCE\ODRMIN.CPP
V44B\PCDSFIT\PCDSFITDLL\NETDEBUG\PCDSFitD.lib
V44B\PCDSFIT\PCDSFITDLL\NETRELEASE\PCDSFit.lib
<<END>>
<< Changes made by Don Turcotte -- 01/19/09  15:49:04>>
Action:  Don Turcotte to David Petrizze, Status:  OPEN to REVIEW
<<END>>
<< Changes made by Don Turcotte -- 01/16/09  17:15:20>>
Status:  REVIEW to OPEN
<<END>>
<< Don Ruggieri  --  01/16/09  16:39:23>>
A 2nd example of an execution that shows a flatness failue is in 01162009_03b.zip.
<<END>>
<< Don Ruggieri  --  01/16/09  16:19:32>>
I just ran the Cummins part again.  The first run looked great.  I have a single (overall) flatness callout and then a double (overall/unit) flatness (PDF # 19).
The second time I ran it, the overall flatness was 0 in the 2nd callout, near the top of page 6 in the report.  (PDF # 20)
<<END>>
<< Changes made by Don Ruggieri -- 01/16/09  16:23:46>>
Action:  David Petrizze to Don Turcotte
<<END>>
<< Don Ruggieri  --  01/13/09  13:14:57>>
I tested this on one program with a 6000 point scan on my machine, and so far so good.  Both overall flatness and unit flatness are reporting non-zero, and unit flatness is less than overall flatness.  I would like to test this on the Cummins part one more time, but the machine is busy right now.
<<END>>
<< Don Turcotte  --  01/12/09  17:12:19>>
I have identified changes to 3 files in PCDSFIT dll that were made in V44B resulting in a great increase in speed of the minmax algorithm.  Results for all tests in both V432 and V44B are identical, the only difference is the speed in V44B.  I have applied these to V432 so now V432 is as fast as V44B.  A test which formerly took 5:06 minutes (both overall and per unit flatness) now runs in 24 seconds.
I have also made some improvements in the way the sliding window increment for the per unit flatness is calculated to produce consistent results (the bigger the per unit area, the bigger the deviation until the deviation equals the overall flatness).
The only fix for V44B was for the window increment changes in dim_flat.cpp since V44B already had the speed improvements in PCDSFIT dll and the changes for BF Plane.
Files inserted to server
------------------------
V432\CONSFEAT\BF_PLANE.CPP
V432\DIMENS\DIM_FLAT.CPP
V432\INCLUDE\BF_PLANE.H
V432\MENU\FEATCTRLFRMDLG.CPP
V432\PCDSFIT\INCLUDE\ODRMIN.H
V432\PCDSFIT\SOURCE\LM_SUBP.CPP
V432\PCDSFIT\SOURCE\ODRMIN.CPP
V432\PCDSFIT\PCDSFITDLL\NETDEBUG\PCDSFitD.lib
V432\PCDSFIT\PCDSFITDLL\NETRELEASE\PCDSFit.lib
V44B\DIMENS\DIM_FLAT.CPP
<<END>>
<< Changes made by Don Turcotte -- 01/12/09  17:12:50>>
Action:  Don Turcotte to David Petrizze, Status:  OPEN to REVIEW
<<END>>
<< Don Turcotte  --  01/09/09  17:28:52>>
I have made a change so that the per unit flatness uses the FCF pointer to get the overall flatness command to determine what the overall flatness value is.  If any interation of the per unit flatness produces a value greater than the overall flatness, the result for that iteration is ignored.  Now I get all good values with the per unit flatness less than the overall flatness for small per unit areas.  The per unit flatness increases as the per unit area increases until it reaches the overall flatness value as would be expected.
The remaining problem is the slowness of the per unit algorithm.  Some cases take 10 minutes total (including the overall flatness which is 1:47).  I am using Don's program as well as Frank's earlier program to do testing to improve the speed but still produce valid results for all cases.
<<END>>
<< Don Turcotte  --  01/08/09  17:15:49>>
The unit flatness is 0 because this is a BF constructed plane and the fixes for #255637 were not merged into V432.  I have done this and the per unit flatness is no longer zero.  However, if I set the per unit area very large (1000mm), I get a per unit deviation which is much larger than the overall deviation.  This should never happen.
<<END>>
<< Don Ruggieri  --  01/06/09  15:09:54>>
More data is in 01062009_02a.zip.  I  wrote a much simpler program in v43MR2 which has only a perimeter scan (>6000 points), a constructed plane, and the flatness callout.  Its interesting to note that in this instance the overall flatness is non-zero while the unit flatness reports 0.
<<END>>
<< Don Turcotte  --  01/05/09  17:19:28>>
Don R.'s latest Cummins program has an overall flatness of 0.  This is because the Chebychev algorithm is not converging (over 5000 pts) although the per unit gives a reasonable value.  I tried this in V44B since I believe the V44B algorithm is an improved version, but the ap crashes trying to load the program (this program has toolkit features).  I am trying to trim down the program so I can load the essential commands in V44B.
<<END>>
<< Don Ruggieri  --  01/05/09  14:44:31>>
I am going to re-open this, as it still seems to be an issue with v43MR2.  I am attaching two file collections, 01052009_01a.zip and 01052009_01b.zip.  After a number of executions which failed to repeat the problem today, it happened on two successive execuions.  The overall flatness is 0 while the unit flatness is non-zero.
<<END>>
<< Changes made by Don Ruggieri -- 01/05/09  14:44:53>>
Action:  Don Ruggieri to Don Turcotte, Status:  CLOSED to OPEN
<<END>>
<< Jerry Naylor  --  12/31/08  16:50:35>>
wasaddedtoreadme431
<<END>>
<< Don Ruggieri  --  12/08/08  12:35:24>>
I am satisfied that this is done, so I will close it.
<<END>>
<< Changes made by Don Ruggieri -- 12/08/08  12:35:27>>
Status:  RESOLVED to CLOSED
<<END>>
<< David Petrizze  --  12/08/08  08:17:49>>
Reviewed.
<<END>>
<< Changes made by David Petrizze -- 12/08/08  08:17:52>>
Action:  David Petrizze to Don Ruggieri, Status:  REVIEW to RESOLVED
<<END>>
<< Don Ruggieri  --  12/08/08  09:55:34>>
I've run approximately 30 cycles of this part, and not once did I see this flatness value missing from the report.  It seems to me that this problem is fixed.
<<END>>
<< Don Ruggieri  --  12/04/08  15:26:11>>
Initial testing (6 runs) shows that this is not a problem.  Since it seemed to be only random in earlier tests, I plan to run more cycles before declaring it fixed.
<<END>>
<< Don Turcotte  --  12/03/08  15:25:51>>
The problem here is that V43B, V44B were updated to use the new LPSOLVE55.DLL (3rd party dll) but V431 was still using the older dll.  Upgrading V431 to this new dll solved the problem of the overall flatness reporting 0.0 (math did not converge).
Files inserted to server
------------------------
V431\NETDLL\LPSOLVE55.DLL
V431\PCDSFIT\PCDSFITDLL\LIB\LPSOLVE.LIB
V431\PCDSFIT\PCDSFITDLL\NETDEBUG\PCDSFitD.lib
V431\PCDSFIT\PCDSFITDLL\NETRELEASE\PCDSFit.lib
<<END>>
<< Changes made by Don Turcotte -- 12/03/08  15:26:31>>
Action:  Don Turcotte to David Petrizze, Status:  OPEN to REVIEW
<<END>>
<< Changes made by Tim Wernicke -- 12/03/08  10:31:35>>
Priority:  Critical to Stop Rel.
<<END>>
<< Don Turcotte  --  12/02/08  17:42:14>>
Using V431 in either debug or release build, the overall flatness fails to converge so the reported value is 0.  This fails consistently every time.   When I use V43B debug build, this converges every time to a reported value of 0.01247.  
Using debug printf's, I have verified that the data going into the maxmin fit in PCDSFit is identical in V431 and V43B.  But the algorithm does not converge in V431 so there must be some difference in the PCDSFit libraries in the two versions.  I have found some differences but nothing yet that gets the V431 to converge.
<<END>>
<< Changes made by Tim Wernicke -- 12/01/08  13:56:56>>
Category:  misc to GD&T, Action:  Systems Group to Don Turcotte, Assigned:  Systems Group to Don Turcotte, Priority:  to Critical
<<END>>