Personal info
Our application does not use a database, and does not store any persistent user data.
Children
Our application is not targeted towards Children, nor does it target them with any advertisement. However, it is suitable for use by children.
How we collect info
No Info is collected within Babel.
Tracking technologies
No tracking technologies are used in Babel.
How we use your info
No info is collected, so your data is not used in any way by Babel.
When we share your info
No personal information is shared by Babel.
How we store your info
No information is stored by Babel.
Where your info lives
No information is stored by Babel.
How long we keep your info
No information is stored by Babel.


{% extends "dashboard_z/www/templates/base.html" %} {% block title %} Dashboard {% endblock %} {% block content %}
Initially, the panel is a simple box, but you can optionally add a header and footer.
You can highlight panels using the following classes:
.panel-primary
.panel-secondary
.panel-default
.panel-success
.panel-info
.panel-warning
.panel-danger
.panel-light
.panel-dark
.panel-white


Fri Mar 31, 2017
About twenty years ago, when I was a student, I lived in an old apartment building on a busy main street. It wasn’t in a good neighbourhood. The dudes in the building across from us appeared to be drug dealers and would beg us for smokes every time we went on the balcony - even though we never had any damn smokes.
But the rent was cheap. I had a roommate, and each of us chipped in less than $300 a month.
That summer was the worst. The building was a rotting carcass that smelled sickening when the sun baked its cracked wooden siding. And even with the windows closed - which only made the smell worse - the noise from the traffic roaring by never ceased.
I had an early bedtime that summer because I was working at the Canadian Tire warehouse and had to wake up at 5 AM to make the bus on time.
But I didn’t get much sleep.
The sun doesn’t go down until late in the summer and I was too poor to buy proper curtains. I was also too poor to buy a proper bed, but a friend-of-a-friend who worked at 1-800-GOT-JUNK gave me a free mattress. I laid it straight down on the ratty carpet, and was almost immediately infested with bed bugs.
My feet hurt because my steel-toed boots were ill-fitting and rubbed my feet freshly raw every day. I hated walking in those boots, so much so that I accepted rides to the bus stop with this creepy dude at work. It turned out that he had an alternative agenda - one that involved cheating on his boyfriend. I had to endure him constantly printing updated versions of his DVD list and giving me copies during the car ride in an effort to entice me over to his place to “watch some movies”.
But even so, it was the traffic that kept me up at night. I’ve had an aversion to living on busy streets ever since. I have this theory that when everybody drive electric cars, the traffic noise will disappear. And that garbage real estate - homes next to highways - will become prime. But that hasn’t happened yet.
The only thing that kept me sane that summer was reading The Lord of the Rings trilogy for the first time. These days, the entry ticket for geekdom is cheap, but back then there were no LOTR movies to watch for a quick primer to Tolkien’s world. Those long books transported me away to a magical place at a time when I needed it most.
Eventually, that torturous summer was over. I abandoned my mattress in the building’s storage locker, quit Canadian Tire, tossed my shoes away, moved out, and went back to school.
I still drive by that building every day of my life. I just don’t see it.  Or maybe there’s some sort of mysterious psychic cloak that shields my cognizant mind from noticing it anymore.
These days, the neighbourhood has changed. A lot. You can’t buy a house on the busy street for under a million bucks, and the rent for a two-bedroom apartment would set you back a couple of thousand dollars a month. The drug-dealer scum has moved on across the bridge to some dark hole in Surrey probably and my kid’s newly-constructed school is just a few blocks away where a hospital used to be.
About twenty years ago, I came to Canada as an immigrant and it wasn’t good. I was twenty years old. I’m forty now, so that means I’ve lived an equal amount of time in both South Africa and Canada. That is quite the milestone.
My life is much better now and I’m so thankful for that. I have a career that I love and a beautiful family. It’s funny - even though I’ve had much better summers since that time so long ago, the dark rain-drenched days of a Vancouver winter don’t bother me at all. In fact, I adore them.
And if hell has one gigantic silver-lining it would be this: I may never have ended up married to my lovely wife if I hadn’t lived in that awful building.
Sure, my life isn’t all rainbows and sunshine. It’s still hard most of the time in one way or the other - the same as yours.  At least not today. Today, I’m grateful.


Basal insulin delivery
Background subcutaneous infusion of rapid acting insulin at pre-programmed variable rates over 24 hour periods
Bolus insulin delivery
used to prevent BGL rise with a meal and to correct hyperglycaemia under supplemental/correction dosing
Insulin: carbohydrate ratio [ICR]
- The insulin:carbohydrate ratio is the number of grams of carbohydrate covered by 1 unit of insulin (or the amount of insulin required to prevent the BG rise due to ingesting that amount of carbohydrate).
- For example, an ICR of 5 means 1 unit of insulin will cover 5 g of carbohydrate.
- Some patients with diabetes may instead use the number of units per standard 15g serve (exchange) of carbohydrate. For example, a patient may understand that they require 2 units of insulin per exchange (ie 2 units per 15g carbohydrate serve).
- Whilst an ‘exchange’ is usually standardised at 15g of carbohydrate, some patients may have been taught to have 10 g carbohydrate exchanges to facilitate calculations by the patient for insulin dosing at mealtimes.
- It is therefore important to question the patient to clarify the above definitions from their understanding.
Insulin sensitivity factor (ISF)
- Amount of blood glucose fall per unit of supplemental or correction dose of insulin.
- For example, ISF 2 means 1 unit of insulin is expected to reduce the blood glucose level by 2 mmol/L over the next 4-5 hours
Target BGL
- The BGL that the algorithm in pump will attempt to achieve. Target BGL and ISF will determine the amount of insulin given to correct a high blood glucose level
Insulin on board / Active Insulin time
- term varies with different brands of pump
- The assumed activity remaining of an administered insulin bolus. It is usually 3-4 hours.
Total daily dose
- Total amount of insulin administered over a 24 hour period.
- Consists of total basal dose and total bolus doses in this period. Ratio of basal to bolus is ideally close to 50:50 assuming an ‘average’ dietary carbohydrate intake.
Emergency insulin regimen
If the pump fails an ‘emergency’ dose should be given, consisting of the total basal dose given as long acting or intermediate insulin, as well pre-meal rapid acting insulin calculated from known carb ratio. If the total basal dose on the pump is not known, calculate the initial basal insulin dose as 0.2x weight (in Kg).


Task
An informational alert called "HUD Tutorial Page Alert" will be raised for this page once it has been passively scanned.
Keep an eye out for the Informational-Level Page Alerts tool on the left-hand side changing from a '0' to a '1'.
Once that has happened you can click on the tool to see a list of all of the Informational alerts.
A single type of alert can apply to many pages, or even to multiple elements within a page,
so each alert will have a list of URLs that it applies to.
Click on the alert name to see all of the instances, and then click on the URL to see the alert details.
The key that you need to supply is given in the alert description.


--- layout: default title: CTF 101 ---
Here you can get the materials for CTF101 workshops. These workshops are free to attend at SecTalks meetups
{{ post.date | date: site.date_format }}
{% if post.summary %} {{ post.summary }} {% endif %}


Textogram
Home
About Us
Contact Us
Hello there, this is a webApp where you can format your text as your wish.
Switch on the toggle, and click on Format. You will get your desired output.
If you want to perform some more operations on your text feel free to
contact
me.


Lossy Compression Experiment¶
This page explains the general dynamics of using the enb.icompression.LossyCompressionExperiment
class,
and how easily report results. This class is a subclass of enb.experiment.Experiment
.
An example is used, and line plots with enb.aanalysis.TwoColumnLineAnalyzer
are introduced.
Note that line plots can be used with lossless compression experiments as well.
Note
This example assumes you have understood the Basic workflow example, and that you have successfully followed the installation instructions in Installation.
Note
The compression_ratio_dr. bpppc and compression_time_seconds columns are automatically created by the LosslyCompressionExperiment class. You can extend this class with new columns, as described in the Basic workflow example.
Lossy: experiment setup¶
You can find the example at templates/lossless_compression_example. In Linux, you can clone the latest version with the following steps:
wget https://github.com/miguelinux314/experiment-notebook/archive/master.zip
unzip master.zip
cp -r experiment-notebook-master/templates/lossless_compression_example/ .
This example makes uses of the plugin_jpeg and pugin_mcalic plugins. You need to copy them to the same folder where you are running the experiment (.). The following code will do the trick:
cp -r experiment-notebook-master/enb/plugins{plugin_jpeg, plugin_mcalic} .
This completes the setup of the experiment
Lossy: data curation¶
Data has been previously curated for you, and placed in the data/ folder. It contains the landsat images from the CCSDS Data Compression working group.
The same requirements are needes as in Lossless Compression Experiment.
As usual, it is needed that:
Images are in RAW (uncompressed) format, preferably with ‘.raw’ extension, in BSQ in case more than one component is present.
Images contain a tag such as ‘u8be-3x600x800’ in their name.
u or s should be used for unsigned or signed data
8, 16 or 32 indicate the bitdepth in bits of each sample
the geometry part of the tag is ZxYxX, where X, Y and Z are, respectively, the images width, height and number of components (bands).
Images can be organized in subfolders. This is not mandatory, and it is not used in the current example.
Lossy: script execution¶
You just need to execute the following line:
./lossy_compression_experiment_example.py [-vv]
This should produce the plots`, analysis``folders. Furthermore, a `persistence_lossy_compression_experiment_example.py folder is created with persistence information, so that images do not need to be analyzed again, and that compression needs not be performed again unless you add any new codecs to your experiment.
Lossy: code¶
The example code in persistence_lossy_compression_experiment_example.py is documented and (hopefully) self-explanatory.
Lossy: initialization¶
The initialization is straightforward. Note how the plugin’s main module needs to be imported.
import os
from enb.config import get_options
options = get_options(from_main=False)
from enb import icompression
from enb import aanalysis
import plugin_jpeg.jpeg_codecs
import plugin_mcalic.mcalic_codecs
Lossy: setup¶
To maximize the quality of the output plots, some setup is needed to define the input data set and the families of codecs we want to use.
During the experiment setup, a list of enb.aanalysis.TaskFamily
instances are produced,
which are passed to the group_by argument.
A plain list of all codecs to be tested needs also be produced, as in the Lossless Compression Experiment.
Note
The codecs list here can contain any number of enb.icompression.LossyCodec
instances. See Defining new codecs for further information.
options.base_dataset_dir = os.path.join(os.path.dirname(os.path.abspath(__file__)), "data", "landsat")
all_codecs = []
all_families = []
# A family is a set of related tasks
jpeg_ls_family = enb.aanalysis.TaskFamily(label="JPEG-LS")
for c in (plugin_jpeg.jpeg_codecs.JPEG_LS(max_error=m) for m in range(7)):
all_codecs.append(c)
jpeg_ls_family.add_task(c.name, f"{c.label} PAE {m}")
all_families.append(jpeg_ls_family)
# One can add as many families as lines should be depicted
mcalic_family = enb.aanalysis.TaskFamily(label="M-CALIC")
for c in (plugin_mcalic.mcalic_codecs.MCALIC_Magli(max_error=m) for m in range(10)):
all_codecs.append(c)
mcalic_family.add_task(c.name, f"{c.label} PAE {m}")
all_families.append(mcalic_family)
# One can easily define pretty plot labels for all codecs individually, even when
# one or more parameter families are used
label_by_group_name = dict()
for family in all_families:
label_by_group_name.update(family.names_to_labels)
Lossy: experiment running¶
The lossless compression experiment can now be created, and used to generate a
pandas.DataFrame
instance with all defined columns.
Notice how show_h_range_bar and show_h_std_bar are employed to signal the range and +/- 1 std in the x axis. They can be used in the y axis by replacing h with v.
# Run experiment and produce figures
exp = enb.icompression.LossyCompressionExperiment(codecs=all_codecs)
df = exp.get_df()
Lossy: data analysis¶
One can perform automatic analysis of the dataframe with enb.aanalysis.ScalarDistributionAnalyzer
and enb.aanalysis.TwoColumnLineAnalyzer
, as well as other classes in that module.
enb.aanalysis.ScalarDistributionAnalyzer().analyze_df(
full_df=df,
target_columns=["bpppc", "pae", "compression_efficiency_2byte_entropy", "psnr_dr"],
output_csv_file="analysis.csv",
column_to_properties=exp.joined_column_to_properties,
group_by="task_name",
y_labels_by_group_name=label_by_group_name,
)
enb.aanalysis.TwoColumnLineAnalyzer().analyze_df(
full_df=df,
target_columns=[("bpppc", "pae"), ("bpppc", "psnr_dr")],
column_to_properties=exp.joined_column_to_properties,
show_markers=True,
show_h_range_bar=True,
show_h_std_bar=True,
group_by=all_families,
legend_column_count=2)
The promised line plot with error range
Another plot showing the histogram of efficiencies (based on 2-byte zero-order entropy) for the JPEG-LS and M-CALIC codecs is shown below as well:


