Merge branch 'feature/QPR-13706' into 'master'

QPR-13706: fix typos in other catalogues

Closes QPR-13706

See merge request qs/oreplus!3080

Author: pcaspers

Docs/AMC/amc.tex

@@ -191,7 +191,7 @@ \section{Overview}\label{overview}
 evolution model driving the XVA simulation, the scenario NPVs in the classic approach are in general not consistent in
 this sense unless the market scenarios are fully implied by the cross asset model. Here ``fully implied'' means that not
 only rate curves, but also market volatility and correlation term structures like FX volatility surfaces, swaption
-volatilties or CMS correlation term structures as well as other parmeters used by the single trade pricers have to be
+volatilities or CMS correlation term structures as well as other parameters used by the single trade pricers have to be
 deduced from the cross asset model, e.g. the mean reversion of the Hull White 1F model and a sutaible model volatility
 feeding into a Bermudan swaption pricer.
 
@@ -613,7 +613,7 @@ \subsection{Multi Leg Options / MC pricing engine}
 \item \verb+IrCalibrationStrategy+ can be \verb+None+, \verb+CoterminalATM+, \verb+UnderlyingATM+
 \item \verb+FXCalibration+ can be \verb+None+ or \verb+Bootstrap+
 \item \verb+ExtrapolateFxVolatility+ can be \verb+true+ or \verb+false+; if false, no calibration instruments are used
-  that require extrapolation of the market fx volatilty surface in option expiry direction
+  that require extrapolation of the market fx volatility surface in option expiry direction
 \item \verb+Corr_Key1_Key2+: These entries describe the cross asset model correlations to be used; the syntax for
   \verb+Key1+ and \verb+Key2+ is the same as in the simulation configuration for the cross asset model, see \cite{oreug}.
 \end{enumerate}

Docs/BondPricingConfig/bondpricingconfig.tex

@@ -143,7 +143,7 @@ \section{Overview}\label{overview}
 
 \begin{itemize}
 \item ReferenceCurve: a rate curve determining the baseline discounting curve for bond valuation.
-\item CreditCurve [optional]: a credit curve determining the default probabilty during the lifetime of a bond. This can
+\item CreditCurve [optional]: a credit curve determining the default probability during the lifetime of a bond. This can
   e.g. be
 \begin{itemize}
 \item a CDS curve of the same issuer and seniority as the bond to proxy the credit risk
@@ -154,7 +154,7 @@ \section{Overview}\label{overview}
 \end{itemize}
 In all cases, the security spread can be used to represent additional credit / liquidity risk, see below.
 \item SecuritySpread [optional]: a single additional discounting spread. This can generally be interpreted as part of
