Closed ckoerber closed 5 years ago
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).
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.
Discussion continued in #20.
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
Correlator
sHardwareArchitecture
RunTimeArguments
, many, ordered by priorityAlgorithm
, manyRunTimeArguments
Time
CPURunTimeArgs(RunTimeArguments)
GPURunTimeArgs(RunTimeArguments)
Hardware Architecture | Machine
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?