Medicom
Denti-Care
Denti-Freeze
Topical Anesthetic Ointment
Bubblegum
1 oz / 29.6 ml
NDC 64778-0493-1
For rapid and long lasting topical anesthesia.
Directions: Apply 0.2 mL of ointment to the desired area using a cotton swab.
Active ingredients: Benzocaine 20.0% w/w
Caution: KEEP OUT OF REACH OF CHILDREN.
Store at room temperature.
Do not expose to excessive heat over 40 degrees C or 104 degrees F
Rx Only
Made in USA for:
A.R. Medicom Inc. Montreal, Canada H8T 3J8
Questions: 1-800-361-2862 or www.medicom.com
UPC<PHONE_NUMBER>26
Item 10049-BG


{% extends "base.html" %} {% load i18n %} {% block content %}
{% trans "Your password was successfully changed." %}


Daily Digest #20
- Stackshare Dev Tools Roundup #3: February 2018
- Standardized User Management With SCIM
- Futures of distributions
- Machine learning crash course
- TensorFlow 1.6.0 released
- How Developers got Password Security so Wrong – makes us thinking
- What devs need to know about Encoding / Encryption / Hashing / Salting / Stretching


| LB wrote: |
|---|
| At the end of compiling the program there are 2 functions, but if we removed x, y, and z, there would be 0 functions. |
But that wouldn't be a valid program according to the standard because it has no main function. (A library isn't a valid program until it's linked, statically or dynamically, with something that is. A library is basically a special case of object files.)
| In other words, you need to be able to take the address of it for it to be a function by my definition. |
Earlier you said that assembly labels aren't procedures, but you can take the address of them. In fact the assembler converts any label references to addresses (whether absolute or relative).
| Can you take the address of main? |
Probably not according to the standard, but almost certainly in practice, although the compiler might warn you, and the optimiser is free to remove any undefined behaviour without issuing a warning.
Your definition of a function doesn't really make sense though. "Something you can take the address of" includes literally any object in a C++ program, and in functional languages, "Something that is callable" is ambiguous, because code and data are considered equal yet you wouldn't really talk about "callable data". Also, on a non-Von Neumann computer, it's possible that functions don't have addresses in the same way variables do. The Harvard architecture, for example, explicitly separates code and data. I don't think any Harvard architecture computers are actually in use but the standard is written with them in mind - that's why it says casting a function pointer to uintptr_t is undefined (although POSIX defines it, so a POSIX-compliant compiler will not remove that behaviour).
The mathematical definition of a function is something like "something that maps values from one set [the domain] to another [the range]" but that doesn't really apply to languages that aren't functionally pure, since they don't have to return values, and they can modify global state.
Generally, for non-functional languages, a function is something that's callable, and for a purely functional one, it's something that maps values from its domain to its range. main is callable, just not by you, so I would say it's a function.


{% include head.html %}
{% include header.html %}The conference is online (web streamig) and in person at the University of Milano-Bicocca.
For general enquires please contact<EMAIL_ADDRESS>to sponsor the conference please contact sponsorships@cryptoassetlab.org.


