After you install PIPS-NLP, it would generate 2 executable files: pipsnlp_serial and pipsnlp_parallel Both of them can read option file pipsnlp.parameter to determine the parameter used in the implementation. See pipsnlp.parameter for details of the adjustable parameters. Note that pipsnlp.parameter should be be placed in the folder where you call the executables.

pipsnlp_serial

solves the problem in serial, without any exploitation of problem structure, i.e., the iterate matrix is treated as a big sparse matrix. The usage is: pipsnlp_serial problem.nl where problem.nl is the problem NL file generated by AMPL or PYOMO.

pipsnlp_parallel

exploits the problem structure and can be used to solve problems in parallel, e.g., use reduced space or stochastic scenario structure The serial usage is: pipsnlp_parallel probRootName_ val where probRootName is the problem root name, and the last number tells how many .NL files are loaded.

For an example, with command pipsnlp_parallel probRootName_ 3 pipsnlp would load three NL files with names: probRootName_1.nl, probRootName_2.nl and probRootName_3.nl.

For this example, the parallel usage is: mpirun -np 3 pipsnlp_parallel probRootName_ 3 with solve the problem with 3 mpi processes.

For the stochastic scenario structure, currently we have two approaches to initialize the parallel setting. For an example, x0 is the 1st stage variables, and x1 and x2 are the second variables which come from two different scenarios. When we load two NL files, which are given by the model with different scenario data respectively, Ampl solver library (ASL) can return a full sparse matrices (Jacobian or Hessian) C1(x0,x1) from the 1st NL file, and C2(x0,x2) from the 2nd NL file.

By setting option AddSlackParallelSetting=0, We do preprocess to split the matrices into 3 parts: the local part is defined by the 2nd stage variables and the 2nd stage constraints; the global part is defined by the 1st stage variables and the 1st stage constraints; and the linking part is defined by the 1st stage variables and the 2nd stage constraints. This preprocess would creat an 1-1 map for the matrice's elements, which can help pipsnlp to quickly reset the matrice in the later iterations.

By setting option AddSlackParallelSetting=1, We do introduce slack variables and additional constraint to lift the problem. That is, we add slack variable s1 and constraint s1=x0 in the first scenario, and s2 and s2=x0 in the second scenario. By lifting the problem, we thus do not need to spilt the matrices returned from ASL. That is, we can use C1(s1,x1) and C1(s2,x1) directly, and add matrices in the bottom of the Jacobian to cover the slack variable and additive constraint.

Generally, approach 1 (AddSlackParallelSetting=0) requires more preprocess time but the problem size is smaller, while approach 1 (AddSlackParallelSetting=1) requires less preprocess time but the problem size is larger due to the extra variables and constraints. Approach 1 is the default method in pipsnlp_parallel.

Note that currently,

1. we do not support linking constraint, i.e., a global constraint which is defined by 2nd stage variables from different scenarios;
2. the reduced space solver only supports approach 1 (AddSlackParallelSetting=0), and all the decision variables MUST be in the 1st stage.