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.

Timeline

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

What are the goals of your project? How is your success with these goals measurable?

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)

What is your planning schedule for completing these goals?

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