User:RaymondJoseph

Hi There!

Thanks for stopping by.

I'm Harry Raymond Joseph, a master's student in EECS at IIT Madras, India. This page is intended to serve as a journal to keep track of my development work at Ascend as part of GSoC 2015. Updates and some relevant aspects of the GSoC proposal I submitted to Ascend are made available below.

Final Report on the Project

About the Project

---

The project was to better organize the entire ida solver module in Ascend. Specific sub-tasks included:

 a) Writing a separate function to pre-process the integrator. Before the project this was packaged as part of the ida.c file.
 b) Work on ida.c and make it a lot more readable and understandable.
 c) Handle the events syntax, with particular requirements and constraints on time-steps after roots.  
 d) An overall goal was to make the code handling the solvers/ida moule compact.

The Hows

---

Created process_integrator.c

1. Initially, as already mentioned preparing the integrator and allocating memory to it was actually part of the ida.c module. This made it slightly more complicated and difficult to understand the main module. The separate prepare_integrator that was created has the following functionality:

2. Allocate ida_mem : This is done by use of IDA_MALLOC.

3. Pass the integrator configuration settings: several integration configuration settings (eg. Pass tolerance settings, type of solver, etc) need to be obtained from the user and passed as input to the IDA, these are accomplished by using a variety of functions, as listed in the IDA manula.

4. Analyse the equations - An initial analysis of the equations is completed – for instance checking solvability, etc.

5. configure IDA (set up the sufficient memory for y, y_d etc vectors)

Created Process_events_and_whens.c

1. Process_events_and_whens.c is actually the main module that handles all the event processing and boundary checking.

2. It returns a flag peaw (process_events_and_whens) – to the ida.c main function. Based on the value of the flag, the integrator makes several choices on the size of time-steps and direction of roots, etc.

3. In this module, the lrslv solver is called to check for roots.

4. Another important role of this function is that it returns root directions, so that if a boundary is crossed from one side, lrslv need not check that side for boundary crossings again. This is done by passing the array pointer by reference to the Process_events_and_whens.c function.

Made changes to ida.c

1. The complete configuration of the ida.c was changed. The following is a brief outline of how the new ida.c is organized:

2. From within ida.c, the solver calls first prepare_integrator.c to make necessary memory allocations and to load integrator preferences.

3. Once this has been done, the main solver routine calls process_events_and_whnens to solve initial conditions as well as to check for crossed boundaries.

4. An important point to note is that this solving of initial condition happens only once within the loop – this is highly efficient, as this enabled combining together two functions – solve_initial_conditions_and_whens and process_events_and_whens.c into one single file.

5. This was accomplished by means of the flag ‘first_run’ which is initialized to TRUE, but is set to FALSE as soon as the process_events_and_whens function is called for the first time.

6. Now, during the subsequent calls, process_events_and_whens returns ‘peaw’, which is a flag, to ascertain the status if roots were found, and smaller integration time-steps need to be taken by the main solver routine calling process_events_and_whens.

7. Peaw is 143 if roots have been found, if roots have been found it also reconfigures ida, before proceeding to next integration SMALLER timestep.

8. The two cases (normal timestep and short after_root timestep) are handled in the if statements on peaw.

9. subpeaw, is for auxiliary shorter timesteps, if there are further roots closer to the roots first found (indicated by peaw==143)

10. Once peaw is set to 143 (root found), shorter timesteps are being taken. So integration now happens from t0 to t0+tmin instead of from t0 to tout.

11. Now further shorter timesteps need to be taken, to check for changes - at this point we also take into account rootdir.

12. Say, after the first root, we increment time by tmin, and we find another root - satisfying rootdir conditions, so within the loop, the integration now changes from t0+tmin*(auxcount-1) to t0+tmin*(auxcount).

13. Once all the timesteps have been completed, the integration is complete, and the solution is returned.

To dos in the Project

---

1. More testing is required to see if time-steps and changing happen properly;

2. Process_events_and_whens needs t be properly debugged.

3. At least the main ida.c and prepare_integrator seem to be working fine, but it might be better to add more comments within the code and perhaps search for places to make it more efficient.

Timeline

Week 13 (17th July to 21st August)

-Fixed all errors Ksenija pointed out on prepare_integrator earlier.

-Finishing a final report for end-term review;

-Successful in compiling working code with new main function and new prepare_integrator

-Succeesful in building new process_events_and_whens, although with the older ida.c

-Loaded some models but a syntax error was returned issue to be investigated.

Week 12 (10th August to 16th August)

-Completed debugging prepare_integrator.

