User:Karthik0112358

C S Karthik is an undergraduate at IIT-Bombay and is working on addition of an rSQP optimiser for ASCEND during GSOC2011.

Goals

1. I would like to implement the option of generating mass matrix in RADAU5. There are 4 parts to this:
   1. Identify all terms in equation
   2. Checking each term for derivative variables
   3. For terms that have a derivative, checking if all factors are constant-valued
   4. Evaluating those constant-valued factors and multiplying them together
2. The reduced space SQP (rSQP) algorithm has seen many applications in large-scale engineering models. I intend to accept an input and parse it such that the solver can act on it. Further I am going to take up various test cases and check for bugs/inconsistencies. And if time permits I would like to write an optimization algorithm/code which, based on the given input, decides which is the best solver to send the input to.

Progress reports

June 23

Today is more like a "No-Coding-day". I plan to spend the entire day studying all the references John Pye has given me over the last 2 days. Trying to understand expression evaluation data structures to greater depths. Will report more.

1. Implementation of an Ascend Interpreter: Ascend is an object oriented language and hence the concept of dealing with instances. A tree data structure was chosen so that parent-child linkage could be exploited for effective storage and referencing. It is followed by explanation of various functionalities - same, alike, arrays in ASCEND. Base types, Relations are discussed. After Parsing, we finally come to the main topic- Instantiation. There is stress on the fact that ASCEND executes in a line by line fashion. The Multi-Pass Instantiator seems to have solved the problem of the interpreter's capability to allow multiple passes by storage of unexecuted instructions in instance data structure. The explanation provided through an algorithm is excellent demonstration. Final Note: Although gave me nice insight, not useful for resolving problem at hand.

June 21

Finally I have been able to reach the lowest level for coding this mass matrix. It involves rewriting doxy:RelationEvaluateResidualGradientSafe(). The code as stated below requires some understanding. John Pye had provided some references. Will see if they are related and may help me.

Hopefully the last of the skeletal code: Coefficient_Calculator().

