Jan Janssen

As a first step I started to create a simpler `run_time_to_db()` function. I guess the easiest way is to define a decorator which wraps the run() function. https://github.com/pyiron/pyiron_base/pull/984

> I was actually thinking about setting `timestart` and `timestop` when entering and leaving status `running`. That might take some refactoring, so a decorator in the mean sounds fine to...

A decorator to track the run time is implemented in https://github.com/pyiron/pyiron_base/pull/992 still we might want to extend this for the Python Template Job, if and call `to_hdf()` also within the...

> Something like this? I am not sure if we want to add the run time calculation to the `jobstatus` class, it should only focus on setting the status and...

> Is there a case where you'd not want to have the run time tracked though? It is more that I want one class for one purpose. Handling the runtime...

> I see your point and I'm also slightly uncomfortable with the setting the CPU time inside `JobStatus`. However, at least the current reality is that the CPU time is...

We had a similar issue https://github.com/pyiron/pyiron_atomistics/issues/598 I guess the quickest way to fix this is `job.input.control.load_string()`

@appassionate the idea of having the remote executables is that a research group could share them between all users, so that they only need to be defined once. Still we...

I have a pull request for this open https://github.com/pyiron/pyiron_base/pull/1182 maybe you can check if it solves your issue, then we should move forward and include it in the next release.

I like the idea, in principle every object attached to the job should have this option, as well as an unfreeze option when somebody copies only the input of a...