-Several errors found when I started debugging process_events_and_whens with the new ida.c

-Errors ranged from complex linking and type incompatibility errors to simple and trivial but difficult t fix beacket_unbalanced errors.

-Also was a good time to revisit process_events_and_whens and see if the logic underlying the code was appropriate

Week 11 (3rd August to 9th August)

-Received detailed feedback from Ksenija on particularly the process_events_and_whens function. In particular

Ksenija pointed out the following issues:

"1. At the beginning you initialize the boundary state variables. But this function will do that *every* time you call it regardless of whether it is the first call or not. I suggest putting it into an 'if (first_run || all_bnds_set == 0)'. And I think that this

boundary evaluation can be moved to a separate function - this will just be more readable.

2. setup_lrslv is called each time when process_events_and_whens is called, while it should be called only at the first run.

3. The way you check if a boundary has been crossed is incorrect. IDA_ROOT_RETURN is a constant, the actual status is returned by IDASolve and it should be compared to IDA_ROOT_RETURN.

4. If no boundary is crossed (so we are making a small step after a root), you call ida_cross_boundary and then check that it does not change the structure o f a model. But ida_log_solve can change some logical variables, and some events might be triggered, but most likely only false events, which should not really be called. So you don't need to call the whole ida_cross_boundary function, but only the logical solver.

5. If a root has been found, you don't need to evaluate the boundary states here."

-Looked into each of these issues, but was unable to attend to them then, since I was still debugging prepare_intgerator

-There was also an

issue with linking new files on scons. The error detailed an unusual filename. This was because of a string concatenation mistake in the SConscripts file.

-Further re-analysed if steps being done in prepare_integrator are right;

Week 10 (27th July to 2nd August)

-Fixed previous errors but got stuck at an 'unrecognized symbol' error. The error seems to be very common, but many of the fixes suggested didn't seem to work. Have requested Ksenija for help on this error.

-Fixed many corrections suggested by Ksenija regarding process_events_..

-Some errors fixed include: 'load_rellist' not defined - on running the main solver. There was a problem in linking the files.

Week 9 (20th July to 26th July) -Faced ida registration problem - Ascend GUI returns the following erroor - 'cannot register ida solver'. Solved the problem - it was due to a wrongly commented command in the prepare_integrator.

-Spoke at length with Ksenija, and shared most of the debugging details and progress by sharing screens on Skype.

-Ksenija suggested I use plots to make sure that everything is alright. Plotting in Ascend requires matplotlib, faced problems getting that sorted out.

-Continued making changes to ida.c, Ksenija pointed out a flaw in testing - was not using ida to solve the models.

-Ran tests integrtor_idaevent and integrator_ida both returned errors so far, and I'm rectifying the same.

Week 8 (13th to 19th July) -Made further changes to process_event_and_whens.

-Tested both prepare_integrator as well as process_events_and_whens by calling these from the previous versions of the ida.c.

-For this, I commented out several lines of code in both ida.c as well as idaboundary.c to see if it worked well - the returned values for models in the Ksenija branch were correct.

-Continued running tests and mostly making changes to the main solver file.

Week 7 (6th to 12th July) -Continued debugging and running all tests to fully complete the integration of the codes I wrote into the Ascend framework.

-Faced difficulties debugging. The problem was mainly due to the en bloc approach followed. Instead of debugging small pieces of code, like Ksenija advised, I ended up integrating massive code chunks (eg: ida.c) in one shot. Better code architecture planning could have helped minimize debugging trouble.

-Completed the integration of prepare_integrator.

-Completed the integration of process_events_and_whens.

-Both these functions were tested, seem to be working fine.

-Calls to these from the main function (in the ida.c file) seem to be problematic.

Week 6 (29th June to 5th July) -Changed the structure of process_events_and_whens and eliminated solve_initial conditions_and_whens.

-process_events_and_whens will now be able to process initial conditions as well. The changed outline is as below:

solve the logrels if no values changed,

   return

if event cases were triggered (ie a positive edge):

   write_timestep_data
   write_event

if the event has 'USE' statement(s),

   run the METHOD, 
   run QRSlv, 
   run the _end method, return
   write time_step data

if when cases were triggered,

   update the solver rel lists

if structure has changed (how to tell?),

   reanalyse lists and reconfigure IDA

do the above if first_run == false else, its: solve the logrels

   if no values changed, 
       return
   if when cases were triggered,
       update the solver rel lists
   if structure has changed  
       reanalyse lists and reconfigure IDA

Week 5 (22nd to 28th June) -Completed implementation of ida_main_solve. The outline of ida_main_solve is as below:

