# -*- text -*-
#
# Copyright (c) 2004-2007 The Trustees of Indiana University and Indiana
#                         University Research and Technology
#                         Corporation.  All rights reserved.
# Copyright (c) 2004-2005 The University of Tennessee and The University
#                         of Tennessee Research Foundation.  All rights
#                         reserved.
# Copyright (c) 2004-2005 High Performance Computing Center Stuttgart,
#                         University of Stuttgart.  All rights reserved.
# Copyright (c) 2004-2005 The Regents of the University of California.
#                         All rights reserved.
# Copyright (c) 2011      Oak Ridge National Labs.  All rights reserved.
# Copyright (c) 2014 Cisco Systems, Inc.  All rights reserved.
# Copyright (c) 2017-2018 Intel, Inc. All rights reserved.
# Copyright (c) 2025-2026 Nanook Consulting  All rights reserved.
# $COPYRIGHT$
#
# Additional copyrights may follow
#
# $HEADER$
#
# This is the US/English general help file for PMIX.
#
[pmix_init:startup:internal-failure]
It looks like pmix_init failed for some reason; your parallel process is
likely to abort.  There are many reasons that a parallel process can
fail during pmix_init; some of which are due to configuration or
environment problems.  This failure appears to be an internal failure;
here's some additional information (which may only be relevant to an
PMIX developer):

  %s failed
  --> Returned value %d instead of PMIX_SUCCESS
#
[no-plugins]
We were unable to find any usable plugins for the %s framework. This PMIx
framework requires at least one plugin in order to operate. This can be caused
by any of the following:

* we were unable to build any of the plugins due to some combination
  of configure directives and available system support

* no plugin was selected due to some combination of MCA parameter
  directives versus built plugins (i.e., you excluded all the plugins
  that were built and/or could execute)

* the PMIX_PREFIX environment variable, or the MCA parameter
  "mca_base_component_path", is set and doesn't point to any location
  that includes at least one usable plugin for this framework.

Please check your installation and environment.
#
[ptl:msg_size]
A received msg header indicates a size that is too large:

  Requested size:  %lu
  Size limit:      %lu

If you believe this msg is legitimate, please increase the
max msg size via the ptl_base_max_msg_size parameter.
#
[bfrops:array_depth]
A data array is nested more deeply inside other data arrays than
this PMIx library is willing to %s:

  Depth reached:   %lu
  Depth limit:     %lu

Each level of nesting costs only a few bytes on the wire but a stack
frame in the library, so the depth is bounded by default. If your data
is legitimately this deeply nested, raise the limit with the
bfrops_base_max_array_depth parameter (0 removes it entirely). Both
ends of the connection must permit the depth: the sender refuses to
build the message, and the receiver refuses to interpret it.
#
[tool:no-server]
A call was made to PMIx_tool_connect_to_server, but no information
was given as to which server the tool should be connected. Accepted
attributes include:

  - PMIX_CONNECT_TO_SYSTEM: connect solely to the system server

  - PMIX_CONNECT_SYSTEM_FIRST: a request to use the system server first,
      if existing, and then look for the server specified in a different
      attribute

  - PMIX_SERVER_URI: connect to the server at the given URI

  - PMIX_SERVER_NSPACE: connect to the server of a given nspace

  - PMIX_SERVER_PIDINFO: connect to a server embedded in the process with
      the given pid

Please correct your program and try again.
#
[module-set]
A function call to %s was made that would have resulted in
overwriting the function pointers in the PMIx server library's
upcall module. This is not allowed - the server module can
only be provided once and cannot be overwritten.

Please correct your program and try again.
#
[progress-thread:bad-cpu-list]
An entry in the list of CPUs to which the PMIx progress thread is to be
bound could not be used, and has been ignored:

  Entry:  %s
  List:   %s

The list is a comma-delimited series of entries, where each entry is
either a single CPU number or an inclusive range written "start-end" -
for example "0,2,8-11". Each number must be between 0 and %d inclusive,
and a range must not run backwards.

The list is set either by the "pmix_progress_thread_cpus" MCA parameter
or by the PMIX_BIND_PROGRESS_THREAD attribute passed to initialization.
If no entry in it is usable, and binding was requested as required
(PMIX_BIND_REQUIRED / "pmix_bind_progress_thread_reqd"), initialization
will fail; otherwise the thread is left unbound.
#
[var_dump_color:format-error]
A malformed entry was found in the "pmix_var_dump_color" MCA parameter
and has been ignored:

  Entry: %s

Each entry in the parameter must have the form "key=code", where "code"
is an ANSI X3.64 CSI SGR sequence (for example, 34 for blue), and the
entries are separated by commas - e.g.

  name=34,value=32,valid_values=36

Keys not given a color are left uncolored.
#
[var_dump_color:unknown-key]
An entry in the "pmix_var_dump_color" MCA parameter names a key this
version of PMIx does not recognize. The entry has been ignored:

  Key:    %s
  Entry:  %s

Recognized keys are: %s

Note that a key added by a later release of PMIx will be reported here
by an earlier one - the parameter is otherwise being read normally.
#
[blocking-call-from-progress-thread]
A blocking call to %s was made from the PMIx progress thread.

Blocking PMIx APIs hand their work to the progress thread and then wait
for it to complete. Calling one FROM that thread cannot work: the work is
posted to the very event loop the caller is standing in, and that loop
cannot run it until the caller returns. The call would never return, and
the process would hang.

The usual way to reach this is to call a blocking PMIx API from inside a
server module upcall, an event handler, or the completion callback of a
non-blocking operation - all of which the library dispatches from the
progress thread.

Use the non-blocking form of the call instead. It hands the request to
the library and returns immediately, and the library will execute your
callback when the operation completes. If you need the operation to
finish before you proceed, have your callback wake a different thread.

The call has not been allowed to hang. An API that reports a status has
returned PMIX_ERR_WOULD_BLOCK without performing the operation. An API
that reports no status has instead completed the operation
asynchronously, which is indistinguishable to the caller except that it
did not wait.
#
[relay-encoding-mismatch]
A PMIx tool cannot relay a request on behalf of a tool that connected to
it, because the two connections do not use the same encoding.

  Requesting tool:  %s
    its bfrops module:  %s   (buffer type %d)
  Our own server:
    its bfrops module:  %s   (buffer type %d)

A relayed request is passed along exactly as it arrived - the bytes are
copied onward without being unpacked, and the answer is copied back the
same way. That is only sound while both ends agree on how those bytes are
encoded. They disagree here, so relaying the request would hand the far
end a message it would misread rather than reject.

This is not expected: a tool imposes its own bfrops module and buffer
type on itself and on the server it attaches to, so the two normally
match by construction. Reaching this message most likely means a peer was
given its modules by some other path - please report it.

The request has been refused rather than relayed.
