DSL control structures¶
Pattern-action blocks¶
These are reminiscent of awk
syntax. They can be used to allow assignments to be done only when appropriate -- e.g. for math-function domain restrictions, regex-matching, and so on:
mlr cat data/put-gating-example-1.dkvp
x=-1 x=0 x=1 x=2 x=3
mlr put '$x > 0.0 { $y = log10($x); $z = sqrt($y) }' data/put-gating-example-1.dkvp
x=-1 x=0 x=1,y=0,z=0 x=2,y=0.3010299956639812,z=0.5486620049392715 x=3,y=0.4771212547196624,z=0.6907396432228734
mlr cat data/put-gating-example-2.dkvp
a=abc_123 a=some other name a=xyz_789
mlr put ' $a =~ "([a-z]+)_([0-9]+)" { $b = "left_\1"; $c = "right_\2" }' \ data/put-gating-example-2.dkvp
a=abc_123,b=left_abc,c=right_123 a=some other name a=xyz_789,b=left_xyz,c=right_789
This produces heteregenous output which Miller, of course, has no problems with (see Record Heterogeneity). But if you want homogeneous output, the curly braces can be replaced with a semicolon between the expression and the body statements. This causes put
to evaluate the boolean expression (along with any side effects, namely, regex-captures \1
, \2
, etc.) but doesn't use it as a criterion for whether subsequent assignments should be executed. Instead, subsequent assignments are done unconditionally:
mlr --opprint put ' $a =~ "([a-z]+)_([0-9]+)"; $b = "left_\1"; $c = "right_\2" ' data/put-gating-example-2.dkvp
a b c abc_123 left_abc right_123 some other name left_ right_ xyz_789 left_xyz right_789
Note that pattern-action blocks are just a syntactic variation of if-statements. The following do the same thing:
boolean_condition { body }
if (boolean_condition) { body }
If-statements¶
These are again reminiscent of awk
. Pattern-action blocks are a special case of if
with no elif
or else
blocks, no if
keyword, and parentheses optional around the boolean expression:
mlr put 'NR == 4 {$foo = "bar"}'
mlr put 'if (NR == 4) {$foo = "bar"}'
Compound statements use elif
(rather than elsif
or else if
):
mlr put ' if (NR == 2) { ... } elif (NR ==4) { ... } elif (NR ==6) { ... } else { ... } '
While and do-while loops¶
Miller's while
and do-while
are unsurprising in comparison to various languages, as are break
and continue
:
echo x=1,y=2 | mlr put ' while (NF < 10) { $[NF+1] = "" } $foo = "bar" '
x=1,y=2,3=,4=,5=,6=,7=,8=,9=,10=,foo=bar
echo x=1,y=2 | mlr put ' do { $[NF+1] = ""; if (NF == 5) { break } } while (NF < 10); $foo = "bar" '
x=1,y=2,3=,4=,5=,foo=bar
A break
or continue
within nested conditional blocks or if-statements will,
of course, propagate to the innermost loop enclosing them, if any. A break
or
continue
outside a loop is a syntax error that will be flagged as soon as the
expression is parsed, before any input records are ingested.
The existence of while
, do-while
, and for
loops in Miller's DSL means
that you can create infinite-loop scenarios inadvertently. In particular,
please recall that DSL statements are executed once if in begin
or end
blocks, and once per record otherwise. For example, while (NR < 10) will
never terminate. The NR
variable is only incremented
between records, and each DSL expression is invoked once per record: so, once
for NR=1
, once for NR=2
, etc.
If you do want to loop over records, see Operating on all records for some options.
For-loops¶
While Miller's while
and do-while
statements are much as in many other languages, for
loops are more idiosyncratic to Miller. They are loops over key-value pairs, whether in stream records, out-of-stream variables, local variables, or map-literals: more reminiscent of foreach
, as in (for example) PHP. There are for-loops over map keys and for-loops over key-value tuples. Additionally, Miller has a C-style triple-for loop with initialize, test, and update statements. Each is described below.
As with while
and do-while
, a break
or continue
within nested control structures will propagate to the innermost loop enclosing them, if any, and a break
or continue
outside a loop is a syntax error that will be flagged as soon as the expression is parsed, before any input records are ingested.
Single-variable for-loops¶
For maps, the single variable is always bound to the key of key-value pairs:
mlr --from data/small put -q ' print "NR = ".NR; for (e in $*) { print " key:", e, "value:", $[e]; } '
NR = 1 key: a value: pan key: b value: pan key: i value: 1 key: x value: 0.346791 key: y value: 0.726802 NR = 2 key: a value: eks key: b value: pan key: i value: 2 key: x value: 0.758679 key: y value: 0.522151 NR = 3 key: a value: wye key: b value: wye key: i value: 3 key: x value: 0.204603 key: y value: 0.338318 NR = 4 key: a value: eks key: b value: wye key: i value: 4 key: x value: 0.381399 key: y value: 0.134188 NR = 5 key: a value: wye key: b value: pan key: i value: 5 key: x value: 0.573288 key: y value: 0.863624
mlr -n put -q ' end { o = {"a":1, "b":{"c":3}}; for (e in o) { print "key:", e, "valuetype:", typeof(o[e]); } } '
key: a valuetype: int key: b valuetype: map
Note that the value corresponding to a given key may be gotten as through a computed field name using square brackets as in $[e]
for stream records, or by indexing the looped-over variable using square brackets.
For arrays, the single variable is always bound to the value (not the array index):
mlr -n put -q ' end { o = [10, "20", {}, "four", true]; for (e in o) { print "value:", e, "valuetype:", typeof(e); } } '
value: 10 valuetype: int value: 20 valuetype: string value: {} valuetype: map value: four valuetype: string value: true valuetype: bool
Key-value for-loops¶
For maps, the first loop variable is the key and the second is the value; for arrays, the first loop variable is the (1-up) array index and the second is the value.
Single-level keys may be gotten at using either for(k,v)
or for((k),v)
; multi-level keys may be gotten at using for((k1,k2,k3),v)
and so on. The v
variable will be bound to a scalar value (non-array/non-map) if the map stops at that level, or to a map-valued or array-valued variable if the map goes deeper. If the map isn't deep enough then the loop body won't be executed.
cat data/for-srec-example.tbl
label1 label2 f1 f2 f3 blue green 100 240 350 red green 120 11 195 yellow blue 140 0 240
mlr --pprint --from data/for-srec-example.tbl put ' $sum1 = $f1 + $f2 + $f3; $sum2 = 0; $sum3 = 0; for (key, value in $*) { if (key =~ "^f[0-9]+") { $sum2 += value; $sum3 += $[key]; } } '
label1 label2 f1 f2 f3 sum1 sum2 sum3 blue green 100 240 350 690 690 690 red green 120 11 195 326 326 326 yellow blue 140 0 240 380 380 380
mlr --from data/small --opprint put 'for (k,v in $*) { $[k."_type"] = typeof(v) }'
a b i x y a_type b_type i_type x_type y_type pan pan 1 0.346791 0.726802 string string int float float eks pan 2 0.758679 0.522151 string string int float float wye wye 3 0.204603 0.338318 string string int float float eks wye 4 0.381399 0.134188 string string int float float wye pan 5 0.573288 0.863624 string string int float float
Note that the value of the current field in the for-loop can be gotten either using the bound variable value
, or through a computed field name using square brackets as in $[key]
.
Important note: to avoid inconsistent looping behavior in case you're setting new fields (and/or unsetting existing ones) while looping over the record, Miller makes a copy of the record before the loop: loop variables are bound from the copy and all other reads/writes involve the record itself:
mlr --from data/small --opprint put ' $sum1 = 0; $sum2 = 0; for (k,v in $*) { if (is_numeric(v)) { $sum1 +=v; $sum2 += $[k]; } } '
a b i x y sum1 sum2 pan pan 1 0.346791 0.726802 2.073593 8.294372 eks pan 2 0.758679 0.522151 3.28083 13.12332 wye wye 3 0.204603 0.338318 3.542921 14.171684 eks wye 4 0.381399 0.134188 4.515587 18.062348 wye pan 5 0.573288 0.863624 6.4369119999999995 25.747647999999998
It can be confusing to modify the stream record while iterating over a copy of it, so instead you might find it simpler to use a local variable in the loop and only update the stream record after the loop:
mlr --from data/small --opprint put ' sum = 0; for (k,v in $*) { if (is_numeric(v)) { sum += $[k]; } } $sum = sum '
a b i x y sum pan pan 1 0.346791 0.726802 2.073593 eks pan 2 0.758679 0.522151 3.28083 wye wye 3 0.204603 0.338318 3.542921 eks wye 4 0.381399 0.134188 4.515587 wye pan 5 0.573288 0.863624 6.4369119999999995
You can also start iterating on sub-maps of an out-of-stream or local variable; you can loop over nested keys; you can loop over all out-of-stream variables. The bound variables are bound to a copy of the sub-map as it was before the loop started. The sub-map is specified by square-bracketed indices after in
, and additional deeper indices are bound to loop key-variables. The terminal values are bound to the loop value-variable whenever the keys are not too shallow. The value-variable may refer to a terminal (string, number) or it may be map-valued if the map goes deeper. Example indexing is as follows:
# Parentheses are optional for single key: for (k1, v in @a["b"]["c"]) { ... } for ((k1), v in @a["b"]["c"]) { ... } # Parentheses are required for multiple keys: for ((k1, k2), v in @a["b"]["c"]) { ... } # Loop over subhashmap of a variable for ((k1, k2, k3), v in @a["b"]["c"]) { ... } # Ditto for ((k1, k2, k3), v in @a { ... } # Loop over variable starting from basename for ((k1, k2, k3), v in @* { ... } # Loop over all variables (k1 is bound to basename)
That's confusing in the abstract, so a concrete example is in order. Suppose the out-of-stream variable @myvar
is populated as follows:
mlr -n put --jknquoteint -q ' begin { @myvar = { 1: 2, 3: { 4 : 5 }, 6: { 7: { 8: 9 } } } } end { dump } '
{ "myvar": { "1": 2, "3": { "4": 5 }, "6": { "7": { "8": 9 } } } }
Then we can get at various values as follows:
mlr -n put --jknquoteint -q ' begin { @myvar = { 1: 2, 3: { 4 : 5 }, 6: { 7: { 8: 9 } } } } end { for (k, v in @myvar) { print "key=" . k . ",valuetype=" . typeof(v); } } '
key=1,valuetype=int key=3,valuetype=map key=6,valuetype=map
mlr -n put --jknquoteint -q ' begin { @myvar = { 1: 2, 3: { 4 : 5 }, 6: { 7: { 8: 9 } } } } end { for ((k1, k2), v in @myvar) { print "key1=" . k1 . ",key2=" . k2 . ",valuetype=" . typeof(v); } } '
key1=3,key2=4,valuetype=int key1=6,key2=7,valuetype=map
mlr -n put --jknquoteint -q ' begin { @myvar = { 1: 2, 3: { 4 : 5 }, 6: { 7: { 8: 9 } } } } end { for ((k1, k2), v in @myvar[6]) { print "key1=" . k1 . ",key2=" . k2 . ",valuetype=" . typeof(v); } } '
key1=7,key2=8,valuetype=int
C-style triple-for loops¶
These are supported as follows:
mlr --from data/small --opprint put ' num suma = 0; for (a = 1; a <= NR; a += 1) { suma += a; } $suma = suma; '
a b i x y suma pan pan 1 0.346791 0.726802 1 eks pan 2 0.758679 0.522151 3 wye wye 3 0.204603 0.338318 6 eks wye 4 0.381399 0.134188 10 wye pan 5 0.573288 0.863624 15
mlr --from data/small --opprint put ' num suma = 0; num sumb = 0; for (num a = 1, num b = 1; a <= NR; a += 1, b *= 2) { suma += a; sumb += b; } $suma = suma; $sumb = sumb; '
a b i x y suma sumb pan pan 1 0.346791 0.726802 1 1 eks pan 2 0.758679 0.522151 3 3 wye wye 3 0.204603 0.338318 6 7 eks wye 4 0.381399 0.134188 10 15 wye pan 5 0.573288 0.863624 15 31
Notes:
-
In
for (start; continuation; update) { body }
, the start, continuation, and update statements may be empty, single statements, or multiple comma-separated statements. If the continuation is empty (e.g.for(i=1;;i+=1)
) it defaults to true. -
In particular, you may use
$
-variables and/or@
-variables in the start, continuation, and/or update steps (as well as the body, of course). -
The typedecls such as
int
ornum
are optional. If a typedecl is provided (for a local variable), it binds a variable scoped to the for-loop regardless of whether a same-name variable is present in outer scope. If a typedecl is not provided, then the variable is scoped to the for-loop if no same-name variable is present in outer scope, or if a same-name variable is present in outer scope then it is modified. -
Miller has no
++
or--
operators. -
As with all
for
/if
/while
statements in Miller, the curly braces are required even if the body is a single statement, or empty.
Begin/end blocks¶
Miller supports an awk
-like begin/end
syntax. The statements in the begin
block are executed before any input records are read; the statements in the end
block are executed after the last input record is read. (If you want to execute some statement at the start of each file, not at the start of the first file as with begin
, you might use a pattern/action block of the form FNR == 1 { ... }
.) All statements outside of begin
or end
are, of course, executed on every input record. Semicolons separate statements inside or outside of begin/end blocks; semicolons are required between begin/end block bodies and any subsequent statement. For example:
mlr put ' begin { @sum = 0 }; @x_sum += $x; end { emit @x_sum } ' ./data/small
a=pan,b=pan,i=1,x=0.346791,y=0.726802 a=eks,b=pan,i=2,x=0.758679,y=0.522151 a=wye,b=wye,i=3,x=0.204603,y=0.338318 a=eks,b=wye,i=4,x=0.381399,y=0.134188 a=wye,b=pan,i=5,x=0.573288,y=0.863624 x_sum=2.26476
Since uninitialized out-of-stream variables default to 0 for addition/subtraction and 1 for multiplication when they appear on expression right-hand sides (not quite as in awk
, where they'd default to 0 either way), the above can be written more succinctly as
mlr put ' @x_sum += $x; end { emit @x_sum } ' ./data/small
a=pan,b=pan,i=1,x=0.346791,y=0.726802 a=eks,b=pan,i=2,x=0.758679,y=0.522151 a=wye,b=wye,i=3,x=0.204603,y=0.338318 a=eks,b=wye,i=4,x=0.381399,y=0.134188 a=wye,b=pan,i=5,x=0.573288,y=0.863624 x_sum=2.26476
The put -q option suppresses printing of each output record, with only emit
statements being output. So to get only summary outputs, you could write
mlr put -q ' @x_sum += $x; end { emit @x_sum } ' ./data/small
x_sum=2.26476
We can do similarly with multiple out-of-stream variables:
mlr put -q ' @x_count += 1; @x_sum += $x; end { emit @x_count; emit @x_sum; } ' ./data/small
x_count=5 x_sum=2.26476
This is of course (see also here) not much different than
mlr stats1 -a count,sum -f x ./data/small
x_count=5,x_sum=2.26476
Note that it's a syntax error for begin/end blocks to refer to field names (beginning with $
), since begin/end blocks execute outside the context of input records.


