Portals:

GAMESS: (http://gridport.npaci.edu/gamess) Originally written in a collaboration with Mary Thomas, Maytal Dahan, Jerry Greenberg, and Kim Baldridge - original method and the SRB version (see below)). With the registration of QMView in the browser and with QMView installed on the client workstation data from GAMESS input and output files may be viewed.

APBS:(AdaptivePoisson-BoltzmannSolver): http://gridport.npaci.edu/apbs program for calculating the electrostatic properties of molecular structure). This portal was built with the cooperation of Nathan Baker (the author of APBS). This portal is a little more complicated then others, because the APBS input file lists the other required input files., requiring a I cgi script that parses the APBS input file, figures out what other input files are needed, and then lists the additional files that need to be downloaded. Also, Nathan uses the "Mozilla" browser (an open source browser based on the netscape browser) and requiring some tayloring.

Euler: A genetic sequencing program ( http://gridport.npaci.edu/euler and soon, http://gridport.npaci.edu/euler_srb )

This portal was written in conjunction with Haixu Tang (Pavel Pezner’s group) They are setting up an account (from their allocation) so that users approved by their group can log on and use the portal. Our main bottle neck on this right now is that for tar files over ~25 MB or so, the gridport/globus calls will not copy the files over and the portals group does not know why this is the case. (The cgi script issues a gridport/globus call to the remote machine to create and copy a tar file of all the results, then issues a gridport/globus call to copy the tar file over). One solution to this, is to port to the SRB, (that is instead of copying the results to /scratch/hpc, copy to the SRB), and this is currently being done..

AMBER: (Assisted Model Builder with Energy Refinement, http://gridport.npaci.edu/amber ) A portal so far written by Jerry Greenberg, and has been now passed to Dave Case.. We are currently extending the portal to connect with SUN HPC as

well as Blue Horizon. (still very much a work in progress). Once this is set up, this portal would be a good candidate for adding visualization components with QMView.

CE: (Combinatorial Extension) ( http://gridport.npaci.edu/CE) Written entirely by Gareth Stockwell. We have made some provisions inserted into QMView to display superimposed structures produces by the program.

Overall the portal structure isas follows:

Original Portal Setup

 

 

Originally the dataflow for the portals was as follows (see above). A user logged onto the portal and loaded input files into a NFS exported file system which served

as a storage area. When a job was submitted, the user would select input files from this area. The user would then select various submission options (platform, queue,

number of processors, time etc) and then submit the job. gridport_globus calls then

copied the input files and the batch script to the remote machine and then submitted

the job to a queue via a gridport_globus call. Further gridport_globus calls were then

used to check on the state of the job (e.g. run "llq" on blue horizon). When a job was finished, it was copied back to the same file system.

The latest portal scheme uses the SRB (Storage Resource Broker). With this method, input data is uploaded from the client workstation to the SRB via perl bound gridport_srb calls . Data is then sent via to the remote HPC machine via gridport_srb calls and output back to the SRB is retrieved the same way. Globus is used only to execute commands on the remote machine. This method has several advantages:
  1. It allows for permanent storage of data instead of in scratch space (albeit non-purging).

  2. A user may, independently of the portal, view their data with, for example, the "SRB Browser" (currently only available for WINDOWS). Under the old system, the data in scratch space was owned by user "hotpage". With the SRB scheme, the data is owned by the user.

  3. The SRB provides a method for structured data (i.e. databases, xml markup etc ) in the future.
  4. Unlike gridport/globus, there are no problems in copying large files.

 

The "euler" portal is partially ported to an srb based portal (based on Maytal Dahan’s work on the GAMESS srb portal). The reason we started with Euler is because it is the first portal where we have ran into problem (4), where the gridport/globus calls will sometimes fail to copy output files from the HPC machine back to the output area. This will test whether the assumption in (4) is correct.

Overall future portal plans
  1. Add analysis tools.
  2. Add data visualization components.
  3. Optimization: Various portal activities are relatively slow, (copying files, submitting jobs, inquiring on job status etc). Now, this is a mere annoyance. However, if portal submission catches on, this may become a real problem. The portals group is working on this.

  4. Create a schema for storing and retrieving data.

  5. Neuron data work (with Maryann Martone)

 

 

 

 

 

 

 

I wrote a perl script to extract polygons from a "SYNU" (SYNthetic Universe) file and make a file which QMView reads. The data in each SYNU file is treated by QMView as a separate object and may, like more then one molecule, be manipulated separately, or together. Data from two SYNU files are shown above. I am waiting to hear from Maryann. Last time I talked to her, they said that they would like to try out QMView on a SUN.

 

 

NwV Virus data from electron cyro-microscopy

(Padmadja Natarajan)

 

 

 

 

The first thing done here was to put the data into a form that QMView could use. Padmadja and I looked at all the pictures, and all but one were correct. I am still waiting to hear from here about this and some new data so that we can try to morph it. I talked to Mike Bailey about doing the animation: he said that I had the right idea: the problem is when the grids for each data set are a different size and/or scaled differently. This is something that can be worked out.