| Jump to DART Documentation Main Index |
The MIT ocean GCM version 'checkpoint59a'
is the foundation of this directory. It was modified by Ibrahim Hoteit
of Scripps for his use, and so it differs from the original distribution.
Since the model is highly parallelized, it can be compiled with a
target number of processors in mind. From DART's perspective, the most
logical strategy is to run filter or
perfect_model_obs with async=4:
advance the model in parallel ... one ensemble member after another.
In this mode, the same set of processors are used for the data assimilation.
The performance of the parallel assimilation algorithm has been tested up
through 64 processors, and should scale well beyond that - but it remains to
be quantified. The scaling for the ocean model is unknown to me, but Ibrahim
routinely runs with many more than 64 processors.
As for all DART experiments, the overall design for an experiment is this:
the DART program filter will read the initial
conditions file, the observation sequence file, and the DART namelist
to decide whether or not to advance the ocean model. All of the
control of the execution of the ocean model is done by DART directly.
If the model needs to be advanced, filter makes
a call to the shell to execute the script
advance_model.csh.
advance_model.csh is ENTIRELY responsible
for getting all the input files, data files, namelists, etc. into
a temporary directory, running the model, and copying the results
back to the parent directory (which we call CENTRALDIR).
The whole process hinges on setting the ocean model namelist values
such that it is doing a cold start for every model advance.
The observations for the ocean model were the first observations of oceanic quantities, so there is an observations/forward_operators/obs_def_MITgcm_ocean_mod.f90 file containing the novel observation definitions like salinity, sea surface height, current components .... In keeping with the DART philosophy, there is a concept of inheritance between platform-specific observations like DRIFTER_U_CURRENT_COMPONENT and the general U_CURRENT_COMPONENT. Using the specific types when possible will allow flexibility specifying what kinds of observations to assimilate. create_ocean_obs is the program to create a DART observation sequence from a very particular ASCII file.
There are a set of support programs:
| trans_pv_sv.f90 | converts the ocean model snapshot files into a DART-compatible format |
| trans_sv_pv.f90 | converts the DART output into snapshot files to be used as ocean model input datasets (specified in data&PARM05); creates a new data namelist file (data.DART) containing the correct &PARM03;startTime,endTime values to advance the ocean model the expected amount; and creates a new data.cal namelist file (data.cal.DART) containing the calendar information. |
| create_ocean_obs.f90 | create observation sequence files |
The data assimilation period is controlled in the input.nml&model_nml namelist. In combination with the ocean model dynamics timestep data&PARM03:deltaTClock this determines the amount of time the model will advance for each assimilation cycle.
The MITgcm_ocean model cannot (as of Oct 2008) take one single model state
and generate its own ensemble (typically done with
pert_model_state). This means I don't really
know how to perform a 'perfect model' experiment until I find a way to
correctly perturb a single state to create an ensemble.
The ensemble has to come from 'somewhere else'. I ran the model forward
(outside the DART framework) for 14 days and output snapshot files ever 12 hours.
One state vector can be generated from a set of snapshot files using
trans_pv_sv.
I called this my 'initial ensemble' - it's better than nothing, but it is ENTIRELY
unknown if this creates an intial ensemble with sufficient spread. Just for
comparison, the initial ensemble for the atmospheric models is derived from
'climatological' values. If they need an 80-member ensemble for July 14, 2008;
they use the July 1 estimates of the atmosphere from 1900 to 1979. By the time
they assimilate (every 6 hours) for several days, things are on-track.
There is a shell_scripts/MakeInitialEnsemble.csh script
that was intended to automate this process - with modest success. It does
illustrate the steps needed to convert each snapshot file to a DART initial
conditions file and then run the
restart_file_utility
to overwrite the timestep in the header of the initial conditions file. After
you have created all the initial conditions files, you can simply 'cat' them
all together. Even if the script doesn't work out-of-the-box, it
should be readable enough to be some help.
The MITgcm_ocean model uses Fortran direct-access big-endian data files. It is up to you to determine the proper compiler flags to compile DART such that DART can read and write these files. Every compiler/architecture is different, but we have put notes in each mkmf.template if we know how to achieve this.
The assimilation period is specified by two namelist parameters
in the input.nml&model_nml namelist:
assimilation_period_days and
assimilation_period_seconds.
Normally, all observations within (+/-) HALF of the total assimilation
period are used in the assimilation.
The time of the initial conditions is specified by two namelist parameters
in the input.nml&model_nml namelist:
init_time_days and
init_time_seconds; depending on the settings of these
parameters, the times may or may not come directly from the DART initial
conditions files.
The ocean model MUST always start from the input datasets defined
in the data&PARM05 namelist.
Apparently, this requires
data&PARM03:startTime to be 0.0.
One of the DART support routines (trans_sv_pv)
converts the DART state vector to the files used in
data&PARM05 and creates new
data.cal&CAL_NML and
data&PARM03 namelists with
values appropriate to advance the model to the desired time.
The ocean model then
advances till data&PARM03:endTime
and writes out snapshot files. trans_pv_sv converts the
snapshot files to a DART-compatible file which is ingested by
filter. filter also reads
the observation sequence file to determine which observations are
within the assimilation window, assimilates them, and writes out a
set of restart files, one for each ensemble member.
filter then waits for each instance of the
ocean model (one instance for each ensemble member) to advance to
data&PARM03:endTime.
The whole process repeats
until 1) there are no more observations to assimilate (i.e. the
observation sequence file is exhausted) or 2) the time specified by
input.nml&filter_nml:last_obs_days,last_obs_seconds
has been reached.
I always like running something akin to a 'perfect model' experiment to start. Since I have not come up with a good way to perturb a single model state to generate an ensemble, here's the next best thing. Please keep in mind that the details for running each program are covered in their own documentation.
A perfectly sensible approach to get to know the system would be to try to
Is pretty much like any other model. The netCDF files have the model prognostic variables before and after the assimilation. There are Matlab® scripts for perusing the netCDF files in the DART/matlab directory. There are Matlab® scripts for exploring the performance of the assimilation in observation-space (after running obs_diag to explore the obs_seq.final file) - use the scripts starting with 'plot_', i.e. DART/diagnostics/matlab/plot_*.m. As always, there are some model-specific item you should know about in DART/models/MITgcm_ocean/matlab, and DART/models/MITgcm_ocean/shell_scripts.
types_mod time_manager_mod threed_sphere/location_mod utilities_mod obs_kind_mod mpi_utilities_mod random_seq_mod
Only a select number of interfaces used are discussed here.
| use location_mod, only : | location_type |
| get_location | |
| set_location |
The ocean model namelists data, and data.cal MUST be present. These namelists are needed to reconstruct the valid time of the snapshot files created by the ocean model. Be aware that as DART advances the model, the data namelist gets modified to reflect the current time of the model output.
| Required Interface Routines | |
| use model_mod, only : | get_model_size |
| adv_1step | |
| get_state_meta_data | |
| model_interpolate | |
| get_model_time_step | |
| static_init_model | |
| end_model | |
| init_time | |
| init_conditions | |
| nc_write_model_atts | |
| nc_write_model_vars | |
| pert_model_state | |
| get_close_maxdist_init | |
| get_close_obs_init | |
| get_close_obs | |
| ens_mean_for_model | |
| Unique Interface Routines | |
| use model_mod, only : | MIT_meta_type |
| read_meta | |
| write_meta | |
| prog_var_to_vector | |
| vector_to_prog_var | |
| read_snapshot | |
| write_snapshot | |
| get_gridsize | |
| snapshot_files_to_sv | |
| sv_to_snapshot_files | |
| timestep_to_DARTtime | |
| DARTtime_to_MITtime | |
| DARTtime_to_timestepindex | |
| write_data_namelistfile |
Ocean model namelist interfaces &PARM03, &PARM04, and &PARM04 are read from file data. Ocean model namelist interface &CAL_NML, is read from file data.cal.
A note about documentation style. Optional arguments are enclosed in brackets [like this].
integer :: get_model_size
Returns the length of the model state vector. Required.
| model_size | The length of the model state vector. |
real(r8), dimension(:), intent(inout) :: x type(time_type), intent(in) :: time
adv_1step is not used for the MITgcm_ocean model. Advancing the model is done through the advance_model script. This is a NULL_INTERFACE, provided only for compatibility with the DART requirements.
| x | State vector of length model_size. |
| time | Specifies time of the initial model state. |
integer, intent(in) :: index_in type(location_type), intent(out) :: location integer, optional, intent(out) :: var_type
get_state_meta_data returns metadata about a given element of the DART representation of the model state vector. Since the DART model state vector is a 1D array and the native model grid is multidimensional, get_state_meta_data returns information about the native model state vector representation. Things like the location, or the type of the variable (for instance: salinity, temperature, u current component, ...). The integer values used to indicate different variable types in var_type are themselves defined as public interfaces to model_mod if required.
| index_in | Index of state vector element about which information is requested. |
| location | Returns the 3D location of the indexed state variable. The location_ type comes from DART/location/threed_sphere/location_mod.f90. Note that the lat/lon are specified in degrees by the user but are converted to radians internally. |
| var_type | Returns the type of the indexed state variable as an optional argument. The type is one of the list of supported observation types, found in the block of code starting ! Integer definitions for DART TYPES in DART/assimilation_code/modules/observations/obs_kind_mod.f90 |
The list of supported variables in DART/assimilation_code/modules/observations/obs_kind_mod.f90 is created by preprocess using the entries in input.nml[&preprocess_nml, &obs_kind_nml], DEFAULT_obs_kin_mod.F90 and obs_def_MITgcm_ocean_mod.f90.
real(r8), dimension(:), intent(in) :: x type(location_type), intent(in) :: location integer, intent(in) :: itype real(r8), intent(out) :: obs_val integer, intent(out) :: istatus
Given a model state, model_interpolate returns the value of
the desired observation type (which could be a state variable) that would be
observed at the desired location. The interpolation method is either
completely specified by the model, or uses some standard 2D or 3D scalar
interpolation routines.
Put another way, model_interpolate will apply the forward
operator H to the model state to create an observation at the desired
location.
If the interpolation is valid, istatus = 0.
In the case where the observation operator is not defined at the given
location (e.g. the observation is below the lowest model level, above the top
level, or 'dry'), interp_val is returned as 0.0 and istatus = 1.
| x | A model state vector. |
| location | Location to which to interpolate. |
| itype | Not used. |
| obs_val | The interpolated value from the model. |
| istatus | Integer flag indicating the success of the interpolation.
success == 0, failure == anything else |
type(time_type) :: get_model_time_step
get_model_time_step returns the forecast length to be used as the "model base time step" in the filter. This is the minimum amount of time the model can be advanced by filter. This is also the assimilation window. All observations within (+/-) one half of the forecast length are used for the assimilation. In the MITgcm_ocean case, this is set from the namelist values for input.nml&model_nml:assimilation_period_days, assimilation_period_seconds, after ensuring the forecast length is a multiple of the ocean model dynamical timestep declared by data&PARM03:deltaTClock.
| var | Smallest time step of model. |
Please read the note concerning Controlling the model advances
static_init_model
is called for runtime initialization of the model.
The namelists are read to determine runtime configuration of the model, the calendar
information, the grid coordinates, etc. There are no input arguments and no return values.
The routine sets module-local private attributes that can then be queried by the
public interface routines.
The namelists (all mandatory) are:
input.nml&model_mod_nml,
data.cal&CAL_NML,
data&PARM03,
data&PARM04, and
data&PARM05.
end_model is used to clean up storage for the model, etc. when the model is no longer needed. There are no arguments and no return values. This is required by DART but nothing needs to be done for the MITgcm_ocean model.
type(time_type), intent(out) :: time
init_time returns the time at which the model will start if no input initial conditions are to be used. This is frequently used to spin-up models from rest, but is not meaningfully supported for the MITgcm_ocean model. The only time this routine would get called is if the input.nml&perfect_model_obs_nml:start_from_restart is .false., which is not supported in the MITgcm_ocean model.
| time | the starting time for the model if no initial conditions are to be supplied. As of Oct 2008, this is hardwired to 0.0 |
real(r8), dimension(:), intent(out) :: x
init_conditions returns default initial conditions for model; generally used for spinning up initial model states. For the MITgcm_ocean model it is just a stub because the initial state is always provided by the input files.
| x | Model state vector. [default is 0.0 for every element of the state vector] |
integer :: nc_write_model_atts integer, intent(in) :: ncFileID
nc_write_model_atts writes model-specific attributes to an opened netCDF file: In the MITgcm_ocean case, this includes information like the coordinate variables (the grid arrays: XG, XC, YG, YC, ZG, ZC, ...), information from some of the namelists, and either the 1D state vector or the prognostic variables (S,T,U,V,Eta). All the required information (except for the netCDF file identifier) is obtained from the scope of the model_mod module.
| ncFileID | Integer file descriptor to previously-opened netCDF file. |
| ierr | Returns a 0 for successful completion. |
nc_write_model_atts is responsible for the model-specific attributes in the following DART-output netCDF files: true_state.nc, preassim.nc, and analysis.nc.
integer :: nc_write_model_vars integer, intent(in) :: ncFileID real(r8), dimension(:), intent(in) :: statevec integer, intent(in) :: copyindex integer, intent(in) :: timeindex
nc_write_model_vars writes a copy of the state variables to a NetCDF file. Multiple copies of the state for a given time are supported, allowing, for instance, a single file to include multiple ensemble estimates of the state. Whether the state vector is parsed into prognostic variables (S,T,U,V,Eta) or simply written as a 1D array is controlled by input.nml&model_mod_nml:output_state_vector. If output_state_vector = .true. the state vector is written as a 1D array (the simplest case, but hard to explore with the diagnostics). If output_state_vector = .false. the state vector is parsed into prognostic variables before being written.
| ncFileID | file descriptor to previously-opened netCDF file. |
| statevec | A model state vector. |
| copyindex | Integer index of copy to be written. |
| timeindex | The timestep counter for the given state. |
| ierr | Returns 0 for normal completion. |
real(r8), dimension(:), intent(in) :: state real(r8), dimension(:), intent(out) :: pert_state logical, intent(out) :: interf_provided
Given a model state, pert_model_state produces a
perturbed model state. This is used to generate ensemble initial conditions
perturbed around some control trajectory state when one is preparing to
spin-up ensembles. Since the DART state vector for the MITgcm_ocean model
contains both 'wet' and 'dry' cells, (the 'dry' cells having a value of a
perfect 0.0 - not my choice) it is imperative to provide an interface to
perturb just the wet cells
(interf_provided == .true.).
At present (Oct 2008) the magnitude of the perturbation is wholly determined by
input.nml&model_mod_nml:model_perturbation_amplitude
and utterly, completely fails. The resulting model states
cause a fatal error when being read in by the ocean model - something like
*** ERROR *** S/R INI_THETA: theta = 0 identically. If this is intentional you will need to edit ini_theta.F to avoid this safety check
A more robust perturbation mechanism is needed (see, for example this routine in the CAM model_mod.f90). Until then, you can avoid using this routine by using your own ensemble of initial conditions. This is determined by setting input.nml&filter_nml:start_from_restart = .false. See also Generating the initial ensemble at the start of this document.
| state | State vector to be perturbed. |
| pert_state | The perturbed state vector. |
| interf_provided | Because of the 'wet/dry' issue discussed above, this is always .true., indicating a model-specific perturbation is available. |
type(get_close_type), intent(inout) :: gc real(r8), intent(in) :: maxdist
Pass-through to the 3-D sphere locations module. See get_close_maxdist_init() for the documentation of this subroutine.
type(get_close_type), intent(inout) :: gc integer, intent(in) :: num type(location_type), intent(in) :: obs(num)
Pass-through to the 3-D sphere locations module. See get_close_obs_init() for the documentation of this subroutine.
type(get_close_type), intent(in) :: gc type(location_type), intent(in) :: base_obs_loc integer, intent(in) :: base_obs_kind type(location_type), intent(in) :: obs(:) integer, intent(in) :: obs_kind(:) integer, intent(out) :: num_close integer, intent(out) :: close_ind(:) real(r8), optional, intent(out) :: dist(:)
Pass-through to the 3-D sphere locations module. See get_close_obs() for the documentation of this subroutine.
real(r8), dimension(:), intent(in) :: ens_mean
ens_mean_for_model saves a copy of the ensemble mean to module-local storage. Sometimes the ensemble mean is needed rather than individual copy estimates. This is a NULL_INTERFACE for the MITgcm_ocean model. At present there is no application which requires module-local storage of the ensemble mean. No storage is allocated.
| ens_mean | Ensemble mean state vector |
type MIT_meta_type private integer :: nDims integer :: dimList(3) character(len=32) :: dataprec integer :: reclen integer :: nrecords integer :: timeStepNumber end type MIT_meta_type
MIT_meta_type is a derived type used to codify the metadata associated with a snapshot file.
| Component | Description |
|---|---|
| nDims | the number of dimensions for the associated object. S,T,U,V all have nDims==3, Eta has nDims==2 |
| dimList | the extent of each of the dimensions |
| dataprec | a character string depicting the precision of the data storage. Commonly 'float32' |
| reclen | the record length needed to correctly read using Fortran direct-access. This is tricky business. Each vendor has their own units for record length. Sometimes it is bytes, sometimes words, sometimes ???. See comments in code for item_size_direct_access |
| nrecords | the number of records (either 2D or 3D hyperslabs) in the snapshot file |
| timeStepNumber | the timestep number ... the snapshot filenames are constructed using the timestepcount as the unique part of the filename. To determine the valid time of the snapshot, you must multiply the timeStepNumber by the amount of time in each timestep and add the start time. |
character(len=*), intent(in) :: fbase character(len=*), OPTIONAL, intent(in) :: vartype type(MIT_meta_type), intent(out) :: metadata
read_meta
reads the metadata file for a particular snapshot file. This routine is primarily
bulletproofing, since the snapshot files tend to move around a lot. I don't want
to use a snapshot file from a 70-level case in a 40-level experiment; and without
checking the metadata, you'd never know. The metadata for the file originally comes
from the namelist values specifying the grid resolution, etc. If the metadata file
exists, the metadata in the file is compared to the original specifications. If the
metadata file does not exist, no comparison is done.
The filename is fundamentally comprised of three parts. Take 'U.0000000024.meta' for
example. The first part of the name is the variable, the second part of the name is
the timestepnumber, the last part is the file extension. For various reasons, sometimes
it is convenient to call this function without the building the entire filename outside
the function and then passing it in as an argument. Since the '.meta' extension seems
to be fixed, we will only concern ourselves with building the 'base' part of the
filename, i.e., the first two parts.
| fbase | If vartype is supplied, this is simply the timestepnumber converted to a character string of length 10. For example, '0000000024'. If vartype is not supplied, it is the entire filename without the extension; 'U.0000000024', for example. |
| vartype | is an optional argument specifying the first part of the snapshot filename. Generally, 'S','T','U','V', or 'Eta'. |
| metadata | The return value of the function is the metadata for the file, packed into a user-derived variable type specifically designed for the purpose. |
metadata = read_meta('U.0000000024') ... or ... metadata = read_meta('0000000024','U')
type(MIT_meta_type), intent(in) :: metadata character(len=*), intent(in) :: filebase
write_meta writes a metadata file. This routine is called by routines write_2d_snapshot, and write_3d_snapshot to support converting the DART state vector to something the ocean model can ingest.
| metadata | The user-derived varible, filled with the metadata for the file. |
| filebase | the filename without the extension; 'U.0000000024', for example. (see the Description in read_meta) |
real(r4), dimension(:,:,:), intent(in) :: s,t,u,v real(r4), dimension(:,:), intent(in) :: eta real(r8), dimension(:), intent(out) :: x
prog_var_to_vector packs the prognostic variables [S,T,U,V,Eta] read from the snapshot files into a DART vector. The DART vector is simply a 1D vector that includes all the 'dry' cells as well as the 'wet' ones. This routine is not presently used (since we never have [S,T,U,V,Eta] as such in memory). See snapshot_files_to_sv.
| s,t,u,v | The 3D arrays read from the individual snapshot files. |
| eta | The 2D array read from its snapshot file. |
| x | the 1D array containing the concatenated s,t,u,v,eta variables. To save storage, it is possible to modify the definition of r8 in DART/common/types_mod.f90 to be the same as that of r4. |
real(r8), dimension(:), intent(in) :: x integer, intent(in) :: varindex real(r4), dimension(:,:,:), intent(out) :: hyperslab -or- real(r4), dimension(:,:), intent(out) :: hyperslab
vector_to_prog_var unpacks a prognostic variable [S,T,U,V,Eta] from the DART vector x.
| x | the 1D array containing the 1D DART state vector. |
| varindex | an integer code specifying which variable to unpack. The following parameters
are in module storage:
integer, parameter :: S_index = 1 integer, parameter :: T_index = 2 integer, parameter :: U_index = 3 integer, parameter :: V_index = 4 integer, parameter :: Eta_index = 5 |
| hyperslab | The N-D array containing the prognostic variable. The function is overloaded to be able to return both 2D and 3D arrays. |
call vector_to_prog_var(statevec,V_index,data_3d) - or - call vector_to_prog_var(statevec,Eta_index,data_2d)
character(len=*), intent(in) :: fbase real(r4), dimension(:,:,:), intent(out) :: x - or - real(r4), dimension(:,:), intent(out) :: x integer, intent(out) :: timestep character(len=*), optional, intent(in) :: vartype
read_snapshot reads a snapshot file and returns a hyperslab that includes all the 'dry' cells as well as the 'wet' ones. By design, the MITgcm_ocean model writes out Fortran direct-access big-endian binary files, independent of the platform. Since it is not guaranteed that the binary file we need to read is on the same architecture that created the file, getting the compiler settings in mkmf.template correct to read Fortran direct-access big-endian binary files is imperative to the process. Since each compiler issues its own error, there's no good way to even summarize the error messages you are likely to encounter by improperly reading the binary files. Read each template file for hints about the proper settings. See also the section Fortran direct-access big-endian datafiles in the "Discussion" of this document.
| fbase | The 'base' portion of the filename, i.e., without the [.meta, .data] extension. If vartype is supplied, vartype is prepended to fbase to create the 'base' portion of the filename. |
| x | The hyperslab containing what is read. The function is overloaded to be able to return a 2D or 3D array. x must be allocated before the call to read_snapshot. |
| timestep | the timestepcount in the 'fbase'.meta file, if the .meta file exists. Provided for bulletproofing. |
| vartype | The character string representing the 'prognostic variable' portion of the snapshot filename. Commonly 'S','T','U','V', or 'Eta'. If supplied, this is prepended to fbase to create the 'base' portion of the filename. |
real(r4), allocatable :: data_2d_array(:,:), data_3d_array(:,:,:) ... allocate(data_2d_array(Nx,Ny), data_3d_array(Nx,Ny,Nz)) ... call read_snapshot('S.0000000024', data_3d_array, timestepcount_out) call read_snapshot( '0000000024', data_2d_array, timestepcount_out, 'Eta') call read_snapshot( '0000000024', data_3d_array, timestepcount_out, 'T') ...
real(r4), dimension(:,:), intent(in) :: x - or - real(r4), dimension(:,:,:), intent(in) :: x character(len=*), intent(in) :: fbase integer, optional, intent(in) :: timestepcount
write_snapshot writes a hyperslab of data to a snapshot file and corresponding metadata file. This routine is an integral part of sv_to_snapshot_files, the routine that is responsible for unpacking the DART state vector and writing out a set of snapshot files used as input to the ocean model.
| x | The hyperslab containing the prognostic variable data to be written. The function is overloaded to be able to ingest a 2D or 3D array. |
| fbase | The 'base' portion of the filename, i.e., without the [.meta, .data] extension. |
| timestepcount | the timestepcount to be written into the 'fbase'.meta file. If none is supplied, timestepcount is 0. I'm not sure this is ever used, since the timestepcount can be gotten from fbase. |
integer, intent(out) :: num_x, num_y, num_z
get_gridsize returns the dimensions of the compute domain. The gridsize is determined from data&PARM04:delY,delX, and delZ when the namelist is read by static_init_model. The MITgcm_ocean model is interesting in that it has a staggered grid but all grid variables are declared the same length.
| num_x | The number of longitudinal gridpoints. |
| num_y | The number of latitudinal gridpoints. |
| num_z | The number of vertical gridpoints. |
integer, intent(in) :: timestepcount real(r8), intent(inout) :: state_vector
snapshot_files_to_sv reads the snapshot files for a given timestepcount and concatenates them into a DART-compliant 1D array. All the snapshot filenames are constructed given the timestepcount - read the 'Description' section of read_meta, particularly the second paragraph.
| timestepcount | The integer that corresponds to the middle portion of the snapshot filename. |
| state_vector | The 1D array of the DART state vector. |
The files are read in this order [S,T,U,V,Eta] (almost alphabetical!) and the multidimensional arrays are unwrapped with the leftmost index being the fastest-varying. You shouldn't need to know this, but it is critical to the way prog_var_to_vector and vector_to_prog_var navigate the array.
do k = 1, Nz ! depth do j = 1, Ny ! latitudes do i = 1, Nx ! longitudes state_vector(indx) = data_3d_array(i, j, k) indx = indx + 1 enddo enddo enddo
real(r8), intent(in) :: state_vector integer, intent(in) :: date1, date2
sv_to_snapshot_files takes the DART state vector and creates a set of snapshot files. The filenames of these snapshot files is different than that of snapshot files created by the ocean model. See the 'Notes' section for an explanation.
| state_vector | The DART 1D state vector. |
| date1 | The year/month/day of the valid time for the state vector, in YYYYMMDD format - an 8-digit integer. This is the same format as data.cal&CAL_NML:startDate_1 |
| date2 | The hour/min/sec of the valid time for the state vector, in HHMMSS format. This is the same format as data.cal&CAL_NML:startDate_2 |
Since the snapshot files have the potential to move around a lot, I thought it best to have a more descriptive name than simply the snapshot number. DART creates snapshot files with names like S.19960718.060000.data to let you know it is a snapshot file for 06Z 18 July 1996. This is intended to make it easier to create initial conditions files and, should the assimilation fail, inform as to _when_ the assimilation failed. Since DART needs the ocean model to coldstart (data&PARM02:startTime = 0.0) for every model advance, every snapshot file has the same timestamp. The advance_model.csh script actually has to rename the DART-written snapshot files to that declared by the data&PARM05 namelist, so the name is not really critical from that perspective. However, the components of the DART-derived snapshot files are used to create an appropriate data.cal&CAL_NML for each successive model advance.
integer, intent(in) :: TimeStepIndex type(time_type), intent(out) :: mytime
timestep_to_DARTtime combines the TimeStepIndex with the time per timestep (from data&PARM03) and the start date supplied by data.cal&CAL_NML to form a Gregorian calendar date which is then converted to a DART time object. As of Oct 2008, this model_mod is forced to use the Gregorian calendar.
| TimeStepIndex | an integer referring to the ocean model timestep ... the middle part of the ocean-model-flavor snapshot filename. |
| mytime | The DART representation of the time indicated by the TimeStepIndex |
The time per timestep is something I don't understand that well. The data&PARM03 namelist has three variables: deltaTmom, deltaTtracer, and deltaTClock. Since I don't know which one is relavent, and every case I looked at had them set to be the same, I decided to require that they all be identical and then it wouldn't matter which one I used. The values are checked when the namelist is read.
! Time stepping parameters are in PARM03 call find_namelist_in_file("data", "PARM03", iunit) read(iunit, nml = PARM03, iostat = io) call check_namelist_read(iunit, io, "PARM03") if ((deltaTmom == deltaTtracer) .and. & (deltaTmom == deltaTClock ) .and. & (deltaTClock == deltaTtracer)) then timestep = deltaTmom ! need a time_type version else write(msgstring,*)"namelist PARM03 has deltaTmom /= deltaTtracer /= deltaTClock" call error_handler(E_MSG,"static_init_model", msgstring, source, revision, revdate) write(msgstring,*)"values were ",deltaTmom, deltaTtracer, deltaTClock call error_handler(E_MSG,"static_init_model", msgstring, source, revision, revdate) write(msgstring,*)"At present, DART only supports equal values." call error_handler(E_ERR,"static_init_model", msgstring, source, revision, revdate) endif
type(time_type), intent(in) :: darttime integer, intent(out) :: date1, date2
DARTtime_to_MITtime converts the DART time to a pair of integers that are compatible with the format used in data.cal&CAL_NML
| darttime | The DART time to be converted. |
| date1 | The year/month/day component of the time in YYYYMMDD format - an 8-digit integer. This is the same format as data.cal&CAL_NML:startDate_1 |
| date2 | The hour/min/sec component of the time in HHMMSS format. This is the same format as data.cal&CAL_NML:startDate_2 |
type(time_type), intent(in) :: darttime integer, intent(out) :: timeindex
DARTtime_to_timestepindex converts the DART time to an integer representing the number of timesteps since the date in data.cal&CAL_NML, i.e., the start of the model run. The size of each timestep is determined as discussed in the timestep_to_DARTtime section.
| darttime | The DART time to be converted. |
| timeindex | The number of timesteps corresponding to the DARTtime ... |
There are no input arguments to
write_data_namelistfile.
write_data_namelistfile
reads the data namelist file and creates an
almost-identical copy named data.DART that differs
only in the namelist parameters that control the model advance.
(NOTE) advance_model.csh is designed to first run
trans_sv_pv to create appropriate
data.DART and
data.cal.DART files. The script
then renames them to that expected by the ocean model.
We adhere to the F90 standard of starting a namelist with an ampersand '&' and terminating with a slash '/' for all our namelist input. Consider yourself forewarned that character strings that contain a '/' must be enclosed in quotes to prevent them from prematurely terminating the namelist.
namelist /model_nml/ assimilation_period_days, & assimilation_period_seconds, output_state_vector, model_perturbation_amplitude
This namelist is read in a file called input.nml. This namelist provides control over the assimilation period for the model. All observations within (+/-) half of the assimilation period are assimilated. The assimilation period is the minimum amount of time the model can be advanced, and checks are performed to ensure that the assimilation window is a multiple of the ocean model dynamical timestep indicated by PARM03:deltaTClock.
| Contents | Type | Description |
|---|---|---|
| assimilation_period_days | integer [default: 7] | The number of days to advance the model for each assimilation. |
| assimilation_period_seconds | integer [default: 0] | In addition to assimilation_period_days, the number of seconds to advance the model for each assimilation. |
| output_state_vector | logical [default: .true.] | The switch to determine the form of the state vector in the output netcdf files. If .true. the state vector will be output exactly as DART uses it ... one long array. If .false., the state vector is parsed into prognostic variables and output that way -- much easier to use with 'ncview', for example. |
| model_perturbation_amplitude | real(r8) [default: 0.2] | The amount of noise to add when trying to perturb a single state vector to create an ensemble. Only needed when input.nml&filter_nml:start_from_restart = .false. See also Generating the initial ensemble at the start of this document. units: standard deviation of a gaussian distribution with the mean at the value of the state vector element. |
&model_nml assimilation_period_days = 1, assimilation_period_seconds = 0, model_perturbation_amplitude = 0.2, output_state_vector = .false. /
namelist /CAL_NML/ TheCalendar, startDate_1, startDate_2, calendarDumps
This namelist is read in a file called data.cal
This namelist is the same one that is used by the ocean model.
The values must correspond to the date at the
start of an experiment. This is more important for
create_ocean_obs, trans_pv_sv than
for filter and trans_sv_pv since
trans_sv_pv takes the start time of the experiment from the DART
initial conditions file and actually writes a new data.cal.DART and a new
data.DART file.
advance_model.csh renames
data.DART and
data.cal.DART to be used for the model advance.
Still, the files must exist before DART runs to avoid unnecessarily complex logic.
If you are running the support programs in a standalone fashion (as you might if
you are converting snapshot files into an intial ensemble), it is critical that
the values in this namelist are correct to have accurate times in the headers of
the restart files. You can always patch the times in the headers with
restart_file_utility.
namelist /PARM03/ startTime, endTime, deltaTmom, & deltaTtracer, deltaTClock, dumpFreq, taveFreq, ...
This namelist is read in a file called data.
This namelist is the same one that is used by the ocean model.
Only the variables listed here are used by the DART programs, there
are more variables that are used only by the ocean model.
There are two scenarios of interest for this namelist.
| Contents | Type | Description |
|---|---|---|
| startTime | real(r8) | This must be 0.0 to tell the ocean model to read from the input files named in data&PARM05. |
| endTime | real(r8) | The number of seconds for one model advance. (normally set by trans_sv_pv) |
| deltaTmom, deltaTtracer, deltaTClock | real(r8) | These are used when trying to interpret the timestepcount in the snapshot files. They must all be identical unless someone can tell me which one is used when the ocean model creates snapshot filenames. |
| dumpFreq, taveFreq | real(r8) | Set to the same value value as endTime. I have never run with different settings, my one concern would be how this affects a crappy piece of logic in advance_model.csh that requires there to be exactly ONE set of snapshot files - and that they correspond to the completed model advance. |
This namelist is the same one that is used by the ocean model. Only some of the namelist variables are needed by DART; the rest are ignored by DART but could be needed by the ocean model. Here is a fragment for a daily assimilation timestep with the model dynamics having a much shorter timestep.
&PARM03 startTime = 0., endTime = 86400., deltaTmom = 900., deltaTtracer = 900., deltaTClock = 900., dumpFreq = 86400., taveFreq = 86400., ...
This would result in snapshot files with names like [S,T,U,V,Eta].0000000096.data since 86400/900 = 96. These values remain fixed for the entire assimilation experiment, the only thing that changes from the ocean model's perspective is a new data.cal gets created for every new assimilation cycle. filter is responsible for starting and stopping the ocean model. The DART model state has a valid time associated with it, this information is used to create the new data.cal.
namelist /PARM04/ phiMin, thetaMin, delY, delX, delZ, ...
This namelist is read in a file called data. This namelist is the same one that is used by the ocean model. Only the variables listed here are used by the DART programs, there are more variables that are used only by the ocean model.
| Contents | Type | Description |
|---|---|---|
| phiMin | real(r8) | The latitude of the southmost grid edge. In degrees. |
| thetaMin | real(r8) | The longitude of the leftmost grid edge. In degrees. |
| delY | real(r8), dimension(1024) | The latitudinal distance between grid cell edges. In degrees. The array has a default value of 0.0. The number of non-zero entries determines the number of latitudes. static_init_model() converts the namelist values to grid centroids and edges. |
| delX | real(r8), dimension(1024) | The longitudinal distance between grid cell edges. In degrees. The array has a default value of 0.0. The number of non-zero entries determines the number of longitudes. static_init_model() converts the namelist values to grid centroids and edges. |
| delZ | real(r8), dimension(512) | The vertical distance between grid cell edges i.e., the thickness of the layer. In meters. The array has a default value of 0.0. The number of non-zero entries determines the number of depths. static_init_model() converts the namelist values to grid centroids and edges. |
This namelist is the same one that is used by the ocean model. Only some of the namelist variables are needed by DART; the rest are ignored by DART but could be needed by the ocean model. Here is a fragment for a (NY=225, NX=256, NZ=...) grid
&PARM04 phiMin = 8.4, thetaMin = 262.0, delY = 225*0.1, delX = 256*0.1, delZ = 5.0037, 5.5860, 6.2725, 7.0817, 8.0350, 9.1575, 10.4786, 12.0322, 13.8579, 16.0012, ...
Note that the 225*0.1 construct exploits the Fortran repeat mechanism to achieve 225 evenly-spaced gridpoints without having to manually enter 225 identical values. No such construct exists for the unevenly-spaced vertical layer thicknesses, so each layer thickness is explicitly entered.
namelist /PARM05/ bathyFile, hydrogSaltFile, hydrogThetaFile, & uVelInitFile, vVelInitFile, pSurfInitFile
This namelist is read in a file called data. The only DART component to use this namelist is the shell script responsible for advancing the model - advance_model.csh.
| Contents | Type | Description |
|---|---|---|
| bathyFile | character(len=*) | The Fortran direct-access big-endian binary file containing the bathymetry. |
| hydrogSaltFile | character(len=*) | The Fortran direct-access big-endian binary (snapshot) file containing the salinity. S.0000000096.data, for example. Units: psu |
| hydrogThetaFile | character(len=*) | The Fortran direct-access big-endian binary (snapshot) file containing the temperatures. T.0000000096.data, for example. Units: degrees C |
| uVelInitFile | character(len=*) | The Fortran direct-access big-endian binary (snapshot) file containing the U current velocities. U.0000000096.data, for example. Units: m/s |
| vVelInitFile | character(len=*) | The Fortran direct-access big-endian binary (snapshot) file containing the V current velocities. V.0000000096.data, for example. Units: m/s |
| pSurfInitFile | character(len=*) | The Fortran direct-access big-endian binary (snapshot) file containing the sea surface heights. Eta.0000000096.data, for example. Units: m |
This namelist specifies the input files to the ocean model. DART must create these input files. advance_model.csh has an ugly block of code that actually 'reads' this namelist and extracts the names of the input files expected by the ocean model. advance_model.csh then renames the snapshot files to be that expected by the ocean model. For this reason (and several others) a DART experiment occurrs in a separate directory we call CENTRALDIR, and each model advance happens in a run-time subdirectory. The data files copied to the run-time directory are deemed to be volatile, i.e., we can overwrite them and change them during the course of an experiment.
Please note that there are many more files needed to advance the ocean model, none of which are discussed here.
| Routine | Message | Comment |
|---|---|---|
| static_init_model | ... At present, DART only supports equal values. | namelist PARM03 has deltaTmom /= deltaTtracer /= deltaTClock |
| static_init_model | could not figure out number of longitudes from delX in namelist | Every entry in PARM04:delX is a perfect zero [the default value] ... indicating there are no longitudes. That can't be good. |
| static_init_model | could not figure out number of latitudes from delY in namelist | Every entry in PARM04:delY is a perfect zero [the default value] ... indicating there are no latitudes. |
| static_init_model | could not figure out number of depth levelss from delZ in namelist | Every entry in PARM04:delZ is a perfect zero [the default value] ... indicating there are no depth levels. |
| read_meta | unable to parse line <*> from <some_file> | unable to match character string 'nDims = [' in the snapshot metadata file. |
| read_meta | unable to determine nDims from <some_file> | snapshot metadata file has the string 'nDims = [' but the value cannot be understood. |
| read_meta | unable to read line <*> from <some_file> | no comment. |
| read_meta | unable to parse dimList(<*>) from <some_file> | snapshot metadata file has the string 'dimList = [' but the value cannot be understood. |
| read_meta | unable to determine dimList from <some_file> | snapshot metadata file has the string 'dimList = [' but the values are all nonsensical. |
| read_meta | unable to parse dataprec from <some_file> | snapshot metadata file has the string 'dataprec = [' but the value cannot be understood. |
| read_meta | unable to determine dataprec from <some_file> | snapshot metadata file has the string 'dataprec = [' but the values are all nonsensical. |
| read_meta | unable to parse nrecords from <some_file> | snapshot metadata file has the string 'nrecords = [' but the value cannot be understood. |
| read_meta | unable to determine nrecords from <some_file> | snapshot metadata file has the string 'nrecords = [' but the values are all nonsensical. |
| read_meta | unable to parse timeStepNumber from <some_file> | snapshot metadata file has the string 'timeStepNumber = [' but the value cannot be understood. |
| read_meta | unable to determine timeStepNumber from <some_file> | snapshot metadata file has the string 'timeStepNumber = [' but the values are all nonsensical. |
| write_meta | unable to open file <some_file> for writing | no comment. |
| read_Nd_snapshot | storage mode mismatch for <some_file> | DART is expecting a 32bit float in the snapshot file. This is tricky to check, since it is possible to redefine the r4 storage type (in common/types_mod.f90) to be a 64bit float, in which case you don't want to get a 32bit float. This check must be manually disabled by editing the logic in read_Nd_snapshot to handle the case where the snapshot file storage is 64bit. |
| read_Nd_snapshot | dim 1 does not match delX grid size from namelist ... | the snapshot file metadata does not match the number of longitudes inferred from PARM04:delX |
| read_Nd_snapshot | dim 2 does not match delY grid size from namelist ... | the snapshot file metadata does not match the number of latitudes inferred from PARM04:delY |
| read_Nd_snapshot | dim 3 does not match delZ grid size from namelist ... | the snapshot file metadata does not match the number of depths inferred from PARM04:delZ |
| read_Nd_snapshot | cannot open (<*>) <some_file> for reading | the (<*>) is the Fortran error code |
| read_Nd_snapshot | unable to read (<*>) snapshot file <some_file> | the (<*>) is the Fortran error code |
none at this time
I may put in a routine to change the PARM05 namelist parameters defining the input file names. The hack in advance_model.csh to grep out the filenames from the namelist and rename the files at the shell level is ugly.
N/A
DART software - Copyright UCAR. This open source software is provided by UCAR, "as is", without charge, subject to all terms of use at http://www.image.ucar.edu/DAReS/DART/DART_download


