Adding CODATA constants

[certik]

Idea:

• https://twitter.com/arclight/status/1371676228856463364

Preliminary repository:

• https://twitter.com/arclight/status/1371913313211273216
• https://gitlab.com/apthorpe/stdlib-codata/-/blob/1c541b3a71556fd89cc6a9f03d401c757d182ceb/src/STDLIB_CODATA_2018.f90

Prior art:

• Scipy: https://docs.scipy.org/doc/scipy/reference/constants.html
• fundamental_constants: https://github.com/vmagnin/fundamental_constants
• QCElemental: https://github.com/MolSSI/QCElemental/blob/master/qcelemental/physical_constants/context.py

[awvwgk]

Related discourse thread: https://fortran-lang.discourse.group/t/physical-constants/822

[14NGiestas]

Sounds like a duplicate of #99, doesn't it? It's about physical "constants" and all but I think this discussion should be kept there.

[certik]

I view #99 as a limited to mathematical constants like pi, e and such. The CODATA are physical constants, so I think it might be slightly different.

[14NGiestas]

Scipy put math and physical constants in the same bag under scipy.constants that's why I bring that (not that we should follow scipy in every possible way but this seems to share the same design issues).

[MilanSkocic]

I would like to contribute to the stdlib. I worked for my own needs on a fpm package implementing Codata constants. Is this topic still relevant today?

[jvdp1]

I would like to contribute to the stdlib. I worked for my own needs on a fpm package implementing Codata constants. Is this topic still relevant today?

Thank you @MilanSkocic for willing to contribute to stdlib.

Implementing Codata constants would be welcome. At this stage I suggest that you open a PR with a first implementation for further discussion. An important item for discussion is how the constants should be provided (e.g., as parameters, or as derived types (see #99 for more some previous comments on this topic).

[MilanSkocic]

I have a working implementation of codata constants (values and uncertainties) as double precision reals. They are implemented as parameters. I'm also working on an implementation with derived types to carry together the values, uncertainties and units. I will try to open a PR by the end of the month.

[MilanSkocic]

@jvdp1 Currently, I have only implemented one precision for the codata constants i.e. real64. CODATA.

If different precisions are mandatory then I need to modify my source generator or write another one specifically for generating the module(s) for the standard library. In my package, I have implemented the values and uncertainties for the different release years , i.e 2018, 2014 2010), but I assume that the "old" values are not needed for standard library. What do you think?

Instead of generating modules (with fixed precision) for different years, I could generate modules with the latest values, i.e 2018, for different precisions. Something similar to what was suggested by @urbanjost in #99. Suffixes for indicating the precision might be problematic because the names are quite long.

I was thinking that implementing the uncertainties would be useful. In that case, it might be better to implement the codata constants as derived types. This way, the values, the uncertainties and the units would easily available.