\ac{PE}s -> \acp{PE}

content/backmatter.tex

@@ -29,7 +29,7 @@ \section*{Incorporating \openshmem{} into Programs}\label{sec:writing_programs}
     (line 13) or an explicit \texttt{exit()} acts as an implicit \openshmem
     finalization.
 \item In \openshmem the order in which lines appear in the output is not fixed
-    as \ac{PE}s execute asynchronously in parallel.
+    as \acp{PE} execute asynchronously in parallel.
 \end{itemize}
 
 \begin{minipage}{\linewidth}
@@ -136,7 +136,7 @@ \section{Running Programs}
 
 \begin{tabular}{p{0.3\textwidth}p{0.6\textwidth}}
 $\langle\mbox{additional options}\rangle$ & {Options passed to the underlying launcher.}\tabularnewline
--np $\langle\mbox{\#}\rangle$ & {The number of \ac{PE}s to be used in the execution.}\tabularnewline
+-np $\langle\mbox{\#}\rangle$ & {The number of \acp{PE} to be used in the execution.}\tabularnewline
 $\langle\mbox{program}\rangle$ & {The program executable to be launched.}\tabularnewline
 $\langle\mbox{program arguments}\rangle$ & {Flags and other parameters to pass to the program.}\tabularnewline
 \end{tabular}
@@ -166,11 +166,11 @@ \chapter{Undefined Behavior in \openshmem}\label{sec:undefined}
 results.  An implementation may choose, for example, to try to continue or abort
 immediately upon the first call to an uninitialized routine.\tabularnewline
 \hline 
-Accessing non-existent \ac{PE}s & If a communications routine accesses a
+Accessing non-existent \acp{PE} & If a communications routine accesses a
 non-existent \ac{PE}, then the \openshmem library can choose to handle this
 situation in an implementation-defined way.  For example, the library may issue
 an error message saying that the \ac{PE} accessed is outside the range of
-accessible \ac{PE}s, or may exit without a warning.\tabularnewline
+accessible \acp{PE}, or may exit without a warning.\tabularnewline
 \hline 
 Use of non-symmetric variables & Some routines require remotely accessible
 variables to perform their function.  A \PUT{} to a non-symmetric variable can
@@ -179,7 +179,7 @@ \chapter{Undefined Behavior in \openshmem}\label{sec:undefined}
 silently.\tabularnewline
 \hline 
 Non-symmetric variables & The symmetric memory management routines are
-collectives, which means that all \ac{PE}s in the program must issue the same
+collectives, which means that all \acp{PE} in the program must issue the same
 \FUNC{shmem\_malloc} call with the same size request.  Program behavior after a
 mismatched \FUNC{shmem\_malloc} call is undefined.\tabularnewline
 \hline 
@@ -514,7 +514,7 @@ \section{Version 1.3}
 
 \begin{itemize}
 %
-\item Clarified implementation of \ac{PE}s as threads.
+\item Clarified implementation of \acp{PE} as threads.
 %
 \item Added \textbf{const} to every read-only pointer argument.
 %

content/execution_model.tex

@@ -1,8 +1,8 @@
-An \openshmem program consists of a set of \openshmem processes called \ac{PE}s
+An \openshmem program consists of a set of \openshmem processes called \acp{PE}
 that execute in a \ac{SPMD}-like model where each \ac{PE} can take a different
 execution path. For example, a \ac{PE} can be implemented using an OS
-process.  The \ac{PE}s progress asynchronously, and can communicate/synchronize
-via the \openshmem interfaces.  All \ac{PE}s in an \openshmem program should
+process.  The \acp{PE} progress asynchronously, and can communicate/synchronize
+via the \openshmem interfaces.  All \acp{PE} in an \openshmem program should
 start by calling the initialization routine  \FUNC{shmem\_init}
 \footnote{\textbf{start\_pes} has been deprecated as of Specification 1.2}
 before using any of the other \openshmem library routines.  An \openshmem
@@ -15,20 +15,20 @@
 resources without terminating the program. Calling any \openshmem routine after
 \FUNC{shmem\_finalize} leads to undefined behavior.
 
-The \ac{PE}s of the \openshmem program are identified by unique integers.  The
+The \acp{PE} of the \openshmem program are identified by unique integers.  The
 identifiers are integers assigned in a monotonically increasing manner from zero
-to the total number of \ac{PE}s minus 1. \ac{PE} identifiers are used for
+to the total number of \acp{PE} minus 1. \ac{PE} identifiers are used for
 \openshmem calls (e.g. to specify \OPR{put} or \OPR{get} routines on symmetric
 data objects, collective synchronization calls) or to dictate a control flow for
-\ac{PE}s using constructs of \Cstd or \Fortran. The identifiers are fixed for
+\acp{PE} using constructs of \Cstd or \Fortran. The identifiers are fixed for
 the life of the \openshmem program.
 
 \subsection{Progress of \openshmem Operations}\label{subsec:progress}
 
 The \openshmem model assumes that computation and communication are naturally
 overlapped. \openshmem programs are expected to exhibit progression of
 communication both with and without \openshmem calls. Consider a \ac{PE} that is
-engaged in a computation with no \openshmem calls. Other \ac{PE}s should be able
+engaged in a computation with no \openshmem calls. Other \acp{PE} should be able
 to communicate (\OPR{put}, \OPR{get}, \OPR{collective}, \OPR{atomic}, etc) and
 complete communication operations with that computationally-bound \ac{PE}
 without that \ac{PE} issuing any explicit \openshmem calls. \openshmem

content/memory_model.tex

@@ -5,12 +5,12 @@
 \end{figure}      
 %
 An \openshmem program consists of data objects that are private to each \ac{PE}
-and data  objects that are remotely accessible by all \ac{PE}s. Private data
+and data  objects that are remotely accessible by all \acp{PE}. Private data
 objects are stored in the local memory of each \ac{PE} and can only be accessed
-by the \ac{PE} itself; these data objects cannot be accessed by other \ac{PE}s
+by the \ac{PE} itself; these data objects cannot be accessed by other \acp{PE}
 via \openshmem routines. Private data objects follow the memory model of
 \Cstd or \Fortran. Remotely accessible objects, however, can be accessed by
-remote \ac{PE}s using \openshmem routines.  Remotely accessible data objects are
+remote \acp{PE} using \openshmem routines.  Remotely accessible data objects are
 called \emph{Symmetric Data Objects}.  Each symmetric data object has a
 corresponding object with the same name, type, and size on all PEs where that object is
 accessible via the \openshmem \ac{API}\footnote{For efficiency reasons,

content/programming_model_overview.tex

@@ -13,9 +13,9 @@
 communication \ac{API} for use in highly parallelized scalable programs.  
 
 The \openshmem{} interfaces can be used to implement \ac{SPMD} style programs.
-It provides interfaces to start the \openshmem{} \ac{PE}s in parallel, and
+It provides interfaces to start the \openshmem{} \acp{PE} in parallel, and
 communication and synchronization interfaces to access remotely accessible data
-objects across \ac{PE}s. These interfaces can be leveraged to divide a problem
+objects across \acp{PE}. These interfaces can be leveraged to divide a problem
 into multiple sub-problems that can be solved independently or with coordination
 using the communication and synchronization interfaces.  The \openshmem
 specification defines library calls, constants, variables, and language bindings
@@ -41,11 +41,11 @@
 
 \item \textbf{Symmetric Data Object Management}
 \begin{enumerate}
-  \item \OPR{Allocation}: All executing \ac{PE}s must participate in the
+  \item \OPR{Allocation}: All executing \acp{PE} must participate in the
       allocation of a symmetric data object with identical arguments.
-  \item  \OPR{Deallocation}: All executing \ac{PE}s must participate in the
+  \item  \OPR{Deallocation}: All executing \acp{PE} must participate in the
       deallocation of the same symmetric data object with identical arguments.
-  \item  \OPR{Reallocation}: All executing \ac{PE}s must participate in the
+  \item  \OPR{Reallocation}: All executing \acp{PE} must participate in the
       reallocation of the same symmetric data object with identical arguments.
 \end{enumerate}
 
@@ -87,7 +87,7 @@
       destination \ac{PE}. 
   \item \OPR{Quiet}: The \ac{PE} calling quiet ensures completion of remote access
       operations and stores to symmetric data objects. 
-  \item \OPR{Barrier}: All or some \ac{PE}s collectively synchronize and ensure
+  \item \OPR{Barrier}: All or some \acp{PE} collectively synchronize and ensure
       completion of all remote and local updates prior to any \ac{PE} returning
       from the call.
 \end{enumerate}

content/shmem_barrier_all.tex

@@ -1,6 +1,6 @@
 \apisummary{
     Registers the arrival of a \ac{PE} at a barrier and suspends \ac{PE} execution
-    until all other \ac{PE}s arrive at the barrier and all local and remote memory
+    until all other \acp{PE} arrive at the barrier and all local and remote memory
     updates are completed.
 }
 
@@ -22,12 +22,12 @@
 
 \apidescription{   
     The \FUNC{shmem\_barrier\_all} routine registers the arrival of a \ac{PE} at
-    a barrier. Barriers are a fast mechanism for synchronizing all \ac{PE}s at
-    once.  This routine causes a \ac{PE} to suspend execution until all \ac{PE}s
+    a barrier. Barriers are a fast mechanism for synchronizing all \acp{PE} at
+    once.  This routine causes a \ac{PE} to suspend execution until all \acp{PE}
     have called \FUNC{shmem\_barrier\_all}.  This routine must be used with
-    \ac{PE}s started by \FUNC{shmem\_init}.
+    \acp{PE} started by \FUNC{shmem\_init}.
 
-    Prior to synchronizing with other \ac{PE}s, \FUNC{shmem\_barrier\_all}
+    Prior to synchronizing with other \acp{PE}, \FUNC{shmem\_barrier\_all}
     ensures completion of all previously issued memory stores and remote memory
     updates issued via \openshmem{} \acp{AMO} and \ac{RMA} routine calls  such
     as \FUNC{shmem\_int\_add}, \FUNC{shmem\_put32}, 

content/shmem_broadcast.tex

@@ -1,6 +1,6 @@
 \apisummary{
     Broadcasts a block of data from one \ac{PE} to one or more destination
-    \ac{PE}s.
+    \acp{PE}.
 }
 
 \begin{apidefinition}
@@ -33,45 +33,45 @@
     0 and less than \VAR{PE\_size}. \VAR{PE\_root} must be of type integer.  If you
     are using \Fortran, it must be a default integer value.}
 \apiargument{IN}{PE\_start}{The lowest \ac{PE} number of the \activeset{} of
-    \ac{PE}s.  \VAR{PE\_start} must be of type integer.  If you are using \Fortran,
+    \acp{PE}.  \VAR{PE\_start} must be of type integer.  If you are using \Fortran,
     it must be a default integer value.}
 \apiargument{IN}{logPE\_stride}{ The log (base 2) of the stride between
     consecutive \ac{PE} numbers in the \activeset. \VAR{log\_PE\_stride} must be of
     type integer.  If you are using \Fortran, it must be a default integer value.}
-\apiargument{IN}{PE\_size}{ The number of \ac{PE}s in the \activeset.
+\apiargument{IN}{PE\_size}{ The number of \acp{PE} in the \activeset.
     \VAR{PE\_size} must be of type integer.  If you are using \Fortran, it must be a
     default integer value.}
 \apiargument{IN}{pSync}{ A symmetric work array.  In \CorCpp, \VAR{pSync} must
     be of type long and size \CONST{SHMEM\_BCAST\_SYNC\_SIZE}. In \Fortran,
     \VAR{pSync} must be of type integer and size \CONST{SHMEM\_BCAST\_SYNC\_SIZE}.
     Every element of this array must be initialized with the value
     \CONST{SHMEM\_SYNC\_VALUE} (in \CorCpp) or \CONST{SHMEM\_SYNC\_VALUE} (in
-    \Fortran) before any of the \ac{PE}s  in  the  \activeset{} enter
+    \Fortran) before any of the \acp{PE}  in  the  \activeset{} enter
     \FUNC{shmem\_broadcast}.}
 
 \end{apiarguments}
 
 \apidescription{   
     \openshmem broadcast routines are collective routines.  They copy data object
     \source{} on the processor specified by \VAR{PE\_root} and store the values at
-    \dest{} on the other \ac{PE}s specified by the triplet \VAR{PE\_start},
+    \dest{} on the other \acp{PE} specified by the triplet \VAR{PE\_start},
     \VAR{logPE\_stride}, \VAR{PE\_size}.  The data is not copied to the \dest{} area
     on the root \ac{PE}.
 
     As with all \openshmem collective routines, each of these routines assumes that
-    only \ac{PE}s in the \activeset{} call the routine.  If a \ac{PE} not in the
+    only \acp{PE} in the \activeset{} call the routine.  If a \ac{PE} not in the
     \activeset{} calls an \openshmem collective routine, undefined behavior results.
 
     The values of arguments \VAR{PE\_root}, \VAR{PE\_start}, \VAR{logPE\_stride},
-    and \VAR{PE\_size} must be equal on all \ac{PE}s in the \activeset.  The same
+    and \VAR{PE\_size} must be equal on all \acp{PE} in the \activeset.  The same
     \dest{} and \source{} data objects and the same \VAR{pSync} work array must be
-    passed to all \ac{PE}s in the \activeset.
+    passed to all \acp{PE} in the \activeset.
 
     Before any \ac{PE} calls a broadcast routine, you must ensure that the following
     conditions exist (synchronization via a barrier or some other method is often
-    needed to ensure this): The \VAR{pSync} array on all \ac{PE}s in the
+    needed to ensure this): The \VAR{pSync} array on all \acp{PE} in the
     \activeset{} is not still in use from a prior call to a broadcast routine.  The
-    \dest{} array on all \ac{PE}s in the \activeset{} is ready to accept the
+    \dest{} array on all \acp{PE} in the \activeset{} is ready to accept the
     broadcast data.
 
     Upon return from a broadcast routine, the following are true for the local
@@ -102,13 +102,13 @@
     require that \VAR{pSync} be reinitialized after the first call.
 
     You must ensure the that the \VAR{pSync} array is not being updated by any
-    \ac{PE} in the \activeset{} while any of the \ac{PE}s participates in processing
+    \ac{PE} in the \activeset{} while any of the \acp{PE} participates in processing
     of an \openshmem broadcast routine. Be careful to avoid these situations: If the
     \VAR{pSync} array is initialized at run time, some type of synchronization is
-    needed to ensure that all \ac{PE}s in the \activeset{} have initialized
+    needed to ensure that all \acp{PE} in the \activeset{} have initialized
     \VAR{pSync} before any of them enter an \openshmem routine called with the
     \VAR{pSync} synchronization array.  A \VAR{pSync} array may be reused on a
-    subsequent \openshmem broadcast routine only if none of the \ac{PE}s in the
+    subsequent \openshmem broadcast routine only if none of the \acp{PE} in the
     \activeset{} are still processing a prior \openshmem broadcast routine call that
     used the same \VAR{pSync} array.  In general, this can be ensured only by doing
     some type of synchronization.        
@@ -118,7 +118,7 @@
 
 \apicexample
     {In the following examples, the call to \FUNC{shmem\_broadcast64} copies \source{}
-    on \ac{PE} 4 to \dest{} on \ac{PE}s 5, 6, and 7. 
+    on \ac{PE} 4 to \dest{} on \acp{PE} 5, 6, and 7. 
 
     \CorCpp{} example:}
     {./example_code/shmem_broadcast_example.c}

content/shmem_calloc.tex

@@ -26,7 +26,7 @@
   \CONST{0}, the return value is a null pointer.
 
   The values for \VAR{count} and \VAR{size} shall each be equal across
-  all \ac{PE}s calling \FUNC{shmem\_calloc}; otherwise, the behavior is
+  all \acp{PE} calling \FUNC{shmem\_calloc}; otherwise, the behavior is
   undefined.
 
   The \FUNC{shmem\_calloc} routine calls \FUNC{shmem\_barrier\_all} on exit.