Physical constants

[milancurcic]

Welcome to the Discourse, Bob!

[arclight]

One other thing: this has been tested with gfortran 9 & 10 on Linux, Windows, and MacOS because those are relatively accessible. I’ve tried to stick with F2018 compliance but I don’t have access to commercial compilers (Intel, PGI, IBM, etc.). There is an issue with single precision support - several parameters overflow or underflow to nothing in REAL32; in those cases single precision constants aren’t provided. I haven’t tested on anything but x86_64 with gfortran so I’m curious how well the code compiles on other architectures and using different compilers.

[arclight]

Thanks again for posting a link to the code; hopefully I’ll be less of a hermit going forward

[vmagnin]

I have created a dev branch in my project:
https://github.com/vmagnin/fundamental_constants/tree/dev
where I have:

• renamed all the validated modules using the following model: CODATA_2018_constants.f90,
• moved them in the src directory,
• created CODATA_latest_constants.f90 simply using the latest available module (2018 at the moment).

I have tested that it could be imported by fpm as a dependency by putting into a fpm.toml file “depencies” section:

fundamental_constants = { git="https://github.com/vmagnin/fundamental_constants.git", branch="dev"}

Any comments welcome!

[msz59]

@ivanpribec

Sorry if my comment was unclear. I’ve created an example to clarify:

module constants

   implicit none
   public 

   !> The following constants have high potential for name clashes
   !  if the client of the module does "use constants" without the only clause
   real(wp), parameter :: h = 6.6260715e-34_wp ! J·s = kg·m²·s⁻¹
   ! [...]
  end type

  !> We only expose a single instance of the type, which is a prameter
  !  I suppose the call to the structure constructor is not needed.
  type(enum_codata), parameter :: codata = enum_codata()

The structure constructor is needed if the codata has parameter attribute.

[vmagnin]

The 2014 and 2010 URLs have changed on the NIST website. I have modified them in my project GitHub - vmagnin/fundamental_constants: Fortran modules with the CODATA fundamental physical constants, generated by a Python script.

The 2022 CODATA values should be made available in 2023:

The results of the 2022 CODATA-TGFC adjustment will be made available later in 2023 with the accepted input data and analysis published in a review article.

Fundamental Physical Constants - CODATA, The Committee on Data for Science...

[RonShepard]

@FortranFan

It seems to me thorough analysis is necessary as to what constitutes fundamental constants that are exact per scientific definition or reference condition. And allow for other constants that are related to such fundamental constants to be computed using documented and consistent floating-point precision.

This is a good point, but the definitions of the fundamental and derived constants can change over time. Before a decade ago, the speed of light was a measured quantity, now it is a defined constant. Similarly, a meter used to be a defined constant, then it became a derived quantity. Avagodro’s number used to be a measured value, now it is a defined integer. So if we use these values in our programs in an automatic way, it must be able to adapt to those changes in the future.

[RonShepard]

@arclight

One other thing: this has been tested with gfortran 9 & 10 on Linux, Windows, and MacOS because those are relatively accessible. I’ve tried to stick with F2018 compliance but I don’t have access to commercial compilers (Intel, PGI, IBM, etc.). There is an issue with single precision support - several parameters overflow or underflow to nothing in REAL32; in those cases single precision constants aren’t provided. I haven’t tested on anything but x86_64 with gfortran so I’m curious how well the code compiles on other architectures and using different compilers.

Good point. This is a question of units. A particular value might overflow or underflow in one set of units, say SI units, while it has a reasonable value O(1) in another set of units, say cgs units, or in my field of quantum chemistry, in what we call atomic units. Is there a good way to extract values from the module and do the unit conversions at the same time in order to avoid the over/under flow issue?