Everything dealing with parameters in the current validate functions is checking for a structure to exist inside those parameters and then reading from that endpoint. All parameters are static. Therefore, all such checks can move into classmethods which the validate method then can call if wanted. The classmethods’ actual purpose is a new top level call on job submission to check that the passed parameters are all valid. All such parameters come direct from the job submission allowing for multinode split etc. to happen first.
Current validate functions combine the checks of static parameter data with the generation of dynamic data which often combines the job parameters, device parameters and other dynamic data into useful constructs for the job at runtime. If the checks of static parameters from the job submission were moved into classmethods, then the validate could also use those methods to build the dynamic data as it does currently. The validate function does not need to have so many conditionals to check for particular structures in the parameters: it simply accesses those structures. The parser would take care of whether the structural elements are valid for the constructed pipeline and the same parsing could be used to document that structure. The structure created from the classmethods is an outline of the fully initialised pipeline, but accesses the same classes in the same sequence. This will require changes in the populate functions.
Some issues within this EPIC cannot be resolved until after the V2 migration is complete and the V1 code has been removed.