Doc

`

PyMechanical Documentation Standards

All PyMechanical documentation follows the standards defined in the PyAnsys developer guide. Apply these rules when writing or reviewing documentation in any PyAnsys library.

Writing Style (Google Developer Documentation Style Guide)

All prose in RST files, docstrings, and README files must follow the Google developer documentation style guide:

• Sentence case for all headings and titles (capitalize first word and proper nouns only)
• Active voice and present tense wherever possible
• Second person — use "you"/"your"; avoid "we"
• Short sentences — one idea per sentence. Avoid semicolons. Break into two sentences instead.
• American English spelling and punctuation
• Omit "please" from instructions
• Replace "In order to" with "To"
• Vale enforces these rules in CI/CD (doc/.vale.ini)

RST File Formatting

Headings

Use this character hierarchy (must be at least as long as the heading text):

###############
Part title
###############

Section title
=============

Subsection
----------

Sub-subsection
~~~~~~~~~~~~~~

Sub-sub-subsection
++++++++++++++++++

General Rules

• One blank line between paragraphs
• Blank line before and after every list
• No trailing whitespace; spaces not tabs for indentation
• Max line length follows library convention (commonly 79–120 chars)
• Use .. prefix for RST comments; use .. todo:: directive for tracked items

RST comment and todo examples:

.. This is a comment that does not appear in the rendered output.

.. todo::

   Add support for exporting results to CSV format.

Inline Formatting

Code Blocks

.. code-block:: python

   import ansys.mechanical.core as pymechanical
   app = pymechanical.launch_mechanical()

Use .. code-block:: console for shell commands, .. code-block:: python for Python.

Notices / Admonitions

.. note::

   Use notes for helpful but non-critical information.

.. warning::

   Use warnings for content that could cause data loss or unexpected behavior.

.. important::

   Use for critical information that must not be missed.

Cross-References and Links

• Use Sphinx :ref: labels for internal cross-references: :ref:`my_label`
• Use :func:, :class:, :meth:, :attr: for API cross-references
• Use .. _label_name: above headings to define reference targets
• Use the `Link text <https://url>`_ format for external URLs. The link text should match exact name of the article or section that the link takes you to, including capitalization. If the referenced content is within a larger document, append that for clarity. For example: For more information on creating NumPy arrays, see Array creation <https://numpy.org/doc/stable/user/basics.creation.html>_ in the NumPy documentation.

Images

.. figure:: /path/to/image.png
   :alt: Descriptive alt text
   :width: 500px

   For the caption, use full sentences or noun phrases. For example:
   alt="Architecture of an app that's built with Apps Script."
   alt="A card message."

Documentation Content Structure

Every PyAnsys library documentation should have these top-level sections:

Toctree in doc/source/index.rst drives the top-level hierarchy. Each section has its own index.rst with a local toctree. Section index filenames: short, descriptive, hyphen-separated.

Python Docstrings (NumPy Style)

PyAnsys libraries use NumPy-style docstrings (not Google-style). NumPy style is preferred because it is used by NumPy, SciPy, and pandas — the primary dependencies.

Required Rules

• Always use triple double-quotes """ — never single quotes
• Lines ≤ 100 characters (keeps API summary tables readable)
• No trailing whitespace
• Use "" for code entities (not '' — single backtick renders italic in Sphinx)

Sections Order

Short summary
Deprecation warning (if applicable)
Extended summary (if applicable)
Parameters (if applicable)
Returns (if applicable)
Raises (if applicable)
Examples (always required)

Sections rarely used in PyAnsys: Yields, Receives, Other Parameters, Warns, Warnings, See Also, Notes, References.

Short Summary Rules

Parameters Section

Parameters
----------
obj : str
    Name of the object to assign the material to.
mat : str
    Name of the material.
timeout : float, default: 30
    Time in seconds to wait before timing out.
method : str or int, default: "auto"
    Solver method to use. If a string, it must be a valid method name.
    If an integer, it is interpreted as the method index.

• Use default: <value> after the type to indicate default values for optional parameters
• Keep the description concise; do not repeat the default in prose

Returns Section

Returns
-------
bool
    ``True`` when successful, ``False`` when failed.
str
    Path to the exported file.

Examples Section

Examples must be doctest-compliant — they are run as regression tests via pytest (addopts = "--doctest-modules" in pyproject.toml).

Examples
--------
Launch a Mechanical instance and get its version.

>>> import ansys.mechanical.core as pymechanical
>>> app = pymechanical.launch_mechanical()
>>> app.version
"2024 R1"

@property Docstring

No Parameters section. No docstring on the setter. Described as a noun.

@property
def working_directory(self):
    """Path to the working directory."""
    return self._working_directory

Protected Methods

Protected methods (single leading underscore _) still need clear docstrings even though Sphinx does not render them publicly.

Deprecation

When deprecating a method or class:

1. Have the old method call the new method and raise DeprecationWarning
2. Add a .. deprecated:: directive in the docstring
3. After a minor release or two, raise AttributeError or a custom DeprecationError

import warnings


class FieldAnalysis2D:
    def assignmaterial(self, obj, mat):
        """Assign a material to one or more objects.

        .. deprecated:: 0.4.0
           Use :func:`FieldAnalysis2D.assign_material` instead.

        Parameters
        ----------
        obj : str
            Name of the object.
        mat : str
            Name of the material.
        """
        warnings.warn(
            "`assignmaterial` is deprecated. Use `assign_material` instead.",
            DeprecationWarning,
        )
        self.assign_material(obj, mat)

For full removal, raise a custom error:

class DeprecationError(RuntimeError):
    """Used for deprecated methods and functions."""

    def __init__(self, message="This feature has been deprecated."):
        RuntimeError.__init__(self, message)

Documentation Tooling

Vale Commands

vale --config=doc/.vale.ini sync    # Download/update styles
vale --config=doc/.vale.ini .       # Check whole repo
vale --config=doc/.vale.ini doc/source/   # Check only doc directory

Sphinx Build Configuration

Minimum required SPHINXOPTS flags in Makefile / make.bat:

Coding Style Quick Reference (for Code in Docs)

All code in examples and docstrings must follow PEP 8:

• Line length: 100 characters (configured via ruff)
• Imports: stdlib → third-party → local; one import per line; no wildcard imports
• Naming: snake_case for functions/methods/variables, CamelCase for classes, UPPER_CASE for constants, lowercase for packages/modules
• Strings: double quotes (configured via ruff)
• Indentation: 4 spaces, no tabs

README Files

• Prefer .rst over .md — RST content can be reused in Sphinx docs via .. include::
• Partial reuse: use :start-after: / :end-before: with explicit RST targets for selective inclusion