Boundary flags initialisation: all the condition equations are evaluated

   and the values of corresponding boundary flags are set.

Boolean variables initialisation: the system is solved using the logical

   equations solver in order to get the correct values of Boolean variables.

Using the logical values found at step 2 the configuration of the system is chosen. Solver initialisation: setting solver parameters, allocating memory, et cetera. Loop through all time steps:

   If a root has not been found at the previous iteration then then reset all 
       the root direction settings. It means that IDA will be searching for 
       roots of condition equations in both directions.
   If a root has been found and we are far from desired output then make a very 
       small time step and solve the system with IDA. Else make a usual time 
       step which is set by the user.
   If we have made a small time step then call a logical solver in order to update 
       the values of logical variables.
   Check if a root has been found at this step. If yes:
       Call a function for processing this boundary.
           If there have been any changes in the system, then reinitialise the solver.
               Set the direction in which the roots of condition equations will be detected: 
               if a boundary has been crossed, then at the next step (which is an 
                   auxiliary small step) it will not be crossed in the same direction.
               If we are still far from desired output then repeat steps.

So basically we have two modes here: the first is when we make an ordinary time step, check all roots and if a boundary is found then call the function for processing it. The second mode is entered.

Week 4 (15th to 21st June) -Completed implementation of process_events_and_whens. The outline for process_events_and_whens is as below:

process_events_and_whens would then

   solve the boundary relations
   if no values changed, 
       return
   if event cases were triggered (ie a positive edge):
       write_timestep_data
       write_event
   if the event has 'USE' statement(s), 
       run the METHOD, 
       run QRSlv, 
       run the _end method, return
       write time_step data
   if when cases were triggered,
       update the solver rel lists
   if structure has changed (how to tell?), 
       reanalyse lists and reconfigure IDA

-Started implementation of ida_main_solve, the main ida solver function.

Week 3 (8th to 14th June) - Completed implementing prepare_integrator.

- Completed the implementation of solve_initial_conditions_and_whens.c, that's when I got stuck a little.

- Considered changes to the implementation plan below, to try and make it more efficient.

To do: Need to organize header files in a better way and make the overall code in the solvers/ida folder more compact.

Week 2 (1st to 7th June)

- Took more time to read up the IDA Sundials manual, especially the architecture of the IDA solver module.

- Received the following implementation outline from Ksenija and John:

integrator_ida_solve

   prepare_integrator
   solve_initial_conditions_and_whens
   write_timestep_data
   while(tsteps_remaining)
   integrate_to_next_step
   if(root triggered)
       process_events_and_whens
       advance timestep if we're really close already
   else:
       write_timestep_data
       advance to next timestep

process_events_and_whens would then

   solve the logrels
   if no values changed, return
   if event cases were triggered (ie a positive edge):
       write_timestep_data
       write_event
   if the event has 'USE' statement(s), 
       run the METHOD, 
       run QRSlv, 
       run the _end method, return
   write time_step data
   if when cases were triggered,
       update the solver rel lists
   if structure has changed (how to tell?)
       reanalyse lists and reconfigure IDA
    

solve_initial_conditions_and_whens would be

   once the continuous part of the problem is solved, we need to evaluate the bnds, and then run LRSlv.
   If that results in triggering any changes to WHEN cases, then we should
       reanalyse the equations
       reconfigure IDA
       go back and solver the continuous problem again (loop)
   If there are too many iterations, then we should return an error to the user.
   we don't want to trigger any EVENTs during this process; only WHENs.

prepare_integrator

   allocate ida_mem etc
   pass the integrator configuration settings
   analyse the equations
   configure IDA (set up the sufficient memory for y, y_d etc vectors)

- looking to complete before 16th June

Week 1 (25th to 31st May)

- Setup CUnit and ran some tests

- Spent time understanding IDA issues and implementation aspects

- Looked at ida.c and idaboundary.c in the ksenija2 branch of the svn repository.

- Worked on enhancing this code based on an implementation outline from John.

Community bonding period (27th April to 25th May)

- Installed Linux, and all other dependencies to prepare for coding.

- Built Ascend on my 64-bit 15.04 Ubuntu system. Log File:Attached.

- Reading the code in the Ksenija2 branch of the SVN repository.

GSoC 2015 Proposal

Organization: ASCEND

===Abstract:=== The IDA solver requires more refinements both in the numerical as well as user-facing aspects is desirable. One important issue is to do with EVENT syntax - which helps to model whole range of systems, in which parametric constants themselves change values with triggered events, or even more sophisticated systems in which constraint equations are added or deleted when a given event is triggered. This project attempts to strengthen the functionalities of the IDA solver. (* I'm using the proposal format, obtained from Carlos' GSoC 2012 proposal *)

