GSOC 2013 (Idea9- Android app for Virtual Cell)

[prita...@gmail.com]

Sir,

I am Pritam Kumar Singh, currently doing my Engineering from BITS Pilani University, India. 

I have worked in Java, C, Android, PHP, HTML and MySQL. Last year I also did a summer training with MIT-IMI (Indian Mobile Initiative) on  Developing Android applications, and have been doing so for a year. I am also currently doing a project in Getting Efficient solution of liquid state Integral Equations using Nitsol Algorithm.

 I am very much interested in Idea 9 - developing an android app to view the simulation results from the database server. As mentioned in your desktop application, does the android application too has to:

1) View data displays from simulation as a Plot or Values 

2) also, whether we have to directly show the Exported simulation data saved in .csv format.

3) Will the API's be provided for retrieving data from the remote database server.

I will be really grateful to hear your inputs on these as soon as possible.

Thanking you,

Pritam Kumar Singh

[Jim Schaff]

Dear Pritam,

The apps primary focus is managing a user's simulations;

viewing status (waiting, queued, running (progress), completed, failed, stopped)

viewing simulated data

cloning a simulation with new parameter values

managing list of submitted simulation jobs viewing/starting/stopping a simulation

managing user's storage quotas (displaying usage, quota, and allowing simulation results to be deleted).

The initial JSON/HTML web API for retrieving simulation job status has been developed (using Restlet server-side framework).  A very simple Android app has been created (using the Restlet client-side framework) which only lists the simulations, and a small browser client is served up directly. (for more details including current API spec and screenshots, see posting https://groups.google.com/forum/?fromgroups=#!topic/vcell-discuss/y0_k5ufMm2k) 

>  1) View data displays from simulation as a Plot or Values 

Plotting time series values with the ability to see the numeric values of the data in the plot (maybe one time point at a time would be ok ... by using some sort of crosshair on the display)

>  2) also, whether we have to directly show the Exported simulation data saved in .csv format.

this is not an absolute requirement, but would be useful.  

>  3) Will the API's be provided for retrieving data from the remote database server.

Yes, all server-side APIs will be provided.

Thanks,

Jim.

[Pritam Kumar Singh]

Hi Jim.

As per what you said, this app will be making an HTTP request to get data to first show the status of simulations, the user can also view the simulated data, then he can clone a simulation with new parameters or editing the simulation and then can start and stop the simulations. For storing the data and managing the usage, will the data be saved in a Sqlite database or will it be stored on a server. Also, from the screenshots the nodes that we will be using from JSON will be modeltype, simkey,simname, simusername,status, etc.

What more will the app be doing as in for writing the proposal should I be including only these points.

Thanking you,

Pritam

[Jim Schaff]

HI Pritam,

I'll try to provide some additional background.  

Current non-mobile, non-browser architecture (for general understanding).

---------------------------------------------------------------------------------------------------------

The current client/server design of VCell uses a "fat" Java Client which can be locally installed and includes native executables for local simulation.  This client can be run standalone simulations and import/export XML BioModel files, but usually connects via Java RMI (an RPC approach) to our VCell RMI Services which provide for centralized model persistence, remote simulation execution on our high performance cluster, and remote simulation data storage, fine grained retrieval of spatial simulation results and mesh, and postprocessing and exporting simulation results in various formats.

In this architecture, the models (including simulation specifications) are stored in a centralized Oracle database by user with permissions of private (default), shared with a group of users, or public.  The "BioModel Document" is composed of a single physiological model (molecules, reactions, compartments, transport mechanisms) and multiple "Applications" (which specify the simulation paradigm ode,pde,ssa,particles,hybrid).  Each Application has multiple "Simulations" which specify the numerical tasks (e.g. which solver to use and numerical settings, and parameter sets).  So the document (physiology,applications,simulations) are captured in a single consistent (and complex) data structure (the "BioModel") which is viewed,edited,analyzed in memory within the client.  The client loads and saves the complete BioModels atomically.  Within the centralized Oracle database, the document is incrementally saved and decomposed into its pieces and stored in 50+ tables (and also in XML for fast caching).  The client-server communication is infrequent and only for persisting intact "documents" to the centralized Oracle database, requesting simulation start/stop, getting simulation status, and retrieving raw (compressed double[] arrays) and processed simulation results (e.g. Movies, images, csv files).  

For the purposes of mobile and browser based clients, the only BioModel component which is editable is the Simulation, and the centralized database owns the BioModel state.  However, for an android app, (or iOS for that matter), in order to have a responsive GUI and prevent unnecessary network communication, some local (SQLite) database (or other local persistence) will likely be necessary (mostly as a cache).  Also proper threading and app lifecycle management should be considered (e.g. a change in orientation of the device should not initiate a network request).

VCell Server Background:

The new VCell RESTful Web API has only just been started and the initial implementation only includes ability to query SimulationJob status.  The plan is for this Web API to become comprehensive - offering much of the capabilities of our existing VCell Services. which are run/cancel simulations, retrieve simulation results, export simulation results as images/movies/csv, load/save/delete models/simulations, manage model permissions, query simulation status, query models and simulations, query for reactions across all accessible models.

I would suggest storing the model/simulation metadata locally in SQLite and only retrieve deltas from our server ... the "current" simulation results should be temporarily stored while viewing (but discarded soon after to manage local storage). 

Another useful but not essential item would be an asynchronous notification scheme for completed simulations. 

All communication will be in JSON and the API will be documented in WADL.  In addition, the server side API will be implemented by me using the Restlet framework (partial prototype exists).  A corresponding set of RESTlet client-side android  "Resources" and "Representations" will be developed to facilitate communication and marshaling objects.  The final form of the API will evolve in collaboration with the mobile device developer during the project period to ensure performance, and functionality.

[Pritam Kumar Singh]

Sir,

Thanks a lot for the detailed description. And sorry for replying so late.

I also went through the other post (iPhone app on the same idea)This is what I have understood

--Making of parent simulation activity through which only we can give the functions for  start, stop delete, but with an option to view Child simulation job data.

-- Also allowing guest users to able to access some simulation data.(So creating a VCell account and run java client using Socket programming)

 and storing data in temp tables in SQLite (for current simulations) and also caching in order to view data (whole history if possible) if there is some network error.

Also, basically to pull data from RESTful service using Generic Interface ResultReceiver and Base Class IntentService:

   --- Creating the intent and call startService()

   ---The operation in the service starts and it sends the activity a message saying it started

   ---The activity processes the message and shows progress.

   ---The service finishes the operation and sends some data back to the activity.

   ---The activity processes the data and puts in in a form.

   ---The service sends Client a message saying that it is done (Push Notification)

Is it what you expect to be done in the project? hoping to hear from you as soon as possible.

Thanking you,

Pritam 

[James Schaff]

Dear Pritam,

 

What you said seems consistent with what would be needed.  But at this point, you have to submit your proposal to GSoC today, and then I can comment on your submission and give you suggestions for improvements.  You will have to come up with a more detailed concept and describe your design.  Summarize the requirements as you understand them, present your design, and comment on approach and technologies you plan to use. If you have more specific questions, please feel free to contact me directly (sch...@neuron.uchc.edu).

 

Best regards,

 

Jim Schaff.