Ensure consistency between max_procs and univ_size values - since ort…

[rhc54]

…e wants max_procs, have the proc get that value instead of univ_size

@jjhursey Please review

[jjhursey]

The following needs to be updated as well (right?):

• orte/mca/ess/singleton/ess_singleton_module.c Line 221

With the addition of the above (or some discussion on it) I think this looks good.

Some notes for me:

• pmix_server_register_fns.c This change makes PMIX_UNIV_SIZE == PMIX_MAX_PROCS when using the orted as the PMIx server.
  • See note about OMPI_UNIVERSE_SIZE at orte/mca/schizo/ompi/schizo_ompi.c Line 400. So when orted sends OPAL_PMIX_UNIV_SIZE it should match jdata->total_slots_alloc.
• ess_pmi_module.c This change is not necessary for the orted (see previous bullet), but is important for other PMIx servers (i.e., direct launch).
  • Since other PMIx servers should make sure to notice that the OMPI_UNIVERSE_SIZE will be set to the value returned from a query for PMIX_MAX_PROCS, and PMIX_UNIV_SIZE is not used by the Open MPI process at this time. However, to be backwards compatible it is best to set these equal to one another. We can tease out the difference on the PMIx list.

OPAL_PMIX_JOB_SIZE
  jdata->num_procs  // number of procs in this job
  PMIX_JOB_SIZE     // #procs in this job

OPAL_PMIX_UNIV_SIZE == PMIX_MAX_PROCS
  jdata->total_slots_alloc // total slots allocated to this job
                           // meant to be universe size
  PMIX_UNIV_SIZE           // #procs in this nspace
  PMIX_MAX_PROCS           // max #procs for this job

[rhc54]

Quite right about the singleton module - I'll update and re-push. For the PMIx list, we should discuss what, if any, difference there really is between max_procs and univ_size. I -think- I remember, but it has been a long time. Certainly, OMPI today does not recognize a difference, and so the current assignments here would be correct.