Release v1.3.0

[shuds13]

Target: May 01 2024

Before release:

• Check documentation. Is gen_on_manager and change to default comms documented sufficiently.
• Polaris build (conda module disappeared - still in Polaris docs) - see if need to update Polaris instructions (tested using cray-python module) Now also tested with conda module - need first use: module use /soft/modulefiles

Features:

• Support generator running on the manager on thread. Refactor/user function handling modules + Manager can run additional worker on thread #1216/Default rsets assigned to -1 #1290
• Default to local comms when num_workers is supplied and no MPI runner detected .Feature/default local #1169
• Parse args defaults to local comms when nworkers is set on command line (via --nworkers or -n). Feature/default local #1169

Possible:

• Improve coverage of core libE methods (if reasonably easy to do so). Files to consider
  • libE.py
    • on_abort, on_cleanup method
    • TCP worker-side content.
  • Should all of worker.py be covered?
  • comms.py
  • executor.py
  • mpi_runner.py
    • including _adjust_procs
  • mpi_resources.py exception handling
  • genfunc init where I think much might be removable.
  • gpu_detect but not if that's difficult to test/mock. Same for tcp_mgr
  • Slots in worker_resources.py
  • What should happen in the cores_info is None case in node_resources

[shuds13]

I think gpu_detect is probably better left to HPC testing. We could mock something to check the output is received correctly, but it seems more important to test that we are interacting with the GPU detection packages correctly, by doing it for real.

[shuds13]

Those lines in genfunc init were set up for rsopt. I sort of thought we had a test for it, but maybe it was in the windows testing. @jlnav ?

[jlnav]

Those lines in genfunc init were set up for rsopt. I sort of thought we had a test for it, but maybe it was in the windows testing. @jlnav ?

Yeah, I believe back-in-the-day this had something to do with windows testing, and any other circumstances where the set of optimizers wasn't staying alive in memory. If I recall correctly this was also a solution to trying to have all our imports at the top of the file instead of in local-optimization subprocesses, trying to keep flake8 happy.

My hunch is this should go away, or get dramatically refactored. We've discussed before that perhaps each local optimizer really ought to have their own imports, but I think PETSc was an odd one out when we tried that

[shuds13]

In node_resources, the if _complete_set(cores_info): in get_sub_node_resources is not set as this would mean GPUs environment variable were detected, which is not set in any of the CI. We could have a unit test that sets SLURM_GPUS_ON_NODE env variable, but I'm a little cautious about setting meaningful environment variables in unit tests.

Actually I can mock it.

But it still does not happen currently as there is not a scheduler which detects both CPUs and GPUs via environment variable, but there might be in the future.