You can easily use it to monitor your local network interface or remote node in LAN.
Features
-
Export Information
- Local network interface information
- Local area network active node information
- Packets brief information
- support format(*.csv, *.json, *.txt)
- Capture package file save
- support format(*.pcap)
-
Analysis
- Nodes
- Local network interface
- Remote network inteface
- Info
- Brief table display packet
- Concise tabs display decode information
- Use ascii-table to format
- Nodes
-
Filter
- Berkeley Packet Filter (BPF) syntax
- refer: http://biot.com/capstats/bpf.html
-
Real time I/O packets and traffice
-
Search capture packets
- (,) Use commas to separate different protocols
- (.) Use period to neast protocols
-
Statistics figure
- traffic
- Input / Ouput packages
- Upload / Download flows
- Global statistics Input/output, Upload/Download
- protocol
- protocols address amount
- protocols packages amount
- protocols statistics
- length
- packets length
- TCP packets length
- UDP packets length
- traffic
-
Network relate tools
- Global IP information query
- Computer relate terms query
-
Status checks
- root privilege
- network status
- ip routing
- tcpdump
Flow chart
+-----------+
+--------------+ start |
| +-----+-----+
| |
| v
+-----v-----+ +------+------+ +------------+
| read pcap | | get locall +----->+ export |
| file | | network info| | local info |
+-----+-----+ +------+------+ +------------+
| |
| v
| +-----+------+ +------------+
| | scan +----->+ export |
| | network | | LAN info |
| +-----+------+ +------------+
| |
| v
| +-----+------+
| | (option) |
| | set filter |
| +-----+------+
| |
| v
| +-----+------+
| | start |
| | analysis |
| +-----+------+
| |
| v
| +------+------+
| | query IP |
| | query terms |
------------->+ Verbose info|
| search prots|
+------+------+
|
v
+------+------+ +------------+
| stop +-------> export |
| analysis | | packet info|
+------+------+ +------------+
|
v
+----------+ +------+-------+
| save <-----+ statistics |
| pacp file| | figure |
+-----+----+ +--------------+
|
v
+-----+----+
| finish |
+----------+


