Additional tables

[ckoerber]

Here are some first thoughts about the tables we need to connect physics to computational information needed to create jobs (with help of @arjunqcd)

Headers are classes (tables), items are properties (columns)

Job/Task/Data

• physics -> physics object like Correlators
• machine -> HardwareArchitecture
• runtime -> RunTimeArguments, many, ordered by priority
• algorithms -> Algorithm, many
• status -> Integer / String

RunTimeArguments

• wallclock -> Time
• executable -> str
• environment -> str
• path -> str
• args -> str

CPURunTimeArgs(RunTimeArguments)

• nodes -> Integer

GPURunTimeArgs(RunTimeArguments)

• ngpus -> Integer

Hardware Architecture | Machine

• topology -> str (distribution of lattice among processors)
• CPUs -> int
• GPUs -> int
• home -> str
• scratch -> str
• tape -> str

Algorithms This seems to be quite specific for the algorithm itself and might be implemented as required. Things to consider here are HMC, Solvers, Stochastic noise, ...

What do you think about this draft? Are these informations sufficient to submit jobs? What is missing?

[evanberkowitz]

This gets very quickly very complicated. The environment depends on architecture and the location of the executable (or, at least, on where the Quda resource path is, for example).

[ckoerber]

Idea

Have a Job/Task/Data/HitList object with physics, machine, status and computation columns. The computation column is a link to another table which has id, tag and blob/json (maybe even the actual script) columns. Thus the computation is super flexible and one can uniquely constrain (physics, machine, computation).

This is a compromise between not too specialized but still able to complete specify jobs and make sure you don't have duplicates.

[ckoerber]

Discussion continued in #20.