Job factory call

[liamhuber]

During @jan-janssen's excellent thesis presentation (🥳 🥳 🥳 ) I really enjoyed seeing all the shiniest pyiron syntax, but during one of the loops I saw we still have pr.create_job('ScriptJob', 'foo'). This doesn't quite deprecate that, because we don't yet overload create with all the various toolkits, but it does let us do syntax like pr.base.job('ScriptJob', 'foo'), pr.atomistics.job('Lammps', 'bar'), etc, which is super convenient for loops over job types. And if/when we get create and create.job overloaded it should trivially extend to pr.create.job('SomeNewJobType', 'baz').

EDIT: Following @niklassiemer's suggestion you can also do pr.create.job(ScriptJob, 'foo') or pr.create.job(MyRandomChildOfGenericJob, 'bar').

[liamhuber]

I'm a little confused why this is still showing up as so many commits...most of them got merged to master in #486, and master since got merged into this. Anyhow, the diff at least is correct that it's only a couple files changing.

[liamhuber]

In principle, for classes passed as strings, it could be re-written to make use of __getattr__ which in turn leans on JOB_CLASS_DICT so that we could pr.create.job('Lammps', 'lmp'). Right now this doesn't work since pyiron_base.job.factory.JobFactory._job_class_dict only knows about base jobs, while pyiron_atomistics.toolkit.JobFactory._job_class_dict only knows about atomistic jobs (see comment at top of PR). In practice JOB_CLASS_DICT is a weird global var we have floating around and I'm trying to phase it out. Since this is a bit of a niche ability anyhow, I'd rather lean on people directly calling pr.base.job, pr.atomistics.job etc. until we work out some sort of registration with pr.create.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[liamhuber]

@niklassiemer bump

[niklassiemer]

Thanks, I was already bumped by the stale bot 😅

[niklassiemer]

Other than the small nit about the job_name handling this LGTM.

[niklassiemer]

And I just realized a failing pyiron_atomistics compatibility test:

======================================================================
ERROR: test_run (atomistics.master.test_murnaghan_non_modal.TestMurnaghan)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "D:\a\pyiron_base\pyiron_atomistics\tests\atomistics\master\test_murnaghan_non_modal.py", line 68, in test_run
    self.project.wait_for_job(murn, interval_in_s=5, max_iterations=50)
  File "C:\Miniconda\envs\test\lib\site-packages\pyiron_base\project\generic.py", line 1271, in wait_for_job
    wait_for_job(
  File "C:\Miniconda\envs\test\lib\site-packages\pyiron_base\server\queuestatus.py", line 200, in wait_for_job
    raise ValueError("Maximum iterations reached, but the job was not finished.")
ValueError: Maximum iterations reached, but the job was not finished.

I triggered a new execution.

[liamhuber]

Super thanks! Good catches; I'll add them tomorrow and merge (provided there is no further complication with the hung test)

[liamhuber]

OSX failure:

======================================================================
302
FAIL: test_worker (job.test_worker.TestScriptJob)
303
----------------------------------------------------------------------
304
Traceback (most recent call last):
305
  File "/Users/runner/work/pyiron_base/pyiron_base/tests/job/test_worker.py", line 28, in test_worker
306
    self.assertEqual(len(df[df.status == "finished"]), 1)
307
AssertionError: 0 != 1
308

309
----------------------------------------------------------------------

I don't think either this nor the Murnaghan error are related to the changes here though.

[liamhuber]

Indeed, it is definitely not. Further, I don't get that issue on my OSX machine.

[liamhuber]

All tests passing after most recent master merge.