In this page we answer some common questions related to the Long Tail of Science (LToS) platform and the connected WS-PGRADE/gUSE gateway.
Q: What type of executables are supported?
The compute infrastructure behind the LToS platform consists of grid and cloud infrastructures running on top of 64-bit Linux operating systems. Thus, this gateway enables the execution of binaries running on top of this operating system.
Q: How to run executables with additional binary dependencies?
One can assume that the LToS platform offers only a base operating system, thus if an executable with additional binary dependencies should be run, the binary dependencies should be submitted along with the executable. These additional dependencies will be placed into the working directory of the executable, and the executable must open them as needed.
Q: Which cloud can be used?
The list of cloud prodivers is available in the LToS Wiki page.
Q: How much capacity can be used inside a cloud?
You can find the different site capacities in the LToS Wiki page. When running jobs in the LToS platform, one can choose different instance types:
- Small: at least 1 vCPU, at least 2 GB of RAM,
- Medium: at least 2 vCPUs, at least 4 GB of RAM,
- Large: at lest 4 vCPUs, at least 8 GB of RAM.
Q: Can I use multiple executables in a single job?
Of course. You have multiple possibilities:
- Upload your "master" executable in the first step of the Job Wizard, and upload its dependencies as additional static input files. In this case, all the input files uploaded will be located in the working directory where the "master" executable is started, thus you'll be able to open them.
- Create a self-extracting, executable archive which contains all of your executable files (for example by using makeself), and define this self-extracting archive as the executable for your experiment. We're going to describe this approach in a bit more detail now.
makeself enables you to create an executable shell script containing an archive of files, which upon execution decompresses the bundled archive and starts a given executable after the extraction has finished.
Let's assume you have tree files which make up your application: start.sh, stuff.jar and basedata.blob, out of which start.sh should be executed. In order to create a self-extracting archive called myapp.sh using this files:
- copy these three files into an empty directory, and enter the directory
- make sure every file has the necessary permissions set (in the above example, start.sh should have executable permissions)
- invoke makeself to create the archive:
$ makeself --notemp . myapp.sh "My Super Application" ./start.sh
These steps will create the self-extracting archive called myapp.sh, which upon execution will extract an archive containing start.sh, stuff.jar and basedata.blob into the current working directory, and execute ./start.sh (start.sh in the working directory). Now you can upload myapp.sh as the executable for your application.
Q: Where can I find answers for my custom questions?
We provide an easy-to-use dicussion forum on this gateway.
Q: Where can I ask for more resource?
Write an email to email@example.com.
Q: How can I contact the support team?
In email: firstname.lastname@example.org.
Q: How can I acknowledge this work?
P. Kacsuk: P-GRADE portal family for Grid infrastructures, Concurrency and Computation: Practice and Experience journal, Volume: 23, Issue: 3, 2011, pp. 235-245.