You are here: Home BEMuSE Enhancing the users experience.
Personal tools
Document Actions

Enhancing the users experience.

by Riccardo Di Meo last modified 2007-11-23 03:30

A short description of the components added to the bare-bone porting of the applications that finally made the BEMuSE package.

Extra (necessary...) features.

Though the client and the server are all what's necessary in order to start and run a simulation, even since testing we noticed how that was not sufficient in order to ensure a satisfactory user experience, as well as very hard to debug in case of error.

Therefore we developed a wide set of added features (a easy to use interface and a real time logging system, among the others) in order to provide a user friendly environment and cope with some of the most common limitations that users face and point to us when porting an application.

The logging service

The first problem we faced while testing the first version of BEMuSE was that the debugging of the execution was painful to say the least: though the grid provides a Sandbox service meant to possibly retrieve log files at end of an execution and (a rather inefficient, if working) interactive job type which should provide the user with a real-time connection to the program executing on the grid (this also the most frequent reason of disappointment from most scientists trying to try the infrastructure as well), we felt that none of those solutions where up to the task of giving a reliable and easy to integrate view of the events happening on the WNs.

Therefore we created a new server (called logging_server and both a python module (to be integrated with python applications) and a stand alone client (derived from the module, not used anymore) to collect on the UI (usually, though other machines may be used) all the informations we might had wanted to send from the grid and we integrated the latter into the BEMuSE client.

This combination proved so successful in both helping to correct problems during the debugging phase, as well as to spot occasional crashes while running the simulations (e.g. due to remote failures on the clusters), that the new feature was be considered an inseparable component of our environment since then.

Though the logging server is a command line application which can be used with different modes, the most common (and well tested) use, (which has been included in the porting of the BEM algorithm) consist in running the application in background, saving the output of all clients connecting to it (through a simple authentication mechanism) in different unique files (other modes make the server open a differnt terminal for every connection, containing the scrolling output of the remote sender, which though is nice looking is not very handful for general usage).

FIXME snapshot of a logging service with terminals opened? FIXME

The user can then browse the directories, searching for the output of a specific client, and see what's happening remotely with no delay at all (or see what's happened, in the past, if the remote end has closed the connection).

FIXME listing of the directory with the logging files FIXME.

This service and it's great contribute to the project also inspired a similar application (the 'logging_tool', on this site) which, though with some very important differences, works with the same principle.

Here is a short snapshot of the logs received locally by the logging service from a client connecting to the server during a simulation:

FIXME connection sequence from the client FIXME.

The management interface

While running the various simulations, we noticed that the increased complexity of the environment had turned into a quite complex, error prone and time consuming procedure that required quite some time and expertise even from skilled people.

Though all aspect of the BEMuSE setup could be handled through user friendly .ini files, the complexity of setting a simulation up was aggravated by the constraint of keeping some of the parameters consistent among different configuration files which made the operation error prone (a very simple example is the configuration of the network parameters for the simulations: the port for the communication in the client and server .ini files should match and not be shared between different simulations, or with the logging service).

Here is reported, as example, the configuration file of a client:

FIXME small snapshot of a .ini file FIXME.

This led us to think a way to avoid what we considered one of the biggest impediments slowing the development and reducing the usability of our application.

We started therefore to build a set of tools (a small number of shell scripts, at the start) that where aimed to ease the burden of configuring and setting up a simulation, and we built a very simple, text based menu (in python), to paste all such scripts together.

The resulting, primitive interface, though allowing only for the most common setups, proved immediately to be very useful, reducing considerably the time necessary to get a simulation running and the burden coming from the sum of the complexity of the setup of the physic simulation (which must still be carried autonomously by the user) and the grid wrapper which constituted the first BEMuSE.

FIXME Figure: snapshot of the first interface. FIXME

Following the success of the first prototype we decided then to improve it in a more advanced and integrated curses based interface (still in python) which, tough still in (advanced) development, is aiming for the future to become the only program the user will need in order to set up and run a simulation.

FIXME Figure: snapshot of the new interface FIXME

The current implementation allows, among the other things, to:

  • Set up and start the logging service.
  • Compile all the programs necessary to run the simulation (like the modified gromacs binaries from the modified source by Alessandro Laio and Stefano Piana), including a new version of python and upload them to an SE.
  • Create and configure any number of simulations (including starting a server and uploading the input data files on the grid).
  • Manage all the grid related aspects of the initialization of a voms proxy (with checks on the extensions), jobs submission (both on a specific resource or match-making based) and deletion.

with each menu option briefly described by a small on-screen help.

FIXME Figure: another snapshot of the new interface (submission?) FIXME

The web server

to be continued...

Related content
« August 2017 »
Su Mo Tu We Th Fr Sa
12345
6789101112
13141516171819
20212223242526
2728293031
 

Powered by Plone This site conforms to the following standards: