Skip to content

Commit

Permalink
Merge pull request #156 from csdms/mcflugen/convert-docs-to-myst
Browse files Browse the repository at this point in the history
Convert the docs from ReStructuredText to MyST
  • Loading branch information
mcflugen authored Nov 8, 2024
2 parents 7c25129 + 914cdfa commit fd1ca9f
Show file tree
Hide file tree
Showing 36 changed files with 1,377 additions and 1,472 deletions.
79 changes: 31 additions & 48 deletions CONTRIBUTING.rst → CONTRIBUTING.md
Original file line number Diff line number Diff line change
@@ -1,28 +1,21 @@
.. highlight:: shell

============
Contributing
============
# Contributing

Contributions are welcomed and greatly appreciated!
BMI is a community-driven open source project, so every little bit helps.
`Credit`_ will always be given.
[Credit] will always be given.

This document describes how to contribute to the BMI project.
It covers the main `BMI repository`_,
It covers the main [BMI repository],
as well as the language specifications and examples
for supported languages
listed in `Table 1`_ of the `BMI documentation`_.
listed in [Table 1] of the [BMI documentation].

--------------
Making changes
--------------
## Making changes

The following sections describe the process through which changes to the BMI
specification, language bindings, language examples, and support tools are made.

Pull requests
~~~~~~~~~~~~~
### Pull requests

If you'd like to propose a change to the BMI or any of its language
bindings, examples, or tools, you must submit a pull request (PR) to the
Expand All @@ -37,8 +30,7 @@ resolution through *lazy consensus*. The RFC process is intended for major
changes to the BMI, whereas lazy consensus applies to minor changes such as
typos or documentation updates.

Request for Comment (RFC)
~~~~~~~~~~~~~~~~~~~~~~~~~
### Request for Comment (RFC)

Once a PR has been tagged as an RFC, a review process begins.
It proceeds in three steps:
Expand All @@ -47,8 +39,7 @@ It proceeds in three steps:
2. summary
3. resolution

Discussion
..........
#### Discussion

Reviewers (the other developers and interested community members) will write
comments on your PR to help you improve its implementation, documentation, and
Expand All @@ -68,8 +59,7 @@ We expect that most PRs will not be accepted without some modification. You can
make changes by pushing commits directly to the PR branch and leaving comments
that explain the modifications.

Summary
.......
#### Summary

Once all parties have weighed in and there has been adequate discussion, the PR
moves to a summary period. A team member will move for the discussion
Expand All @@ -88,66 +78,59 @@ discussion taking place during the discussion phase. There will likely be times,
however, where stakeholders might raise serious enough concerns that the PR
moves back into the discussion phase.

Resolution
..........
#### Resolution

The RFC process concludes with the PR being merged, closed, or postponed.

There must be a *consensus* from project developers and interested community
members for a PR to be merged. Consensus has a particular meaning when used
with open source projects; see the `BMI governance document`_ for a definition
with open source projects; see the [BMI governance document] for a definition
of consensus in this context.

If consensus isn't achieved, the PR will be postponed (the team feels the PR can
wait until some future time) or closed.

Lazy Consensus
~~~~~~~~~~~~~~
### Lazy Consensus

`Lazy consensus`_, as defined by the Apache Software Foundation, is a
[Lazy consensus], as defined by the Apache Software Foundation, is a
decision-making policy which assumes general consent if no responses are posted
within a defined period.

For the BMI project, a PR tagged for resolution through lazy consensus can be
merged if no comments are posted within about a week.

-------------------
Reporting a problem
-------------------
## Reporting a problem

Report bugs or other problems by creating a GitHub issue at
https://github.com/csdms/bmi/issues.
<https://github.com/csdms/bmi/issues>.

In the issue, be sure to explain the problem and include additional details to
help maintainers reproduce the problem. Here are some suggestions that will make
it easier to track down the source of the problem:

* Use a clear and descriptive title for the issue that identifies the problem.
* Describe, and if possible provide a minimal example that demonstrates, the
- Use a clear and descriptive title for the issue that identifies the problem.
- Describe, and if possible provide a minimal example that demonstrates, the
exact steps that reproduce the problem.
* Describe the behavior you are seeing after these steps.
* Describe the behavior you expect to see after these steps.
- Describe the behavior you are seeing after these steps.
- Describe the behavior you expect to see after these steps.

------------------
Providing feedback
------------------
## Providing feedback

The best way to send feedback is to file an issue at
https://github.com/csdms/bmi/issues.
<https://github.com/csdms/bmi/issues>.

If you are proposing a feature:

* Explain in detail how it would work.
* Keep the scope as narrow as possible, to make it easier to implement.
* Remember that this is a volunteer-driven project, and that contributions
- Explain in detail how it would work.
- Keep the scope as narrow as possible, to make it easier to implement.
- Remember that this is a volunteer-driven project, and that contributions
are welcome.

<!-- Links -->

