Remeis-Wiki - User contributions [en]

General organisation of the lab

2019-02-21T12:03:43Z

Kreuzer: /* Who is involved in which experiment? */

[[Category:internal]]
This page is up to date for the Spring Lab 2019.
=== Who is involved in which experiment? ===
'''Azimuth''': Katya, Philipp (T.), Thomas, Ole 
'''CCD''': Maria, Matthias, Dominic, Melanie, Katrin, Christian 
'''Error propagation''': Max, Basti 
'''Imaging''': Simon, Roberto 
'''Observing''': David 
'''Radio''': Ralf, Jonathan, (Jakob), Andrea, (Konstantin, Florian), Stefan 
'''Spectroscopy''': Andreas, Matti, Markus D. 

=== Labtable ===
This is the link to our labtable: https://www.sternwarte.uni-erlangen.de/internal-area/labtable/ 
Please insert the dates of both experiment and final protocol as well as your scores in this table. You can also leave comments. 
This link is a permanent link, so for simplicity you might want to save it as a bookmark in your favorite browser.

=== Attendance ===
In order to have an overview of the individual attendances during the lab, there is a Doodle poll, where you have sign in for the days you will be at the observatory. At the days marked with 'yes', you are expected to be in Bamberg. 
First block: 
Second block: 
Additionally, it is mandatory for everyone to help during the observing night(s) in the garden. In order to have enough people around and to distribute this task fairly, you need to sign into additional Doodle polls, whose outcome Ingo is using to create a list containing the night shifts for everyone. 
The decision whether observing is planned for that night will be made until 5 pm by the profs. 
Night Doodle first block: 
Night Doodle second block:

Slurm

2019-02-12T13:00:54Z

Kreuzer: /* About */

[[Category:Slurm]]

= About =

In order to spread the workload of scientific computations on our compute nodes the resource manager SLURM is used.

