![]() If the jobs are going to use a lot of memory, a large percentage of available CPU time (ie, be CPU bound), or a large percentage of avaiable Input/Output bandwidth (ie, be disk bound), then it is better to run them within SGE. If the footprint of the jobs is light, then they can just be run directly on the headnode after logging in. In some cases, you may just want to run a very quick job, or otherwise just need to run some commands without packaging them up in a job script. Whether using our scripts, or writing your own, it's advisable to run them a few at a time while you determine how much shared resources such as RAM, and disk that you need. Changing just these few items is enough to have a workable script that you can submit. Each of our scripts has several variables that tell the script where to find source data, config files, and other parameters that alter the job. We can help write others for you as needed, or you can use these as a template. ![]() As mentioned below the output and error messages generated during a job run on the cluster are captured into output, and error files for you to review.ĭepending on what software is needed we have some pre-written scripts that you will find in /share/scripts (or via \\\scripts). We cannot predict or control when these things happen so you should be prepared for that. Any number of things can go wrong, such as a node crashing, a resource (disk, memory) being exhausted, programming errors, or usage errors. You cannot assume that because your job finishes it actually completed successfully. Once processing is done review logs to make sure no problems occurred. ![]()
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |