Open MIredell opened 5 years ago
@Miredell, Do you have an example that is not just a unit conversion? My concern is that your example does not use any information from the PCD and just duplicates functionality that already exists in public libraries such as UDUNITS (https://www.unidata.ucar.edu/software/udunits/).
@gold2718 One example I had in mind is gravity as a quadratic function of height, which becomes particularly significant in the thermosphere where the height above surface is about a tenth of the Earth's radius.
@MIredell, that is a good example. Here is an alternative proposal for the syntax for that:
- name: acceleration_of_gravity_above_earth
formula: {geocentric_gravitational_constant} / (({height} + {mean_radius}) ** 2)
units: m s-2
parameter: height, m
prec: double
type: strict
uncertainty: exact
description: "
Acceleration of an object in a vacuum at an altitude
(height) above sea level.
"
A few thoughts and misgivings about this proposal:
g
at sea level (9.8202). There is no radius in the dictionary which results in the correct value of g
because the standard value takes into account the acceleration due to Earth's rotation. Perhaps there is some other standard formula used in thermosphere / ionosphere models?Here is what the polynomial version might look like:
- name: acceleration_of_gravity_above_earth
formula: {standard_acceleration_of_gravity} * (1.0 - (2.0 * {p}) + (3.0 * {p} * {p}))
units: m s-2
parameter: p = ({height} / {mean_radius}), 1
prec: double
type: strict
uncertainty: exact
description: "
Approximate acceleration of an object in a vacuum at an altitude
(height) above sea level.
"
Thoughts?
@gold2718 I like your alternative version better. However, now that I see concrete formulations, I worry this may be overly complexifying the constants dictionary. It raises the question of how the YAML file is going to be processed and in particular how the newly required input parameter from user code would be identified and accessed. Should the constants dictionary be left clean and language-independent as it is and standard formulas be left to a common code library instead?
@MIredell, I am also on the fence as to whether this extension best fits in the constants dictionary but think the issue should be open a while for more discussion before we decide.
As to the usability, I thought through the parsing and usage when I came up with my syntax. I am confident that this syntax is usable in that it could be used to generate conversion functions as part of the dictionary module. I also think we can specify a language-independent syntax for the formulas. For instance, the first formula could be rewritten:
formula: {geocentric_gravitational_constant} / (({height} + {mean_radius}) * ({height} + {mean_radius}))
or, we could specify that exponentiation needs special syntax which the code generator would understand:
formula: {geocentric_gravitational_constant} / pow({height} + {mean_radius}), 2)
The second syntax would also allow for language-independent use of special functions.
Maybe the constants can be extended to polynomial relationships at some later time. Here's a simple example (noting I'm a novice at YAML syntax).
name: degrees_Fahrenheit polynomial_argument_name: degrees_Celsius polynomial_argument_units: °C polynomial_order: 1 polynomial_coefficients:
(Perhaps polynomial_order is not needed if it can be deduced from the size of the polynomial_coefficients list.)