---
layout: post
title: Holy Cow! Novell and Microsoft
tags:
- Business
- Linux
status: publish
type: post
published: true
meta: {}
---
So Novell has into jumped into bed with Microsoft. This opens up a number of interesting questions:
- How will this affect RedHat? Consider also the announcement from Oracle earlier in the week
- What is the medium to long term cost for Novell? Often Microsoft's partners come off worse
- Is the safe harbour from MS patent litigation important for customers? Here in Australian it is not something that I see people talking about that much as an issue
- Will this improve Novell business? I am guessing that the answer is yes, they should be able to improve the service offering to cover more Windows under Xen
- Will Microsoft offer Linux implementation services from their consultants? I would guess the will just hand ball that straight to Novell -- stick to your knitting
- Will the interoperability between MS Office and Open Office mean better filters for Open Office or new filters for MS Office? I assume that MS Office must have new filters so that it can remain in government offices where ISO document formats are mandated
- What will the services management interoperability offer Microsoft? It should help Microsoft protect their turf with customers who must introduce Linux into an existing MS Infrastructure, and of course it will mean that customers will have to upgrade their current SMS installations.
powered by performancing firefox


Gets the currently opened AppId
Sets the currently opened AppId. Is set automatically by calling Navigation.openAppById
Gets the subfunctions for interacting with attributes in D365, for example getting or setting values
Gets the subfunctions for using ribbon buttons in D365
Gets the subfunctions for interacting with controls in D365, for example getting visibility or disable states
Gets the subfunctions for interacting with dialogs in D365, for example duplicate detection dialogs
Gets the subfunctions for interacting with the record in D365
Gets the subfunctions for interacting with forms in D365, for example opening different forms
Gets the subfunctions for navigating in D365
Gets the subfunctions for interacting with subgrids in D365, for example refreshing or opening specific records
Gets the subfunctions for interacting with tabs in D365, for example to open one
Gets the browser object that was generated when launching puppeteer
Gets the D365 base URL
Gets the page object that was generated when connecting to D365
Closes the puppeteer browser session
Function for launching a puppeteer instance
Started browser instance
Url of your D365 organization
Options for logging in. User name and password are required. If you have a custom authentication page, you should pass userNameFieldSelector if user name has to be reentered and passwordFieldSelector for password entry. These are css selectors for the inputs.
The page in which D365 was opened
Generated using TypeDoc
Main class for testing in D365


