On Tue, Aug 9, 2022 at 5:08 PM Patrick Dupre <pdupre@xxxxxxx> wrote:
Hello,
You pointed my parameters controlling the integration.
However, the integration provide the "correct" values
712 times, and fails the 713th time,
while the function to integrate is the same, but with a slight
change in a numeric value which is not singular as much as I can see.
I already checked my parameters, to optimize the
accuracy of the integrations, as well as the required CPU time.
>From that, I think that my set of parameters is OK.
In my opinion, if one integration controlling parameter is incorrect, the
gsl function must return an error (status) and not fails.
That way I could really control the parameters, and investigate.
Calculating thousands of integrations is not possible if
the algorithm fails without options of monitoring what could be wrong.
Advanced quadrature algorithms estimate errors at each step. For most
software. error estimates neglect the limitations of floating point arithmetic,
so things like underflow to zero aren't taken into account. My career has
involved calculations using observational data. I was moved into a group
doing remote sensing where millions of calculations were done for each
month's data, for periods of 3 to 20 years. The software was initially developed
using shop-based observations. Since ships encounter only a small fraction
of the conditions that can be picked up in remote sensing images, calculations
were constantly aborting due to failures in some numerical subroutine that
had only been tested with the ship data.
Most of the work was done in SGI IRIX64 using Fortran. I used the SLATEC
xerror library, which allows you to report errors and store a count for each type
of error. When a numerical routine reports a failure, the failure is logged, a failure
code replaces the result, and the calculation moves to the next iteration. This
provides a set of test data that triggers each error and can be used to create
small test programs.
I spent several years tracking down and working around the failures.
In the
vast majority of cases the problems were due to sloppy coding by the
scientists who developed the theoretical approach. In a few cases there were
bugs in a numerical library that were quickly fixed thanks to having test inputs
that trigger the error.
The software has been running reliably since the late 1990's and has produced identical
results as old hardware was replaced, but Moore's Law, improvements in the libraries, and
attention to optimizations means a decade of data can now be processed in days on a $5k
desktop instead of months on a $100k deskside..
--
George N. White III
_______________________________________________ users mailing list -- users@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to users-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
