Creating a job object

[AndrewSazonov]

I propose to discuss here how the user creates the main EasyDiffraction object, job, and what this object should be responsible for.

A job is a wrapper for everything related to the physical model, experiment description, data store with experimentally measured and calculated data, binding to calculation engines, etc. Currently, the job type is defined by the class used to create the job object, e.g. Powder1DCW, Powder1DTOF, etc. The proposal is to instead have a generic job type, but support multiple types of experiments.

Currently, a job needs a name because a datastore object can store data from multiple jobs. The job name is then used as a prefix in the dataset label. It is proposed to make datastore specific to jobs so that a job name is not required.

⚙ Current

from easyDiffractionLib.Jobs import Powder1DCW

job = Powder1DCW(name='jb')

💡 Suggested

import EasyDiffraction

job = EasyDiffraction.Job()

[damskii9992]

Having a single primary object that the user interacts with is not only simpler, but also allows for cleaner user scripts. I fully support this idea, but I would propose a different name for this object, as job brings to mind many unnecessary connotations. I would instead propose the name Study.

[AndrewSazonov]

I'm also not entirely happy with the name Job. In the EasyDiffraction application we use Project, the idea of which is very similar to Job in the library. Projects are quite common in graphical applications, and the step of creating a project seems like a logical first step in a data analysis workflow. I'm not sure if project is better than job for a library, but I think it would be nice to find a name that works equally well for both library and application. This will definitely be an advantage for users who use both the app and the library, or started with the app and then decided to switch to the library. Also not sure if study is a right alternative, but it sounds fine in the sense of scientific study, which involves scientific models, experiments, etc. So we should consider study as an alternative to both job in the library and project in the app. And, of course, other suggestions are welcome.

[rozyczko]

A Project to me is a loose collection of items, which our Job is not.
A Job (and Study) on the other hand sound too generic.

We want to have a well-structured object with phases and experiments, with datastore with information relevant to both phase and experiment and a number of methods to operate on those items: fitting, load/save, etc.
This concept is going to be reused in all EasyScience applications.

Maybe we should then have a base Job class defining some common functionality (in EasyCore?) and reimplement it in ED as DiffractionJob, in ER as ReflectometryJob etc?

[AndrewSazonov]

In the current implementation of EasyDiffractionLib, we have the following dependency

flowchart  LR
    Profiles.common._PowderBase --> Jobs.JobBase_1D --> Jobs.Powder1DCW

Loading

But even _PowderBase is diffraction specific. So if we remove the diffraction part, the _PowderBase becomes almost empty. Then the question is whether we can find a base job functionality common to different scattering techniques...

[rozyczko]

I would propose the simple Job class hierarchy to be actually present. The base Job class could be an abstract class, which would enforce the main components to be properly overwritten in derived classes.

flowchart  LR
    A[JobBase] --> B[DiffractionJob]
   A --> C[ReflectometryJob]

Loading

The main components, as discussed, would be

1. Model (could be Phase for some techniques)
2. Experiment
3. Analysis
4. Summary
5. ProjectInfo

JobBase would also contain an abstract Fitting method, to be reimplemented as a requirement.

Datastore is another component which needs defining for a derived class to have.

Should the base class contain anything else?

[rozyczko]

As for specialization of the Job class within a single technique -
I don't think having multiple classes deriving from DiffractionJob for specific types of experiment is useful.

flowchart  LR
    A[DiffractionJob] --> B[DiffractionJob_Powder]
   A --> C[DiffractionJob_SC] --> I(etc)
  B --> D[DiffractionJob_Powder_TOF]
  B --> E[DiffractionJob_Powder_CW]
  D --> F[DiffractionJob_Powder_TOF_1D] --> H(etc)

Loading

This would be quite unwieldy, if we wanted to specialize the Job classes properly.

Maybe having object attributes on DiffractionJob, describing which particular experimental data it has, would be better?
This moves the specialization to Experiment, where it is most sensible.

    job.is_tof = isinstance(job.experiment, "DiffractionExperiment_TOF_1D_Powder")