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). <div><br></div><div>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!</div>
<div><br></div><div>Now that it works on my PC I will have to see how it works on the embedded system. Wish me luck :) </div><div><br></div><div>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).</div>
<div><br></div><div>Thanks for all your help!</div><div><br></div><div>Henri</div><div><br></div><div><br><div class="gmail_quote">On Mon, Nov 8, 2010 at 3:10 PM, Brian Borchers <span dir="ltr"><<a href="mailto:borchers@nmt.edu">borchers@nmt.edu</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">I've retested example.c on my 64 bit system, and it runs without<br>
errors and solves the SDP in 11 iterations.<br>
<br>
It definitely appears to me that you have a situation in which<br>
allocated memory blocks are being overwritten, making the code<br>
unreliable. I'm not sure of the details of what's going on here, but<br>
I do have some background information that may be useful.<br>
<br>
In moving to 64 bit systems, implementors of the C programming<br>
language have had to make decisions about how C's short, int, long<br>
int, and long long int should be implemented in a 64 bit system.<br>
Historically, there was a similar problem with the transition from 16<br>
bit to 32 bit systems, but that transition was so long ago that most<br>
of the kids writing code today were in day care or not even born when<br>
it happened...<br>
<br>
In the 32 bit era, the programming model was universally "ILP32" This<br>
means that "int", "long int" and pointers were all 32 bits long. Many<br>
programmers foolishly assumed that int's and pointers would always be<br>
of the same size and that pointers could be stored in the same space<br>
as int's. This is very bad.<br>
<br>
In the 64 bit Linux world (and among nearly all other varieties of 64<br>
bit unix with the notable exception of the old DEC Alpha systems), the<br>
programming model is "I32LP64" That is, "int" is a 32 bit integer,<br>
"long int" is a 64 bit integer, and pointers are 64 bits. Converting<br>
an ILP32 code to I32LP64 requires finding and fixing every place where<br>
a programmer assumed that size(int)=size(int *).<br>
<br>
In the 64 bit Windows world, microsoft make the decision (for reasons<br>
that I don't understand at all) to use IL32P64. You can get a 64 bit<br>
integer in this programming model by using "long long int"<br>
<br>
CSDP is written for the I32LP64 model. I've never tested it in the<br>
IL32P64 model. I expect that the code would break in at least some<br>
calculations involving very large SDP's, since CSDP performs array<br>
indexing calculations on arrays that could easily exceed 2^31-1<br>
elements. However, for smaller problems, I'm not aware of any<br>
particular reason why CSDP would fail under the IL32P64 model.<br>
<br>
My guess is that you've encountered a problem related to this.<br>
However, I don't know exactly which programming model is implemented<br>
by cygwin-64/gcc. To determine this, could you run the simple<br>
program:<br>
<br>
#include <stdio.h><br>
<br>
int main()<br>
{<br>
printf("sizeof(int)=%d\n",(int) sizeof(int));<br>
printf("sizeof(long int)=%d\n",(int) sizeof(long int));<br>
printf("sizeof(int *)=%d\n",(int) sizeof(int *));<br>
}<br>
<br>
On my I32LP64 Linux system, I get:<br>
sizeof(int)=4<br>
sizeof(long int)=8<br>
sizeof(int *)=8<br>
<br>
<br>
If CYGWIN-64 is using IL32P64, then size(long int) would be 4 rather<br>
than 8. This would explain why the f2c'd routines that used "long<br>
int" rather than "int" would still work, since "long int" and "int"<br>
are equivalent in the IL32P64 programming model.<br>
<font color="#888888"><br>
--<br>
</font><div><div></div><div class="h5">Brian Borchers <a href="mailto:borchers@nmt.edu">borchers@nmt.edu</a><br>
Department of Mathematics <a href="http://www.nmt.edu/~borchers/" target="_blank">http://www.nmt.edu/~borchers/</a><br>
New Mexico Tech Phone: (575) 322-2592<br>
Socorro, NM 87801 FAX: (575) 835-5366<br>
</div></div></blockquote></div><br></div>