#10 GSoC’18 – Second evaluation

This week has been a wrap up for second evaluations which are due next week. This means rigorous testing and finding issues. I have already been working on repeated tasks for several weeks passively and this is mainly because of the amount of work it required.

In one of my past posts, I described what are repeated tasks and what are the challenges that had to be addressed for successfully implementing repeated tasks.

Implementation of different simulation types:

As per the SED-ML specifications, there are three different ways to run a simulation. (a) UniformTimeCourse, (b) OneStep, and (c) SteadyState. UniformTimeCourse simulation specifies the start and end time for simulations along with step size which can be both linear and logarithmic. This was already implemented in the simulation-core library, however, there was a weird bug about the total number output points. The OneStep simulation method was implemented by running a UniformTimeCourse for just 2 steps which is a start point and end point. The steady-state simulation implementation simply checks for the change in the solver output until the change is below a certain tolerance. Every time the output doesn’t converge, the total simulation time gets increased logarithmically.

Implementation of repeated tasks:

Briefly, repeated tasks is a looping construct provided by SED-ML to run a set of sub-tasks repeatedly. The implementation is divided into 3 parts:

a) Sort the sub-tasks within one repeated tasks

b) Reset model, if required, and apply any required changes

c) Run all the sub-tasks in sorted order over the range specified

The current implementation does all of this and combines all sub-task results in a huge hashmap which maps each abstract task with the corresponding results list. Note that the simulation library doesn’t support nested repeated tasks currently. It is outside the scope of this GSoC project.

Post-processing sed-ml results:

One of the reasons why the implementation of the repeated task too long is because of the changes required for the downstream code. Once I implemented the repeated tasks, the simulation output changed from Map<AbstractTask, IRawSimulationResults> to Map<AbstractTask, List<IRawSimulationResults>>. This means that the raw results processing by the data generator has to be changed.

More on the results post-processing and data generators next week.



Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s