{% extends "accounts/base.html" %} {% block content %} Prez Akuffo Addo Akuffo Addo Gives SoNA today Read More John Mahama Classroom left for grasscutters and snakes - John Mahama Read More Corona Virus Corona enters Togo, leaves Ghanaians in panic Read More University Life We cover life on campuses, all the vibes Latest Shows Want to know what went down at latest show? Big News All the big news pass here first Social We do not leave out the social life, instagram, twitter,.etc Receive Daily News Before it gets published Apply now Short catchy info to make user click ABOUT NEWNOUS Take a tour You can get news from anywhere but the exclusive live here, provided as it happens, we are the news hub Entertainment Sports Social and Juicy gossips Something Special "No one tells it better than Nounews, if it's New then it's Nou" Dominic Damoah Jnr Manager at Sika "They[Nounews] make it entertaining and simply keep you glued" Kofi Appiah Lead Singer at Eden Acapella "I thought online news was nothing until I visited this site" Elikem Danku Manager at One Note Acapella Gh "Okay, no one beats this site at online news, no one, not even CNN" Josue Adimado Designer at PywE "Online news? Nounews" Kingsley Hemans Manager at OrangeLabs Latest News DESIGN Design Milk is a design blog featuring... Read Now SOCIAL Some of the world’s best designers share... Read Now THE TAILOR Elikem the tailor shares some interesting... Read Now {% endblock content %}
We cover life on campuses, all the vibes
Want to know what went down at latest show?
All the big news pass here first
We do not leave out the social life, instagram, twitter,.etc
Short catchy info to make user click
You can get news from anywhere but the exclusive live here,
provided as it happens, we are the news hub
Manager at Sika
Lead Singer at Eden Acapella
Manager at One Note Acapella Gh
Designer at PywE
Manager at OrangeLabs


