[Csdp] Using cblas and clapack with CSDP

[Henri Kjellberg]

And Success! I now have the code working using clapack (with its own blas)
and the csdp code calling gsl_cblas (I did this out of convenience).

Turns out I had a single transpose statement incorrect in linesearch.c and
that was causing the erratic behavior. I am surprised it ever functioned
even marginally!

Now that it works on my PC I will have to see how it works on the embedded
system. Wish me luck :)

If you are interested, I can clean up my work and submit it to you for
incorporation into the project (in case there is anyone else out there that
does not have a FORTRAN compiler available).

Thanks for all your help!

Henri


On Mon, Nov 8, 2010 at 3:10 PM, Brian Borchers <borchers at nmt.edu> wrote:

> I've retested example.c on my 64 bit system, and it runs without
> errors and solves the SDP in 11 iterations.
>
> It definitely appears to me that you have a situation in which
> allocated memory blocks are being overwritten, making the code
> unreliable.  I'm not sure of the details of what's going on here, but
> I do have some background information that may be useful.
>
> In moving to 64 bit systems, implementors of the C programming
> language have had to make decisions about how C's short, int, long
> int, and long long int should be implemented in a 64 bit system.
> Historically, there was a similar problem with the transition from 16
> bit to 32 bit systems, but that transition was so long ago that most
> of the kids writing code today were in day care or not even born when
> it happened...
>
> In the 32 bit era, the programming model was universally "ILP32"  This
> means that "int", "long int" and pointers were all 32 bits long.  Many
> programmers foolishly assumed that int's and pointers would always be
> of the same size and that pointers could be stored in the same space
> as int's.  This is very bad.
>
> In the 64 bit Linux world (and among nearly all other varieties of 64
> bit unix with the notable exception of the old DEC Alpha systems), the
> programming model is "I32LP64"  That is, "int" is a 32 bit integer,
> "long int" is a 64 bit integer, and pointers are 64 bits.  Converting
> an ILP32 code to I32LP64 requires finding and fixing every place where
> a programmer assumed that size(int)=size(int *).
>
> In the 64 bit Windows world, microsoft make the decision (for reasons
> that I don't understand at all) to use IL32P64.  You can get a 64 bit
> integer in this programming model by using "long long int"
>
> CSDP is written for the I32LP64 model.  I've never tested it in the
> IL32P64 model.  I expect that the code would break in at least some
> calculations involving very large SDP's, since CSDP performs array
> indexing calculations on arrays that could easily exceed 2^31-1
> elements.  However, for smaller problems, I'm not aware of any
> particular reason why CSDP would fail under the IL32P64 model.
>
> My guess is that you've encountered a problem related to this.
> However, I don't know exactly which programming model is implemented
> by cygwin-64/gcc.  To determine this, could you run the simple
> program:
>
> #include <stdio.h>
>
> int main()
> {
>  printf("sizeof(int)=%d\n",(int) sizeof(int));
>  printf("sizeof(long int)=%d\n",(int) sizeof(long int));
>  printf("sizeof(int *)=%d\n",(int) sizeof(int *));
> }
>
> On my I32LP64 Linux system, I get:
> sizeof(int)=4
> sizeof(long int)=8
> sizeof(int *)=8
>
>
> If CYGWIN-64 is using IL32P64, then size(long int) would be 4 rather
> than 8.  This would explain why the f2c'd routines that used "long
> int" rather than "int" would still work, since "long int" and "int"
> are equivalent in the IL32P64 programming model.
>
> --
> Brian Borchers                          borchers at nmt.edu
> Department of Mathematics      http://www.nmt.edu/~borchers/
> New Mexico Tech                       Phone: (575) 322-2592
> Socorro, NM 87801                   FAX: (575) 835-5366
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://list.coin-or.org/pipermail/csdp/attachments/20101108/77f39f6d/attachment-0001.html