List outputs

[ElliottKasoar]

Adds output_files to all calculations, which is recorded in the summary file generated by the CLI.

Will need rebasing after #452

To do:

• Add tests

[oerc0122]

I do wonder if at this point files ought to become descriptors. Intercepting their __set__ with building the appropriate filenames and extensions and maybe even building the output files dict.

[ElliottKasoar]

New summary looks something like:

command: janus singlepoint
inputs:
  attach_logger: true
  calc:
    arch: mace_mp
    calc_kwargs: {}
    device: cpu
    model_path: null
    read_kwargs: {}
  enable_progress_bar: true
  file_prefix: null
  log: /Users/elliottkasoar/Documents/PSDI/janus-core/NaCl-singlepoint-log.yml
  properties: null
  struct:
    formula: Cl4Na4
    n_atoms: 8
    struct_path: tests/data/NaCl.cif
  track_carbon: true
  write_kwargs: {}
  write_results: true
output_files:
  log: /Users/elliottkasoar/Documents/PSDI/janus-core/NaCl-singlepoint-log.yml
  results: /Users/elliottkasoar/Documents/PSDI/janus-core/NaCl-results.extxyz
  summary: /Users/elliottkasoar/Documents/PSDI/janus-core/NaCl-singlepoint-summary.yml
start_time: 03/03/2025, 16:51:11
emissions: 2.3386228257216414e-07
end_time: 03/03/2025, 16:51:23

In most cases, the output files are relatively simple to predict, so I write them before running the calculation.

The main exceptions are:

• Phonons, where there are multiple Python entry points, so we cannot guarantee the output files will be generated in general, but for the CLI, we can manually specify this
• MD, where the restart files generated depends on how far the simulation gets
  • We could predict the final set of results files generated, but instead I update the list after MD completes, so in general, it should be accurate, but won't help if errors occur.

[ElliottKasoar]

I do wonder if at this point files ought to become descriptors. Intercepting their __set__ with building the appropriate filenames and extensions and maybe even building the output files dict.

What would be the advantage of this?

Also, would it work for filenames that depend on things we only easily know at initialisation?

[oerc0122]

I do wonder if at this point files ought to become descriptors. Intercepting their __set__ with building the appropriate filenames and extensions and maybe even building the output files dict.

What would be the advantage of this?

Also, would it work for filenames that depend on things we only easily know at initialisation?

The advantage would be that filenames are declared as extant on the class with a single definition and potentially avoiding a lot of the build_file(file, **kwargs) if file else None throughout.

The disadvantages are increased code complexity (comprehending descriptors), and a number of special cases which may not be helped and it may not save anything at all in the end.

When setting the value of the attribute the parent instance is known, but local function arguments (except the values) aren't. So it depends a little.

It was more a passing thought I noted midway (and then submitted as my only comment making it seem more important).