-  the credit risk (generating additional default probabilty) or as part of the baseline discounting (liquidity
+  the credit risk (generating additional default probability) or as part of the baseline discounting (liquidity
   spread). Assumed to be zero if not given. Exception: If a price quote is given and the security spread is configured
   in the security curve config, but no market data is given for the security spread, the security spread is implied from
   the price quote.
@@ -216,7 +216,7 @@ \subsection{Credit Curve Config}
 The credit curve represents the survival probability entering the bond pricing. It also provides a recovery rate that is
 used as a fallback if the recovery rate from the security curve config is not available.
 
-The curve config can either be explicitly set up or ore can auto-generate it. Listing
+The curve config can either be explicitly set up or ORE can auto-generate it. Listing
 \ref{lst:autogen_default_curve_config} shows an auto-generated config for the bond from section \ref{refdata}:
 
 \begin{itemize}
@@ -257,7 +257,7 @@ \subsection{Security Curve Config}
 
 The security curve config points to additional market data used for bond pricing.
 
-It can be explicitly set up or ore can auto-generate it. Listing \ref{lst:autogen_security_curve_config} shows an
+It can be explicitly set up or ORE can auto-generate it. Listing \ref{lst:autogen_security_curve_config} shows an
 auto-generated config for the bond from section \ref{refdata}:
 
 \begin{itemize}

Docs/CodingStandards/ore_coding_standards.tex

@@ -165,7 +165,7 @@ \section*{git usage - pull requests}
 \textbf{Optional:} \texttt{\% git push bob bob\_widget}
 \item Once the coding task in complete, developer pushes the branch to the origin repo. Care should be taken not to push to origin/master.\\
  \texttt{\% git push origin bob\_widget}
- \item Then go to codebasehq.com \url{https://qrm.codebasehq.com/projects/openxva/repositories/openxva/tree/master} and click on "Merge Request" and then "New Merge Request" with the following details:
+ \item Then go to codebasehq.com \url{https://qrm.codebasehq.com/projects/openxva/repositories/openxva/tree/master} and click on ``Merge Request'' and then ``New Merge Request'' with the following details:
  \begin{itemize}
  \item \textbf{Subject} A short description
  \item \textbf{User} The merge manager (currently Niall O'Sullivan)
@@ -182,9 +182,9 @@ \section*{git usage - pull requests}
 
 The git workflow for the merge manager is as follows
 \begin{enumerate}
-\item Note that everyone who has a codebase account can preform these tasks, currently there is one designated manager who may delegate.
+\item Note that everyone who has a codebase account can perform these tasks, currently there is one designated manager who may delegate.
 \item go to merge requests in codebase
-\item if there are no conflicts, click on "merge request"
+\item if there are no conflicts, click on ``merge request''
 \item if there are conflicts, send it back to the developer
 \item Once the request has been merged, the temporary branch should be deleted. This is not strictly necessary but means origin is kept cleaner and avoids conflicts.\\
  \texttt{\% git push -{}-delete origin bob\_widget}
@@ -219,7 +219,7 @@ \subsection*{Policy on personal github accounts}
 This policy statement does not supersede your employment contract.
 
 \subsection*{Policy on opensourcerisk.org forum accounts}
-Quaternion developers are permitted and encouraged to create a forum account and engage with the community. As we are representing Quaternion on the forum you should indicate this in your profile somehow, one example of this is to use the Quaternion "Q" logo as an avatar. There are no strict posting rules on the forum however if your account is associated with Quaternion it is expected that all posts and messages are formal and polite.
+Quaternion developers are permitted and encouraged to create a forum account and engage with the community. As we are representing Quaternion on the forum you should indicate this in your profile somehow, one example of this is to use the Quaternion ``Q'' logo as an avatar. There are no strict posting rules on the forum however if your account is associated with Quaternion it is expected that all posts and messages are formal and polite.
 
 %-------------------------------------------------------------------------------
 \section*{ORE and ORE+ code layout}

Docs/CommodityModel/CommodityModel.tex

@@ -72,7 +72,7 @@ \section{One Factor Model}
 %%%%%%%%%%%%%%%%%%%%%%%%%%%%
 \subsection{Time Dependent Multiplier}
 %%%%%%%%%%%%%%%%%%%%%%%%%%%%
-Seasonality is observed in the market for both commodity future price curves and option volatilities. To incorporate the seasonality in the modelling a time dependent multiplier is introduced in the literature. Andersen \cite{Andersen} suggests\footnote{See section 7.2 in Andersen \cite{Andersen} for the discussion on dependence of seasonality adjustment to calendar days and expiry of future contracts.} that the time dependent variable depends on the maturity of the futures contract. By following this approach, we define it in the one factor case\footnote{Andersen worked on a two factor set up, where the first factor affects the short-end of the futures curve and has the form the $e^{b(T)}$, and the second factor has an additional term containing $e^{a(T)}h_{\infty}$ for long futures maturities.} as follows
+Seasonality is observed in the market for both commodity future price curves and option volatilities. To incorporate the seasonality in the modelling a time dependent multiplier is introduced in the literature. Andersen \cite{Andersen} suggests\footnote{See section 7.2 in Andersen \cite{Andersen} for the discussion on dependence of seasonality adjustment to calendar days and expiry of future contracts.} that the time dependent variable depends on the maturity of the futures contract. By following this approach, we define it in the one factor case\footnote{Andersen worked on a two factor set up, where the first factor affects the short-end of the futures curve and has the form $e^{b(T)}$, and the second factor has an additional term containing $e^{a(T)}h_{\infty}$ for long futures maturities.} as follows
 %
 $$
 m_i(T) = e^{b_i(T)} 

Docs/ComputeEnvironment/computeenvironment.tex

@@ -455,7 +455,7 @@ \subsection{Populating the input variates}
 
 where \verb+k+ loops over the dimensions (e.g. number of assets) and \verb+j+ loops over the time steps and \verb+rv+ is
 a vector of vectors storing the indices of the required random variates by dimensions and time steps. The external
-random variable contructor used in this case is
+random variable constructor used in this case is
 
 \begin{minted}[fontsize=\footnotesize]{xml}
 ExternalRandomVariable::ExternalRandomVariable(std::size_t id)
@@ -650,7 +650,7 @@ \subsection{Variable management}
 \begin{itemize}
 \item input variables: {\tt x[offset + i]}, with x a buffer in the global address space
 \item input variates: {\tt r[offset + i]}, with r a buffer in the global address space
-\item intermediate variables: {\tt b[offset + i]}, with b a buffer in the global address space. It is refered to as the
+\item intermediate variables: {\tt b[offset + i]}, with b a buffer in the global address space. It is referred to as the
   values buffer. Note that this buffer also contains conditional expectation arguments and results and all output
   variables.
 \end{itemize}

Docs/CreditModel/creditmodel.tex

@@ -120,7 +120,7 @@ \subsection{Credit-worthiness model and transition matrices}
 
 \begin{itemize}
 \item $Y_i$ is the systematic part of the credit risk driven by global credit factors $G_j$ (shared between entities),
-  which are standard Brownian motions with correlation $dG_k\,dG_l = \rho_{kl}\,dt$. The $\beta_{ij}$ are entity-specifc
+  which are standard Brownian motions with correlation $dG_k\,dG_l = \rho_{kl}\,dt$. The $\beta_{ij}$ are entity-specific
   loadings.
 \item $Z_i$ is the idiosyncratic part of the credit risk of entity $i$, driven by standard Brownian motions $W_i$ which are independent of all
   global factors $G_j$
@@ -494,15 +494,15 @@ \subsection{CreditMigrationHelper}
   \item computing the conditional transition matrices
   \item generating the issuer-risk pnl at the simulation horizon based on the conditional matrices and the NPVs for all
     credit states computed with multi-state pricing engines
-  \item generating the counterparty-risk pnl at the simulation horizon based on the conditional migration probabilty to
+  \item generating the counterparty-risk pnl at the simulation horizon based on the conditional migration probability to
     default and the usual NPV for relevant derivative trades
   \end{itemize}
 \item Evaluation $\neq$ Analytic: generate the credit-risk pnl using calls to
   \begin{itemize}
   \item \verb+initEntityStateSimulation()+: Compute conditional transition matrices for large step (TerminalSimulation)
   \item for each ``inner'' simulation path: simulate the entity state using \verb+simulateEntityStates()+
   \item for each ``inner'' simulation path: generate credit-risk pnl using \verb+generateMigrationPnl()+ based on the
-    simulated entity state at the terminal time step and for issuer and counterparty risk (this is donw similar to
+    simulated entity state at the terminal time step and for issuer and counterparty risk (this is done similar to
     Evaluation = Analytic described above)
   \end{itemize}
 \end{itemize}

Docs/Design/aad.tex

@@ -80,7 +80,7 @@ \section{Automatic Differentiation}
   \frac{\partial y}{\partial c} &= \frac{\partial y}{\partial e} \cdot \frac{\partial e}{\partial c} = -d
   \end{align*}
 
-The following section provides a brief introduction to the AD mechanics, {\em Forward} and {\em Backward} modes. The latter is also referred to as Adjoint Algorithmic Differentiation (AAD) and particularly important for fast sensitivity calulation.
+The following section provides a brief introduction to the AD mechanics, {\em Forward} and {\em Backward} modes. The latter is also referred to as Adjoint Algorithmic Differentiation (AAD) and particularly important for fast sensitivity calculation.
 
 %------------------------------------------------------------------------------------------------------------
 \subsection{Automatic Differentiation Basics}
@@ -270,7 +270,7 @@ \subsection{Computation Graphs in ORE}
 the operator overloading path introducing an ``active'' {\tt Real} data type, replacing the
 ``inactive'' {\tt Real} type across the entire ORE libraries, we extract the computation graph
 explicitly from the script in its AST representation in order to utilize AAD in the scripted trade
-processing only. Thus we avoid negative perfomance impact (recall the ``factor 4'' overhead)
+processing only. Thus we avoid negative performance impact (recall the ``factor 4'' overhead)
 elsewhere and in the valuation of vanilla instruments. Moreover, we make the ``AAD activation'' of the
 scripted trade framework configurable, i.e. we can switch AAD on and off without recompiling the
 code base. How this works is discussed briefly in the following.
@@ -1008,7 +1008,7 @@ \subsubsection{Portfolio decomposition}\label{aad:dynamic_delta_subportfolios}
 
 In general the calculations described in the previous sections are performed on suitable subsets of the whole
 portfolio. First of all, if the dynamic delta is required for each individual trade, these subsets consist of a single
-trade. If the dynamic delta is only required on the portfolio level, the porfolio is first decomposed into
+trade. If the dynamic delta is only required on the portfolio level, the portfolio is first decomposed into
 
 \begin{itemize}
 \item ``plain vanilla'' trades for which the calculations can be done on an the level of aggregated npvs

Docs/Design/ore_design.tex

@@ -293,7 +293,7 @@ \subsection*{Applications}
 		OREApp ore(params);
 		return ore.run();
 	} catch (const exception& e) {
-		cout << endl << "an error occured: " << e.what() << endl;
+		cout << endl << "an error occurred: " << e.what() << endl;
 		return -1;
 	}
 }
@@ -839,7 +839,7 @@ \subsubsection{Scenario Generation}
 \end{listing}
 
 The scenario object refers to a unique reference date and contains an arbitrarily large number of data points that are identified by a RiskFactorKey. The key identifies the risk factor class (25 types so far in ORE, see the definition in
-{\tt OREAnalytics/orea/scenario/scenario.hpp}, e.g. {\tt DiscoutCurve}, {\tt IndexCurve}, {\tt SwaptionVolatility}, etc.), a name (e.g. a currency or index name), and an integer indicating the position of the data item in a vector, matrix or cube. A market
+{\tt OREAnalytics/orea/scenario/scenario.hpp}, e.g. {\tt DiscountCurve}, {\tt IndexCurve}, {\tt SwaptionVolatility}, etc.), a name (e.g. a currency or index name), and an integer indicating the position of the data item in a vector, matrix or cube. A market
 evolution or path is hence represented by a vector of scenarios. So far there is only one derived class from the base Scenario in ORE, {\tt SimpleScenario}, which stores the scenario data in simple vectors and maps, also serializable.
 
 \subsubsection{Engine}
@@ -848,19 +848,19 @@ \subsubsection{Engine}
 \item {\bf ValuationEngine} - performs a market simulation, prices a portfolio under scenarios, possibly through time, and fills a resulting NPV cube, with the help of the ValuationCalculator class; the ValuationEngine is used for Monte Carlo simulations of the market evolution but also the hypothetical scenario analytics below
 \item {\bf SensitivityAnalysis}, also performed with the help of ValuationEngine and ValuationCalculator: This class wraps functionality to perform a sensitivity analysis for a given portfolio.
 \begin{itemize}
-\item builds the "simulation" market to which sensitivity scenarios are applied, 
+\item builds the ``simulation'' market to which sensitivity scenarios are applied, 
 \item builds the portfolio linked to this simulation market
 \item generates sensitivity scenarios
-\item runs the scenario "engine" to apply these and compute the NPV impacts of all required shifts
+\item runs the scenario ``engine'' to apply these and compute the NPV impacts of all required shifts
 \item compiles first and second order sensitivities for all factors and all trades
 \item fills result structures that can be queried
 \end{itemize}
 \item {\bf StressTest}, also performed with the help of ValuationEngine and ValuationCalculator: This class wraps functionality to perform a stress testing analysis for a given portfolio and
 \begin{itemize}
-\item builds the "simulation" market to which stress scenarios are applied, 
+\item builds the ``simulation'' market to which stress scenarios are applied, 
 \item builds the portfolio linked to this simulation market
 \item generates stress scenarios
-\item runs the scenario "engine" to apply these and compute the NPV impacts of all required shifts
+\item runs the scenario ``engine'' to apply these and compute the NPV impacts of all required shifts
 \item fills result structures that can be queried
 \item writes stress test report to a file
 \end{itemize}
@@ -969,7 +969,7 @@ \subsubsection{Aggregation, Cubes, XVA and Post Process}
 \end{itemize}
 \item {\tt ExposureAllocator}/ {\tt RelativeFairValueNetExposureAllocator}/ {\tt RelativeFairValueGrossExposureAllocator}/ {\tt RelativeXvaExposureAllocator}/ {\tt NoneExposureAllocator}: calculates EPE/ENE based on selected AllocationMethod
 \item {\tt CollateralExposureHelper}: This class contains helper functions to aid in the calculation of collateralised exposures. It can be used to calculate margin requirements in the presence of e.g. thresholds and minimum transfer amounts, update collateral account details with e.g. new margin call info, and return collateralised exposures to the user/invoker.
-\item {\tt CollateralAccount}: This class holds information corresponding to collateral cash accounts. It stores a balance as well as an asof date for the balance. The class also includes "margin" information relating to the most recent margin call (e.g. call amount, status, expected pay date. The idea is that this class can be updated on-the-run with new margin requirements and collateral balances, and the timestamps updated accordingly.
+\item {\tt CollateralAccount}: This class holds information corresponding to collateral cash accounts. It stores a balance as well as an asof date for the balance. The class also includes ``margin'' information relating to the most recent margin call (e.g. call amount, status, expected pay date. The idea is that this class can be updated on-the-run with new margin requirements and collateral balances, and the timestamps updated accordingly.
 \item {\tt CVASpreadSensitivityCalculator}: Compute hazard rate and CDS spread sensitivities for a given exposure profile on an externally provided sensitivity grid.
 \end{itemize}
 
@@ -1706,7 +1706,7 @@ \subsection*{Current Scope}
 for data management outside (before and after) calling {\tt ORE.run()} and to facilitate
 ORE-based application development in Python.
 
-We curently extend the SWIG wrapper scope mainly upon client request, rather than embarking
+We currently extend the SWIG wrapper scope mainly upon client request, rather than embarking
 on a systematic internal extension project. 
 
 \subsection*{Python Wheels}
@@ -1929,7 +1929,7 @@ \subsection*{RESTORE}
   to maintain such data manually
 \end{itemize}
 
-\subsubsection*{RESTORE Implemenation}
+\subsubsection*{RESTORE Implementation}
 
 Source code components and their purpose
 \begin{itemize}