- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content

I'm running MKL 11 Update 3 and am getting a floating point divide by zero exception at _mkl_trs_dmintr_ls_lc() + 0x10a1 from a call to strnlspbc_solve. I'm using LS to fit a Gaussian, and the code works for many cases and I've validated it when data generated from a Gaussian. When it fails, it occurs after a number of loops through the RCI loop.

Link Copied

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content

Per my continued testing, this problem doesn't occur in the "without boundary conditions" version of the solver.

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content

There must be something about the specific problem to which you are applying this solver, or something specific about how you call the solver in your code, which causes the failure of the solver.

There is an example code provided with MKL, called ex_nlsqp_bc_f.f, and that example runs without errors.

Therefore, not much can be done or said until you provide example code that displays the same problems that you reported.

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content

Thanks for your feedback.

I think the function name and "divide by zero" error provides a tremendous amount of information, likely enough to find the bug. I'm tempted to say a robust solver (which is the whole idea behind TR methods) should be guarding against divide by zero error.

I'll do some more investigation and then see if I can pull together an example.

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content

Attached is a sample VC++ project that illustrates the problem.

Important: the code failure is dependent on the _EM_ZERODIVIDE mask being cleared, which suggests a work-around. However, I don't know whether the code can be trusted to provide accurate results when the zero divide mask is set.

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content

Hi, when can I expect that someone from Intel will take a look at this?

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content

I was trying to compiling: "...fatal error C1083: Cannot open include file: 'PSNumeric.h': No such file or directory"

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content

Thanks for taking a look at this. You can remove the #include directive for PSNumeric.h, it builds without it.

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content

ok, I see you submitted the same topic to the intel premier support and my colleague reproduced the problem on her side. Stay tuned.

- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page