Problem

Common use case:

• User runs sdp2input, it writes sdp to disk
• User run sdpb, it reads sdp from disk and runs solver
• Intermediate sdp is never used elsewhere

These intermediate IO operations can be quite expensive (tens of minutes). In Skydive, sdp2input+sdpb are called for each iteration, and IO takes up to ~50% of total sdpb time (as noted by @suning-git).

Solution

Create a single executable that accepts input in different formats and performs in-memory conversion to the format accepted by solver.

Potential issues

See comments below for details.

• sdp.zip is needed for SDPB restart. SDPB has to decide whether to overwrite sdp.zip or ignore PMP input, if both are present. May lead to subtle bugs if the user doesn't really understand SDPB behavior.
• Redistributing PMP matrices and blocks among the cores may be non-trivial, with lots of MPI messaging. Do we get any significant speedup compared to our current simple strategy "write sdp, the read sdp"?
• Possible to get too many open files error (each core writes something) - need to limit number number of open files during SDP write? By the way, we can get that same problem e.g. in SDPB in debug mode when writing profiling data.

libxml2 has directory structure include/libxml2/libxml/*.h. Include statements in Vector_State.hxx and Number_State.hxx ask for #include <libxml2/libxml/parser.h>. At configuration time, waf configure tries to compile a trivial file with the include #include <libxml/parser.h> using the user-supplied include path for libxml2.

This means that providing the include path .../include/ fails the waf configuration step. Then waf resorts to asking pkg-config for libxml2 paths, which on my system gives ../include/libxml2 for the include path. This does not seem to be verified by compiling a trivial source.

The result of this is that compilation of files which include Vector_State.hxx and Number_State.hxx fails. A workaround is to run ./waf configure --libxml2-incdir=".../include/ .../include/libxml2/" which makes the configuration tool happy with its include of <libxml/parser.h> but also makes <libxml2/libxml/parser.h> work.

I am not sure what is the proper solution of this. Changing the configuration script to use <libxml2/libxml/parser.h> doesn't help -- parser.h uses <libxml/...> under the hood (or so it seemed). Perhaps the files Vector_State.hxx and Number_State.hxx should be changed. But it seems that the issue doesn't arise for other users.

Compiling on Linux and Windows works without a hitch , however the clusters computers in my department are Mac and when I try to compile sdpb i get -lrt library not found error. I tried removing the -lrt flag in makefile, it gives multiple errors while compiling.

I should also add the Mac installation command and process listed does not work anymore as some required files in the homebrew installation process have been removed.

Any workaround or fix?

Advantage: smaller checkpoint files
Disadvantage: checkpoint files no longer portable

I'm not sure about this tradeoff. Another possibility would be to include an option that lets the user switch between binary and text-based checkpoint files.

I'll leave this issue open for now, and if demand exists, I'll implement it (or accept a pull request!).

Description

When processing input generated from mathematica file, the program aborts providing error messages of type "A was not numerically HPD: 82 128 -5.30674e-286"

Steps to reproduce:

export $DOCKER_WD=/usr/local/share/sdpb
wget https://raw.githubusercontent.com/davidsd/sdpb/master/test/sdp2input_test.m
docker run -v $PWD:$DOCKER_WD wlandry/sdpb:2.5.1 mpirun --allow-run-as-root -n 4 sdp2input --precision=1024 --input=$DOCKER_WD/sdp2input_test.m --output=$DOCKER_WD/problem
docker run -v $PWD:$DOCKER_WD wlandry/sdpb:2.5.1 mpirun --allow-run-as-root -n 4 sdpb --precision=1024 --procsPerNode=4 -s $DOCKER_WD/problem

Logs

Output of the last (failing) command:

stdout:
SDPB started at 2022-Jun-01 14:37:57
SDP directory   : "/usr/local/share/sdpb/problem"
out directory   : "/usr/local/share/sdpb/problem_out"

Parameters:
maxIterations                = 500
maxRuntime                   = 9223372036854775807
checkpointInterval           = 3600
findPrimalFeasible           = false
findDualFeasible             = false
detectPrimalFeasibleJump     = false
detectDualFeasibleJump       = false
precision(actual)            = 1024(1024)
dualityGapThreshold          = 1e-30
primalErrorThreshold         = 1e-30
dualErrorThreshold           = 1e-30
initialMatrixScalePrimal     = 1e+20
initialMatrixScaleDual       = 1e+20
feasibleCenteringParameter   = 0.1
infeasibleCenteringParameter = 0.3
stepLengthReduction          = 0.7
maxComplementarity           = 1e+100
initialCheckpointDir         = "/usr/local/share/sdpb/problem.ck"
checkpointDir                = "/usr/local/share/sdpb/problem.ck"
noFinalCheckpoint            = false
writeSolution                = x,y
procsPerNode                 = 4
procGranularity              = 1
verbosity                    = 1

Performing a timing run

stderr:
Process 1 caught error message:
A was not numerically HPD: 82 128 -5.30674e-286
--------------------------------------------------------------------------
MPI_ABORT was invoked on rank 1 in communicator MPI_COMM_WORLD
with errorcode 1.

NOTE: invoking MPI_ABORT causes Open MPI to kill all MPI processes.
You may or may not see output from other processes, depending on
exactly when Open MPI kills them.
--------------------------------------------------------------------------
Process 3 caught error message:
A was not numerically HPD: 82 128 -5.30674e-286
Process 0 caught error message:
A was not numerically HPD: 82 128 -5.30674e-286
Process 2 caught error message:
A was not numerically HPD: 82 128 -5.30674e-286
[c52345ef0a57:00001] PMIX ERROR: UNREACHABLE in file ../../../src/server/pmix_server.c at line 2795
[c52345ef0a57:00001] 3 more processes have sent help message help-mpi-api.txt / mpi-abort
[c52345ef0a57:00001] Set MCA parameter "orte_base_help_aggregate" to 0 to see all help / error messages

Environment:

Linux Mint with docker-ce freshly pulled from official package

$ uname -a
Linux jan-tempos 5.4.0-110-generic #124-Ubuntu SMP Thu Apr 14 19:46:19 UTC 2022 x86_64 x86_64 x86_64 GNU/Linux
$ docker --version
Docker version 20.10.16, build aa7e414

Hardware:

AMD Ryzen™ 7 5800X (x86_64, 8c16t)

$ cat /proc/cpuid
processor       : 0
vendor_id       : AuthenticAMD
cpu family      : 25
model           : 33
model name      : AMD Ryzen 7 5800X 8-Core Processor
stepping        : 0
microcode       : 0xa201009
cpu MHz         : 3644.633
cache size      : 512 KB
physical id     : 0
siblings        : 16
core id         : 0
cpu cores       : 8
apicid          : 0
initial apicid  : 0
fpu             : yes
fpu_exception   : yes
cpuid level     : 16
wp              : yes
flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt pdpe1gb rdtscp lm constant_tsc rep_good nopl nonstop_tsc cpuid extd_apicid aperfmperf pni pclmulqdq monitor ssse3 fma cx16 sse4_1 sse4_2 movbe popcnt aes xsave avx f16c rdrand lahf_lm cmp_legacy svm extapic cr8_legacy abm sse4a misalignsse 3dnowprefetch osvw ibs skinit wdt tce topoext perfctr_core perfctr_nb bpext perfctr_llc mwaitx cpb cat_l3 cdp_l3 hw_pstate ssbd mba ibrs ibpb stibp vmmcall fsgsbase bmi1 avx2 smep bmi2 erms invpcid cqm rdt_a rdseed adx smap clflushopt clwb sha_ni xsaveopt xsavec xgetbv1 xsaves cqm_llc cqm_occup_llc cqm_mbm_total cqm_mbm_local clzero irperf xsaveerptr wbnoinvd arat npt lbrv svm_lock nrip_save tsc_scale vmcb_clean flushbyasid decodeassists pausefilter pfthreshold avic v_vmsave_vmload vgif umip pku ospke vaes vpclmulqdq rdpid overflow_recov succor smca
bugs            : sysret_ss_attrs spectre_v1 spectre_v2 spec_store_bypass
bogomips        : 7600.11
TLB size        : 2560 4K pages
clflush size    : 64
cache_alignment : 64
address sizes   : 48 bits physical, 48 bits virtual
power management: ts ttp tm hwpstate cpb eff_freq_ro [13] [14]

...

Additional notes:

wlandry/sdpb:2.4.0 is equally affected, despite different input format. test.xml evaluates correctly.

'1.0*x' works, but not a plain 'x'. Mathematica does not like to write out 1.0, so this causes some minor inconvenience.

If I have a working boostrap system for which the polynomials V=(V_1(x),....V_s(x)) are 1x1 matrices, if seems to me that I should be able to replace them by 2x2 matrices W=(W_1(x),....,W_s(x)) with
W_i(x)={{V_i(x),0},{0,0}}
(0 are vectors with the same size as V_i)

After all,
alpha.V=alpha_1 V_1(x)+....+alpha_s V_s(x) is >=0 iff
alpha.W=alpha_1 W_1(x)+....+alpha_s W_s(x) is positive semi-definite.

The normalization vector should be able to stay the same.

Yet, it does not work. In the example provided "Bootstrap2dExample.m", it just gives
"Segmentation fault (core dumped)". In my code that I am working on, sdpb accepts the input, but gives nonsense.

Why is that?

Currently, if one accidentally provides a prefactor with positive poles, sdp2input will crash (not for all choices of positive poles) with "Integer division by 0". This is very confusing: in reality this is actually how the square root behaves on negative numbers in gmp. The error occurs in line 31 of sample_bilinear_basis.cxx, called from line 73 of Dual_Constraint_Group.cxx. The reason is that some sample_scalings may be negative if some of the poles are positive.

Since positive poles are mathematically meaningless, and messing up relative shifts of these poles is super-easy for the user (I've done this at least twice), it could be helpful to validate the input by checking that all poles are non-positive (zeros are fine).

It is great to see that approx_objective is now available.

I have a few questions and comments about it.

Typo: In the usage newSDP should be newSdp.

Also what is the exact purpose of the writeSolverState? When can/should this state be reused? For each different SDP that I am perturbing from? So say I am perturbing an SDP to N different perturbed SDP', i.e. changing N variables should it be reused for the N-1 following runs? Or can it be reused much more, say for all SDPs of the same form (same number of vectors and order of polynomials) but completely different parameter values?

(It might also be nice to include somewhere that the input format for SDPB has changed and is no longer compatible with the old version. Or is this written somewhere and did I miss it.)

We have a user on our local HPC system running sdpb, and recently discovered that he had produced 100M (100 million) output files. This is causing problems for us because there is a limit on the number of inodes (files) that our file system can support. In addition, writing many small files is much less efficient than writing fewer larger files.

Do you have any plans for creating fewer, larger files? Depending on the output format, either HDF5, JSON, YAML etc. might be good candidates for this, which have widely used, mature libraries.

I would be happy to assist with implementing this (if this makes sense).

The name sdp_derivative is not quite right, since it is not writing out a derivative, but the approximate value of the new objective. approx_objective is the placeholder name until we make a better one.

Hi,
I'm working on extending the (univariate) PMP to the multivariate setting, hopefully with SDPB as solver. A lot stays similar, the most important change is that you need more blocks per constraint, and the number of blocks can vary between constraints.
I.e, in the univariate case you have (for positve definiteness on a set ):

whereas in the multivariate case you need (for positive definiteness on a set ):

where are polynomials.
So you really need the option to add a different number of Y blocks per constraint (blocks_j contains more than 2 elements).

However, it seems like this is not supported at the moment. In the input format (the files pvm2sdp generates from xml), blocks.i and bilinear_basis.i assume 2 blocks per constraint, and also during the reading of those files it is assumed (the part with parity in sdpb/src/sdp_solve/SDP/SDP/read_bilinear_basis.cxx seems to have to do with whether it is the first or second block of a constraint). In most computations, it looks like the information about the blocks comes from block_info; if that's the case, adding support for an arbitrary number of blocks might not be too difficult.

This raises a few questions:

1. To what extend is the assumption used in the solver itself?
2. Can it be implemented in the (near) future? A problem might be the input format. Not only the reading would have to change, but also writing the input by pvm2sdp and so on, as well as the wrappers. An idea would be to add an extra option for a slightly different input format, allowing for multiple blocks, while keeping 2 blocks per constraint as the default. Or an extra input file specifying the number of blocks per constraint, with 2 blocks per constraint as the default when that file is not found.

If it will be low on your priority list and the assumption is not very wide spread, I might give it a try myself. In that case, any advice would be appreciated (also because I only know the basics of programming in C++)!

EDIT: added the ^n for the multivariate setting

Hi.
I build SDPB on Debian Buster successfully. However, tests on *.m files in mathematica directory return, e.g. for Bootstrap2dExample.m, the following error:

alexis@debian:~/Descargas/sdpb-source$ ./build/sdp2input --precision=1024 --input=mathematica/Bootstrap2dExample.m --output=$HOME/test
Error: Error when parsing mathematica/Bootstrap2dExample.m: mpf_set_str
--------------------------------------------------------------------------
MPI_ABORT was invoked on rank 0 in communicator MPI_COMM_WORLD with errorcode 1.
NOTE: invoking MPI_ABORT causes Open MPI to kill all MPI processes. You may or may not see output from other processes, depending on exactly when Open MPI kills them.
--------------------------------------------------------------------------

I tested the *.xml files in test directory using build/pvm2sdp and build/sdbp, and they run ok as well as the script run_test.sh.

Thanks.

Something like TTTT_small. This includes proper convergence tests.

I posted a question here at stackoverflow. Even with the --enable-cxx option when I configure GMP, I still get Undefined symbols for architecture x86_64.

This can use the sequence of inputs deltaSigma_0.5*deltaEps_1_4 from dsd.

The two files

https://github.com/davidsd/sdpb/blob/master/src/sdpb/solve/SDP_Solver/run/compute_primal_residues_and_error_p.cxx

and

https://github.com/davidsd/sdpb/blob/master/src/sdpb/solve/SDP_Solver/run/compute_primal_residues_and_error_P.cxx

are only distinguished by the case of the last letter, P or p. This causes a lot of headaches when compiling, on the default file systems on Windows or Mac, which are case-preserving but case-insensitive. (There might be other pairs of files like this.)

This problem can be dealt with by using a file system different from the default on Windows or Mac, but it would be nicer if you do not use two file names distinguished only by the case of the letters.

I would have been happy to prepare a pull request on my side, but I would presume that @wlandry and @davidsd would have their own opinion on the naming of the files. So I’m raising the issue here first.

I'm currently trying to install locally on a server without root access. The code compiled without showing any obvious errors but trying to run the compiled executable leads to issues. a make test gives
[praharsh@chepcs1 sdpb]$ make test ./sdpb -s test.xml --noFinalCheckpoint ./sdpb: error while loading shared libraries: libgmp.so.10: cannot open shared object file: No such file or directory make: *** [test] Error 127
For reference this is what my makefile looks like

BASEDIR := $(HOME)
GMPINCLUDEDIR = /home/praharsh/lib/include
BOOSTINCLUDEDIR = /home/praharsh/lib/include/boost
LIBDIR = /home/praharsh/lib/lib`
and the contents of my /home/praharsh/lib/lib contain libgmp.so.10 as clear from the running ls there. Is there any way I can figure out where this error is coming from?

Hi,

I am not sure if this is generic, but I had the following issue when using your makefile: when linking the final target, some symbols from gmp are unresolved, apparently due to ordering of the libs when invoking g++ for $(RESULT). Solved by adding $(LIBS) to the end of the command for $(RESULT).

I rarely work in linux so I am not sure if this is a problem with my configuration.

As a side comment, in case someone tries to build this under cygwin -- boost detects cygwin and defines BOOST_WINDOWS_API instead of BOOST_POSIX_API. This makes boost::filesystem::path use wchar_t instead of char_t, which makes it incompatible with tinyxml2.

And thanks for writing and publishing this solver!

When following your instructions in Install.md for OS X everything works fine until the last step, i.e. compiling the sdpb executable. When compiling I get the following error

ld: library not found for -lrt

Apparently it is not a new feature, but simply removing -lrt from the Makefile as suggested in https://github.com/davidsd/sdpb/pull/10 doesn't work for me. Indeed I get the error

ld: symbol(s) not found for architecture x86_64

Could you help me with that?

Thanks a lot,
Best regards
Martina Cornagliotto

By default, SDPB prints the distribution of blocks between different cores after the timing run. When there are a large number of constraints, this can take up a lot of space in log files. Maybe we could suppress this output when there are a lot of blocks, unless the user sets a high verbosity level?

Are feature requests welcome here? When hot-starting sometimes SDPB gets stuck. When this happens the P-step and D-step become excessively small (e.g. respectively 5.17e-81 and 1.01e-85 within 50 steps). Also beta grows excessively large (2.72e+29). It would be useful if we could terminate based on these parameter values, so that we can restart without a checkpoint. As far as I am aware we cannot do this at the moment.

(There might also be fancy ways to get "unstuck", but this very simple feature would already mitigate most of the problem.)

Maybe the size of the primal and dual objective vectors, the number of blocks and their sizes, or something like that.

This is the error I am getting while configuring waf.

(base) aneekphys@ANEEKs-Air sdpb % ./waf configure --elemental-dir=$HOME/install
Setting top to : /Users/aneekphys/sdpb
Setting out to : /Users/aneekphys/sdpb/build
Checking for 'clang++' (C++ compiler) : mpicxx
Checking C++ 17 flag : no
Checking C++ 17 flag -std=c++17 : yes
Checking for Boost : no
The configuration failed
(complete log in /Users/aneekphys/sdpb/build/config.log)

More than one user has reported that sdpb or pvm2sdp will sometimes stall when running under Docker on an Intel Mac. It is not consistent. It can work many times in a row before failing. Restarting Docker.app will let it run again.

One workaround is to use an older version of Docker (3.2.2). This seems to eliminate or at least significantly reduce the frequency of stalls.

Coincidentally, both users discovered this while running sdpb through Mathematica. It is unclear if that is important.

I am currently trying and failing to implement a mixed bootstrap program. A truncated system for one correlation function with 1x1 polynomials matrices works, but the full system with 2x2 polynomial matrices does not.

I keep getting the error message

"sdpb: src/Matrix.cpp:196: void LUDecomposition(Matrix&, std::vector&): Assertion `info == 0' failed.
Aborted (core dumped)"

What causes this error? Is it a mistake in the implementation of the normalization condition or of the polynomial matrices?

Now sdpb needs input file sample.xml to be converted into directory sample by pvm2sdp.
The format of sample.xml is described in SDPB-Manual.pdf or arXiv:1502.02033, but no documents for the format of directory sample are given.
If the format is fixed, one can generate directory sample directly.

I read source of pvm2sdp and conjectured following format (which was successful in generating working input directory).
I think this conjecture is not so wrong, but there should be documents in sdpb repository, which would help developers of PyCFTBoot, cboot or other new wrappers in the future.

put vector v (N elements)

N
v[0]
...
v[N-1]

put matrix M (r rows, c columns)

r c
M[0,0]
...
M[0,c-1]
...
M[r-1,0]
...
M[r-1,c-1]

blocks.0

Let v_I, v_m, v_d, v_s be a vector of length J and for j=0,...,J-1, v_I[j]=j, v_m[j]=m_{j+1}, v_d[j]=d_{j+1} and v_s[j]=(d_{j+1}+1)m_{j+1}(m_{j+1}+1)/2.
Let q_r, q_c be a vector of length 2J and for j=0,...,J-1, q_r[2j]=(floor(d_{j+1}/2)+1)*m_{j+1}, q_r[2j+1]=(floor((d_{j+1}-1)/2)+1)*m_{j+1}, q_c[2j]=q_c[2j+1]=(d_{j+1}+1)*m_{j+1}.

1
put v_I
put v_m
put v_d
put v_s
put q_r
put q_c

bilinear_bases.0

For j=0,...,J-1, let qe_{j+1} be a matrix of floor(d_{j+1}/2)+1 rows and d_{j+1}+1 columns and its element in m-th row, k-th column (m,k>=0) is sqrt(s_k^{(j+1)})q_m^{(j+1)}(x_k^{(j+1)}).
For j=0,...,J-1, let qo_{j+1} be a matrix of floor((d_{j+1}-1)/2)+1 rows and d_{j+1}+1 columns and its element in m-th row, k-th column (m,k>=0) is sqrt(s_k^{(j+1)}x_k^{(j+1)})q_m^{(j+1)}(x_k^{(j+1)}).

J
put qe_1
put qo_1
...
put qe_J
put qo_J

objectives

Let b be a vector of length N and for n=0,...,N-1, b[n]=b_{n+1}.

b_0
put b

for j=0,...,J-1, primal_objective_c.j

Let schur=(d_{j+1}+1)m_{j+1}(m_{j+1}+1)/2.
Let c_j be a vector of length schur and for p=0,...,schur-1, c_j[p]=s_k^{(j+1)}P_{j+1,r+1,s+1}^0(x_k^{(j+1)}.
(r,s,k) (0<=s<=r<m_{j+1} and 0<=k<=d_{j+1}) corresponds to an index p of c_j, which is arranged in lexicographical order of (r,s,k).

put c_j

for j=0,...,J-1, free_var_matrix.j

Let schur=(d_{j+1}+1)m_{j+1}(m_{j+1}+1)/2.
Let B_j be a matrix of schur rows and N columns and for p=0,...,schur-1, n=0,...,N-1, B_j[p,n]=-s_k^{(j+1)}P_{j+1,r+1,s+1}^{n+1}(x_k^{(j+1)}.

put B_j

1. Support CMake
2. At some point, deprecate Waf

Why CMake instead of Waf?

• According to the 2022 C++ Developer Surveys by ISO C++ and by JetBrains, CMake is by far the most popular build system among C++ developers. Waf is not even mentioned there!

• In particular, CMake is used in SDPB dependencies such as Elemental, RapidJSON or libarchive. If SDPB will use CMake too, it will be easier to build it (or other projects using SDPB) with a single command.

• CMake is required for popular test frameworks such as GoogleTest (however, the second most popular Catch2 can be included without CMake). Test frameworks would be useful to organize SDPB tests, if we need more (everyone needs more tests!).

• Due to its popularity, CMake has better IDE support: VSCode has official CMake Tools Extension by Microsoft, and CLion uses CMake as its main project model.

I am generating SDPs in the Mathematica format via a Python script and then create the SDPB input file with sdp2input. However I want to use spectrum-extraction on the output, so I need an XML.

While I am aware that SDPB.m can convert a .m to an XML file, we do not have access to a Mathematica license on the cluster, and sdp2input is moreover lightning fast compared to Mathematica. It also has additional advantage of bypassing the need to compute the bilinear bases and samples on our end.

I'm trying to write a parser doing the reverse. Is there a straightforward way to convert the SDPB input format back to an XML? I have looked at the documentation but I couldn't figure out what structure they were following.

The current input format, based on XML, is much more verbose than necessary:

• XML is verbose in general
• some redundant information is included -- for instance all entries of symmetric matrices are included, instead of just the upper-triangular half.

It might be nice to allow:

• A text-based format that is less-verbose than XML (YAML?)
• A binary format that is compact and can be written from a variety of languages. Maybe something like thrift or protocol buffers would be a good idea for this?

There are small tests, but a larger, realistic test is required to make sure that it works for more than one problem.

Andy Stergiou says:

I'm writing to you regarding a possible bug in sdpb compiled with boost 1.58. Everything works well until I need to restart a job from a ck file. When I try to do that, I get the following message:

sdpb: src/Matrix.cpp:211: void choleskyDecomposition(Matrix&, Matrix&): Assertion `L.rows == dim' failed.

There is no problem with the xml file. On the same machine, if I compile sdpb using boost 1.55 and run sdpb on the same xml file this problem is not encountered.

Hi,

I'm trying to build from the latest tagged release, so I downloaded the tarball from https://github.com/davidsd/sdpb/releases/tag/2.4.0 . When I run the "waf" command to configure it, it fails looking for the git tag:

$ ./waf configure --elemental-dir=/cm/shared/apps/elemental/sdpb-fork/
Setting top to                           : /home/dlang/sdpb-build/sdpb-2.4.0
Setting out to                           : /home/dlang/sdpb-build/sdpb-2.4.0/build
Checking for 'g++' (C++ compiler)        : mpicxx
Checking C++ 14 flag                     : yes
Checking for Boost                       : yes
Checking for GMPXX                       : yes
Checking for MPFR                        : yes
Checking for Elemental                   : yes
Checking for libxml2                     : not found
Checking for 'libxml-2.0'                : yes
Checking for rapidjson                   : yes
fatal: not a git repository (or any parent up to mount point /)
Stopping at filesystem boundary (GIT_DISCOVERY_ACROSS_FILESYSTEM not set).
Traceback (most recent call last):
  File "/home/dlang/sdpb-build/sdpb-2.4.0/.waf3-2.0.14-e67604cd8962dbdaf7c93e0d7470ef5b/waflib/Scripting.py", line 119, in waf_entry_point
    run_commands()
  File "/home/dlang/sdpb-build/sdpb-2.4.0/.waf3-2.0.14-e67604cd8962dbdaf7c93e0d7470ef5b/waflib/Scripting.py", line 179, in run_commands
    ctx=run_command(cmd_name)
  File "/home/dlang/sdpb-build/sdpb-2.4.0/.waf3-2.0.14-e67604cd8962dbdaf7c93e0d7470ef5b/waflib/Scripting.py", line 170, in run_command
    ctx.execute()
  File "/home/dlang/sdpb-build/sdpb-2.4.0/.waf3-2.0.14-e67604cd8962dbdaf7c93e0d7470ef5b/waflib/Configure.py", line 85, in execute
    super(ConfigurationContext,self).execute()
  File "/home/dlang/sdpb-build/sdpb-2.4.0/.waf3-2.0.14-e67604cd8962dbdaf7c93e0d7470ef5b/waflib/Context.py", line 85, in execute
    self.recurse([os.path.dirname(g_module.root_path)])
  File "/home/dlang/sdpb-build/sdpb-2.4.0/.waf3-2.0.14-e67604cd8962dbdaf7c93e0d7470ef5b/waflib/Context.py", line 126, in recurse
    user_function(self)
  File "/home/dlang/sdpb-build/sdpb-2.4.0/wscript", line 14, in configure
    conf.env.git_version=subprocess.check_output('git describe --dirty', universal_newlines=True, shell=True).rstrip()
  File "/cm/shared/apps/miniconda3/miniconda3-4.6.14/lib/python3.7/subprocess.py", line 395, in check_output
    **kwargs).stdout
  File "/cm/shared/apps/miniconda3/miniconda3-4.6.14/lib/python3.7/subprocess.py", line 487, in run
    output=stdout, stderr=stderr)
subprocess.CalledProcessError: Command 'git describe --dirty' returned non-zero exit status 128.

Clearly I will just try git cloning the repo and checking out the tag, but thought I would report this issue in case others come across it. Thanks.

There is already an input schema. There should be something like the SDPB user manual for outer_limits.

We have created two scripts, one in python and one in Mathematica, to test the OPE-maximisation bootstrap for four identical scalars in 4D.

The python script dumps the result in a .m file in the SDP[obj, norm, pols] format described in the manual. Converting to input with sdp2input raises no errors, but SDPB itself returns a max complementarity exit code. We compared the SDP produced by Python with our Mathematica implementation and found it was strictly the same. The Mathematica implementation finds the expected primal-dual solution.

I was surprised that importing the SDP in Mathematica and directly re-exporting it, that is running only

mySDP = Import[“testPython.m”];
Export[“testPython2mma.m”, mySDP];

the new SDP testPython2mma.m leads to the primal-dual solution we expect (the same as the one produced directly by the Mathematica implementation).

The only difference I can see between the two SDPs is that Mathematica adds precisions after the numbers, e.g. 1.0000... -> 1`306. I took a quick look at the source code of sdp2input, and as far as I understand this added information is stripped off when reading the file.

Is there a particular format beyond what is described in the manual that the SDP must respect?

The log for both runs can be found here and the SDPs here.

Following installation instructions along with (now obsolete) site notes.

Configuration log

./waf configure --prefix=/home/marucha/.local-sdpb --mpfr-dir=/home/marucha/.local-sdpb --elemental-dir=/home/marucha/.local-sdpb --rapidjson-dir=/home/marucha/.local-sdpb --libarchive-dir=/home/marucha/.local-sdpb --gmpxx-dir=/home/marucha/.local-sdpb

and resulting config.log

Build log

 ./waf build -vvv 2>stderr.txt 1>stdout.txt

with resulting

• stdout
• stderr

Software stack

• RHEL 7.6 with kernel version 3.10.0-957.78.2.el7.x86_64
• Site packages:
  • gcc 8.4.0
  • openblas 0.3.10
  • mvapich2 2.3.4
  • boost 1.73.0
  • cmake 3.16.5 & python 3.7.7 (probably not relevant)
• Compiled packages
  • gmp-6.2.1 (compiled with --enable-cxx)
  • mpfr-4.1.0
  • qd-2.3.23
  • libarchive-v3.6.1
  • rapidjson-1.1.0
  • bootstrapcollaboration fork of elemental

Hardware

2 x Intel Xeon Gold 6410 (2 x 18c, HT disabled)

cat /proc/cpuinfo

...
processor       : 35
vendor_id       : GenuineIntel
cpu family      : 6
model           : 85
model name      : Intel(R) Xeon(R) Gold 6140 CPU @ 2.30GHz
stepping        : 4
microcode       : 0x2006c0a
cpu MHz         : 2300.000
cache size      : 25344 KB
physical id     : 1
siblings        : 18
core id         : 27
cpu cores       : 18
apicid          : 118
initial apicid  : 118
fpu             : yes
fpu_exception   : yes
cpuid level     : 22
wp              : yes
flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx pdpe1gb rdtscp lm constant_tsc art arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc aperfmperf eagerfpu pni pclmulqdq dtes64 monitor ds_cpl vmx smx est tm2 ssse3 sdbg fma cx16 xtpr pdcm pcid dca sse4_1 sse4_2 x2apic movbe popcnt tsc_deadline_timer aes xsave avx f16c rdrand lahf_lm abm 3dnowprefetch epb cat_l3 cdp_l3 invpcid_single intel_ppin intel_pt ssbd mba ibrs ibpb stibp tpr_shadow vnmi flexpriority ept vpid fsgsbase tsc_adjust bmi1 hle avx2 smep bmi2 erms invpcid rtm cqm mpx rdt_a avx512f avx512dq rdseed adx smap clflushopt clwb avx512cd avx512bw avx512vl xsaveopt xsavec xgetbv1 cqm_llc cqm_occup_llc cqm_mbm_total cqm_mbm_local dtherm ida arat pln pts pku ospke md_clear spec_ctrl intel_stibp flush_l1d arch_capabilities
bogomips        : 4604.62
clflush size    : 64
cache_alignment : 64
address sizes   : 46 bits physical, 48 bits virtual
power management:

Afterwords

Honestly, I've never seen GCC just crashing before, without mentioning what's roughly wrong with the code. Diagnosing and fixing stuff like that is way beyond my C++ skills and I'd love to learn what went wrong.

After a fresh install of SDPB (v2.2.0) and the modified elemental library (v0.88) the following sequence of commands, as described in Usage.md,

  sdp2input --precision=1024 --input=test/sdp2input_test.m --output=sdp2input_test

and

  sdpb --precision=1024 --procsPerNode=1 -s sdp2input_test

yields an error message

  A was not numerically HPD: 82 128 -2.94329e-286

This is an error coming from inside elemental when it finds that the matrix which it is attempting to decompose is not Hermitian positive definite.

This appears to be the elemental version of the MPACK error that was described in Issue #28, which occurs when there are flat directions in the SDP, and thus the matrix is degenerate. For other input files that are generated ourselves this error pattern appears when there are flat directions ('too many zeroes') in the SDP and after removing them then running sdp2input and SDPB produces the expected results.

I had to replace:

include <boost/filesystem.hpp>

With:

define BOOST_NO_CXX11_SCOPED_ENUMS

include <boost/filesystem.hpp>

undef BOOST_NO_CXX11_SCOPED_ENUMS

In 5-6 files to get it to build. I'll make a pull request to fix this if interested.

Create an option to SDPB to output the spectrum as in spectrum_extraction.py..

Currently JSON is used. Input file can be several GB, reading it in sdpb is slow (see also #78).
Binary format is more compact (by a factor ~ 8/log2(10) ~ 2.4 ), thus reducing IO costs.

We can add this format and let the user to decide which one to use.

On Debian sdpb crashes on most architectures (except amd64) with the error "stack smashing detected", see https://buildd.debian.org/status/package.php?p=sdpb
The links in the "Status" column lead to the full build logs.

This is probably a sign of buffer overflows. It's likely exposed by compiling with -fstack-protector-strong. It might be worth running some tests with valgrind to find the memory issues.

Hi,

I'm an IT staffer at Perimeter Institute (Canada) trying to install a build from source on our Ubuntu 16.04 cluster. Following your excellent INSTALL.md -- thank you!

One thing -- not sure if this is intended or not -- it looks like you merged the elemental branch to master a while back. The INSTALL.md instructions say to check out the elemental branch. I encountered a different error there, but then tried the master branch and at the ./waf stage I am getting:

[88/94] Compiling src/sdp2input/write_output/bilinear_basis/bilinear_form/bilinear_form.cxx
12:06:07 runner ['mpicxx', '-Wall', '-Wextra', '-O3', '-D SDPB_VERSION_STRING="2.1.2-2-g7cadb27"', '-std=c++14', '-I/cm/shared/apps/elemental/spdb-fork/include', '-I/usr/include/libxml2', '-DHAVE_GMPXX_H=
1', '-DHAVE_MPFR_H=1', '-DHAVE_LIBXML2=1', '../src/sdp2input/write_output/bilinear_basis/bilinear_form/bilinear_form.cxx', '-c', '-o/home/dlang/spdb-build/sdpb/build/src/sdp2input/write_output/bilinear_ba
sis/bilinear_form/bilinear_form.cxx.4.o']
../src/sdpb/SDP_Solver_Parameters/SDP_Solver_Parameters.cxx: In constructor ‘SDP_Solver_Parameters::SDP_Solver_Parameters(int, char**)’:
../src/sdpb/SDP_Solver_Parameters/SDP_Solver_Parameters.cxx:264:15: error: ‘ofstream’ is not a member of ‘boost::filesystem’
               boost::filesystem::ofstream ofs(out_directory / "out.txt");
               ^

which doesn't make any sense to me, since we have the Ubuntu libboost-filesystem-dev package installed, version 1_58_0, and that definitely does have ofstream in the boost::filesystem namespace. I added to

src/sdpb/SDP_Solver_Parameters/SDP_Solver_Parameters.cxx

#include <boost/filesystem/fstream.hpp>

and that compiles.

Then I get:

[89/94] Compiling src/sdp2input/write_output/bilinear_basis/bilinear_form/bilinear_form.cxx
12:18:40 runner ['mpicxx', '-Wall', '-Wextra', '-O3', '-D SDPB_VERSION_STRING="2.1.2-2-g7cadb27"', '-std=c++14', '-I/cm/shared/apps/elemental/spdb-fork/include', '-I/usr/include/libxml2', '-DHAVE_GMPXX_H=
1', '-DHAVE_MPFR_H=1', '-DHAVE_LIBXML2=1', '../src/sdp2input/write_output/bilinear_basis/bilinear_form/bilinear_form.cxx', '-c', '-o/home/dlang/spdb-build/sdpb/build/src/sdp2input/write_output/bilinear_ba
sis/bilinear_form/bilinear_form.cxx.4.o']
../src/sdp2input/write_output/bilinear_basis/bilinear_form/bilinear_form.cxx: In function ‘Boost_Float bilinear_form(const Damped_Rational&, const std::vector<boost::multiprecision::number<boost::multipre
cision::backends::mpfr_float_backend<0u, (boost::multiprecision::mpfr_allocation_type)1u> > >&, const std::vector<std::pair<__gnu_cxx::__normal_iterator<const boost::multiprecision::number<boost::multipre
cision::backends::mpfr_float_backend<0u, (boost::multiprecision::mpfr_allocation_type)1u> >*, std::vector<boost::multiprecision::number<boost::multiprecision::backends::mpfr_float_backend<0u, (boost::mult
iprecision::mpfr_allocation_type)1u> > > >, __gnu_cxx::__normal_iterator<const boost::multiprecision::number<boost::multiprecision::backends::mpfr_float_backend<0u, (boost::multiprecision::mpfr_allocation
_type)1u> >*, std::vector<boost::multiprecision::number<boost::multiprecision::backends::mpfr_float_backend<0u, (boost::multiprecision::mpfr_allocation_type)1u> > > > > >&, const std::vector<long int>&, c
onst std::vector<boost::multiprecision::number<boost::multiprecision::backends::mpfr_float_backend<0u, (boost::multiprecision::mpfr_allocation_type)1u> > >&, const std::vector<std::vector<boost::multiprec
ision::number<boost::multiprecision::backends::mpfr_float_backend<0u, (boost::multiprecision::mpfr_allocation_type)1u> > > >&, const int64_t&)’:
../src/sdp2input/write_output/bilinear_basis/bilinear_form/bilinear_form.cxx:53:59: error: no matching function for call to ‘boost::math::tools::polynomial<boost::multiprecision::number<boost::multiprecision::backends::mpfr_float_backend<0u, (boost::multiprecision::mpfr_allocation_type)1u> > >::polynomial(<brace-enclosed initializer list>)’
     pow(boost::math::tools::polynomial<Boost_Float>({0, 1}), m)),
                                                           ^
In file included from ../src/sdp2input/write_output/bilinear_basis/bilinear_form/bilinear_form.cxx:6:0:
/usr/include/boost/math/tools/polynomial.hpp:127:4: note: candidate: template<class U> boost::math::tools::polynomial<T>::polynomial(const boost::math::tools::polynomial<U>&)
    polynomial(const polynomial<U>& p)
    ^
/usr/include/boost/math/tools/polynomial.hpp:127:4: note:   template argument deduction/substitution failed:
../src/sdp2input/write_output/bilinear_basis/bilinear_form/bilinear_form.cxx:53:59: note:   couldn't deduce template parameter ‘U’
     pow(boost::math::tools::polynomial<Boost_Float>({0, 1}), m)),
                                                           ^
In file included from ../src/sdp2input/write_output/bilinear_basis/bilinear_form/bilinear_form.cxx:6:0:
/usr/include/boost/math/tools/polynomial.hpp:123:4: note: candidate: boost::math::tools::polynomial<T>::polynomial(const boost::math::tools::polynomial<T>&) [with T = boost::multiprecision::number<boost::multiprecision::backends::mpfr_float_backend<0u, (boost::multiprecision::mpfr_allocation_type)1u> >]
    polynomial(const polynomial& p)
    ^
/usr/include/boost/math/tools/polynomial.hpp:123:4: note:   no known conversion for argument 1 from ‘<brace-enclosed initializer list>’ to ‘const boost::math::tools::polynomial<boost::multiprecision::number<boost::multiprecision::backends::mpfr_float_backend<0u, (boost::multiprecision::mpfr_allocation_type)1u> > >&’
/usr/include/boost/math/tools/polynomial.hpp:117:4: note: candidate: template<class U> boost::math::tools::polynomial<T>::polynomial(const U&)
    polynomial(const U& point)
    ^
[....etc.....]

Is there a minimum Boost version that we're missing? Or can you provide any hints?

Is there a way to pass additional flags to the C++ compiler (analogous to -DCMAKE_CXX_FLAGS) when building SDPB without modifying wscript? I cannot find any such option in ./waf --help.

Apologies if this is a standard waf feature that I missed - I've never seen or used this build system before.

(Context: we want to inject -pg for profiling purposes.)

Could there be some bug in (the new version of) spectrum? I don't see where I can obtain the OPE or lambda of a fixed-x vector. It seems to just output something like

{
    "zeros":
      [
      ],
    "error": "3.454758966957157707376396366416383656106449573775604269577538038134155756314629827411604921638009520213765277182408071436510668902793057769924459441178074665931983101049853202482456808960034294158458280064057606422363788116736383566925873509412963146755133575701748377776"
  }

for the vector. I think spectrum is solving crossing correctly including the contribution from this fixed vector since the other OPE coefficients seem correct. Is it just not writing the lambda to the output for these fixed-x vectors? It has no zero since it is already a number, perhaps the code forgets to write the lambda in these cases?