Cada IPAC concursó para una cantidad de horas CPU finita para el lapso de 1 año.

• PADS: Proyectos de Avances Decisivos con Supercómputo
• PCI: Proyectos de Cálculo Intensivo
• PISCA: Proyectos de Iniciación en Supercómputo en Argentina

Cada una de las categorías tiene asignadas distinta cantidad de horas.

• PADS: hasta 4.000.000 de horas de CPU y/o 250.000 h GPU.
• PCI; hasta 1.000.000 de horas de CPU y/o 60.000 h GPU.
• PISCA: hasta 100.000 de horas de CPU y/o 1.000 h GPU.

En un principio vamos a limitar únicamente las horas CPU (entiéndase horas/core) debido a que Slurm no está identificando correctamente las GPU.

Como cada proyecto va a tener asignados múltiples usuarios, creamos una account de slurm por usuario. Para limitar las horas de esa account, creamos una qos por separado ya que la misma necesita la opción NoDecay. Si seteáramos el límite NoDecay directamente sobre la Account, en teoría afectaría el FairShare.

Esto se debe a que NoDecay hace que no entre en efecto PriorityDecayHalfLife de slurm.conf, utilizado para regenerar el fairshare de cada usuario a lo largo del tiempo. Si esto fuera así, el GrpTresMins se regeneraría.

Entonces se configura:

• Una Account por IPAC.
• Una QOS por IPAC para limitar la cantidad de horas disponibles.
• Usuarios associados a la Account.

Los comandos a utilizar son los siguentes:

PAD

sacctmgr add account PAD_<nro>
sacctmgr create qos qos_pad_<nro> set flags=DenyOnLimit,NoDecay GrpTRESMins=cpu=240000000
sacctmgr modify account pad_<nro> set qos=qos_pad_<nro>
sacctmgr create user name=<usename> account=pad_<nro>

PCI

sacctmgr add account PCI_<nro>
sacctmgr create qos qos_pci_<nro> set flags=DenyOnLimit,NoDecay GrpTRESMins=cpu=60000000
sacctmgr modify account pci_<nro> set qos=qos_pci_<nro>
sacctmgr create user name=<usename> account=pci_<nro>

PISCA

sacctmgr add account PISCA_<nro>
sacctmgr create qos qos_pisca_<nro> set flags=DenyOnLimit,NoDecay GrpTRESMins=cpu=6000000
sacctmgr modify account pisca_<nro> set qos=qos_pisca_<nro>
sacctmgr create user name=<usename> account=pisca_<nro>

Documentación de las opciones elegidas:

DenyOnLimit If set, jobs using this QOS will be rejected at submission time if they do not conform to the QOS 'Max' limits as stand-alone jobs. Jobs that go over these limits when other jobs are considered, but conform to the limits when considered individually will not be rejected. Instead they will pend until resources are available (as by default without DenyOnLimit). Group limits (e.g. GrpTRES) will also be treated like 'Max' limits (e.g. MaxTRESPerNode) and jobs will be denied if they would violate the limit as stand-alone jobs. This currently only applies to QOS and Association limits.

NoDecay If set, this QOS will not have its GrpTRESMins, GrpWall and UsageRaw decayed by the slurm.conf PriorityDecayHalfLife or PriorityUsageResetPeriod settings. This allows a QOS to provide aggregate limits that, once consumed, will not be replenished automatically. Such a QOS will act as a time-limited quota of resources for an association that has access to it. Account/user usage will still be decayed for associations using the QOS. The QOS GrpTRESMins and GrpWall limits can be increased or the QOS RawUsage value reset to 0 (zero) to again allow jobs submitted with this QOS to run (if pending with QOSGrp{TRES}MinutesLimit or QOSGrpWallLimit reasons, where {TRES} is some type of trackable resource).

GrpTRESMins The total number of TRES minutes that can possibly be used by past, present and future jobs running from an association and its children. If any limit is reached, all running jobs with that TRES in this group will be killed, and no new jobs will be allowed to run. This usage is decayed (at a rate of PriorityDecayHalfLife). It can also be reset (according to PriorityUsageResetPeriod) in order to allow jobs to run against the association tree. This limit only applies when using the Priority Multifactor plugin.