tasks.py has recently become awkward with the addition of tasks to run pure-gauge ORA binaries. In order to implement this, I had to make a parallel class to HMCJob, which is PureGaugeORAJob.
There is a class of classes descended from HMCAuxJob which run, e.g., flow or clovert_invert on a gauge configuration that comes out of an HMCJob. These AuxJobs are extremely convenient to use, because they pull the bare parameters they need directly from the HMCJob they're pointed at, which dramatically reduces the requirement for error-prone human input. However, because PureGaugeORAJob is not descended from HMCJob, HMCAuxJobs cannot be pointed at it. This means that, in order to implement the same structure, a parallel set of mostly identical "PureGaugeAuxJobs" is required.
Further, the HMCJob tasks are multirep-specific, and the special-case HMCJob subclasses that run sextet-only and fundamental-only runs are awkwardly implemented. Implementing calls to different binaries (especially non-MILC binaries) promises to be more awkward still, and as it stands, will require lots of code replication.
How can we gracefully implement a generalized "GaugeGenerator" task (as a parent for, eg, "MultirepHMCJob", "PureGaugeORAJob", etc) , that "GaugeGeneratorAuxJobs"/etc can be pointed at? How can we make "GaugeGeneratorAuxJobs" agnostic to what type of binary actually generates the gauge configuration?
tasks.py has recently become awkward with the addition of tasks to run pure-gauge ORA binaries. In order to implement this, I had to make a parallel class to HMCJob, which is PureGaugeORAJob.
There is a class of classes descended from HMCAuxJob which run, e.g., flow or clovert_invert on a gauge configuration that comes out of an HMCJob. These AuxJobs are extremely convenient to use, because they pull the bare parameters they need directly from the HMCJob they're pointed at, which dramatically reduces the requirement for error-prone human input. However, because PureGaugeORAJob is not descended from HMCJob, HMCAuxJobs cannot be pointed at it. This means that, in order to implement the same structure, a parallel set of mostly identical "PureGaugeAuxJobs" is required.
Further, the HMCJob tasks are multirep-specific, and the special-case HMCJob subclasses that run sextet-only and fundamental-only runs are awkwardly implemented. Implementing calls to different binaries (especially non-MILC binaries) promises to be more awkward still, and as it stands, will require lots of code replication.
How can we gracefully implement a generalized "GaugeGenerator" task (as a parent for, eg, "MultirepHMCJob", "PureGaugeORAJob", etc) , that "GaugeGeneratorAuxJobs"/etc can be pointed at? How can we make "GaugeGeneratorAuxJobs" agnostic to what type of binary actually generates the gauge configuration?