S5P_L2_CH4
Variables
The table below lists the variables that are present in the HARP product that results from an ingestion of S5P_L2_CH4
data.
field name |
type |
dimensions |
unit |
description |
|---|---|---|---|---|
scan_subindex |
int16 |
{time} |
pixel index (0-based) within the scanline |
|
datetime_start |
double |
{time} |
[seconds since 2010-01-01] |
start time of the measurement |
datetime_length |
double |
[s] |
duration of the measurement |
|
orbit_index |
int32 |
absolute orbit number |
||
validity |
int32 |
{time} |
processing quality flag |
|
latitude |
float |
{time} |
[degree_north] |
latitude of the ground pixel center (WGS84) |
longitude |
float |
{time} |
[degree_east] |
longitude of the ground pixel center (WGS84) |
latitude_bounds |
float |
{time, 4} |
[degree_north] |
latitudes of the ground pixel corners (WGS84) |
longitude_bounds |
float |
{time, 4} |
[degree_east] |
longitudes of the ground pixel corners (WGS84) |
sensor_latitude |
float |
{time} |
[degree_north] |
latitude of the geodetic sub-satellite point (WGS84) |
sensor_longitude |
float |
{time} |
[degree_east] |
longitude of the goedetic sub-satellite point (WGS84) |
sensor_altitude |
float |
{time} |
[m] |
altitude of the satellite with respect to the geodetic sub-satellite point (WGS84) |
solar_zenith_angle |
float |
{time} |
[degree] |
zenith angle of the Sun at the ground pixel location (WGS84); angle measured away from the vertical |
solar_azimuth_angle |
float |
{time} |
[degree] |
azimuth angle of the Sun at the ground pixel location (WGS84); angle measured East-of-North |
sensor_zenith_angle |
float |
{time} |
[degree] |
zenith angle of the satellite at the ground pixel location (WGS84); angle measured away from the vertical |
sensor_azimuth_angle |
float |
{time} |
[degree] |
azimuth angle of the satellite at the ground pixel location (WGS84); angle measured East-of-North |
altitude_bounds |
float |
{time, vertical, 2} |
[m] |
altitude bounds per profile layer |
pressure_bounds |
float |
{time, vertical, 2} |
[Pa] |
pressure bounds per profile layer |
surface_altitude |
float |
{time} |
[m] |
surface altitude |
surface_altitude_uncertainty |
float |
{time} |
[m] |
surface altitude precision |
surface_pressure |
float |
{time} |
[Pa] |
surface pressure |
surface_meridional_wind_velocity |
float |
{time} |
[m/s] |
northward wind |
surface_zonal_wind_velocity |
float |
{time} |
[m/s] |
eastward wind |
CH4_column_volume_mixing_ratio_dry_air |
float |
{time} |
[ppbv] |
column averaged dry air mixing ratio of methane |
CH4_column_volume_mixing_ratio_dry_air_uncertainty |
float |
{time} |
[ppbv] |
uncertainty of the column averaged dry air mixing ratio of methane (1 sigma error) |
CH4_column_volume_mixing_ratio_dry_air_validity |
int8 |
{time} |
continuous quality descriptor, varying between 0 (no data) and 100 (full quality data) |
|
CH4_column_number_density_avk |
float |
{time, vertical} |
[] |
column averaging kernel for methane retrieval |
CH4_column_number_density_apriori |
float |
{time, vertical} |
[mol/m2] |
a-priori column number density profile of methane |
dry_air_column_number_density |
float |
{time, vertical} |
[mol/m2] |
column number density profile of dry air |
H2O_column_number_density |
float |
{time} |
[mol/m^2] |
H2O total column density |
H2O_column_number_density_uncertainty |
float |
{time} |
[mol/m^2] |
uncertainty of the H2O column density (standard error) |
cloud_fraction |
float |
{time} |
[] |
cloud fraction from VIIRS data in the SWIR channel for the instantaneous field of view |
aerosol_height |
float |
{time} |
[m] |
aerosol height parameter in the CH4 retrieval |
aerosol_optical_depth |
float |
{time} |
[] |
aerosol optical thicknesss in the SWIR band |
surface_albedo |
float |
{time} |
[] |
surface albedo in the SWIR channel |
surface_albedo_uncertainty |
float |
{time} |
[] |
precision of the surface albedo in the SWIR channel |
index |
int32 |
{time} |
zero-based index of the sample within the source product |
Ingestion options
The table below lists the available ingestion options for S5P_L2_CH4
products.
option name |
legal values |
description |
|---|---|---|
ch4 |
bias_corrected |
whether to ingest the ‘normal’ CH4 column vmr (default) or the bias corrected CH4 column vmr (ch4=bias_corrected) |
Mapping description
The table below details where and how each variable was retrieved from the input product.
field name |
mapping description |
|
|---|---|---|
scan_subindex |
description |
the scanline and pixel dimensions are collapsed into a temporal dimension; the index of the pixel within the scanline is computed as the index on the temporal dimension modulo the number of scanlines |
datetime_start |
path |
/PRODUCT/time, /PRODUCT/delta_time[] |
description |
time converted from milliseconds since a reference time (given as seconds since 2010-01-01) to seconds since 2010-01-01 (using 86400 seconds per day); the time associated with a scanline is repeated for each pixel in the scanline |
|
datetime_length |
path |
/@time_coverage_resolution |
description |
the measurement length is parsed assuming the ISO 8601 ‘PT%(interval_seconds)fS’ format |
|
orbit_index |
path |
/@orbit |
validity |
path |
/PRODUCT/SUPPORT_DATA/DETAILED_RESULTS/processing_quality_flags[] |
description |
the uint32 data is cast to int32 |
|
latitude |
path |
/PRODUCT/latitude[] |
longitude |
path |
/PRODUCT/longitude[] |
latitude_bounds |
path |
/PRODUCT/SUPPORT_DATA/GEOLOCATIONS/latitude_bounds[] |
longitude_bounds |
path |
/PRODUCT/SUPPORT_DATA/GEOLOCATIONS/longitude_bounds[] |
sensor_latitude |
path |
/PRODUCT/SUPPORT_DATA/GEOLOCATIONS/satellite_latitude[] |
description |
the satellite latitude associated with a scanline is repeated for each pixel in the scanline |
|
sensor_longitude |
path |
/PRODUCT/SUPPORT_DATA/GEOLOCATIONS/satellite_longitude[] |
description |
the satellite longitude associated with a scanline is repeated for each pixel in the scanline |
|
sensor_altitude |
path |
/PRODUCT/SUPPORT_DATA/GEOLOCATIONS/satellite_altitude[] |
description |
the satellite altitude associated with a scanline is repeated for each pixel in the scanline |
|
solar_zenith_angle |
path |
/PRODUCT/SUPPORT_DATA/GEOLOCATIONS/solar_zenith_angle[] |
solar_azimuth_angle |
path |
/PRODUCT/SUPPORT_DATA/GEOLOCATIONS/solar_azimuth_angle[] |
sensor_zenith_angle |
path |
/PRODUCT/SUPPORT_DATA/GEOLOCATIONS/viewing_zenith_angle[] |
sensor_azimuth_angle |
path |
/PRODUCT/SUPPORT_DATA/GEOLOCATIONS/viewing_azimuth_angle[] |
altitude_bounds |
condition |
processor version >= 01.00.00 |
path |
/PRODUCT/SUPPORT_DATA/INPUT_DATA/altitude_levels[] |
|
description |
derived from height per level (layer boundary) by repeating the inner levels; the upper bound of layer k is equal to the lower bound of layer k+1; the vertical grid is inverted to make it ascending |
|
condition |
processor version < 01.00.00 |
|
path |
/PRODUCT/SUPPORT_DATA/INPUT_DATA/height_levels[] |
|
description |
derived from height per level (layer boundary) by repeating the inner levels; the upper bound of layer k is equal to the lower bound of layer k+1; the vertical grid is inverted to make it ascending |
|
pressure_bounds |
path |
/PRODUCT/SUPPORT_DATA/INPUT_DATA/surface_pressure[],/PRODUCT/SUPPORT_DATA/INPUT_DATA/pressure_interval[] |
description |
derived from surface pressure and pressure difference between retrieval levels (the pressure grid is equidistant between the surface pressure and a fixed top pressure); given a zero-based layer index k, the pressure bounds for layer k are derived as: (surface_pressure - k * pressure_interval, surface_pressure - (k + 1) * pressure_interval); the vertical grid is inverted to make it ascending |
|
surface_altitude |
path |
/PRODUCT/SUPPORT_DATA/INPUT_DATA/surface_altitude[] |
surface_altitude_uncertainty |
path |
/PRODUCT/SUPPORT_DATA/INPUT_DATA/surface_altitude_precision[] |
surface_pressure |
path |
/PRODUCT/SUPPORT_DATA/INPUT_DATA/surface_pressure[] |
surface_meridional_wind_velocity |
available |
optional |
condition |
processor version >= 01.03.00 |
|
path |
/PRODUCT/SUPPORT_DATA/INPUT_DATA/northward_wind[] |
|
surface_zonal_wind_velocity |
available |
optional |
condition |
processor version >= 01.03.00 |
|
path |
/PRODUCT/SUPPORT_DATA/INPUT_DATA/eastward_wind[] |
|
CH4_column_volume_mixing_ratio_dry_air |
condition |
ch4 unset |
path |
/PRODUCT/methane_mixing_ratio[] |
|
condition |
ch4=bias_corrected |
|
path |
/PRODUCT/methane_mixing_ratio_bias_corrected[] |
|
CH4_column_volume_mixing_ratio_dry_air_uncertainty |
path |
/PRODUCT/methane_mixing_ratio_precision[] |
CH4_column_volume_mixing_ratio_dry_air_validity |
path |
/PRODUCT/qa_value |
CH4_column_number_density_avk |
path |
/PRODUCT/SUPPORT_DATA/DETAILED_RESULTS/column_averaging_kernel[] |
description |
the vertical grid is inverted to make it ascending |
|
CH4_column_number_density_apriori |
path |
/PRODUCT/SUPPORT_DATA/INPUT_DATA/methane_profile_apriori[] |
description |
the vertical grid is inverted to make it ascending |
|
dry_air_column_number_density |
path |
/PRODUCT/SUPPORT_DATA/INPUT_DATA/dry_air_subcolumns[] |
description |
the vertical grid is inverted to make it ascending |
|
H2O_column_number_density |
path |
/PRODUCT/SUPPORT_DATA/DETAILED_RESULTS/water_total_column[] |
H2O_column_number_density_uncertainty |
path |
/PRODUCT/SUPPORT_DATA/DETAILED_RESULTS/water_total_column_precision[] |
cloud_fraction |
path |
/PRODUCT/SUPPORT_DATA/INPUT_DATA/cloud_fraction_VIIRS_SWIR_IFOV[] |
aerosol_height |
condition |
processor version >= 01.00.00 |
path |
/PRODUCT/SUPPORT_DATA/DETAILED_RESULTS/aerosol_mid_altitude[] |
|
condition |
processor version < 01.00.00 |
|
path |
/PRODUCT/SUPPORT_DATA/DETAILED_RESULTS/aerosol_mid_height[] |
|
aerosol_optical_depth |
path |
/PRODUCT/SUPPORT_DATA/DETAILED_RESULTS/aerosol_optical_thickness_SWIR[] |
surface_albedo |
path |
/PRODUCT/SUPPORT_DATA/DETAILED_RESULTS/surface_albedo_SWIR[] |
surface_albedo_uncertainty |
path |
/PRODUCT/SUPPORT_DATA/DETAILED_RESULTS/surface_albedo_SWIR_precision[] |


