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 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, as Ksenija advised, I ended up integrating assive 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.
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