= Tentative feedback from previous meeting
Here's the feedback from previous meeting, email received on 2023/05/29
----
Comments for MPPE-MEA Datasets description at
http://bepi-colombo.irap.omp.eu/software/page=cdf
The following rules and convention are not finalized yet.
We would welcome any comments and suggestions from PI teams and
the project HQ.
=== Data file name convention
bc_mmo_mppe-mia_l2p_l_et-all_20210810_r00_v00_00.cdf
bc_mmo_mppe-mea1_l2_m_omni-flux-16e_r00_v00_00.cdf
bc_mmo_mgfo_l2p_l_spinfit_r00_v00_00.cdf
bc_mmo_mgfi_l2p_m_waveform-4hz_r00_v00_00.cdf
All in lower case.
The data rate in a file name is represented by a single
letter among "l", "m", or "h", rather than partially- or
fully-spelled ones such as low, mid, low-mode, ...
version number convention:
rAA_vBB_CC
rAA: the release number of a dataset
vBB: the major version number
CC : the minor version number
Question:
- What does the [unit] in a file name stand for?
"counts", "flux", and others?
=== MEA L2 datasets
I agree with you on the comment that use of both epoch_delta1
and epoch_delta2 may be a bit redundant.
How about using only two variables, "epoch" and "time_width"?
TI values (TI0 in Lv.1 data?) should be accommodated by
a data variable "mdp_ti" (all in lower case).
For particle data quantities, we plan to use either of the
following words:
- counts, dflux or flux, deflux or eflux
Particle data files should contain the following variables:
- dflux_energy (the central energy of energy bins)
- dflux_energyrange (optional: if having the upper/lower limits)
- dflux_angle (optional: for 2/3-D count/flux)
- dflux_qflag (optional: if adding quality flags in future)
"dflux" may be replaced with "counts", "flux", or others.
Comments for MPPE-MEA Datasets description at
http://bepi-colombo.irap.omp.eu/software/page=cdf
The following rules and convention are not finalized yet.
We would welcome any comments and suggestions from PI teams and
the project HQ.
----
== Some comments on feedback
=== Filename convention (Data rate)
We can agree to use the l,m,h character to specify the data rate, but:
We would prefer to use "-" than "_" character, as it can be used to separate logical part of filename pattern :
bc_mmo_<instrument>_<level>_<dataset>_<yyyymmdd>_<version>.cdf
We are thinking it's better to use "-" to seperate tokens inside <dataset>, <level>, <time-coverage> and <version> descriptors.
Moreover, some of our datasets should mix both Low, Medium or High rate data, and this descriptor will not be part of filename.
=== Version convention
We can agree to follow the convention (but here also we would prefer <release>-<major>-<minor> than "_" separator.
* The <release> number can be useful if we change the content of some CDF structure (addind, deleting some variable)
* The <major> number will indicate a new delivery (increasing from 0 or 1 to N)
* What will indicate the <minor> version number? We have never use such
=== Units
Will indicate the physical units of the data, in human readable string (like "km/s")
It can be also relied to another attribute, generally called "SI_CONVERSION", computer readable "1000>m.s^-1"
The latest is composed of a numerical factor, the ">" separator, and strings separated by "." indicating various SI units.
=== epoch, epoch_delta1, epoch_delta2
Generally, in most of the CDAweb CDF datasets, when data is time-tagged at the center of an interval,
epoch and half_interval are used.
The epoch variable has 2 attributes DELTA_PLUS_VAR = DELTA_MINUS_VAR = half_interval
We can of course change (except epoch that is mandatory), but half_interval is commonly used.
=== Name of main CDF variables
OK to use counts, dflux, flux, ...
=== Name of depending variables
There are used to desribe the various axis of a N-dimensions variable, corresponding to DEPEND_i attributes of the main variable (couns, dflux, ...)
So we do not see the need to prefix :
dflux_energy, dflux_energyrange...
We would prefer to use only energy, energy_range...
Note also that it's not easy to describe logarithmic energy tables with only central and energy range.
Each energy bins are differents and not arithmetically centered.
For polar or azimuthal angle bins, the center values and a delta_angle are enough.
=== TI values
OK to use "mdp_ti" variable name.