The following data are not yet synced with CLASS Server.
Press "Start Sync Now" button to sync your data.
Make sure you have an active internet connection and do not turn off your computer till the operation completes.


PURPLE NOON (PLEIN SOLEIL) A film review by James Berardinelli Copyright 1996 James Berardinelli
RATING (0 TO 10): 8.5 Alternative Scale: ***1/2 out of ****
France, 1960 Re-release date: 7/3/96 (limited) Running Length: 2:05 MPAA Classification: PG-13 (Violence, mature themes) Theatrical Aspect Ratio: 1.66:1
Cast: Alain Delon, Marie Laforet, Maurice Ronet, Bill Kearns, Erno Crisa Director: Rene Clement Producers: Robert and Raymond Hakim Screenplay: Rene Clement and Paul Gegauff based on the novel THE TALENTED MR. RIPLEY by Patricia Highsmith Cinematography: Henri Decae Music: Nino Rota U.S. Distributor: Miramax Zoe In French with English subtitles
It's interesting to note that two of the best films I've seen theatrically in 1996 weren't made this year. In fact, they weren't even made this decade. The first, Martin Scorsese's classic, TAXI DRIVER, is celebrating its twentieth anniversary. The second, Rene Clement's PURPLE NOON, is now age thirty-six. Championed by Scorsese, this re- release was handled by Miramax Films, which has brought back to the screen one of the greatest suspense thrillers ever to be filmed.
PURPLE NOON is an autopsy of a near-perfect crime, and a compelling look at the man who commits it. Played by a twenty-something Alain Delon, Tom Ripley is, at first glance, an unlikely criminal. Apparently insecure, he spends his time bumming around Italy, trailing after playboy Phillippe Greenleaf (Maurice Ronet) and his beautiful fiancee, Marge (Marie Laforet). Tom has been commissioned by Phillippe's father to bring the wayward son back home to San Francisco. The fee for the job is $5000, but, once Tom becomes involved in Phillippe's life, its seductive leisure entices him away from his original goal -- or so it seems.
This is all really setup, because the meat of the story reveals that Tom is, in fact, an amoral killer, willing to do just about anything to get what he wants. And, while there's a prize for each crime, it's not the money that interests Tom. Rather, he enjoys toying with his victims and the police by seeing just how far he can go without being caught. His schemes become progressively more complex, involving switched identities, forged signatures, and more than one body. Tom is without remorse; the only emotion he displays is satisfaction at the success of his latest caper.
The plot, which is a wonderfully twisty affair filled with ingenious turns, is a delight to watch as it unfolds. On more than one occasion, Tom intentionally places himself in a precarious situation, and one fascination of PURPLE NOON is figuring out how he's going to extricate himself. Nothing about this movie is pedantic or predictable; it's two hours of pure suspense that puts many of the recent so-called "thrillers" to shame. It's a masterful effort by director Clement, and, considering the nature of the main character, it's not hard to understand why Scorsese would lend his name to the re-release (much as he did for BELLE DU JOUR).
One of PURPLE NOON's most obvious assets is Delon's acting. Tom is fascinating because Delon makes him so. This isn't a run-of-the-mill villain; he's a complex character with a well thought-out reason for everything he does. He may be a psychopath, but there's a quality about him that engrosses and seduces us even as his actions cause repulsion. And, because the movie centers on Tom, there are times when we find ourselves hoping that his schemes will work, if only for the pleasure of seeing what he will do next.
In addition to Delon's fine performance, PURPLE NOON is characterized by expert camerawork and crisp direction. Clement understands how to sustain tension without drawing it out too far. The film is exactly the right length, as are each of the individual scenes. Cinematographer Henri Decae has composed each of his shots carefully, including a masterful series of closeups of Delon's eyes that reveal the sinister intelligence behind the apparently-guileless exterior.
With TWISTERs and INDEPENDENCE DAYs packing theaters and grabbing headlines, it's easy to bemoan the current state of cinema. So far, 1996 has not been a particularly good year for movies. For evidence, consider that this, the most suspenseful entry of the year (to date), first hit screens over three decades ago. But, regardless of its history, PURPLE NOON is currently available, albeit only in selected venues (and probably not in those multiplexes where INDEPENDENCE DAY has captured four screens). There's nothing so engrossing as watching a truly intelligent thriller, and that makes this film a rare treat.
- James Berardinelli e-mail<EMAIL_ADDRESS>ReelViews web site: http://www.cybernex.net/~berardin
The review above was posted to the
rec.arts.movies.reviews newsgroup (de.rec.film.kritiken for German reviews).
The Internet Movie Database accepts no responsibility for the contents of the
review and has no editorial control. Unless stated otherwise, the copyright
belongs to the author.
Please direct comments/criticisms of the review to relevant newsgroups.
Broken URLs inthe reviews are the responsibility of the author.
The formatting of the review is likely to differ from the original due
to ASCII to HTML conversion.
Related links: index of all rec.arts.movies.reviews reviews