.. Links
.. _Credit: https://bmi.readthedocs.io/en/latest/credits.html
.. _BMI repository: https://github.com/csdms/bmi
.. _Table 1: https://bmi.readthedocs.io/en/latest/#id43
.. _BMI documentation: https://bmi.readthedocs.io
.. _BMI governance document: https://bmi.readthedocs.io/en/latest/governance.html
.. _Lazy consensus: https://community.apache.org/committers/lazyConsensus.html
[bmi documentation]: https://bmi.readthedocs.io
[bmi governance document]: https://bmi.readthedocs.io/en/latest/governance.html
[bmi repository]: https://github.com/csdms/bmi
[credit]: https://bmi.readthedocs.io/en/latest/credits.html
[lazy consensus]: https://community.apache.org/committers/lazyConsensus.html
[table 1]: https://bmi.readthedocs.io/en/latest/#id43
1 change: 1 addition & 0 deletions docs/requirements.txt
Original file line number Diff line number Diff line change
@@ -1,3 +1,4 @@
furo
myst-parser
sphinx
sphinx_design
81 changes: 81 additions & 0 deletions docs/source/bmi.best_practices.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,81 @@
(best-practices)=

# BMI best practices

BMI is a simple concept---it's just a set of functions
with rules for the function names, arguments, and returns.
However, when implementing a BMI, the devil is often in the details.
In no particular order,
here are some tips to help when writing a BMI for a model.

- All functions in the BMI must be implemented. For example, even if a
model operates on a {ref}`uniform rectilinear <uniform-rectilinear>`
grid, a {ref}`get-grid-x` function has to be written. This function
can be empty and simply return the `BMI_FAILURE` status code or
raise a `NotImplemented` exception, depending on the language.
- The {ref}`BMI functions <basic-model-interface>` listed in the
documentation are the minimum required. Optional functions that act
as helpers can be added to a model's BMI. For example, an
`update_frac` function that updates a model's state by a fractional
time step is a common addition to a BMI.
- Implementation details are left up to the model developer. All that
the BMI specifies are the names of the functions, their arguments,
and their return values.
- {term}`Standard Names` are not required for naming a model's
{term}`exchange items <exchange item>`. However, the use of
standardized names makes it easier for a framework (or a human) to
match input and output variables between models.
- Don't change the variable names for exchange items
you currently use within your model
to {term}`Standard Names`. Instead, find a
[matching] Standard Name for each variable and then
write your BMI functions to accept the Standard Names and map them
to your model's internal names.
- Constructs and features that are natural for the language should be
used when implementing a BMI. BMI strives to be developer-friendly.
- BMI functions always use flattened, one-dimensional arrays. This
avoids any issues stemming from row/column-major indexing when
coupling models written in different languages. It's the developer's
responsibility to ensure that array information is
flattened/redimensionalized in the correct order.
- Recall that models can have multiple grids. This can be particularly
useful for defining {term}`exchange items <exchange item>` that
don't vary over the model domain; e.g., a diffusivity -- just define
the variable on a separate {ref}`scalar grid <unstructured-grids>`.
- Avoid using global variables, if possible. This isn't strictly a BMI
requirement, but if a model only uses local variables, its BMI will
be self-contained. This may allow multiple instances of the model to
be run simultaneously, possibly permitting the model to be coupled
with itself.
- Boundary conditions, including boundary conditions that change with
the model state, can be represented with {term}`exchange items
<exchange item>`.
- {term}`Configuration files <configuration file>` are typically text
(e.g., [YAML] is preferred by CSDMS), but this isn't a strict
requirement; binary data models such as [HDF5] and [netCDF] also
work well for storing configuration data.
- Before fitting a model with a BMI, the model code may have to be
{term}`refactored <refactor>` into modular *initialize-run-finalize*
(IRF) steps in order to interact with the BMI functions. This is often
the most difficult part of adding a BMI, but the modularization
tends to improve the quality of the code.
- Avoid allocating memory within a BMI function. Memory allocation is
typically the responsibility of the model. This helps keep the BMI
middleware layer thin.
- Be sure to check out the examples: [C], [C++], [Fortran], [Java], [Python].
Although they wrap a very simple model, they give useful insights into how a
BMI can be implemented in each language.
- Return codes (C and Fortran) and exceptions (C++, Java, and Python) can help with
debugging a BMI, and can provide useful information to a user.

% Links:

[c]: https://github.com/csdms/bmi-example-c
[c++]: https://github.com/csdms/bmi-example-cxx
[fortran]: https://github.com/csdms/bmi-example-fortran
[hdf5]: https://www.hdfgroup.org/solutions/hdf5/
[java]: https://github.com/csdms/bmi-example-java
[matching]: https://github.com/csdms/standard_names_registry
[netcdf]: https://www.unidata.ucar.edu/software/netcdf/
[python]: https://github.com/csdms/bmi-example-python
[yaml]: https://yaml.org/
96 changes: 0 additions & 96 deletions docs/source/bmi.best_practices.rst

This file was deleted.

Loading

0 comments on commit fd1ca9f

Please sign in to comment.