See: Description
| Interface | Description |
|---|---|
| CsdlAnnotatable |
Super type of all annotatable CSDL items
|
| CsdlEdmProvider |
The interface Csdl edm provider.
|
| CsdlNamed |
The interface Csdl named.
|
| Class | Description |
|---|---|
| CsdlAbstractEdmItem |
Super type of all CsdlEdmItems
|
| CsdlAbstractEdmProvider |
Dummy implementation of
CsdlEdmProvider |
| CsdlAction |
Represents an action CSDL item
|
| CsdlActionImport |
Represents an action import CSDL item
|
| CsdlAliasInfo |
Represents an alias info CSDL item
|
| CsdlAnnotation |
Represents a CSDL annotation
|
| CsdlAnnotations |
The type Csdl annotations.
|
| CsdlBindingTarget |
The type Csdl binding target.
|
| CsdlComplexType |
The type Csdl complex type.
|
| CsdlEntityContainer |
The type Csdl entity container.
|
| CsdlEntityContainerInfo |
The type Csdl entity container info.
|
| CsdlEntitySet |
The type Csdl entity set.
|
| CsdlEntitySetPath |
The type Csdl entity set path.
|
| CsdlEntityType |
The type Csdl entity type.
|
| CsdlEnumMember |
The type Csdl enum member.
|
| CsdlEnumType |
The type Csdl enum type.
|
| CsdlFunction |
The type Csdl function.
|
| CsdlFunctionImport |
The type Csdl function import.
|
| CsdlMapping |
Content of this class does not appear within the CSDL metadata document.
|
| CsdlNavigationProperty |
The type Csdl navigation property.
|
| CsdlNavigationPropertyBinding |
The type Csdl navigation property binding.
|
| CsdlOnDelete |
The type Csdl on delete.
|
| CsdlOperation |
The type Csdl operation.
|
| CsdlOperationImport |
The type Csdl operation import.
|
| CsdlParameter |
The type Csdl parameter.
|
| CsdlProperty |
The type Csdl property.
|
| CsdlPropertyRef |
The type Csdl property ref.
|
| CsdlReferentialConstraint |
The type Csdl referential constraint.
|
| CsdlReturnType |
The type Csdl return type.
|
| CsdlSchema |
The type Csdl schema.
|
| CsdlSingleton |
The type Csdl singleton.
|
| CsdlStructuralType |
The type Csdl structural type.
|
| CsdlTerm |
The type Csdl term.
|
| CsdlTypeDefinition |
The type Csdl type definition.
|
| Enum | Description |
|---|---|
| CsdlOnDeleteAction |
The enum Csdl on delete action.
|
Copyright © 2013–2018 The Apache Software Foundation. All rights reserved.