About:

Master's student at TUM Germany/IITM India. Specializing in the numerical aspects in EECS, such as machine learning and probabilistic methods. Research enthusiast, few publications. Amateur poet and writer.

Email: raymond.harry@tum.de/raymond.joseph.7@gmail.com

Project Topic Numerical Algorithmic Enhancement: Dynamic Modelling in ASCEND

Basic Information

URL link to your CV: https://drive.google.com/file/d/0B04lAfTBvrd0a1dWc3hPYnZQTkU/view?usp=sharing

URL link to your personal blog/homepage: http://raymondjoseph7.wix.com/ctkotww

Research page: http://dl.acm.org/author_page.cfm?id=92458619092

Goals of the project

The main goal (Deliverable 1, D1) is to fully integrate IDA into ASCEND by providing and refining EVENT support syntax elements, especially ensuring that the integrator restarts efficiently after events are triggered with modified constraint equations. Secondary goals are:

- Improve IDA numerical solver efficiency. (D2)

- Refine existing code in the \ksenija2 branch. (D3)

- Possible GUI improvements in the use of the IDA solver. (D4)

- Event syntax for periodic events. (D5)

- Implement model of the simple solar water heater system as a test case. (D6)

- Make the documentation of migration and faq for users with applications. (D7)

Schedule

Week 1: Read up and understand IDA integration issues. Great sources and discussions have been documented on the integration issues.

Week 2: Scrub existing \ksenija2 code.

Week 3, 4 & 5: Implement advanced EVENT syntax, to complete integration of IDA into ASCEND. (D1)

Week 6: Explore possible syntax architectural changes for the IDA solver problems. (D3)

Week 7: Read latest cutting-edge research papers and see if new methods are available to increase solver efficiency. (Hint: Yes, more optimal methods are available, that perform better than the IDA solver adopted as part of the SUNDIALS project) (D2)

Week 8: Implement solver improvements to make the IDA solver state-of-the-art. (D2)

Week 9: GUI improvements. (D4)

Week 10: Periodic events support syntax. (D5)

Week 11: Buffer week for finalizing code, and running tests. Fix any bugs discovered.

Week 12: Implement test case: solar water heater system. (D6)

Week 13: Documentation and FAQs. (D7)

Coding experience

Programming languages you have learnt, and how many lines of code, approximately, you have written in each. C++ >1500 LoC (Lots of numerical methods experience. Monte-carlo methods, Newton-Raphson method, ODE simulation, etc.) MatLab >500 LoC (Lots of experience with advanced numerical methods. Example: water-filling, convex optimization using CVX, modified gradient-descent methods, linear algebra systems in communication, etc.) Java >400 LoC Python >1000 LoC (* Though most of it is classified. I worked as a data analytics programmer at a French startup, Tilkee *)

I also have lex/yacc experience. Used these to create my own 'business artifact modelling language' called BASQL. Based on SQL, the language was relatively successful, a paper on this was published at the IEEE ICES conference jointly with Youakim Badr. The language achieved great success and further research on this is being carried out by Youakim Badr at LIRIS-CNRS, INSA Lyon, France.

Some of these coding samples is provided in the URL.

MatLab: https://drive.google.com/folderview?id=0B04lAfTBvrd0fjhuLWFBNHprOXpsdlhDbU5XSmd3WnNfa3JqakdXRFRScmxIYkdfeTJKWGc&usp=sharing

C++: https://drive.google.com/folderview?id=0B04lAfTBvrd0TWl2T1BBSXlFNDQ&usp=sharing

Have you written any ASCEND models? Please provide copies.

I have been able to write two successful (albeit, very simple models):

1. The first one is on the 'dynamics of love affairs' paper by (Felmlee and Greenberg). The model can be found here: https://drive.google.com/file/d/0B04lAfTBvrd0SjU2aHZTZ2lwYkE/view?usp=sharing The snapshot of the solved model is below: https://drive.google.com/file/d/0B04lAfTBvrd0RmRmTzh5MVQ2WmM/view?usp=sharing

2. The second model is the simple non-flow domestic solar water heater system. The model can be found here: https://drive.google.com/file/d/0B04lAfTBvrd0SjU2aHZTZ2lwYkE/view?usp=sharing The snapshot of the solved model is below: https://drive.google.com/file/d/0B04lAfTBvrd0TERrcG5nbS1kckU/view?usp=sharing