%include templates/parts/head.html
The Beta distribution is the distribution most often used as the distribution of probabilities.
beta pdf


Checkers Help
Buttons
Quit: will log you out of the entire game.
Help: will take you to this page
Continue: will allow you to continue the most recent game.
New Game: will allow you to create a new game. This game can be open for any one person to join or open to a
specific person.
The offical rules of US checkers are derived from World Checkers Draughts Federation
rules, found at http://www.usacheckers.com/downloads/WCDF_Revised_Rules.doc
Order
The first move in each game is made by the player with the Red disks. The subsequent moves are made in turns.
Moves
There are 4 types of moves: ordinary move of a normal piece, ordinary move of a king, the capturing move a a normal
piece, and the capture of a king.
Ordinary move of a normal piece
A normal piece moves diagonally left or right from one square to an immediately neighboring vacant square
When it reaches the farthest row forward or the opposite side of the board ("king-row" or "crown-head") it becomes
a king.
Ordinary move of a king
A king can move from one square diagonally forward or backward, left or right, to an immediately neighboring vacant
square.
Capture of a normal piece
A piece of the opposite color jumps over the piece and lands on the vacant square immediately beyond it. ("jump")
General Capturing
If a jump creates an immediate further captureing opportunity, then the current player can complete that jump until
all jumps are completed. The only exception is if the piece becomes a king then they may not make any further jumps
A play must complete all jumps that can be carried out until there are no more jumps available.
Capture of a king
Similar to that of a normal piece but can be made in any direction, forwards or backwards.
Illegal moves
No illegal moves will be allowed to be made in the game.


Backbone supplies structure to JavaScript-heavy applications by providing models with key-value binding and custom events, collections with a rich API of enumerable functions, views with declarative event handling, and connects it all to your existing application over a RESTful JSON interface.
Backbone-ES6 is a fork of Backbone 1.2.3 (https://github.com/jashkenas/backbone) converting and modularizing it into idiomatic ES6. The impetus for this fork is to experiment with modernizing and making Backbone easier to modify in a granular fashion. In particular the Parse JS SDK (http://www.parse.com) previously also was a fork of Backbone, but with the 1.6+ SDK release the Backbone API was unceremoniously removed. Backbone-ES6 provides the base for Backbone-Parse-ES6 (https://github.com/typhonjs/backbone-parse-es6) which provides a solution for Backbone dependent Parse users.
This repository contains several pre-packed downloads in the dist/
directory. There are AMD, CJS, and Global distributions. The "global-inclusive" bundle includes the latest jQuery and Underscore libraries.
Please view the wiki for build instructions and other pertinent info: https://github.com/typhonjs/backbone-es6/wiki
API documentation can be found in the docs/
directory and online here:
https://doc.esdoc.org/github.com/typhonjs/backbone-es6/'
For original Backbone Docs, License, Tests, pre-packed downloads, and everything else, really, see: http://backbonejs.org
To suggest a feature or report a bug: https://github.com/typhonjs/backbone-es6/issues
Many thanks to DocumentCloud & all Backbone contributors: https://github.com/jashkenas/backbone/graphs/contributors
Backbone (c) 2010-2015 Jeremy Ashkenas, DocumentCloud and Investigative Reporters & Editors
Backbone-ES6 (c) 2015 Michael Leahy, TyphonRT, Inc.
Backbone / Backbone-ES6 may be freely distributed under the MIT license.


@* * Copyright 2023 HM Revenue & Customs * * Licensed under the Apache License, Version 2.0 (the "License"); * you may not use this file except in compliance with the License. * You may obtain a copy of the License at * * http://www.apache.org/licenses/LICENSE-2.0 * * Unless required by applicable law or agreed to in writing, software * distributed under the License is distributed on an "AS IS" BASIS, * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. * See the License for the specific language governing permissions and * limitations under the License. *@ @import common.Dates @import models._ @import common.Dates.TemplateImplicits._ @this(layout: Layout) @(data: DateModel)(implicit request: Request[_], messages: Messages, lang: Lang) @layout( messages("nocgt.invaliddate.title") ){
@Messages("nocgt.content.one")
@Messages("nocgt.content.two") @Dates.constructDate(data.day, data.month, data.year).localFormat("d MMMM uuuu").


The LHC is a particle accelerator that pushes protons or ions to near the speed of light. It consists of a 27-kilometre ring of superconducting magnets with a number of accelerating structures that boost the energy of the particles along the way.
Every time protons collide, the results are slightly different. They vary so much in fact, that a reliable way to predict or calculate the result is currently not possible. Even though, we collide seemingly identical material (or equally recyclable material), the results of the collisions differ. Why? We don’t know yet.
The total CERN energy consumption is 1.3 TWh per year while the total electrical energy production in the world is around 20000 TWh, in the European Union 3400 TWh, in France around 500 TWh, and in Geneva canton 3 TWh.
Green Object Collider highlights the paradox of combining two materials. Two protons smashed together result in everything from Gamma Rays to Higgs Boson, while two plastic bottles can result in unicorns or a water fall... There's simply much more to learn about our world.


Drive
Vibha Singh is a corrupt bureaucrat in the Accounts Department of the Indian Government who pushes many of her clients into giving her "percentages" of their money which may either have been stolen or confiscated. With the support of her assistant Hamid, she continues to do so and keeps hiding the money in a basement of the Rashtrapati Bhavan which is only known to her, and resumes her lifestyle until she receives news from Kirit Ojha, the Honorary Secretary to the Prime Minister, that her help is needed critically by the Prime Minister for a certain task, and Ojha sends his man, Irfan to work with them and start an investigation from within their department to avoid being caught, as the investigation in question is against the notorious criminal King......
watch now