Future release (1.4.x or 1.5.0 or 2.0)

[shuds13]

Target date: TBC

Question: Should gen_on_manager becomes default (what about non-persistent gens). This is very breaking hence might be for 2.0.

• Support sub-classed generators with an ask/tell interface Interface with Generators that expose an .ask/.tell interface #1240

• Make sure persistent gens return None as first parameter unless want to return something.

• Resolve Better capture dependencies for 'extra' tests. #1403 and Pydantic warnings #1404

• Updating forces and other examples (inc. notebooks) to use gen on manager. Update platform tutorials.

• Better interface support for generator running outside of libE (and make example notebook).

• Create unified index of examples - based on gen type - points to location (libE or community examples) and shows gen/calling script examples.

• In the Sim function examples add links to community examples (and/or WarpX/Opal when these are up to date).

• Improve coverage of core libE methods (if reasonably easy to do so). Files to consider

  • libE.py
    • TCP worker-side content.
  • Should all of worker.py be covered?
  • comms.py
  • 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

Canceled / Put on hold:

• Support generator running on the manager Support in-place gen on manager #1142 (in-place)
• Allow num workers to be set by detected GPUs Allows workers and rsets to be set by detected GPUs. #939
• Add notebook with simple optimization example - inc. simple persistent generator (similar to paper example).

Questions:

• Should use_persis_return_sim be deprecated - if so now or next release. Requires ensuring all functions update to returning None (including in docs) - which should do anyway.
• Should H0 be an argument to ensemble.run()?
• naming "persistent_" do we update as most examples are persistent (2.0 consideration).
• Consider order of arguments to Ensemble object

[jlnav]

Make sure persistent gens return None as first parameter unless want to return something.

Out of curiosity, I think functions that return "nothing" already have their output parameter captured as None, e.g.

>>> out = print("HELLO")
>>> type(out)
<class 'NoneType'>

Within the worker, current logic, probably can be dramatically improved:

            if out:
                if len(out) >= 3:  # Out, persis_info, calc_status
                    calc_status = out[2]
                    return out
                elif len(out) == 2:  # Out, persis_info OR Out, calc_status
                    if isinstance(out[1], (int, str)):  # got Out, calc_status
                        calc_status = out[1]
                        return out[0], Work["persis_info"], calc_status
                    return *out, calc_status  # got Out, persis_info
                else:
                    return out, Work["persis_info"], calc_status
            else:
                return None, Work["persis_info"], calc_status

Looks like if a gen returns None or otherwise, the intention may be captured anyway? I dunno

[shuds13]

Out of curiosity, I think functions that return "nothing" already have their output parameter captured as None, e.g.

If you look at most persistent gens in gen_funcs they return

return H_o, persis_info, FINISHED_PERSISTENT_GEN_TAG

not

return None, persis_info, FINISHED_PERSISTENT_GEN_TAG

which will result in the last set of points being added to the end of H as duplicates if we dont require use_persis_return_gen. So these should be replaced with None in most cases.

[jlnav]

Fair enough; by the last set of points do you mean the last generated, but not sent out, set of points being added as duplicates? Would those points having sim_ids by that point prevent duplication? Maybe I'm missing something

[shuds13]

Fair enough; by the last set of points do you mean the last generated, but not sent out, set of points being added as duplicates? Would those points having sim_ids by that point prevent duplication? Maybe I'm missing something

Look at this code, which is typical for our persistent gens.

    while tag not in [STOP_TAG, PERSIS_STOP]:
        H_o = np.zeros(b, dtype=gen_specs["out"])
        H_o["x"] = persis_info["rand_stream"].uniform(lb, ub, (b, n))
        tag, Work, calc_in = ps.send_recv(H_o)


    return H_o, persis_info, FINISHED_PERSISTENT_GEN_TAG

H_o is sent to the manager in ps.send_recv(H_o). Then at end those points are returned (again). They get added twice - the manager will give new sim_ids. We decided to ignore the return H_o unless use_persis_return_gen is set, in order to prevent that. Also, bear in mind, users will have used these as templates to their own gens.

We should make our gens end with

return None, persis_info, FINISHED_PERSISTENT_GEN_TAG

unless we do something after the loop and actually make a different H_o.