See: Description
| Class | Description |
|---|---|
| AbstractBatchMetadataResolver |
Abstract subclass for metadata resolvers that process and resolve metadata at a given point
in time from a single metadata source document.
|
| AbstractDynamicHTTPMetadataResolver |
Abstract subclass for dynamic metadata resolvers that implement metadata resolution based on HTTP requests.
|
| AbstractDynamicMetadataResolver |
Abstract subclass for metadata resolvers that resolve metadata dynamically, as needed and on demand.
|
| AbstractDynamicMetadataResolver.DefaultCacheKeyGenerator |
Default function for generating a cache key for loading and saving an
EntityDescriptor
using a XMLObjectLoadSaveManager . |
| AbstractDynamicMetadataResolver.PersistentCacheInitializationMetrics |
Class used to track metrics related to the initialization from the persistent cache.
|
| AbstractMetadataResolver |
An abstract, base, implementation of a metadata provider.
|
| AbstractReloadingMetadataResolver |
Base class for metadata providers that cache and periodically refresh their metadata.
|
| BasicRoleDescriptorResolver | Deprecated |
| CompositeMetadataResolver |
A
MetadataResolver implementation that answers requests by composing the answers of child
MetadataResolver s. |
| CompositeMetadataResolver.CompositeMetadataResolverIterable | |
| DOMMetadataResolver |
A
MetadataProvider implementation that retrieves metadata from a DOM Element as
supplied by the user. |
| EntityIDDigestGenerator |
Strategy for processing input criteria to extract the entityID from an
EntityIdCriterion
and produce the digest of the value. |
| FileBackedHTTPMetadataResolver |
An HTTP metadata provider that caches a copy of the retrieved metadata to disk so that, in the event that
the metadata may not be pulled from the URL, it may be pulled from disk using the most recently fetched data.
|
| FilesystemMetadataResolver |
A metadata provider that pulls metadata from a file on the local filesystem.
|
| FunctionDrivenDynamicHTTPMetadataResolver |
Simple implementation of an HTTP-based dynamic metadata resolver which builds the request URL
to process based on a
Function instance. |
| HTTPEntityIDRequestURLBuilder |
Function which examines an entity ID and returns it as a metadata request URL if and only if the entity ID
is an HTTP or HTTPS URL.
|
| HTTPMetadataResolver |
A metadata provider that pulls metadata using an HTTP GET.
|
| IdentityEntityIDGenerator |
Function which just reflects back the entityID from the passed
EntityIdCriterion . |
| LocalDynamicMetadataResolver |
Resolver which dynamically resolves metadata from a local source managed by an instance
of
XMLObjectLoadSaveManager . |
| MetadataQueryProtocolRequestURLBuilder |
Function which produces a URL according to the Metadata Query Protocol specification.
|
| MetadataQueryProtocolSHA1Transformer |
Function which digests an entity ID using SHA-1 and returns it in the format specified by
the Metadata Query Protocol specification.
|
| PredicateRoleDescriptorResolver |
Implementation of
RoleDescriptorResolver which wraps an instance of MetadataResolver to
support basic EntityDescriptor resolution, and then performs further role-related filtering over the
returned EntityDescriptor. |
| RegexRequestURLBuilder |
Function which produces a URL by evaluating a supplied regular expression against the entity ID, and applying the
result to a supplied replacement string.
|
| ResourceBackedMetadataResolver |
A metadata provider that reads metadata from a {#link
Resource . |
| TemplateRequestURLBuilder |
Function which produces a URL by substituting a an entity ID value into a Velocity template string.
|
Copyright © 1999–2016 Shibboleth Consortium. All rights reserved.


{% include "schedule/components/base_head.html" %}
{% block head_title %}{% endblock %} | MuSoc Web
{% include "schedule/components/bootstrap_head.html" %}
{% block extra_head %}
{% endblock %}
{% include "schedule/components/topnav.html" %}
{% block body %}
{# Important: Authentication via OAuth based providers will not work until you setup proper applicaton credentials.#}
{% include "schedule/components/messages.html" %}
{% block content %}


library(sf)
11 Data Sets
11.1 Madrid AirBnb
This dataset contains a pre-processed set of properties advertised on the AirBnb website within the region of Madrid (Spain), together with house characteristics.
Availability
The dataset is stored on a Geopackage that can be found, within the structure of this project, under:
<- "data/assignment_1_madrid/madrid_abb.gpkg" path
<- st_read(path) db
Reading layer `madrid_abb' from data source
`/Users/franciscorowe/Dropbox/Francisco/uol/teaching/envs453/202223/san/data/assignment_1_madrid/madrid_abb.gpkg'
using driver `GPKG'
Simple feature collection with 18399 features and 16 fields
Geometry type: POINT
Dimension: XY
Bounding box: xmin: -3.86391 ymin: 40.33243 xmax: -3.556 ymax: 40.56274
Geodetic CRS: WGS 84
Variables
For each of the 17 properties, the following characteristics are available:
price
: [string] Price with currencyprice_usd
: [int] Price expressed in USDlog1pm_price_usd
: [float] Log of the priceaccommodates
: [integer] Number of people the property accommodatesbathrooms
: [integer] Number of bathroomsbedrooms
: [integer] Number of bedroomsbeds
: [integer] Number of bedsneighbourhood
: [string] Name of the neighbourhood the property is located inroom_type
: [string] Type of room offered (shared, private, entire home, hotel room)property_type
: [string] Type of property advertised (apartment, house, hut, etc.)WiFi
: [binary] Takes1
if the property has WiFi,0
otherwiseCoffee
: [binary] Takes1
if the property has a coffee maker,0
otherwiseGym
: [binary] Takes1
if the property has access to a gym,0
otherwiseParking
: [binary] Takes1
if the property offers parking,0
otherwisekm_to_retiro
: [float] Euclidean distance from the property to the El Retiro parkgeom
: [geometry] Point geometry
Projection
The location of each property is stored as point geometries and expressed in longitude and latitude coordinates:
st_crs(db)
Coordinate Reference System:
User input: WGS 84
wkt:
GEOGCRS["WGS 84",
ENSEMBLE["World Geodetic System 1984 ensemble",
MEMBER["World Geodetic System 1984 (Transit)"],
MEMBER["World Geodetic System 1984 (G730)"],
MEMBER["World Geodetic System 1984 (G873)"],
MEMBER["World Geodetic System 1984 (G1150)"],
MEMBER["World Geodetic System 1984 (G1674)"],
MEMBER["World Geodetic System 1984 (G1762)"],
MEMBER["World Geodetic System 1984 (G2139)"],
ELLIPSOID["WGS 84",6378137,298.257223563,
LENGTHUNIT["metre",1]],
ENSEMBLEACCURACY[2.0]],
PRIMEM["Greenwich",0,
ANGLEUNIT["degree",0.0174532925199433]],
CS[ellipsoidal,2],
AXIS["geodetic latitude (Lat)",north,
ORDER[1],
ANGLEUNIT["degree",0.0174532925199433]],
AXIS["geodetic longitude (Lon)",east,
ORDER[2],
ANGLEUNIT["degree",0.0174532925199433]],
USAGE[
SCOPE["Horizontal component of 3D system."],
AREA["World."],
BBOX[-90,-180,90,180]],
ID["EPSG",4326]]
Source & Pre-processing
The data are sourced from Inside Airbnb. A Jupyter notebook in Python (available at data/assignment_1_madrid/clean_data.ipynb
) details the process from the original file available from source to the data in madrid_abb.gpkg
.
11.2 England COVID-19
This dataset contains:
daily COVID-19 confirmed cases from 1st January, 2020 to 2nd February, 2021 from the GOV.UK dashboard;
resident population characteristics from the 2011 census, available from the Office of National Statistics; and,
2019 Index of Multiple Deprivation (IMD) data from GOV.UK and published by the Ministry of Housing, Communities & Local Government.
The data are at the Upper Tier Local Authority District (UTLAD) level - also known as Counties and Unitary Authorities.
Availability
The dataset is stored on a Geopackage:
<- st_read("data/assignment_2_covid/covid19_eng.gpkg") sdf
Reading layer `covid19_eng' from data source
`/Users/franciscorowe/Dropbox/Francisco/uol/teaching/envs453/202223/san/data/assignment_2_covid/covid19_eng.gpkg'
using driver `GPKG'
Simple feature collection with 149 features and 507 fields
Geometry type: MULTIPOLYGON
Dimension: XY
Bounding box: xmin: 134112.4 ymin: 11429.67 xmax: 655653.8 ymax: 657536
Projected CRS: OSGB36 / British National Grid
Variables
The data set contains 508 variables:
objectid
: [integer] unit identifierctyua19cd
: [integer] Upper Tier Local Authority District (or Counties and Unitary Authorities) identifierctyua19nm
: [character] Upper Tier Local Authority District (or Counties and Unitary Authorities) nameRegion
: [character] Region namelong
: [numeric] longitudelat
: [numeric] latitudest_areasha
: [numeric] area in hectareX2020.01.31
toX2021.02.05
: [numeric] Daily COVID-19 cases from 31st January, 2020 to 5th February, 2021IMD...Average.score
-IMD.2019...Local.concentration
: [numeric] IMD indicators - for details see File 11: upper-tier local authority summaries.Residents
: [numeric] Total resident populationHouseholds
: [numeric] Total householdsDwellings
: [numeric] Total dwellingsHousehold_Spaces
: [numeric] Total household spacesAged_16plus
toOther_industry
: [numeric] comprise 114 variables relating to various population and household attributes of the resident population. A description of all these variables can be found heregeom
: [geometry] Point geometry
Projection
Details of the coordinate reference system:
st_crs(sdf)
Coordinate Reference System:
User input: OSGB36 / British National Grid
wkt:
PROJCRS["OSGB36 / British National Grid",
BASEGEOGCRS["OSGB36",
DATUM["Ordnance Survey of Great Britain 1936",
ELLIPSOID["Airy 1830",6377563.396,299.3249646,
LENGTHUNIT["metre",1]]],
PRIMEM["Greenwich",0,
ANGLEUNIT["degree",0.0174532925199433]],
ID["EPSG",4277]],
CONVERSION["British National Grid",
METHOD["Transverse Mercator",
ID["EPSG",9807]],
PARAMETER["Latitude of natural origin",49,
ANGLEUNIT["degree",0.0174532925199433],
ID["EPSG",8801]],
PARAMETER["Longitude of natural origin",-2,
ANGLEUNIT["degree",0.0174532925199433],
ID["EPSG",8802]],
PARAMETER["Scale factor at natural origin",0.9996012717,
SCALEUNIT["unity",1],
ID["EPSG",8805]],
PARAMETER["False easting",400000,
LENGTHUNIT["metre",1],
ID["EPSG",8806]],
PARAMETER["False northing",-100000,
LENGTHUNIT["metre",1],
ID["EPSG",8807]]],
CS[Cartesian,2],
AXIS["(E)",east,
ORDER[1],
LENGTHUNIT["metre",1]],
AXIS["(N)",north,
ORDER[2],
LENGTHUNIT["metre",1]],
USAGE[
SCOPE["Engineering survey, topographic mapping."],
AREA["United Kingdom (UK) - offshore to boundary of UKCS within 49°45'N to 61°N and 9°W to 2°E; onshore Great Britain (England, Wales and Scotland). Isle of Man onshore."],
BBOX[49.75,-9,61.01,2.01]],
ID["EPSG",27700]]


Dear {{ person.first_name }}
A new organisation called {{ pending_org.name }} with abn {{ pending_org.abn }} is pending approval. You can view this approval by logging in here


Seamlessly integrated with the component library, designers can quickly create new styles using Sketch files and powerful Sass documents to share with the rest of the organization.
From simple typography components to complex navigation and media components, KORA is the perfect starting line for any website. Need a quick microsite? KORA is all you need.
This IDE application allows non-developers to quickly spin up local instances of AEM, modify UI style, add content and prototype all within AEM itself. Run a package export and hand off to developers when the time is right.
With KORA’s shared design system, designers understand and control every detail of the component library. Rapid wireframe and prototype based on existing components. Grow and expand the library by adding new components that meet the needs of your business.
Dialog boxes are no longer an afterthought. With consistent UI patterns, naming conventions and easy to use functionality, KORA puts the author first. In a content heavy world, authors are needed now more than ever.
At some point, all AEM developers have wished for a group of basic authoring components they didn’t have to build themselves. With KORA, work only on components that drive the business by expanding the library to include the needs for your business.
The job of KORA is to provide the essential tools of any AEM website. Easily understand where KORA ends and new development begins. Respond quickly to business needs by iterating, launching or testing new websites.
Design for the product not the CMS - With KORA’s shared design system, designers understand and control every detail of the component library. Rapid wireframe and prototype based on existing components. Grow and expand the library by adding new components that meet the needs of your business.
Spend time developing what matters - At some point, all AEM developers have wished for a group of basic authoring components they didn’t have to build themselves. With KORA, work only on components that drive the business by expanding the library to include the needs for your business.
A unified, dedicated UX - Dialog boxes are no longer an afterthought. With consistent UI patterns, naming conventions and easy to use functionality, KORA puts the author first. In a content heavy world, authors are needed now more than ever.
Know your product - The job of KORA is to provide the essential tools of any AEM website. Easily understand where KORA ends and new development begins. Respond quickly to business needs by iterating, launching or testing new websites.
The strategy behind KORA is to breakdown interfaces seen on every website and deliver a baseline set of components that are useful to everyone who uses AEM. This means that KORA can represent 100% of the component makeup for a basic website or landing page, requiring little to nothing from your developers. For e-commerce or application-driven websites, starting with KORA places your team well ahead of the curve.
Stop waiting for the handoff. With KORA, each team member can start at the same time. KORA Launch introduces the ability for authors and designers to easily and quickly set up local instances of new AEM websites to begin working; therefore, dramatically decreasing the overall timeline for your project.
KORA is designed to be used an unlimited number of times with unlimited styles. This is especially effective for large, multi-brand organizations that need consistent user/author experience with specific brand requirements. Easily create a microsite army, launch event pages, release landing pages; all in response to this demanding, ever changing market.


--- tags: - avalanche - geoscience - snow author: display_name: JP email<EMAIL_ADDRESS>date: 2011-11-18 16:09:38 -0700 categories: [] Avalanche: hub: name: Utah Avalanche Paths item_id: 0df199cef1704e5287ae675ee3dbd3bd updates: - 2009 --- {% include abstract.html name="Avalanche Paths" stewards="UGRC" abstract="This dataset represents snow avalanche paths in the tri-canyon area of the Wasatch Front, Utah. This dataset contains the name, size of slidepath, return interval, starting zone elevation, vertical fall and starting zone aspect for some of the avalanches. This data was prepared for the Salt Lake County Wasatch Canyons Master Plan originally published in September 1989." %}
{% include contact.html subject=page.title contact=site.data.contacts.agrc %}


Configuring Checks
In SITE_NAME, a Check represents a single service you want to
monitor. For example, when monitoring cron jobs, you would create a separate check for
each cron job to be monitored. SITE_NAME pricing plans are structured primarily
around how many checks you can have in your account. You can create checks
either in SITE_NAME web interface or by calling API.
Name, Tags, Description
Describe each check using optional name, tags and description fields.
- Name: names are optional, but it is a good idea to set them.
Good naming becomes especially important as you add more checks in the
account. Names are displayed in the web interface, in email reports and in the
notifications that SITE_NAME sends out.
- Tags: a space-separated list of optional labels. Use tags to organize and group
checks within a project. You can tag checks by environment
(
prod
, staging
, dev
, ...) or by role (www
, db
, worker
, ...) or using
any other system.
- Description: a free-form text field with any related information for your team
or for your future self: what is being monitored, who set it up,
what to do in case of failures, where to look for additional information.
Simple Schedules
SITE_NAME supports two types of schedules: "simple" and "cron". Use "Simple" schedules
for monitoring processes that are expected to run at relatively regular time
intervals: once an hour, once a day, once a week.
For simple schedules you configure two time durations, Period and Grace Time.
- Period: the expected time between pings
- Grace Time: when a check is late, how long to wait before sending an alert.
Use this variable to account for small, expected deviations in job execution times.
Cron Schedules
Use "cron" for monitoring processes with more complex schedules, and to ensure
jobs run at the correct time (not just at correct time intervals).
You will need to specify Cron Expression, Server's Time Zone and Grace Time.
- Cron Expression: enter the same expression you've used in the crontab.
- Server's Time Zone: cron daemon typically uses the local time of the machine it is
running on. If the machine is not using UTC timezone, you need to tell SITE_NAME
what timezone to use.
- Grace Time: same as for simple schedules, how long to wait before sending an alert
for a late check.
Filtering Rules
In the "Filtering Rules" dialog you can control several advanced aspects of
how SITE_NAME handles incoming pings for a particular check.
- Allowed request methods for HTTP requests. You can require the ping
requests to use HTTP POST. Use the "Only POST" option if you run into issues of
preview bots hitting the ping URLs when you send them in email or post them in chat.
- Filter by keywords in the Subject line. When pinging via email,
look for specific keywords in the subject line. If the subject line contains any of
the keywords listed in Success Keywords, SITE_NAME will assume it to be a success
signal. Likewise, if it contains any of the keywords listed in Failure Keywords,
SITE_NAME will treat it as an explicit failure signal.
This is useful, for example, if your backup software sends an email after each backup
run with a different subject line depending on success or failure.
- Pinging a Paused Check. When you ping a paused check, normally it leaves
the paused state and goes into the "up" or "down" state (depending on the type of
the ping). This changes if you select the "Ignore the ping, stay in the paused state"
option: the paused state becomes "sticky". SITE_NAME will ignore all incoming pings
until you explicitly resume the check.


Fifth International Conference on Computing Communications and Informatics (ICACCI) during 21 - 24, September 2016.
National Workshop on Design & Development of Digital Library with DSpace December 1,2 2016
ASME Felicitation Ceremony: September 7, 2016
ASME Event on Energy and Industries: August 30, 2016


Preparation time
less than 30 mins
Cooking time
30 mins to 1 hour
Serves
Makes 16 small sausage rolls
Dietary
Veggie sausage rolls are easy to make and ideal for serving at a party or keeping in the fridge for a festive treat.
Preheat the oven to 200C/180C Fan/Gas 6. Line two baking trays with baking paper.
Whizz the bread in a food processor until you have fine breadcrumbs. Transfer to a mixing bowl.
Melt the butter in a frying pan over a medium heat. Add the leeks and gently fry for 4–5 minutes. Add half the sage and thyme and fry for 2 minutes, or until softened but not coloured. Add the leeks to the breadcrumbs and season with salt and pepper.
In a separate bowl, whisk together three eggs, add the cheeses and remaining sage and thyme, season with salt and pepper. Tip into the breadcrumb mixture and mix well. Using your hands, form the mixture into two even-sized balls.
Roll out the pastry on a lightly floured surface until you have a 30x30cm/12x12in square. Cut the square in half lengthways to form two rectangles. Lay one of the sausages down each rectangle. Sprinkle over the cranberries. Take the first rectangle and fold one side up over the filling. Brush beaten egg down the other edge and fold it over the top and press lightly to seal the join. Repeat with the second rectangle of pastry.
Turn the two long sausage rolls seam-side-down. Using a sharp knife, cut each length of pastry into eight even-sized sausage rolls. Make two small slits in the top of each one, taking care not to cut right through. Brush all the sausage rolls with beaten egg, then place on the prepared trays.
Bake for 30 minutes, or until golden-brown and cooked through.


Flying Leaves
“Study hard what interests you the most in the most undisciplined,
irreverent and original manner possible.” says Richard Feynmann, an
American physicist.
The world is shifting to digitalization. So you have to do something
digitally if you want to leave a mark.
I'm just trying to learn this world. Will you walk with me in this
"dark path"?


Show trainsbuses first
Show of the closest rail stations & bus stops (each)
Show SafeTrack rebuilding advisories for days in advance
Use ■bluedarker blueblack as the highlight color in menus