Re: [ublas] boost numeric bindings lapack gesv + RHEL5 issue.

Subject: Re: [ublas] boost numeric bindings lapack gesv + RHEL5 issue.
From: Sunil Thomas (sgthomas27_at_[hidden])
Date: 2011-09-21 20:59:01

Hi all!

I resolved this issue by using a locally built lapack version I picked from
Jack Dongorra's group.
Basically I found that the problem was not with the boost numeric bindings
to lapack, but the
lapack library itself, or some more subtle problem with the environment set
up by the client
software using my application. Building lapack into my application
circumvents the problem.
A workaround, no doubt, but these kind of things can take forever to figure
out.

Thanks to everyone who paid attention.
--Thomas.

On Wed, Sep 21, 2011 at 9:01 AM, Sunil Thomas <sgthomas27_at_[hidden]> wrote:

> Btw, forgot to mention that in all cases it bails out with INFO=3 (so
> U(3,3) is exactly zero
> when it fails on Linux).
> Thanks,
> --Thomas.
>
>   On Wed, Sep 21, 2011 at 8:52 AM, Sunil Thomas <sgthomas27_at_[hidden]>wrote:
>
>> Thanks Rutger!
>>
>>     On Windows I am using Lapack built with IFC, while on Linux, we are
>> using already
>> existing Lapack libraries (built with fortran compilers g77, I think)..
>> The problem is more
>> subtle than I thought.. when I build and run my standalong application on
>> Windows and
>> Linux, it actually runs fine on both. Its only when I am linking my
>> application as 3rd party
>> libraries to a client application, that it fails on Linux. I forgot to
>> mention this fact and for
>> that, I apologise. Somehow I think the issue is related to the condition
>> number of the
>> matrix. Here it is the matrix (9x9) and RHS:
>>
>> Matrix:
>>
>> Row #0
>> 0.1  4.54773e-010  8.62559e-018  0  0  0  0  0  0
>> Row #1
>> 0  0  0  0.1  4.54773e-010  8.62559e-018  0  0  0
>> Row #2
>> 0  0  0  0  0  0  0.1  4.54773e-010  8.62559e-018
>> Row #3
>> 1.44948e-010  0.166667  -2.61688e-018  0  0  0  0  0  0
>> Row #4
>> 0  0  0  1.44948e-010  0.166667  -2.61688e-018  0  0  0
>> Row #5
>> 0  0  0  0  0  0  1.44948e-010  0.166667  -2.61688e-018
>> Row #6
>> -8.12841e-010  -8.11836e-010  0.0952381  0  0  0  0  0  0
>> Row #7
>> 0  0  0  -8.12841e-010  -8.11836e-010  0.0952381  0  0  0
>> Row #8
>> 0  0  0  0  0  0  -8.12841e-010  -8.11836e-010  0.0952381
>> RHS:
>> 0.1   4.54773e-009   8.62559e-016   1.44948e-010   1.66667
>> -2.61688e-016   -8.12841e-010   -8.11836e-009   9.52381
>>
>> This is just a typical example.. since the matrix/RHS changes
>> from iteration to iteration, say. But since all solves fail (when
>> they fail on Linux linking to client application), understanding
>> this problem should suffice, I think.
>>
>> Thanks again,
>> --Thomas.
>>
>>
>> On Tue, Sep 20, 2011 at 11:40 PM, Rutger ter Borg <rutger_at_[hidden]>wrote:
>>
>>> On 09/20/2011 11:04 PM, Sunil Thomas wrote:
>>>
>>>> Hi!
>>>>   I am using boost numeric bindings for doing a direct solve using the
>>>> lapack function gesv. While this
>>>> works great on Windows and gives me the right answer, the exact same
>>>> matrix (I printed it out to make
>>>> sure) fails on Linux RHEL4 or RHEL5 (returns info=3, zero element on
>>>> diagonal). I think the Windows
>>>> case was able to pivot it automatically. I am working with some legacy
>>>> code here and I see some lines
>>>> such as:
>>>>
>>>>
>>> [snip]
>>>
>>>
>>> ()
>>>>    It looks like the fix might be something really trivial, but I have
>>>> no clue where to look for a hint to resolve
>>>> the problem.. appreciate if somebody who's an expert at using boost
>>>> ublas can kindly help resolve this
>>>> problem.
>>>> Thanks a lot for your time,
>>>> --S.
>>>>
>>>
>>> In order to help, we need a bit more info on your build environments.
>>> I.e., which LAPACK backends are you using, on Windows and on RHEL? Which
>>> compilers?
>>>
>>> Cheers,
>>>
>>> Rutger
>>>
>>>
>>> ______________________________**_________________
>>> ublas mailing list
>>> ublas_at_[hidden]
>>> http://lists.boost.org/**mailman/listinfo.cgi/ublas
>

>>> Sent to: sgthomas27_at_[hidden]
>>>
>>
>>
>