Skip to content

Instantly share code, notes, and snippets.

@jppelteret
Last active January 1, 2017 11:04
Show Gist options
  • Star 0 You must be signed in to star a gist
  • Fork 0 You must be signed in to fork a gist
  • Save jppelteret/ccb0ece1a89e6920662d8414ae0de181 to your computer and use it in GitHub Desktop.
Save jppelteret/ccb0ece1a89e6920662d8414ae0de181 to your computer and use it in GitHub Desktop.
Dear all,
It is my pleasure to announce the inception of a **Physics** module in the deal.II project.
This module, and its associated namespaces, is dedicated providing some core functionality for computations commonly required in continuum physics.
We hope that you fill find this a useful addition to the library, and we are looking forward to extending its capabilities and scope with your help!
To this end, we have provided a set of guidelines in the wiki to help you along the way.
Best regards,
Jean-Paul,
on behalf of the other deal.II developers

Physics module and namespaces

Below are a set of guidelines that we request that you adhere to when making a contribution to deal.II's physics module. As always, you're welcome to make contributions via a pull-request to the GitHub repository.

Guidelines for documentation of functions

It hardly needs mentioning that there exists a huge variety to the notation and symbology utilized in the scientific literature. For this reason we request that you follow these guidelines in order to maintain transparency of, and consistency between, all provided functions.

  • Each utility or operation must have literature associated with it, authored by authorities in their field. The primary formula that is the basis of a utility must be displayed in the Doxygen documentation.
  • To document these utilities, one should use widely accepted and adopted notation. This notation must be based on the listed literature, and must be documented in the introduction to the enclosing namespace.
  • If it is necessary or appropriate to deviate from the notation in the cited literature, then a detailed disclosure should be made at the point at which this takes place.
  • Formulae and discussion points are to have citations that are as precise as possible (page and equation numbers).
  • New functionality that augments an existing namespace must be documented in a manner that is consistent with that namespace. In such a case it may, therefore, be necessary to adapt your regularly used notation to that which has been previously used.

Non-viable contributions

Unfortunately, it is not possible to provide a consistent set of utilities that cater to everyone's requirements. Sometimes the literature (or background mathematics) opens up many posibilities as how to frame an operation. At this point we may choose to draw a boundary and say that it is not sensible to choose one definition over another, and (as much as it may pain us) may not accept the proposed function. We maintain a list of example cases where we've had to use this type of discresion below to provide some illustration of the thought behind the decision. If you're unsure as to whether your potential contribution is appropriate, feel free to open an issue to start discussions beforehand.

Elasticity

  • Constitutive laws
  • Multiple parameterizations possible
  • Multiple accepted, but conflicting, definitions in the literature
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment