In the beginning, the user will enter the page of the CG Application Portal which is
If the user has already an account with the Application Portal, then he can enter with his username and password. Otherwise, he should have to create a new account in order to be able to enter the portlets area. The creation of a new account is a very easy procedure. All the user has to do is to fill in the relevant form with a few details, such as the name and e-mail address.
The steps are the following:
· The user loads proxy certificate from a MyProxy server that he has already delegated his credentials
· As soon as the proxy is loaded in the Proxy Manager portlet area, the user sees all the portlets with their introductory screen, ready for the user’s input and submission to the Grid.
· After that, the user can choose either to submit a simple job, or to submit a CG application with the parameter values that he would like to put.
· When the user has proceeded with the actual submission, he then waits for the results of the submission.
· In the meantime, the user can check the status of the job submission, to see if the job is output ready or has been scheduled, or whatever is its current status.
· When the job has finished its execution, the results are transferred back to the portal and the user is able to see them in the specific portlet area.
Below you are provided with a detailed description of the current version of the basic CrossGrid portlets. You are invited to study it before you proceed with any job submission.
A Short Tutorial on the basic CrossGrid portlets
In this short tutorial, the Job Submission and Job Get Output portlets are thoroughly described and explained. These two portlets cover all aspects of a job lifecycle, including submitting a job, checking its status and retrieving the output. With these two portlets one can submit any job to the CrossGrid testbed.
1) The Job Submission portlet
At the top of the portlet, the user has the ability to give a name to the job (it’s not obligatory), and after that the name of the executable or the full path to it together with any numerical parameters, if they exist, must be written in a text box. The full path must be included if the directory in which the application executable resides is not included in the user’s path.
If the job is an MPI job, then MPICH must be written in the text box under the executable. The number of processes follows, which should also be added in that case. If the job is not an MPI job, these two text boxes should be left blank.
The user can give a name in the StdOutput and StdError text fields for the standard output and error files that will be produced.
In case that the application executable is not installed in the testbed, the user has to write the location of the executable. This location is the full URL (starting with gsiftp://). Then, it will be transferred to the Computing Element via globus-url-copy.
The user can take advantage of the dynamic row creation that can happen for both the input and output files. These will too be transferred to the CE via globus-url-copy. In the case of the input files, the user can add any files that are needed for the specific application to run by pressing the “add” button. While in the case of the output files, the user can specify just the names of the files that are going to be produced after the execution of the application, if there are such files created at the end. In both cases, the user can remove the rows that he added dynamically by selecting any of them and pressing the “remove” button.
For those applications that will only run at a unique Computing Element, there is the ability to specify that CE in the appropriate text field (named ce_Id). Then, there are two drop-down boxes from which one can choose the RB and LB hosts (all the available hosts in the testbed are included). The user can also insert their respective ports, in case some changes are made and the default ones are not used.
2) The Job Get Output portlet
The Job Get Output portlet provides now the feature of showing the status of the submitted job inside its area. And whenever there is a “Done (finished)” flag for the job, the output files are presented in the form of HTML links. The user can click on these links and another browser window will open for each of the links, with the contents of the respective output file.
If the flag is one of the following: Done (Failed), Running, Aborted, Scheduled, Waiting, then the portlet screen is similar to the one below.
If the flag is Waiting or Scheduled or Running, the user is then able to try many times to retrieve the output files, until this is successfully done. Eventually the status of the submitted job will reach the Done (Finished) flag, and the links to the output files will appear.
Sometimes the output files that were specified by the user may not all of them be produced at the CE at the end of the application’s execution. In that case, the HTML links of the output files that were produced will appear inside the portlet, while on the other hand there will be a warning about the output files that were not produced.