[Csdp-tickets] message "store_unpacked block type"

[angelika.wiegele at aau.at]

On Fri, 1 Jun 2012, viktor.haerter at tu-harburg.de wrote:

> 
> Dear Angelika, I suggest you to use follwoging software for reliable semidefintie programming. It seems that this is what you need. If you wantd I can submit you a new version that has interface to
> CSDP, SDPT3, SDPA and SEDUMI, using sedumi data format. All results are reliable. One disadavante is that you need Matlab.
> 
> http://www.ti3.tu-harburg.de/jansson/vsdp/
> 
> Best Regards
> Viktor
> 
>

dear viktor,

thank you for your reply. i use the csdp-libraries within my c++ code, 
thus i cannot use matlab.

best regards,
angelika



> Zitat von angelika.wiegele at aau.at:
>
>       On Thu, 31 May 2012, Brian Borchers wrote:
>
>             On Mon, May 21, 2012 at 6:34 AM, <angelika.wiegele at aau.at> wrote:
>
>                  i'm using csdp 6.1.0 and i sometimes get the following message:
>
>                  store_unpacked block type
>
>                  after that message the program terminates. i think that the message should be "store_unpacked illegal block type", because i found this message only in the file packed.c
>             (function
>                  store_unpacked).
>
>                  however, i never call the routine "store_unpacked". i call initsoln, easy_sdp and write_prob. i'm thankful for any hint on how to trace this error.
>                  (maybe that has to do with this error: apart from default parameters, i use usexzgap=0, tweakgap=1, affine=1.)
>
>                  thanks in advance for any comments or suggestions!
>                  angelika
> 
>
>             Let me apologize for not responding to this sooner.  You're correct that the message should state that the block type is illegal.  This is a safety check in the code.  It tells
>             me that some other bit of
>             code wrote over an important data structure.  Unfortunately, it can be very tricky to determine exactly where this problem is.  
>              
>             Here are some questions to start the debugging process.   
>              
>             1. First, can you consistently reproduce this problem with your code by repeating the same inputs, or does it occur entirely at random?  It will be much easier to debug this if
>             you have a test case that
>             repeatedly and consistently causes the crash.  
>
>             2. You can simplify your code by having it write out the problem as a .dat-s file without calling easy_sdp() to solve the problem.  If you do this, do you still get a crash?  
>
>             3. If not, then use csdp to solve the .dat-s problem and see whether you get a reasonable solution.  It may be that the .dat-s file isn't correct- this would indicate that you
>             made a mistake in setting
>             up the problem data structures.  
>              
>             4. Assuming that the .dat-s version of the problem looks good, I'd continue by looking at the output from the easy_sdp() call.  How many iterations are performed before the
>             crash?  Does it crash on the
>             first iteration or only later on?  
>              
>             5. It's quite likely that at some point you've either allocated an array of the wrong size (too small) or written beyond the end of an array that was of the correct size.  These
>             kinds of bugs can often
>             be tracked down quickly by using a specialized debugging version of the malloc (memory allocator) library.  There are many of these, including "electric-fence", dmalloc, and
>             valgrind.  By linking your
>             code with a debugging malloc library, you might be able to cause a crash at the moment when any part of the code writes past the end of an array.     
>              
>             If you'd be willing to share your code and a test case that is known to provoke this bug, I'd be happy to run it under a debugging malloc to see if I can find the problem.  I can
>             understand if you'd be
>             uncomfortable with sharing your code
>
>             --
>             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
>              
>
>       dear brian,
>
>       thank you very much for your help! i realized now that the change of the parameter file causes this error message. that's what i did: i write the problem using write_prob() to a file
>       (attached). then i solve it on the command line using csdp. if i use default parameters, then the problem can be solved. but with the parameter setting:
>       usexzgap=0
>       tweakgap=1
>       affine=1
>       the program terminates with the error message "store_unpacked block type" after 16 iterations. the reason for choosing this parameter setting is, that we want to avoid negative duality gaps.
>       (we want to obtain a reliable upper bound from the sdp-relaxation, that's why we usually take the dual objectvie value. however, in this problem the dual is below the primal.) furthermore,
>       since we use csdp within a branch-and-bound algorithm, there might be problems without interior (due to branching decisions) and thus i've chosen affine=1 (as suggested in the user's guide).
>
>       i appreciate any suggestions on how to find the appropriate parameter setting for our purposes or on how to avoid the error message.angelika
> 
> 
> 
> 
>