Application
Portal
In the beginning, the user
will enter the page of the CG Application Portal which is
http://kentauros.rtd.algo.com.gr:8080/jetspeed .
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.