Fix capitalization of project name in documentation [ci skip]

README.md

-# 🐍🟡♦️🟦 pyHMMER [![Stars](https://img.shields.io/github/stars/althonos/pyhmmer.svg?style=social&maxAge=3600&label=Star)](https://github.com/althonos/pyhmmer/stargazers)
+# 🐍🟡♦️🟦 PyHMMER [![Stars](https://img.shields.io/github/stars/althonos/pyhmmer.svg?style=social&maxAge=3600&label=Star)](https://github.com/althonos/pyhmmer/stargazers)
 
 *[Cython](https://cython.org/) bindings and Python interface to [HMMER3](http://hmmer.org/).*
 
@@ -159,7 +159,7 @@ A possible explanation for this observation would be that HMMER
 platform-specific code requires too many [SIMD](https://en.wikipedia.org/wiki/SIMD)
 registers per thread to benefit from [simultaneous multi-threading](https://en.wikipedia.org/wiki/Simultaneous_multithreading).
 
-To read more about how pyHMMER achieves better parallelism than HMMER for
+To read more about how PyHMMER achieves better parallelism than HMMER for
 many-to-many searches, have a look at the [Performance page](https://pyhmmer.readthedocs.io/en/stable/performance.html)
 of the documentation.
 

docs/benchmarks.rst

@@ -50,7 +50,7 @@ v0.4.0 - 2021-06-05
 
 .. image:: _images/bench-v0.4.0.svg
 
-The overhead of pyHMMER has been reduced, and has a much smaller effect when
+The overhead of PyHMMER has been reduced, and has a much smaller effect when
 using a high number of threads.
 
 The main thread has been updated so that it only loads the next `pyhmmer.plan7.HMM`
@@ -79,5 +79,5 @@ total number of physical CPUs (6 cores). This could be a hint of hindrance
 between the different threads.
 
 Loading from a pressed HMM saves a constant time, independently of the number
-of threads. pyHMMER also has a constant overhead compared to HMMER for a
+of threads. PyHMMER also has a constant overhead compared to HMMER for a
 higher number of threads.

docs/index.rst

-pyHMMER |Stars|
+PyHMMER |Stars|
 ===============
 
 .. |Stars| image:: https://img.shields.io/github/stars/althonos/pyhmmer.svg?style=social&maxAge=3600&label=Star
@@ -125,12 +125,18 @@ Library
    Changelog <changes>
 
 
-Related Project
----------------
+Related Projects
+----------------
 
-If despite of all the advantages listed earlier, you would rather use HMMER through its CLI,
-this package will not be of great help. You should then check the
-`hmmer-py <https://github.com/EBI-Metagenomics/hmmer-py>`_ package developed
+Building a HMM from scratch? Then you may be interested in the `PyFAMSA <https://pypi.org/project/pyfamsa/>`_
+package, providing bindings to `FAMSA <https://github.com/refresh-bio/FAMSA>`_,
+a very fast multiple sequence aligner. In addition, you may want to trim alignments:
+in that case, consider `PytrimAl <https://pypi.org/project/pytrimal>`_, which
+wraps `trimAl 2.0 <https://github.com/inab/trimal/tree/2.0_RC>`_.
+
+If despite of all the advantages listed earlier, you would rather use HMMER
+through its CLI, this package will not be of great help. You can instead check
+the `hmmer-py <https://github.com/EBI-Metagenomics/hmmer-py>`_ package developed
 by `Danilo Horta <https://github.com/horta>`_ at the `EMBL-EBI <https://www.ebi.ac.uk>`_.
 
 

docs/performance.rst

@@ -4,21 +4,21 @@ Performance
 Background
 ----------
 
-Benchmarks of pyHMMER conducted against the ``hmmsearch`` and ``hmmscan`` binaries
+Benchmarks of PyHMMER conducted against the ``hmmsearch`` and ``hmmscan`` binaries
 suggest that running a domain search pipeline takes about the same time in
 single-threaded mode, and are faster when the right number of CPUs is used.
 
 This comes from several changes in the implementation of the search pipeline
-with the pyHMMER API compared to the original HMMER C code, both of which have
+with the PyHMMER API compared to the original HMMER C code, both of which have
 absolutely no effect on the final result.
 
 
 Parallelisation strategy
 ------------------------
 
-Both pyHMMER and HMMER support searching / scanning several targets with
+Both PyHMMER and HMMER support searching / scanning several targets with
 several queries in parallel using multithreading. However, benchmarks suggest
-that pyHMMER takes a greater advantage of the number of available CPUs.
+that PyHMMER takes a greater advantage of the number of available CPUs.
 
 Querying modes
 ^^^^^^^^^^^^^^
@@ -47,7 +47,7 @@ sequence targets in either of two modes:
 
 Although the threaded mode removes the potential I/O bottleneck, it only works for
 a sufficiently large number of targets (:math:`1000 \times n_{cpus}`). To achieve
-true parallelism, pyHMMER improves on the threaded mode by switching the worker
+true parallelism, PyHMMER improves on the threaded mode by switching the worker
 thread logic. Target sequences are pre-fetched in memory before looping
 over the queries, and are passed by reference to all the worker threads. Each
 worker then receives a HMM from the main thread, and process the entirety of
@@ -58,8 +58,8 @@ other before moving on to the next query**.
 
 .. admonition:: Note
 
-    Obviously, the pyHMMER parallelisation strategy will only work for multiple
-    queries. But one main motivation to develop pyHMMER was to annotate protein
+    Obviously, the PyHMMER parallelisation strategy will only work for multiple
+    queries. But one main motivation to develop PyHMMER was to annotate protein
     sequences with a subset of the `Pfam <http://pfam.xfam.org/>`_ HMM library,
     which is why we benchmark this particular use case.
 
@@ -71,7 +71,7 @@ other before moving on to the next query**.
 Example
 ^^^^^^^
 
-To check how well pyHMMER and HMMER3 handle parallelism on a real dataset,
+To check how well PyHMMER and HMMER3 handle parallelism on a real dataset,
 we annotated proteins from representative genomes of the
 `proGenomes <https://progenomes.embl.de/>`_ database with the
 `Pfam <http://pfam.xfam.org/>`_ collection of HMMs. ``hmmsearch`` runs
@@ -87,8 +87,8 @@ and we measured the runtime of either the* ``hmmsearch`` *binary or the*
 Memory allocation
 -----------------
 
-pyHMMER is slightly more conservative with memory: in several places where
-the original HMMER binary would reallocate memory within loops, pyHMMER tries
+PyHMMER is slightly more conservative with memory: in several places where
+the original HMMER binary would reallocate memory within loops, PyHMMER tries
 to simply clear the original buffers instead to allow reusing a previous
 object.
 
@@ -119,7 +119,7 @@ For instance, the ``hmmsearch`` binary will reallocate a new ``P7_PROFILE`` and
 These ``struct`` are not so large by themselves, but they in turn allocate a
 buffer of sufficient size to store the :math:`N` nodes of a HMM.
 
-In pyHMMER, the pipeline will cache memory to be used for the profile and optimized
+In PyHMMER, the pipeline will cache memory to be used for the profile and optimized
 profiles, and only reallocate if the new HMM to be processed is larger than what the
 currently cached ``P7_OPROFILE`` can store.