From [https://slurm.schedmd.com/overview.html official SLURM website]:

''Slurm is an open source, fault-tolerant, and highly scalable cluster management and job scheduling system for large and small Linux clusters. Slurm requires no kernel modifications for its operation and is relatively self-contained. As a cluster workload manager, Slurm has three key functions. First, it allocates exclusive and/or non-exclusive access to resources (compute nodes) to users for some duration of time so they can perform work. Second, it provides a framework for starting, executing, and monitoring work (normally a parallel job) on the set of allocated nodes. Finally, it arbitrates contention for resources by managing a queue of pending work.''
[[File:entities_slurm.gif|frame|Different entities of Slurm]]
From [https://slurm.schedmd.com/overview.html official SLURM website]:

''SLURM manages the cluster in partitions, which are a set of compute nodes. Note, that partitions may overlap, e.g. one compute node may be in two or more partitions. A node is a physical computer which provides consumable resources: CPUs and Memory. A CPU does not necessarily have to be a physical processor but is more like a virtual CPU to run one single task on. A dual core with hyper threading technology, for instance, would show up as a node with 4 CPUs consisting of two cores with the capability of running two threads on each core. Physical memory is defined in MB.''

The following partitions exist in the current setup:

* remeis: default partition, all machines, timelimit: 7days
* erosita: only available for selected people involved in the project, timelimit: infinite
* debug: very high priority partition for software development, timelimit: 1h

= Quick users tutorial =

This tutorial will give you a quick overview over the most important commands. The [https://slurm.schedmd.com/overview.html official SLURM website] provides more detailed information.

== Get cluster status ==
In order to get an overview of the cluster, type
<pre>
sinfo
</pre>
This command offers a variety of options how to format the output. In order to get a detailed output while focusing on the nodes rather than the partitions, type
<pre>
sinfo -N -l
</pre>
An overview over the available partitions can be shown with
<pre>
scontrol show partition
</pre>
an the current queued and running jobs can be displayed using
<pre>
squeue
</pre>

== Executing a job in real-time ==
In order to allocate for instance 1 CPUs and 100MB of memory for real-time work, type
<pre>
salloc --mem-per-cpu=100 -n1 bash
</pre>
Your bash is now connected to the compute nodes. In order to execute a script use the srun-command
<pre>
srun my_script.sh
</pre>
Each srun-command you execute now is interpreted as a job step. The currently running job step of submitted jobs can be displayed using
<pre>
squeue -s
</pre>

You can also start a job by simply use the srun command and specify your requirements. In the following case, srun will allocate 100MB of memory and 1 CPU(s) for 1 task, only for the duration of execution.
<pre>
srun --mem-per-cpu=100 -n1 my_script.sh
</pre>
If resources are available your job will start immediately.

== Submitting a job for later execution ==

The most convenient way is to submit a job script for later execution. The top part of the script contains scheduling information for SLURM, the more information you provide here, the better.

First of all, a job name is specified, followed by a maximum time. If your job exceeds this time, it will be killed. However, do not overestimate too much because short jobs might start earlier. Acceptable time formats include "minutes", "minutes:seconds", "hours:minutes:seconds", "days-hours", "days-hours:minutes" and "days-hours:minutes:seconds". The output file is set to be test-job(jobID).out and the partition to run the job on is "remeis".
The sbatch-script itself will not initiate any job but only allocate the resources. The ''ntasks'' and ''mem-per-cpu'' options advise the SLURM controller that job steps run within the allocation will launch a maximum of number tasks and to provide for sufficient resources.

The ''srun'' commands in the job script launch the job steps. The example below thus consists of two job steps. Each of the ''srun'' commands may have own requirements concerning memory any may also spawn less tasks than given in the header of the script file. However, the values in the header may never be exceeded!
<pre>
#!/bin/bash
#SBATCH --job-name my_first_job
#SBATCH --time 05:00
#SBATCH --output test-job_%A_%a.out
#SBATCH --error test-job_%A_%a.err
#SBATCH --partition=remeis
#SBATCH --ntasks=4
#SBATCH --mem-per-cpu=100
srun -l my_script1.sh
srun -l my_script2.sh
</pre>
The ''-l'' parameter of ''srun'' will print the task number in front of a line of stdout/err. You can submit this script by saving it in a file, e.g. ''my_first_job.slurm'', and sumitting it using
<pre>
cepheus:~> sbatch my_first_job.slurm
Submitted batch job 144
</pre>

You can check the estimated starting time of your job using
<pre>
squeue --start
</pre>

== Submitting a job array ==

In order to submit a array of jobs with the same requirements you have to modify your script file.
The script above is going to spawn 4 jobs each consisting of one srun command. Note the presence of the new environment variable ''${SLURM_ARRAY_TASK_ID}'' which might be useful for your work. In this example we start an isis-script with different input values. You can also simply use different scripts.
<pre>
#!/bin/bash
#SBATCH --partition remeis
#SBATCH --job-name important_job
#SBATCH --ntasks=1
#SBATCH --time 00:05:00
#SBATCH --output /home/dauser/tmp/jobscript_beta.%A_%a.out
#SBATCH --error /home/dauser/tmp/jobscript_beta.%A_%a.err
#SBATCH --array 0-3

cd /home/user/script/

COMMAND[0]="./sim_script.sl 0.00"
COMMAND[1]="./sim_script.sl 0.10"
COMMAND[2]="./sim_script.sl 0.20"
COMMAND[3]="./sim_script.sl 0.30"

srun /usr/bin/nice -n +19 ${COMMAND[$SLURM_ARRAY_TASK_ID]}
</pre>
As above, this code might be saved in a file, for example ''job.slurm'' can be executed using
<pre>
sbatch job.slurm
</pre>

If you need a specific machine to run your job on, you can use
<pre>
#SBATCH --nodelist=leo,draco
</pre>
If you have a job with high I/O and/or traffic on the network you can limit the number of jobs running simultaneously (to 2 in this example) by
<pre>
#SBATCH --array 0-3%2
</pre>
SLURM will only allocate resources on the given nodes. However, if all nodes in 'nodelist' cannot fulfill the job requirements, SLURM will also allocate other machines.

If you would like to cancel jobs 1, 2 and 3 from job array 20 use
<pre>
scancel 20_[1-3]
</pre>
Note that you might have to escape the brackets when using the above command, e.g.,
<pre>
tcsh:~> scancel 20_\[1-3\]
</pre>
If you want to cancel the whole array, ''scancel'' works as usual
<pre>
scancel 20
</pre>
Note, there is also the option to modify requirements of single jobs later using ''scontrol update job=101_1 ...''.

If you have jobs which are dependent on the result of others or if you want a more detailed description concerning job arrays you can find it in the official SLURM manual: [[https://slurm.schedmd.com/job_array.html]]

== Submitting a job array where each command needs to change into a different directory ==

In order to allow each command of the job array to change into an individual directory (as opposed to all into the same directory as above), modify the script as follows:
<pre>
#!/bin/bash
#SBATCH --partition remeis
#SBATCH --job-name important_job
#SBATCH --ntasks=1
#SBATCH --time 00:05:00
#SBATCH --output /home/dauser/tmp/jobscript_beta.%A_%a.out
#SBATCH --error /home/dauser/tmp/jobscript_beta.%A_%a.err
#SBATCH --array 0-3

DIR[0]="/home/user/dir1"
DIR[1]="/home/user/dir2"
DIR[2]="/userdata/user/dir3"
DIR[3]="/userdata/user/dir4"

cd ${DIR[$SLURM_ARRAY_TASK_ID]}

COMMAND[0]="./sim_script.sl 0.00"
COMMAND[1]="./sim_script.sl 0.10"
COMMAND[2]="./sim_script.sl 0.20"
COMMAND[3]="./sim_script.sl 0.30"

srun /usr/bin/nice -n +19 ${COMMAND[$SLURM_ARRAY_TASK_ID]}
</pre>
This also works with paths relative to the directory where the slurm script was submitted.

== Submitting a job array with varying number of tasks ==

This is not really a job "array". But to execute multiple jobs with different number of tasks one can use multiple
srun calls chained with an '&'. This will submit the jobs at once but allow one to specify job parameters individually
for each job.

Example: Simultaneous fit of multiple datasets with different functions

<syntaxhighlight lang="bash" line='line'>
#!/bin/bash
#SBATCH --job-name my_simultaneous_fit_%n
#SBATCH --time 05:00
#SBATCH --output test-job_%A_%a.out
#SBATCH --error test-job_%A_%a.err
#SBATCH --partition=remeis
#SBATCH --mem-per-cpu=100
srun -l my_complicated_fit.sh 2 --ntasks=2 & # my_complicated_fit fits 2 line centers -> needs 2 tasks
srun -l my_complicated_fit.sh 4 --ntasks=4 # my_complicated_fit fits 4 line centers -> needs 4 tasks
</syntaxhighlight>

== Graphical jobs (srun.x11) ==
Not all applications run only on the commandline. Slurm does not support graphical applications natively but there is a wrapper script available which allocates the resources on the cluster and then provides a [[screen]] session inside a running [[SSH|SSH-session]] to the host where the resources have been allocated on. For example
<pre>
[12:06]weber@lynx:~$ srun.x11
</pre>
results in a new shell :
<pre>
[12:06]weber@messier15:~$
</pre>

which forwards the window if you start a graphical program for example
<pre>
[12:06]weber@messier15:~$ kate
</pre>
would open the text editor [[https://de.wikipedia.org/wiki/Kate_(KDE) kate]]. However, this only uses the standard resources set for the remeis partition. If you have other requirements you can also specify these in exactly the same way as for ''srun'':
<pre>
[12:06]weber@lynx:~$ srun.x11 --mem=2G
</pre>
would allocate 2GB of memory for the application.

== Using the ''erosita'' partition (serpens)==

If you are allowed to use the eRosita Partition, contact a SLURM admin (eg. [mailto:simon.kreuzer@fau.de simon.kreuzer@fau.de]). Once your username is added to the list of privileged users, you just have to add
<pre>
#SBATCH --partition=erosita
#SBATCH --account=erosita
</pre>
to your jobfiles.

== Other useful commands ==

* ''sstat'' Real-time status information of your running jobs

* ''sattach <jobid.stepid>'' Attach to stdI/O of one of your running jobs

* ''scancel [OPTIONS...] [job_id[_array_id][.step_id]] [job_id[_array_id][.step_id]...]'' Cancel the execution of one of your job arrays/jobs/job steps.

* ''scontrol'' Administration tool, you can for example use this to modify the requirements of your jobs. You can for exaple show your jobs ''show jobs'' or update the time limit ''update JobId= TimeLimit=2''.

* ''smap'' graphically view information about Slurm jobs, partitions, and set configurations parameters.

* ''sview'' graphical user interface for those who prefer clicking over typing. X-Server required.

= SLURM and MPI =
== About MPI ==
MPI (the Message Passing Interface) makes it possible to run parallel processes on CPUs of different hosts. To do so it uses TCP packets to communicate via the normal network connection. Some tasks can profit a lot of using more cores for computation.
At Remeis MPICH2 is used for initialisation of MPI tasks which is well supported within Slurm. The process manager is called '''pmi2''' and is set as default for srun. If an older MPI process manager is needed, for example for older MPI applications used in '''torque''', it can be set with
<pre>
#SBATCH --mpi=
</pre>
in the submission script.
<pre>
srun --mpi=list
</pre>
provides a list of supported MPI process managers.

The implementation of MPI for SLang/ISIS is called '''SLMPI'''.

== Best practice for MPI tasks ==

The usage of MPI might cause continuously high network traffic especially on the host which holds the master process. Please consider this when deciding which nodes are used for the job. It's a good idea to provide servers (e.g. leo or lupus) with the ''--nodelist='' option one of which is then used to hold the master process since nobody is sitting in front of it and trying to use a browser. Additional nodes are allocated automatically by Slurm if required to fit the ''--ntasks'' / ''-n'' option.

MPI jobs depend on all allocated nodes to be up and running properly, so I'd like to use this opportunity to remind about shutting down/rebooting PCs on your own without any permission can abort a whole MPI job.

== Requirements and Tips ==
To use MPI obviously the application or function used should support MPI. Examples range from programs written in C using some MPI features and compiled with the ''mpicc'' compiler to common ISIS-functions such as ''mpi_emcee'' or ''mpi_fit_pars''.

Keep in mind that everything in the compiled programs/scripts which is not an MPI compatible function is executed on each node on its own. For example in ISIS with ''-n 20'':
<pre>
fit_counts;
</pre>
would fit the defined function to the dataset 20 times at once. That's not very helpful so think about which tasks should be performed in the actual MPI process. Special care has to be taken if something has to be saved as a file. Consider:
<pre>
save_par("test.par");
</pre>
with ''-n 20''. This would save the current fit parameters to '''test.par''' in the working directory 20 times at exactly the same time. This might be helpful if the file is needed on the scratch disk of each node, but doing this on for example ''/userdata'' can cause serious trouble. The function ''mpi_master_only'' can be used to perform a user defined task in an MPI job only once. Best way is to only submit an MPI job to Slurm which only contains actual MPI functions. If some models in ISIS are used which output something to stdout or stderr while loading these messages are also generated 20 times since it's loaded in each process individually.

== Usage ==
If the job is a valid MPI process then the submission works exactly like for any other job:
<pre>
#!/bin/bash
#SBATCH --job-name my_first_mpi_job
#SBATCH ...
#SBATCH --ntasks=20
cd /my/working/dir
srun /usr/bin/nice -n +15 ./my_mpi_script
</pre>
It might be necessary to set a higher memory usage than for the according non MPI job since some applications try to limit the network traffic by just copying the required data to each node in the first place.

Also make sure that if it is necessary to specify the number of child processes in the application itself, set it to the same as with the ''--ntasks'' / ''-n'' option in the submission. An example would be the ''num_slaves'' qualifier in ''mpi_emcee''.

Note that the ''srun'' command does not contain ''mpiexec'' or ''mpirun'' which were used in older versions of MPI to launch the processes. The processes manager ''pmi2'' is built into Slurm and makes it possible that Slurm itself can initialize the network communication with the ''srun'' command only.

Of course it's also possible to run the MPI process directly from the commandline. As an example let's have a look at the calculation of pi with the MPI program ''cpi''. The program comes with the source code of MPICH2 and is compiled in the ''check'' rule. It's located in
<pre>
/data/system/software/mpich/mpich-3.2/examples
</pre>
To run the calculation in 10 parallel processes directly from the commandline use:
<pre>
[1:11]weber@lynx:/data/system/software/mpich/mpich-3.2/examples> srun -n 10 ./cpi
Process 0 of 10 is on aquarius
Process 1 of 10 is on ara
Process 6 of 10 is on asterion
Process 2 of 10 is on ara
Process 8 of 10 is on asterion
Process 7 of 10 is on asterion
Process 3 of 10 is on aranea
Process 5 of 10 is on aranea
Process 4 of 10 is on aranea
Process 9 of 10 is on cancer
pi is approximately 3.1415926544231256, Error is 0.0000000008333325
wall clock time = 0.010601
</pre>
As we can see Slurm launched 10 processes distributed to aquarius, ara, asterion, aranea and cancer. Keep in mind that running MPI interactively doesn't really make sense. The best way to go is to write a submission script like explained above and let Slurm handle the initialisation.

Slurm

2019-02-12T13:00:37Z

Kreuzer: /* About */

[[Category:Slurm]]

= About =

In order to spread the workload of scientific computations on our compute nodes the resource manager SLURM is used.

From [https://slurm.schedmd.com/overview.html official SLURM website]:

''Slurm is an open source, fault-tolerant, and highly scalable cluster management and job scheduling system for large and small Linux clusters. Slurm requires no kernel modifications for its operation and is relatively self-contained. As a cluster workload manager, Slurm has three key functions. First, it allocates exclusive and/or non-exclusive access to resources (compute nodes) to users for some duration of time so they can perform work. Second, it provides a framework for starting, executing, and monitoring work (normally a parallel job) on the set of allocated nodes. Finally, it arbitrates contention for resources by managing a queue of pending work.''
[[File:entities_slurm.gif|frame|Different entities of Slurm]]
From [https://slurm.schedmd.com/overview.html official SLURM website]:

''SLURM manages the cluster in partitions, which are a set of compute nodes. Note, that partitions may overlap, e.g. one compute node may be in two or more partitions. A node is a physical computer which provides consumable resources: CPUs and Memory. A CPU does not necessarily have to be a physical processor but is more like a virtual CPU to run one single task on. A dual core with hyper threading technology, for instance, would show up as a node with 4 CPUs consisting of two cores with the capability of running two threads on each core. Physical memory is defined in MB.''

The following partitions exist in the current setup:

* remeis: default partition, all machines, timelimit: 7days
* erosita: only available for selected people involved in the project, timelimit: infinite
* power: only the newest machines and servers, higher priority than 'remeis' (e.g. if you submit via power you will get the power machines as soon as possible and not compete with 'remeis' jobs but only other jobs submitted to 'power'), timelimit: 1day
* messier: only messier cluster, also higher priority than 'remeis', timelimit: 7 days
* debug: very high priority partition for software development, timelimit: 1h

= Quick users tutorial =

This tutorial will give you a quick overview over the most important commands. The [https://slurm.schedmd.com/overview.html official SLURM website] provides more detailed information.

== Get cluster status ==
In order to get an overview of the cluster, type
<pre>
sinfo
</pre>
This command offers a variety of options how to format the output. In order to get a detailed output while focusing on the nodes rather than the partitions, type
<pre>
sinfo -N -l
</pre>
An overview over the available partitions can be shown with
<pre>
scontrol show partition
</pre>
an the current queued and running jobs can be displayed using
<pre>
squeue
</pre>

== Executing a job in real-time ==
In order to allocate for instance 1 CPUs and 100MB of memory for real-time work, type
<pre>
salloc --mem-per-cpu=100 -n1 bash
</pre>
Your bash is now connected to the compute nodes. In order to execute a script use the srun-command
<pre>
srun my_script.sh
</pre>
Each srun-command you execute now is interpreted as a job step. The currently running job step of submitted jobs can be displayed using
<pre>
squeue -s
</pre>

You can also start a job by simply use the srun command and specify your requirements. In the following case, srun will allocate 100MB of memory and 1 CPU(s) for 1 task, only for the duration of execution.
<pre>
srun --mem-per-cpu=100 -n1 my_script.sh
</pre>
If resources are available your job will start immediately.

== Submitting a job for later execution ==

The most convenient way is to submit a job script for later execution. The top part of the script contains scheduling information for SLURM, the more information you provide here, the better.

First of all, a job name is specified, followed by a maximum time. If your job exceeds this time, it will be killed. However, do not overestimate too much because short jobs might start earlier. Acceptable time formats include "minutes", "minutes:seconds", "hours:minutes:seconds", "days-hours", "days-hours:minutes" and "days-hours:minutes:seconds". The output file is set to be test-job(jobID).out and the partition to run the job on is "remeis".
The sbatch-script itself will not initiate any job but only allocate the resources. The ''ntasks'' and ''mem-per-cpu'' options advise the SLURM controller that job steps run within the allocation will launch a maximum of number tasks and to provide for sufficient resources.

The ''srun'' commands in the job script launch the job steps. The example below thus consists of two job steps. Each of the ''srun'' commands may have own requirements concerning memory any may also spawn less tasks than given in the header of the script file. However, the values in the header may never be exceeded!
<pre>
#!/bin/bash
#SBATCH --job-name my_first_job
#SBATCH --time 05:00
#SBATCH --output test-job_%A_%a.out
#SBATCH --error test-job_%A_%a.err
#SBATCH --partition=remeis
#SBATCH --ntasks=4
#SBATCH --mem-per-cpu=100
srun -l my_script1.sh
srun -l my_script2.sh
</pre>
The ''-l'' parameter of ''srun'' will print the task number in front of a line of stdout/err. You can submit this script by saving it in a file, e.g. ''my_first_job.slurm'', and sumitting it using
<pre>
cepheus:~> sbatch my_first_job.slurm
Submitted batch job 144
</pre>

You can check the estimated starting time of your job using
<pre>
squeue --start
</pre>

== Submitting a job array ==

In order to submit a array of jobs with the same requirements you have to modify your script file.
The script above is going to spawn 4 jobs each consisting of one srun command. Note the presence of the new environment variable ''${SLURM_ARRAY_TASK_ID}'' which might be useful for your work. In this example we start an isis-script with different input values. You can also simply use different scripts.
<pre>
#!/bin/bash
#SBATCH --partition remeis
#SBATCH --job-name important_job
#SBATCH --ntasks=1
#SBATCH --time 00:05:00
#SBATCH --output /home/dauser/tmp/jobscript_beta.%A_%a.out
#SBATCH --error /home/dauser/tmp/jobscript_beta.%A_%a.err
#SBATCH --array 0-3

cd /home/user/script/

COMMAND[0]="./sim_script.sl 0.00"
COMMAND[1]="./sim_script.sl 0.10"
COMMAND[2]="./sim_script.sl 0.20"
COMMAND[3]="./sim_script.sl 0.30"

srun /usr/bin/nice -n +19 ${COMMAND[$SLURM_ARRAY_TASK_ID]}
</pre>
As above, this code might be saved in a file, for example ''job.slurm'' can be executed using
<pre>
sbatch job.slurm
</pre>

If you need a specific machine to run your job on, you can use
<pre>
#SBATCH --nodelist=leo,draco
</pre>
If you have a job with high I/O and/or traffic on the network you can limit the number of jobs running simultaneously (to 2 in this example) by
<pre>
#SBATCH --array 0-3%2
</pre>
SLURM will only allocate resources on the given nodes. However, if all nodes in 'nodelist' cannot fulfill the job requirements, SLURM will also allocate other machines.

If you would like to cancel jobs 1, 2 and 3 from job array 20 use
<pre>
scancel 20_[1-3]
</pre>
Note that you might have to escape the brackets when using the above command, e.g.,
<pre>
tcsh:~> scancel 20_\[1-3\]
</pre>
If you want to cancel the whole array, ''scancel'' works as usual
<pre>
scancel 20
</pre>
Note, there is also the option to modify requirements of single jobs later using ''scontrol update job=101_1 ...''.

If you have jobs which are dependent on the result of others or if you want a more detailed description concerning job arrays you can find it in the official SLURM manual: [[https://slurm.schedmd.com/job_array.html]]

== Submitting a job array where each command needs to change into a different directory ==

In order to allow each command of the job array to change into an individual directory (as opposed to all into the same directory as above), modify the script as follows:
<pre>
#!/bin/bash
#SBATCH --partition remeis
#SBATCH --job-name important_job
#SBATCH --ntasks=1
#SBATCH --time 00:05:00
#SBATCH --output /home/dauser/tmp/jobscript_beta.%A_%a.out
#SBATCH --error /home/dauser/tmp/jobscript_beta.%A_%a.err
#SBATCH --array 0-3

DIR[0]="/home/user/dir1"
DIR[1]="/home/user/dir2"
DIR[2]="/userdata/user/dir3"
DIR[3]="/userdata/user/dir4"

cd ${DIR[$SLURM_ARRAY_TASK_ID]}

COMMAND[0]="./sim_script.sl 0.00"
COMMAND[1]="./sim_script.sl 0.10"
COMMAND[2]="./sim_script.sl 0.20"
COMMAND[3]="./sim_script.sl 0.30"

srun /usr/bin/nice -n +19 ${COMMAND[$SLURM_ARRAY_TASK_ID]}
</pre>
This also works with paths relative to the directory where the slurm script was submitted.

== Submitting a job array with varying number of tasks ==

This is not really a job "array". But to execute multiple jobs with different number of tasks one can use multiple
srun calls chained with an '&'. This will submit the jobs at once but allow one to specify job parameters individually
for each job.

Example: Simultaneous fit of multiple datasets with different functions

<syntaxhighlight lang="bash" line='line'>
#!/bin/bash
#SBATCH --job-name my_simultaneous_fit_%n
#SBATCH --time 05:00
#SBATCH --output test-job_%A_%a.out
#SBATCH --error test-job_%A_%a.err
#SBATCH --partition=remeis
#SBATCH --mem-per-cpu=100
srun -l my_complicated_fit.sh 2 --ntasks=2 & # my_complicated_fit fits 2 line centers -> needs 2 tasks
srun -l my_complicated_fit.sh 4 --ntasks=4 # my_complicated_fit fits 4 line centers -> needs 4 tasks
</syntaxhighlight>

== Graphical jobs (srun.x11) ==
Not all applications run only on the commandline. Slurm does not support graphical applications natively but there is a wrapper script available which allocates the resources on the cluster and then provides a [[screen]] session inside a running [[SSH|SSH-session]] to the host where the resources have been allocated on. For example
<pre>
[12:06]weber@lynx:~$ srun.x11
</pre>
results in a new shell :
<pre>
[12:06]weber@messier15:~$
</pre>

which forwards the window if you start a graphical program for example
<pre>
[12:06]weber@messier15:~$ kate
</pre>
would open the text editor [[https://de.wikipedia.org/wiki/Kate_(KDE) kate]]. However, this only uses the standard resources set for the remeis partition. If you have other requirements you can also specify these in exactly the same way as for ''srun'':
<pre>
[12:06]weber@lynx:~$ srun.x11 --mem=2G
</pre>
would allocate 2GB of memory for the application.

== Using the ''erosita'' partition (serpens)==

If you are allowed to use the eRosita Partition, contact a SLURM admin (eg. [mailto:simon.kreuzer@fau.de simon.kreuzer@fau.de]). Once your username is added to the list of privileged users, you just have to add
<pre>
#SBATCH --partition=erosita
#SBATCH --account=erosita
</pre>
to your jobfiles.

== Other useful commands ==

* ''sstat'' Real-time status information of your running jobs

* ''sattach <jobid.stepid>'' Attach to stdI/O of one of your running jobs

* ''scancel [OPTIONS...] [job_id[_array_id][.step_id]] [job_id[_array_id][.step_id]...]'' Cancel the execution of one of your job arrays/jobs/job steps.

* ''scontrol'' Administration tool, you can for example use this to modify the requirements of your jobs. You can for exaple show your jobs ''show jobs'' or update the time limit ''update JobId= TimeLimit=2''.

* ''smap'' graphically view information about Slurm jobs, partitions, and set configurations parameters.

* ''sview'' graphical user interface for those who prefer clicking over typing. X-Server required.

= SLURM and MPI =
== About MPI ==
MPI (the Message Passing Interface) makes it possible to run parallel processes on CPUs of different hosts. To do so it uses TCP packets to communicate via the normal network connection. Some tasks can profit a lot of using more cores for computation.
At Remeis MPICH2 is used for initialisation of MPI tasks which is well supported within Slurm. The process manager is called '''pmi2''' and is set as default for srun. If an older MPI process manager is needed, for example for older MPI applications used in '''torque''', it can be set with
<pre>
#SBATCH --mpi=
</pre>
in the submission script.
<pre>
srun --mpi=list
</pre>
provides a list of supported MPI process managers.

The implementation of MPI for SLang/ISIS is called '''SLMPI'''.

== Best practice for MPI tasks ==

The usage of MPI might cause continuously high network traffic especially on the host which holds the master process. Please consider this when deciding which nodes are used for the job. It's a good idea to provide servers (e.g. leo or lupus) with the ''--nodelist='' option one of which is then used to hold the master process since nobody is sitting in front of it and trying to use a browser. Additional nodes are allocated automatically by Slurm if required to fit the ''--ntasks'' / ''-n'' option.

MPI jobs depend on all allocated nodes to be up and running properly, so I'd like to use this opportunity to remind about shutting down/rebooting PCs on your own without any permission can abort a whole MPI job.

== Requirements and Tips ==
To use MPI obviously the application or function used should support MPI. Examples range from programs written in C using some MPI features and compiled with the ''mpicc'' compiler to common ISIS-functions such as ''mpi_emcee'' or ''mpi_fit_pars''.

Keep in mind that everything in the compiled programs/scripts which is not an MPI compatible function is executed on each node on its own. For example in ISIS with ''-n 20'':
<pre>
fit_counts;
</pre>
would fit the defined function to the dataset 20 times at once. That's not very helpful so think about which tasks should be performed in the actual MPI process. Special care has to be taken if something has to be saved as a file. Consider:
<pre>
save_par("test.par");
</pre>
with ''-n 20''. This would save the current fit parameters to '''test.par''' in the working directory 20 times at exactly the same time. This might be helpful if the file is needed on the scratch disk of each node, but doing this on for example ''/userdata'' can cause serious trouble. The function ''mpi_master_only'' can be used to perform a user defined task in an MPI job only once. Best way is to only submit an MPI job to Slurm which only contains actual MPI functions. If some models in ISIS are used which output something to stdout or stderr while loading these messages are also generated 20 times since it's loaded in each process individually.

== Usage ==
If the job is a valid MPI process then the submission works exactly like for any other job:
<pre>
#!/bin/bash
#SBATCH --job-name my_first_mpi_job
#SBATCH ...
#SBATCH --ntasks=20
cd /my/working/dir
srun /usr/bin/nice -n +15 ./my_mpi_script
</pre>
It might be necessary to set a higher memory usage than for the according non MPI job since some applications try to limit the network traffic by just copying the required data to each node in the first place.

Also make sure that if it is necessary to specify the number of child processes in the application itself, set it to the same as with the ''--ntasks'' / ''-n'' option in the submission. An example would be the ''num_slaves'' qualifier in ''mpi_emcee''.

Note that the ''srun'' command does not contain ''mpiexec'' or ''mpirun'' which were used in older versions of MPI to launch the processes. The processes manager ''pmi2'' is built into Slurm and makes it possible that Slurm itself can initialize the network communication with the ''srun'' command only.

Of course it's also possible to run the MPI process directly from the commandline. As an example let's have a look at the calculation of pi with the MPI program ''cpi''. The program comes with the source code of MPICH2 and is compiled in the ''check'' rule. It's located in
<pre>
/data/system/software/mpich/mpich-3.2/examples
</pre>
To run the calculation in 10 parallel processes directly from the commandline use:
<pre>
[1:11]weber@lynx:/data/system/software/mpich/mpich-3.2/examples> srun -n 10 ./cpi
Process 0 of 10 is on aquarius
Process 1 of 10 is on ara
Process 6 of 10 is on asterion
Process 2 of 10 is on ara
Process 8 of 10 is on asterion
Process 7 of 10 is on asterion
Process 3 of 10 is on aranea
Process 5 of 10 is on aranea
Process 4 of 10 is on aranea
Process 9 of 10 is on cancer
pi is approximately 3.1415926544231256, Error is 0.0000000008333325
wall clock time = 0.010601
</pre>
As we can see Slurm launched 10 processes distributed to aquarius, ara, asterion, aranea and cancer. Keep in mind that running MPI interactively doesn't really make sense. The best way to go is to write a submission script like explained above and let Slurm handle the initialisation.

Skivergnuegen 2019

2019-01-10T16:42:39Z

Kreuzer: /* Allgemeines */

'''Remeis Skifahren 2019''' The same procedure as every year ;-)
Hier werden die wichtigsten organisatorischen Dinge festgehalten. Jeder darf hier gerne editieren; wer keinen Account für das Wiki hat, soll sich bitte an jemanden wenden der Zugang hat.

[[File:154854 silvretta-montafon-panorama.jpeg|right|700px]]

== Allgemeine Infos ==
*Wann: 12.01.19 (Sa) bis 19.01.19 (Sa)

*Ferienwohnung(en):
**Wir kommen wieder unter im [https://www.ferienwohnungen-montafon.com/ferienhaus-enzian/ Haus Enzian] des [https://www.grandau.at/ Sporthotels Grandau], sowie dem 5-er Apartment [https://www.grandau.at/zimmer/ferienwohnungen/Ferienwohnung-Edelweiss-Top-5/ TOP5] nebenan.
**Adresse des Sporthotel: Montafonerstraße 274a, 6791 St. Gallenkirch, Österreich. Unsere Unterkünfte liegen im Türkeiweg.

*Skigebiet: Montafon (Vorarlberg)
**Skigebiet Karte: https://winter.intermaps.com/montafon?lang=de
**Skipass Preise: https://www.montafon.at/de/Service/Bergbahn-Preise-Tickets/Mehrtageskarte-Winter
**Wer nicht alle 7 Tage Skifahren möchte: Es gibt Angebote wie z.B. 5 aus 7, mit einem solchen Skipass kann man innerhalb von 7 Tagen an 5 beliebigen Tagen skifahren.

*Skiverleih: [http://www.sportharry.at/ Sport Harry], direkt an der Talstation. Promotioncode ALPISKI auf alpinresorts.com spart bis zu 35% auf die Preise.

== Unterkunft ==
=== Aufteilung ===
Dieses Jahr gibt es neben der Hütte noch zusätzlich das 5-er Appartment (TOP5).
{| class="wikitable"
! scope="col" | Zimmer
! scope="col" | Insassen
|-
! scope="row" | 2-er
| Basti, Andrea
|-
! scope="row" | 3-er
| Ralf, Flo, Thomas
|-
! scope="row" | 4-er
| Nela, Ohle, Eva, Katya
|-
! scope="row" | 5-er
| Christian, Person 2, Person 3, Person 4, Person 5
|-
! scope="row" | Apartment (5)
| Eugenia, Michi, Johannes Veh, Katrin, Person 5
|}

Bettwäsche/Handtücher sind dort vorhanden und müssen nicht mitgenommen werden. Kaffeemaschine, Waffeleisen sind ebenfalls vorhanden.
Brötchen können wir vorbestellen im Hotel. Dazu müssen wir sie am Vortag vorbestellen und am nächsten Morgen bei der Besitzerin bzw. im Hotel gegen 7:15 Uhr abholen.

== Fahrer ==
Fahrer können sich hier eintragen und Eckdaten angeben. Diejenige, die mitfahren möchten, sprechen sich mit den Fahrern ab und tragen sich ebenfalls ein. Klärt bitte auch die Gepäcklage, ggf. kann ein anderer Fahrer z.B. Skiausrüstung mitnehmen.

Auf der Suche nach einer Mitfahrgelegenheit: Katya, Fritz

{| class="wikitable"
! scope="col" | Fahrer
! scope="col" | # Plätze
! scope="col" | Anreise
! scope="col" | Mitfahrer Anreise
! scope="col" | Abreise
! scope="col" | Mitfahrer Abreise
! scope="col" | Skimitnahme
! scope="col" | Kommentar
|-
! scope="row" | Eugenia
| 2(3)
| 12.1., Vormittags/Mittags los in Fürth
| Michi, kleiner Johannes
| 19.1. Vormittags, wahrscheinlich keine Mitnahmemöglichkeit von Passagieren
| Michi, kleiner Johannes
| 2 Paar
| Evtl ein Platz fuer einen Mitfahrer, falls es sonst nicht aufgeht
|-
! scope="row" | Basti
| 3 (4)
| Sat, noon, Erlangen
| Andrea, Veh
| Sat, morning
| Andrea, Veh
| no
| 2
|-
! scope="row" | Ralf
| 3
| Sat, noon
| Katya, Max
| Abreise Auto 3
| Mitfahrer Abreise Auto 3
| Skimitnahme Auto 3
| Kommentar Auto 3
|-
! scope="row" | Simon
| 3
| Sat noon
| Christian H., Katrin
| Abreise Auto 4
| Mitfahrer Abreise Auto 4
| Skimitnahme Auto 4
| Kommentar Auto 4
|-
! scope="row" | Johannes H (???)
| 4
| Sat noon
| Flo, Eva, Fritz
| Abreise Auto 5
| Mitfahrer Abreise Auto 5
| Skimitnahme Auto 5
| Kommentar Auto 5
|}

== Schwarzes Brett ==

=== Essen ===
Hier gibts den Essensplan, soweit übernommen von den letzten Jahren. Da wir sehr viele Leute sind, sollten wir wieder vorab grob planen, was wir kochen wollen. Wir können einige Dinge in Deutschland besorgen und mitnehmen, es gib aber auch einen nahe gelegen Supermarkt. Generelle Dinge, wie z.B. Gewürze oder Aufstriche für Frühstücksbrötchen könnte man auch mitbringen.

Wer Kochvorschläge oder andere Ideen hat, gerne unten eintragen und kommentieren. Bedenkt, dass die Zubereitung (relativ) einfach sein sollte. Ich (Thomas) habe jetzt mal eine Liste unten erstellt, aber vor allem die Reihenfolge/Tage kann man sicher noch hin und her bewegen. Einige (wenigere) Sachen müssen wir dann manchmal trotzdem noch beim Spar kaufen, da ja auch der Kühlschrank nur begrenzt Platz hat.

''VEGANE Optionen für Christian: vegane Sahne, Quark, Leinöl''

*Samstag: Spaghetti Bolognese + veg. Bolognese
*Sonntag: Käse Spätzle
*Montag: Burritos
*Dienstag: Risotto
*Mittwoch: Gulasch
*Donnerstag: Kartoffeln mit Kräuter-Quark
*Freitag: Curry with Sweet Potatoes

==== Einkaufliste Abendessen ====
'' Wird von X & Y eingekauft''
*2.5kg Hackfleisch
*3.5kg Spaghetti
*2.5kg Risotto Reis
*4.0kg Basmati Reis (für Burritos und Curry)
*12 Dosen gestückelte Tomaten
*6.0kg Spätzle (vorgekocht aus dem Kühlregal)
*1 Olivenöl (extra nativ)
*3kg geriebenen Käse
*1kg Emmentaler am Stück
*1kg Parmesan / Grana Padano
*1 Flaschen Weißwein (2-3€ pro Flasche dürfen es schon sein)
*2 Flasche Rotwein (2-3€ pro Flasche dürfen es schon sein)
*2 Knollen Sellerie (od 4 mal Staudensellerie)
*6kg Karotten
*3 Netze Zwiebeln
*2kg Pilze
*3kg Paprika
*1.5 kg Zucchini (2-3 Packungen)
*10kg (große) festkochende Kartoffeln
*ca. 50 größere Tortillas (2-3 pro Person)
*12 Dose schwarze Bohnen
*1-2 Gläser Jalapenos (je nach Größe)
*2kg Quark (halbfett, 20% sollte genügen)
*Tacos-Salsa-Soße für die Burritos (gerne scharf)
*10 Avocados
*Knoblauch
*Salz
*Pfeffer
*Rosmarin
*Basilikum
*Paprika-Gewürz (scharf)
*roter Chilli (fürs Gulasch)
*Zutaten für Curry???

==== Früh und Mittags ====
'' Wird von X & Y eingekauft''
*Obst (Bananen, Äpfel, Orangen, Mandarinen)
*5 Gurken
*einige Tomaten (für die Brotzeit)
*5 Butter
*3kg Wurst & Käseaufschnitt (Auswahl, gerne gute Qualität und von der Theke)
*Obstriegel
*Frischkäse (natur und Kräuter)
*2 Gläser Essiggurken
*mehr Marmelade (Himbeer und Hagebutte)
*Nutella
*kernige Haferflocken (für Porridge)
*Honig
*40 Eier (Freilandhaltung!!!)
*Auswahl an Müsli-Riegel / Snickers

====Allgemeines ====
'' Wird von X & Y eingekauft''
*Spülmittel
*Spülschwamm
*Seife
*1 Packung Kaffee (1 Pfund mittelstarker Kaffee)
*[Tee (Ceylon & Früchtetee) noch vorhanden!]
*O-Saft & anderer Saft (> 10 Liter)
*24 Liter Milch
*2 Liter Sojamilch (Natur)
*[Kaffeefilter noch vorhanden von letztem Jahr]
*Zucker
*[Toilettenpapier schon vorhanden!]
*Müllsäcke
*Lappen
*Spülmaschinen Tabs
*Schnapsglaeser fuer B52
*Strohhalms

==== Persönliches ====
Bitte bringt mit was ihr selbst gerne esst, aber schreibt es trotzdem hier rein (kann dann von mir aus auch gerne am Schluss abgerechnet werden)
* '' bitte hier persönliches, wie z.B. Süßigkeiten, etc. auflisten''

=== Alkohol/Party ===
Wir werden dieses mal sicher wieder feiern und dafür sollten wir auch vorsorgen :)
Vorschlag: jeder bringt mit, was er/sie gern möchte mit Vermerk im Wiki?!
* '' bitte hier Alkohol auflisten''

=== Spiele ===

Immer lustig sind gemeinsame Spieleabende. Also, wer im Besitz von Gesellschaftsspielen ist, bringt diese gerne mit! Um eine Übersicht zu bekommen auch bitte hier eintragen:
*''bitte hier Spiele auflisten''

=== Sonstiges ===
* Audiokabel für Anschluss Laptop - Aux-Anschluss Stereoanlage '''wer hat sowas?''' Glaube Michi hatte eins (Eugenia)

=== Alternativprogramm ===
* Rodeln (http://www.montafon.at/de/urlaubswelten/echte_naturliebhaber/rodeln)
* Schneeschuhwandern (http://www.montafon.at/schneeschuhwanderungen)
* Therme (http://www.montafon.at/schwimmen), z.B. http://www.aqua-dome.at/de (ca. 130km entfernt!)

[[Category:Internal]]

Skivergnuegen 2019

2019-01-10T16:42:22Z

Kreuzer: /* Allgemeines */

'''Remeis Skifahren 2019''' The same procedure as every year ;-)
Hier werden die wichtigsten organisatorischen Dinge festgehalten. Jeder darf hier gerne editieren; wer keinen Account für das Wiki hat, soll sich bitte an jemanden wenden der Zugang hat.

[[File:154854 silvretta-montafon-panorama.jpeg|right|700px]]

== Allgemeine Infos ==
*Wann: 12.01.19 (Sa) bis 19.01.19 (Sa)

*Ferienwohnung(en):
**Wir kommen wieder unter im [https://www.ferienwohnungen-montafon.com/ferienhaus-enzian/ Haus Enzian] des [https://www.grandau.at/ Sporthotels Grandau], sowie dem 5-er Apartment [https://www.grandau.at/zimmer/ferienwohnungen/Ferienwohnung-Edelweiss-Top-5/ TOP5] nebenan.
**Adresse des Sporthotel: Montafonerstraße 274a, 6791 St. Gallenkirch, Österreich. Unsere Unterkünfte liegen im Türkeiweg.

*Skigebiet: Montafon (Vorarlberg)
**Skigebiet Karte: https://winter.intermaps.com/montafon?lang=de
**Skipass Preise: https://www.montafon.at/de/Service/Bergbahn-Preise-Tickets/Mehrtageskarte-Winter
**Wer nicht alle 7 Tage Skifahren möchte: Es gibt Angebote wie z.B. 5 aus 7, mit einem solchen Skipass kann man innerhalb von 7 Tagen an 5 beliebigen Tagen skifahren.

*Skiverleih: [http://www.sportharry.at/ Sport Harry], direkt an der Talstation. Promotioncode ALPISKI auf alpinresorts.com spart bis zu 35% auf die Preise.

== Unterkunft ==
=== Aufteilung ===
Dieses Jahr gibt es neben der Hütte noch zusätzlich das 5-er Appartment (TOP5).
{| class="wikitable"
! scope="col" | Zimmer
! scope="col" | Insassen
|-
! scope="row" | 2-er
| Basti, Andrea
|-
! scope="row" | 3-er
| Ralf, Flo, Thomas
|-
! scope="row" | 4-er
| Nela, Ohle, Eva, Katya
|-
! scope="row" | 5-er
| Christian, Person 2, Person 3, Person 4, Person 5
|-
! scope="row" | Apartment (5)
| Eugenia, Michi, Johannes Veh, Katrin, Person 5
|}

Bettwäsche/Handtücher sind dort vorhanden und müssen nicht mitgenommen werden. Kaffeemaschine, Waffeleisen sind ebenfalls vorhanden.
Brötchen können wir vorbestellen im Hotel. Dazu müssen wir sie am Vortag vorbestellen und am nächsten Morgen bei der Besitzerin bzw. im Hotel gegen 7:15 Uhr abholen.

== Fahrer ==
Fahrer können sich hier eintragen und Eckdaten angeben. Diejenige, die mitfahren möchten, sprechen sich mit den Fahrern ab und tragen sich ebenfalls ein. Klärt bitte auch die Gepäcklage, ggf. kann ein anderer Fahrer z.B. Skiausrüstung mitnehmen.

Auf der Suche nach einer Mitfahrgelegenheit: Katya, Fritz

{| class="wikitable"
! scope="col" | Fahrer
! scope="col" | # Plätze
! scope="col" | Anreise
! scope="col" | Mitfahrer Anreise
! scope="col" | Abreise
! scope="col" | Mitfahrer Abreise
! scope="col" | Skimitnahme
! scope="col" | Kommentar
|-
! scope="row" | Eugenia
| 2(3)
| 12.1., Vormittags/Mittags los in Fürth
| Michi, kleiner Johannes
| 19.1. Vormittags, wahrscheinlich keine Mitnahmemöglichkeit von Passagieren
| Michi, kleiner Johannes
| 2 Paar
| Evtl ein Platz fuer einen Mitfahrer, falls es sonst nicht aufgeht
|-
! scope="row" | Basti
| 3 (4)
| Sat, noon, Erlangen
| Andrea, Veh
| Sat, morning
| Andrea, Veh
| no
| 2
|-
! scope="row" | Ralf
| 3
| Sat, noon
| Katya, Max
| Abreise Auto 3
| Mitfahrer Abreise Auto 3
| Skimitnahme Auto 3
| Kommentar Auto 3
|-
! scope="row" | Simon
| 3
| Sat noon
| Christian H., Katrin
| Abreise Auto 4
| Mitfahrer Abreise Auto 4
| Skimitnahme Auto 4
| Kommentar Auto 4
|-
! scope="row" | Johannes H (???)
| 4
| Sat noon
| Flo, Eva, Fritz
| Abreise Auto 5
| Mitfahrer Abreise Auto 5
| Skimitnahme Auto 5
| Kommentar Auto 5
|}

== Schwarzes Brett ==

=== Essen ===
Hier gibts den Essensplan, soweit übernommen von den letzten Jahren. Da wir sehr viele Leute sind, sollten wir wieder vorab grob planen, was wir kochen wollen. Wir können einige Dinge in Deutschland besorgen und mitnehmen, es gib aber auch einen nahe gelegen Supermarkt. Generelle Dinge, wie z.B. Gewürze oder Aufstriche für Frühstücksbrötchen könnte man auch mitbringen.

Wer Kochvorschläge oder andere Ideen hat, gerne unten eintragen und kommentieren. Bedenkt, dass die Zubereitung (relativ) einfach sein sollte. Ich (Thomas) habe jetzt mal eine Liste unten erstellt, aber vor allem die Reihenfolge/Tage kann man sicher noch hin und her bewegen. Einige (wenigere) Sachen müssen wir dann manchmal trotzdem noch beim Spar kaufen, da ja auch der Kühlschrank nur begrenzt Platz hat.

''VEGANE Optionen für Christian: vegane Sahne, Quark, Leinöl''

*Samstag: Spaghetti Bolognese + veg. Bolognese
*Sonntag: Käse Spätzle
*Montag: Burritos
*Dienstag: Risotto
*Mittwoch: Gulasch
*Donnerstag: Kartoffeln mit Kräuter-Quark
*Freitag: Curry with Sweet Potatoes

==== Einkaufliste Abendessen ====
'' Wird von X & Y eingekauft''
*2.5kg Hackfleisch
*3.5kg Spaghetti
*2.5kg Risotto Reis
*4.0kg Basmati Reis (für Burritos und Curry)
*12 Dosen gestückelte Tomaten
*6.0kg Spätzle (vorgekocht aus dem Kühlregal)
*1 Olivenöl (extra nativ)
*3kg geriebenen Käse
*1kg Emmentaler am Stück
*1kg Parmesan / Grana Padano
*1 Flaschen Weißwein (2-3€ pro Flasche dürfen es schon sein)
*2 Flasche Rotwein (2-3€ pro Flasche dürfen es schon sein)
*2 Knollen Sellerie (od 4 mal Staudensellerie)
*6kg Karotten
*3 Netze Zwiebeln
*2kg Pilze
*3kg Paprika
*1.5 kg Zucchini (2-3 Packungen)
*10kg (große) festkochende Kartoffeln
*ca. 50 größere Tortillas (2-3 pro Person)
*12 Dose schwarze Bohnen
*1-2 Gläser Jalapenos (je nach Größe)
*2kg Quark (halbfett, 20% sollte genügen)
*Tacos-Salsa-Soße für die Burritos (gerne scharf)
*10 Avocados
*Knoblauch
*Salz
*Pfeffer
*Rosmarin
*Basilikum
*Paprika-Gewürz (scharf)
*roter Chilli (fürs Gulasch)
*Zutaten für Curry???

==== Früh und Mittags ====
'' Wird von X & Y eingekauft''
*Obst (Bananen, Äpfel, Orangen, Mandarinen)
*5 Gurken
*einige Tomaten (für die Brotzeit)
*5 Butter
*3kg Wurst & Käseaufschnitt (Auswahl, gerne gute Qualität und von der Theke)
*Obstriegel
*Frischkäse (natur und Kräuter)
*2 Gläser Essiggurken
*mehr Marmelade (Himbeer und Hagebutte)
*Nutella
*kernige Haferflocken (für Porridge)
*Honig
*40 Eier (Freilandhaltung!!!)
*Auswahl an Müsli-Riegel / Snickers

====Allgemeines ====
'' Wird von X & Y eingekauft''
*Spülmittel
*Spülschwamm
*Seife
*1 Packung Kaffee (1 Pfund mittelstarker Kaffee)
*[Tee (Ceylon & Früchtetee) noch vorhanden!]
*O-Saft & anderer Saft (> 10 Liter)
*24 Liter Milch
*2 Liter Sojamilch (Natur)
*[Kaffeefilter noch vorhanden von letztem Jahr]
*Zucker
*[Toilettenpapier schon vorhanden!]
*Müllsäcke
*Lappen
*Spülmaschinen Tabs
*Schnapsglaeser fuer B52

==== Persönliches ====
Bitte bringt mit was ihr selbst gerne esst, aber schreibt es trotzdem hier rein (kann dann von mir aus auch gerne am Schluss abgerechnet werden)
* '' bitte hier persönliches, wie z.B. Süßigkeiten, etc. auflisten''

=== Alkohol/Party ===
Wir werden dieses mal sicher wieder feiern und dafür sollten wir auch vorsorgen :)
Vorschlag: jeder bringt mit, was er/sie gern möchte mit Vermerk im Wiki?!
* '' bitte hier Alkohol auflisten''

=== Spiele ===

Immer lustig sind gemeinsame Spieleabende. Also, wer im Besitz von Gesellschaftsspielen ist, bringt diese gerne mit! Um eine Übersicht zu bekommen auch bitte hier eintragen:
*''bitte hier Spiele auflisten''

=== Sonstiges ===
* Audiokabel für Anschluss Laptop - Aux-Anschluss Stereoanlage '''wer hat sowas?''' Glaube Michi hatte eins (Eugenia)

=== Alternativprogramm ===
* Rodeln (http://www.montafon.at/de/urlaubswelten/echte_naturliebhaber/rodeln)
* Schneeschuhwandern (http://www.montafon.at/schneeschuhwanderungen)
* Therme (http://www.montafon.at/schwimmen), z.B. http://www.aqua-dome.at/de (ca. 130km entfernt!)

[[Category:Internal]]

CUPS

2018-10-23T09:52:35Z

Kreuzer:

==== Printing Service CUPS ====

Printing at the observatory is handled by [https://www.cups.org/index.html CUPS].
CUPS is installed in the virtual box auriga (which lives on taurus) and can be administered through a web interface running on port 631: http://auriga:631/ (accessible only from within the institute).

Through this web interface, printers can be added or modified, queues can be stopped, jobs canceled, and other other maintenance jobs can be performed. To perform such tasks, CUPS requires you to login: use '''ubuntuadmin''' and the corresponding password.

When addong new printers, do forget to enable '''sharing''' to make the printer visible in the entire cluster.

Check out the [https://www.cups.org/documentation.html CUPS documentation] how to work with CUPS.

=== Trouble shooting ===

If a printer is not responding/not accessible:
* make sure that the printer is online (also check the network cable!), working properly, and not just busy.
* check the web interface of that printer, try to print a test page from the web interface.
* check the web interface for jobs in that queue. Remove failed jobs.

If no printers are availble (or just a generic printer), CUPS is probably down:
* login to auriga as ubuntuadmin
* restart the CUPS service:
<pre>
sudo service cups stop
sudo service cups start
</pre>
* sometimes it might be necessary to reboot the entire virtual box (CUPS will automatically be started after the reboot):
<pre>
sudo shutdown -r now
</pre>

=== List of Printers on the Cluster ===

[[Category:Admin]]