So here is some explanation of the intent of Coefficient_Calculator(): I have assumed the equation looks like Q(x,y,y')=0. I have tried to find the length of the relation and get each term out. I have dealt with finishing cases also such as when both lhs and rhs are processed or when pointers are passed to top of stack. I would like to add a switch case for various terms which would be preceded by the following code segment:

term = NewRelationTerm(r, t++, lhs);

June 20

I have worked on a skeletal code (this is an addition to previous skeletal code- in other words providing some flesh to the skeleton) where I try to determine a row entry of the mass matrix: coefficient_find().

Again here I have tried to get a required version of relman_diff2() of ascend/system/relman.c. So in crux the entire task boils down to rewriting RelationCalcResidGradSafe() of ascend/compiler/relation_util.c into a function which gets the coefficients of the derivative terms - Coefficient_Calculator(). I will get a code out for that.

As of now I have a partial code for Coefficient_Calculator():

int Coefficient_Calculator(struct Instance *i){
   struct relation *r;
   enum Expr_enum reltype;
   int dummy_int;
   r = (struct relation *)GetInstanceRelation(i, &reltype);
   if( r == NULL ) {
      ERROR_REPORTER_HERE(ASC_PROG_ERR,"null relation\n");
      return -1;
   }
//At this point of writing the code, I realize the significance of why John Pye had asked me to understand expression-evaluation data structures. I need to write cases for reltype. I need some thinking.   
}

As part of understanding doxy:Expr_enum better, I would like to do a bit of "doxy search". Will get back with some update.

Simultaneously I will also write some test code file in compiler/test/ and try to see if I can get to know the contents of the structure. I will report worthy findings here.

June 19

So here is some skeletal-code: massmatrix(). This is code for one of the top layers.

I know I haven't followed the coding style of Ascend. I will modify code ASAP once other parts fall into place.

June 17

After giving it some thought, I think the structure of the mass matrix function should look more like system_jacobian() which is present in jacobian.c in ascend/system. Will sketch a pseudo code out after better clarity.

I am trying to see how to utilize doxy:System Structure, as I see potential information regarding extracting coefficients of y_i^' in equation. Since I am asked not to access the structure directly, I am looking through its implementation in slv_client.h.

After reading ascend/system/slv_client.h comments (which I might add are very descriptive and helpful), I realize the importance of the rel_relation structure as this contains the equation data. I have stopped trying to understand struct system and focus back on rel_relation.

So here is a plan. I replicate the entire set of codes required to find the Jacobian matrix. Now from what I know entries to the Jacobian are done row wise. Now Jacobian(mXn matrix) is found out for functions F : Rⁿ → R^m. However with the mass matrix problem, I am dealing with equations. So, my idea is to manipulate these equations into functions and replace the content of the (i,j) entry (by replacing the code which writes the content) into Jacobian with a different set of code, so that we get desirable result. Will get back on this.

June 16

• Reading relman_diff2() and trying to understand what are the input variables, which header to include, etc. Got some nice help from http://www.ascend4.org/doxy/d0/d7e/a00770.html#ga9469a6f8ff5a7d0eec8a1cad74732fdf. Came up with a vague code structure:

#include <ascend/compiler/rel_blackbox.h>
#include <ascend/compiler/relation.h>
#include <ascend/compiler/relation_util.h>
#include <ascend/compiler/relation_io.h>
#include "mass_matrix.h"
#include "slv_server.h"
#define IPTR(i) ((struct Instance *)(i))
#define KILL 0 /* compile dead code if kill = 1 */
#define REIMPLEMENT 0 /* code that needs to be reimplemented */
#define rel_tmpalloc_array(nelts,type)  \
   ((nelts) > 0 ? (type *)tmpalloc((nelts)*sizeof(type)) : NULL)
static double dsolve_scratch = 0.0;        /* some workspace */
#define DSOLVE_TOLERANCE 1.0e-08                /* no longer needed */
#define BROKENKIRK 0
/* return 0 on success (derivatives, variables and count are output vars too) */
int massmatrix(struct rel_relation *rel, const var_filter_t *filter
        ,real64 *derivatives, int32 *variables
        ,int32 *count){
  const struct var_variable **vlist=NULL;
  int32 len,c;
  int status;
  //CONSOLE_DEBUG("In Function: relman_diff2");
  assert(rel!=NULL && filter!=NULL);
  len = rel_n_incidences(rel);//this gives me the length of incidence- which I think is the number of columns of mass matrix
  vlist = rel_incidence_list(rel);//have to write rel_mass_matrix() which basically does the same thing
  *count = 0;

    for (c=0; c < len; c++) {
     //write the stuff here
     
      }
  return status;
}

June 15

• Trying to understand about expression-evaluation data structures by reading the following c code: ascend/system/relman.c.
• Re-reading Developer's Manual for better clarity.
• Checked out contents of Moocho and broadly read basic documentation.
• Installing MOOCHO: Downloaded trilinos-10.6.4-Source.tar.gz. As first step of the installation, I downloaded CMake. In the last step of Installation of CMake, I got the following error:

CMake Error at cmake_install.cmake:36 (FILE): file cannot create directory: /usr/local/doc/cmake-2.8. Maybe need administrative privileges.

make: *** [install] Error 1

Further on trying to install Trilinos, with the following commands, I got the following error :

~/SOME_BUILD_DIR$ cmake \

> -D CMAKE_BUILD_TYPE:STRING=DEBUG \

> -D Trilinos ENABLE <moocho>:BOOL=ON \

> -D Trilinos_ENABLE_TESTS:BOOL=ON \

> -D DART_TESTING_TIMEOUT:STRING=600 \

> $EXTRA_ARGS \

> {TRILINOS_HOME}

bash: moocho: No such file or directory

I contacted Bartlett, Roscoe A (rabartl@sandia.gov) via email regarding this problem. Hoping for an early reply.

June 6 - June 12

Finding a temporary fix for the mass matrix problem. I have split the task as to finding solution to 2 problems:

• (i) Making sure algebraic equations are being sent to solver.
• (ii) Writing a feasible mass matrix function to generate the mass matrix. This depends on (i).

Regarding Solving Part (i), I made an outside link and was able to capture all the variables involved. Trying to use them to find total number of equations. In completing part (ii) I am facing "INSUFFICIENT MEMORY" problem. Trying to fix that too. I am at present able to count total number of variables, solver variables, independent variables and number of differential equations. I would like to figure out a way to count number of free variables.

I have been able to find a solution to part(i), but it has 2 constraints,

• If number of total variables>>total number of equations, then the max number of substeps has to be reduced.
• The solution involves providing data outside given data structures and thus cannot employed as it is to ascend.

As far as part (ii) goes, there seems to be a simple fix. I am trying to figure it out through Valgrind's Memory loss method.

May 30 - June 5

• Completed reading Mathematical and High-Level Overview of MOOCHO.

May 23 - May 29

• Continue reading Mathematical and High-Level Overview of MOOCHO.

Prior to 23 May 2011:

Related to rSQP:

• Started reading Mathematical and High-Level Overview of MOOCHO. However was later redirected to chapter 12 (Nonlinear programming) of "Operations Research: Applications and Algorithms" from Winston, 1994, 3rd (or a later) Ed., Duxbury Press (Belmont, California) as a preliminary reading for mathematical background.
• Completed reading chapter 12 (Nonlinear programming) of "Operations Research: Applications and Algorithms".
• Re-reading Mathematical and High-Level Overview of MOOCHO.
• Revisited theory behind the Simplex Algorithm from "Introduction to Algorithms", 3rd Edition, Page 864-879 authored by Cormen, Leisersin, Rivest, Stein.

Related to Radau5:

• Investigated code ascend/integrator/integrator.h and ascend/integrator/integrator.c to understand the data structures used.
• Devised and tried implementation of various for the mass matrix problem in solvers/radau5/asc_radau5.c.
• Settled on the idea of replacing neq with total number of equations as compared to the previous implementation of number of states.