On reread, my wording here is a bit flaky:
posError7 and 1e-9 for posError9), and posError7 *happens* to stop
more precisely for this run.
The test as scripted is actually asking for the results reported as
posError7 to be more precise than for posError9. That expectation is
counter to what should be expected -- a looser tolerance should allow
for a less precision final state -- but apparently at some point in the
past, the result was actually better at 1e-7 than at 1e-9. Regardless,
we should be comparing to some acceptable value, not comparing two
acceptable steps against each other.
- DJC
On 05/25/2017 02:12 PM, Darrel Conway wrote:
The 2 cases for Linux look okay to me. Please feel free to disagree.
(But only if you actually say so!) Details below.
On 05/25/2017 11:57 AM, Hughes, Steven P. (GSFC-5950) wrote:
Need to run on Linux and find out why failing, DJC
·Integrator_LEO_PD853_Accuracy []
This is a tolerance issue we've seen before for this script (in
R2016a, I think). The script performs 3 checks:
If posError9 > posError7
passFlag = 0
EndIf
If posError11 > 5e-6
passFlag = 0
EndIf
If posError13 > 5e-6
passFlag = 0
EndIf
When I report those values, I get
posError9 = 4.407143931102817e-06
posError7 = 0.00121590394539874
posError11 = 1.119000169511592e-06
posError13 = 5.053184463840418e-06
For this run, posError9 < posError 7, so the first case is failing.
But the test cases seems pretty suspicious to me -- it is counting on
one stop being more precise than the other (tolerance is 1e-7 for
posError7 and 1e-9 for posError9), and posError7 *happens* to stop
more precisely for this run. Both runs are stepping to within
tolerance, though.
Conclusion: The test is poorly constructed IMO. The script produces
acceptable results.
·TrkFile_SimEst_TDRS_range_Solve_Cd []
This is a tolerance issue. The script performs 3 checks:
If PosError < .2 & VelError < 1e-5 & CdError < 0.1
PassFlag = 1
EndIf
When I run the test, the converged solution has
PosError = 0.003098802948995548
VelError = 3.452776017122671e-06
CdError = 0.1016732209751297
The CdError exceeds the expected value by 0.0016..., making PassFlag 0.
Conclusion: The test tolerance is slightly too tight for the sim/est
process on Linux.
*Finally, a recommendation: Can we please stop using the
TrueFalseComparator for test cases that have _actual expected_
numerical results?**
*
- DJC
--
Darrel J. Conway, Ph.D. Thinking Systems, Inc.
Senior Scientist and CEO 437 W Thurber Road, Suite 6
Phone: (623) 298-4530 Tucson, AZ 85705
FAX: (520) 232-2533www.thinksysinc.com
Cell: (520) [email protected]
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Gmat-buildtest mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/gmat-buildtest
--
Darrel J. Conway, Ph.D. Thinking Systems, Inc.
Senior Scientist and CEO 437 W Thurber Road, Suite 6
Phone: (623) 298-4530 Tucson, AZ 85705
FAX: (520) 232-2533 www.thinksysinc.com
Cell: (520) 425-3626 [email protected]
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Gmat-buildtest mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/gmat-buildtest
