Naming of the different objects and attributes

[davidwaroquiers]

This is not a pressing issue but objects used should be named "nicely" and not confuse the users (or contributors).

One example is "QBase", which is the base object that should be inherited by all classes so that subclasses can be made MSONable or not depending on whether monty is available or not (note that other optional dependencies could be included there). This "QBase" sounds like it is the base class for queues. Another name would make it more clear, e.g. QObject or QtkObject ?

Another example is the word "Queue" (BaseQueue, SlurmQueue). These should represent the object interacting with a queuing system, not a specific queue (a single "queue" is named a partition in slurm, it is named queue in pbs). Another name could be [BaseQueueManager, SlurmManager], [BaseQueingSystemInterface, SlurmInterface], ...

Other examples are likely to occur.

[davidwaroquiers]

Another naming question concerns cpus, threads, processes, tasks, processplacement, ...

[davidwaroquiers]

Thoughts and proposals on namings. As we need to go on and soon release a first version, I would like to have some things decided on the naming so that hopefully we don't need to change that afterwards.

QBase: this is the base object used to have optional MSONable superclass. By default, qtoolkit is installed without ANY dependency. The QBase name is confusing as the user/developer could think it is the base of a queue/queuing system.
Proposal to name it QtkBase or QObject or QtkObject. My preferred one is QtkObject.

QEnum: this is the base enum to allow to have it MSONable or not as above.
Proposal to name it QtkEnum.

QueueManager: this is the object representing a given cluster with its scheduler system (e.g. slurm or pbs). I find it not so descriptive for a single "cluster". This object is used to interact remotely with the cluster and its scheduler system, e.g. "what is the status of job number something").
Proposal to name it just "Cluster", or "Worker" or "Computer" or "Machine". My preferred one is "Cluster".

@gbrunin @gpetretto @damienfrancois @utf @ml-evs

[gbrunin]

About the QueueManager, it could represent something else than a cluster+queue manager, for instance a user could have a personal workstation without a queue manager and want to run there. Also, in the future, maybe some cloud might be envisioned. So, I think Worker is better suited than Cluster.

The others seem fine to me (QtkObject and QtkEnum).

[damienfrancois]

From my ignorant position (i.e. far away from the code and the other discussions), the question is whether the Q in QToolKit refers to the queue on a remote PBS/Slurm/etc-managed cluster or to a "local" work queue (i.e. a list of jobs waiting to be processed by one or more clusters [or other types of resources]). In the first case, it makes sense to name it Cluster, in the second, the more generic Worker could be more appropriate.

[gbrunin]

I think initially it was referring to the queue on a remote cluster, but it could be something else than a cluster. I worry that if it is called Cluster, then users will think it's only for remote clusters.
Let me just add another suggestion: QWorker (or QCluster, depending on which one is chosen). That way it reflects that it's not only a machine but also its queuing system (or just shell).

There could also be an object that would contain the possible QWorkers/QClusters defined by the user. That would more fall into your second example I think?

[davidwaroquiers]

I like QCluster and QWorker as they also add up to the "implicit convention" that all the objects start with Q. I would go for one or the other. For an object that would "manage" multiple of these (this does not exist, ... yet at least), it could be named QManager. This way all the objects exposed to the user have this "convention", which makes it kind of "nice".

[utf]

I think I'm a minimalist. Personally, I'm not the biggest fan of the "Q" prefix, it seems unnecessary.

My suggestions would be:

• QCluster -> Worker
• QBase -> BaseObject
• QEnum -> BaseEnum

But I'm not too fussy either way!

[davidwaroquiers]

Hi all,

Thanks for your comments.
@utf about the Q prefix, it originated from Job initially. One of the things I am always annoyed by is: there is a jobflow Job, a custodian Job and now a qtoolkit Job, making it a QJob makes it clear that it is different and from a queue. Some of the other classes followed the same idea (e.g. QState, QResources) and I think it makes it clearly different from other possible objects so I would keep the Q as you are not too fussy ;)

In any case, if in the future we find that this is annoying and nobody likes it, we can always change (with backward incompatibility though).

I'll go with QWorker (also "in line" with workers in jobflow remote, even if they are not the same, at least currently).