- clone() - Method in class it.unisa.studenti.easyworkplatform.model.Account
-
Duplicate an account
- clone() - Method in class it.unisa.studenti.easyworkplatform.model.Activity
-
Duplicate an activity
- clone() - Method in class it.unisa.studenti.easyworkplatform.model.Article
-
Duplicate an article
- clone() - Method in class it.unisa.studenti.easyworkplatform.model.Customer
-
Duplicate a customer
- clone() - Method in class it.unisa.studenti.easyworkplatform.model.Newsletter
-
Duplicate a newsletter
- clone() - Method in class it.unisa.studenti.easyworkplatform.model.Payment
-
Duplicate a payment
- clone() - Method in class it.unisa.studenti.easyworkplatform.model.Service
-
Duplicate a service
- clone() - Method in class it.unisa.studenti.easyworkplatform.model.User
-
Duplicate a user
- closeConnection() - Method in class it.unisa.studenti.easyworkplatform.model.AccountModelDS
-
Close connection to the database
- closeConnection() - Method in class it.unisa.studenti.easyworkplatform.model.ActivityModelDS
-
Close connection to the database
- closeConnection() - Method in class it.unisa.studenti.easyworkplatform.model.ArticleModelDS
-
- closeConnection() - Method in class it.unisa.studenti.easyworkplatform.model.CustomerModelDS
-
Close connection to the database
- closeConnection() - Method in interface it.unisa.studenti.easyworkplatform.model.ModelInterface
-
Close connection to the database
- closeConnection() - Method in class it.unisa.studenti.easyworkplatform.model.PaymentModelDS
-
Close connection to the database
- closeConnection() - Method in class it.unisa.studenti.easyworkplatform.model.ServiceModelDS
-
Close connection to the database
- Customer - Class in it.unisa.studenti.easyworkplatform.model
-
Class that collects customer information
- Customer() - Constructor for class it.unisa.studenti.easyworkplatform.model.Customer
-
Empty constructor
- Customer(int, String, String, Date, String, String, String, String, int, int, String, String) - Constructor for class it.unisa.studenti.easyworkplatform.model.Customer
-
Parametric constructor
- Customer(String, String, Date, String, String, String, String, int, int, String, String) - Constructor for class it.unisa.studenti.easyworkplatform.model.Customer
-
Parametric constructor
- CustomerController - Class in it.unisa.studenti.easyworkplatform.controller
-
Class that handles requests from the browser to the database of a Customer
- CustomerController() - Constructor for class it.unisa.studenti.easyworkplatform.controller.CustomerController
-
Empty Constructor
- CustomerModelDS - Class in it.unisa.studenti.easyworkplatform.model
-
Class that interacts with the database through the information of Customer
- CustomerModelDS() - Constructor for class it.unisa.studenti.easyworkplatform.model.CustomerModelDS
-
Empty constructor
- CustomerModelDS(String, String) - Constructor for class it.unisa.studenti.easyworkplatform.model.CustomerModelDS
-
Parametric constructor with the name of the database


Home
Wharf
Docker
{% if current_user.is_authenticated() %}
Logout
{% else %}
Login
{% endif %}
Some files were missing from your service...
{% for key,value in missing_files.iteritems() %}
Missing {{ key.capitalize() }}
{% endfor %}
Finished
×
Service Description
×
Service Client
×
Modal title
×
Modal title
×
Modal title


Use this section to load up some sample Blog Entries. Please note that it can take a few minutes for your entry to show up in the index.
Number of Posts:
Body Text:
Use this section to run some searches (try some of the lorem ipsum dolor sit amet ... words)
Topic: An Important Topic A Less Important Topic A Minor Topic
Query:
Number of Results: 10 25 50 100


Form Elements
A basic form control input and textarea with disabled and readonly mode.
A form control with success, warning and error state.
A custom styled checkboxes and radios.
A custom styled file browser.
A custom made toggles with jquery support.
| Class Reference | Values |
|---|---|
class="az-toggle az-toggle-[value]" |
secondary | success | dark |
Easily extend form controls by adding text, buttons, or button groups on either side of textual inputs.
Input masks allows a user to more easily enter fixed width input where you would like them to enter the data in a certain format (dates,phones, etc).
A simple component to select color in the same way you select color in Adobe Photoshop.
You can allow alpha transparency selection. Check out these example.
Show pallete only. If you'd like, spectrum can show the palettes you specify, and nothing else.
The datepicker is tied to a standard form input field. Click on the input to open an interactive calendar in a small overlay. If a date is chosen, feedback is shown as the input's value.
Set the numberOfMonths option to an integer of 2 or more to show multiple months in a single datepicker.
Display the datepicker embedded in the page instead of in an overlay.
Datetimepicker style variant on top of AmazeUI Datetimepicker.
Datetimepicker style variant 2 by jquery-simple-datetimepicker
Datetimepicker style variant 3 by picker.js
Select2 gives you a customizable select box with support for searching, tagging, remote data sets, infinite scrolling, and many other highly used options.
Single Select
Single Select with Search
Single Select (Disabled)
Multiple Select
Multiple Select with Pre-Filled Input
Multiple Select (Disabled)
Easy, flexible and responsive range slider with skin support.
Below is the modern skin slider default.
Below is the outline skin slider default.


The following components convert input data in csv format to the binary format required by the calculation components in the reference model;
Static data
A reference intensity bin dictionary csv should also exist, although there is no conversion component for this file because it is not needed for calculation purposes.
Input data
These components are intended to allow users to generate the required input binaries from csv independently of the original data store and technical environment. All that needs to be done is first generate the csv files from the data store (SQL Server database, etc).
The following components convert the binary input data required by the calculation components in the reference model into csv format;
Static data
Input data
These components are provided for the convenience of viewing the data and debugging.
The damage bin dictionary is a reference table in Oasis which defines how the effective damageability cdfs are discretized on a relative damage scale (normally between 0 and 1). It is required by getmodel and gulcalc and must have the following location and filename;
The csv file should contain the following fields and include a header row.
| Name | Type | Bytes | Description | Example |
|---|---|---|---|---|
| bin_index | int | 4 | Identifier of the damage bin | 1 |
| bin_from | float | 4 | Lower damage threshold for the bin | 0.01 |
| bin_to | float | 4 | Upper damage threshold for the bin | 0.02 |
| interpolation | float | 4 | Interpolation damage value for the bin (usually the mid-point) | 0.015 |
The interval_type field has been deprecated and will be filled with zeros in the binary file. It does not need to be included as the final column in the csv file:
| Name | Type | Bytes | Description | Example |
|---|---|---|---|---|
| interval_type | int | 4 | Identifier of the interval type, e.g. closed, open (deprecated) | 0 |
The data should be ordered by bin_index ascending and not contain nulls. The bin_index should be a contiguous sequence of integers starting from 1.
$ damagebintobin < damage_bin_dict.csv > damage_bin_dict.bin
$ damagebintocsv < damage_bin_dict.bin > damage_bin_dict.csv
The deprecated interval_type field can be sent to the output using the -i argument:
$ damagebintocsv -i < damage_bin_dict.bin > damage_bin_dict.csv
The intensity bin dictionary defines the meaning of the bins of the hazard intensity measure. The hazard intensity measure could be flood depth, windspeed, peak ground acceleration etc, depending on the type of peril. The range of hazard intensity values in the model is discretized into bins, each with a unique and contiguous bin_index listed in the intensity bin dictionary. The bin_index is used as a reference in the footprint file (field intensity_bin_index) to specify the hazard intensity for each event and areaperil.
This file is for reference only as it is not used in the calculation so there is no component to convert it to binary format.
The csv file should contain the following fields and include a header row.
| Name | Type | Bytes | Description | Example |
|---|---|---|---|---|
| bin_index | int | 4 | Identifier of the intensity bin | 1 |
| bin_from | float | 4 | Lower intensity threshold for the bin | 56 |
| bin_to | float | 4 | Upper intensity threshold for the bin | 57 |
| interpolation | float | 4 | Mid-point intensity value for the bin | 0.015 |
| interval_type | int | 4 | Identifier of the interval type, e.g. closed, open | 1 |
The data should be ordered by bin_index ascending and not contain nulls. The bin_index should be a contiguous sequence of integers starting from 1.
The event footprint is required for the getmodel component, as well as an index file containing the starting positions of each event block. These must have the following location and filenames;
The csv file should contain the following fields and include a header row.
| Name | Type | Bytes | Description | Example |
|---|---|---|---|---|
| event_id | int | 4 | Oasis event_id | 1 |
| areaperil_id | int | 4 | Oasis areaperil_id | 4545 |
| intensity_bin_index | int | 4 | Identifier of the intensity bin | 10 |
| prob | float | 4 | The probability mass for the intensity bin between 0 and 1 | 0.765 |
The data should be ordered by event_id, areaperil_id and not contain nulls.
$ footprinttobin -i {number of intensity bins} < footprint.csv
This command will create a binary file footprint.bin and an index file footprint.idx in the working directory. The number of intensity bins is the maximum value of intensity_bin_index.
There is an additional parameter -n, which should be used when there is only one record per event_id and areaperil_id, with a single intensity_bin_index value and prob = 1. This is the special case 'no hazard intensity uncertainty'. In this case, the usage is as follows.
$ footprinttobin -i {number of intensity bins} -n < footprint.csv
Both parameters -i and -n are held in the header of the footprint.bin and used in getmodel.
The output binary and index file names can be explicitly set using the -b and -x flags respectively:
$ footprinttobin -i {number of intensity bins} -b {output footprint binary file name} -x {output footprint index file name} < footprint.csv
Both output binary and index file names must be given to use this option.
In the case of very large footprint files, it may be preferrable to compress the data as it is written to the binary file. Compression is performed using zlib by issuing the -z flag. If the -u flag is used in addition, the index file will include the uncompressed data size. It is recommended to use the -u flag to prevent any memory issues during decompression with getmodel or footprinttocsv:
$ footprinttobin -i {number of intensity bins} -z < footprint.csv
$ footprinttobin -i {number of intensity bins} -z -u < footprint.csv
The value of the -u parameter is held in the same location as -n in the header of the footprint.bin file, left-shifted by 1.
$ footprinttocsv > footprint.csv
footprinttocsv requires a binary file footprint.bin and an index file footprint.idx to be present in the working directory.
Input binary and index file names can be explicitly set using the -b and -x flags respectively:
$ footprinttocsv -b {input footprint binary file name} -x {input footprint index file name} > footprint.csv
Both input binary and index file name must be given to use this option.
Footprint binary files that contain compressed data require the -z argument to be issued:
$ footprinttocsv -z > footprint.csv
A random number file may be provided for the gulcalc component as an option (using gulcalc -r parameter) The random number binary contains a list of random numbers used for ground up loss sampling in the kernel calculation. It must have the following location and filename;
If the gulcalc -r parameter is not used, the random number binary is not required and random numbers are instead generated dynamically during the calculation, using the -R parameter to specify how many should be generated.
The random numbers can be imported from a csv file using the component randtobin.
The csv file should contain a simple list of random numbers and include a header row.
| Name | Type | Bytes | Description | Example |
|---|---|---|---|---|
| rand | float | 4 | Number between 0 and 1 | 0.75875 |
$ randtobin < random.csv > random.bin
There are a few parameters available which allow the generation of a random number csv file as follows;
$ randtocsv -r < random.bin > random.csv
$ randtocsv -g 1000000 > random.csv
$ randtocsv -g 1000000 -S 1234 > random.csv
The -S {seed value} option produces repeatable random numbers, whereas usage of -g alone will generate a different set every time.
The vulnerability file is required for the getmodel component. It contains the conditional distributions of damage for each intensity bin and for each vulnerability_id. This file must have the following location and filename;
The csv file should contain the following fields and include a header row.
| Name | Type | Bytes | Description | Example |
|---|---|---|---|---|
| vulnerability_id | int | 4 | Oasis vulnerability_id | 45 |
| intensity_bin_index | int | 4 | Identifier of the hazard intensity bin | 10 |
| damage_bin_index | int | 4 | Identifier of the damage bin | 20 |
| prob | float | 4 | The probability mass for the damage bin | 0.186 |
The data should be ordered by vulnerability_id, intensity_bin_index and not contain nulls.
$ vulnerabilitytobin -d {number of damage bins} < vulnerability.csv > vulnerability.bin
The parameter -d number of damage bins is the maximum value of damage_bin_index. This is held in the header of vulnerability.bin and used by getmodel.
In the case of very large vulnerability files, it may be preferrable to create an index file to improve performance. Issuing the -i flag creates vulnerability.bin and vulnerability.idx in the current working directory:
$ vulnerabilitytobin -d {number of damage bins} -i < vulnerability.csv
Additionally, the data can be compressed as it is written to the binary file. Compression is performed with zlib by issuing the -z flag. This creates vulnerability.bin.z and vulnerability.idx.z in the current working directory:
$ vulnerabilitytobin -d {number of damage bins} -i < vulnerability.csv
The getmodel component will look for the presence of index files in the following order to determine which algorithm to use to extract data from vulnerability.bin:
$ vulnerabilitytocsv < vulnerability.bin > vulnerability.csv
$ vulnerabilitytocsv -i > vulnerability.csv
$ vulnerabilitytocsv -z > vulnerability.csv
The coverages binary contains the list of coverages and the coverage TIVs. The data format is as follows. It is required by gulcalc and fmcalc and must have the following location and filename;
The csv file should contain the following fields and include a header row.
| Name | Type | Bytes | Description | Example |
|---|---|---|---|---|
| coverage_id | int | 4 | Identifier of the coverage | 1 |
| tiv | float | 4 | The total insured value of the coverage | 200000 |
Coverage_id must be an ordered contiguous sequence of numbers starting at 1.
$ coveragetobin < coverages.csv > coverages.bin
$ coveragetocsv < coverages.bin > coverages.csv
One or more event binaries are required by eve. It must have the following location and filename;
The csv file should contain a list of event_ids (integers) and include a header.
| Name | Type | Bytes | Description | Example |
|---|---|---|---|---|
| event_id | int | 4 | Oasis event_id | 4545 |
$ evetobin < events.csv > events.bin
$ evetocsv < events.bin > events.csv
The items binary contains the list of exposure items for which ground up loss will be sampled in the kernel calculations. The data format is as follows. It is required by gulcalc and outputcalc and must have the following location and filename;
The csv file should contain the following fields and include a header row.
| Name | Type | Bytes | Description | Example |
|---|---|---|---|---|
| item_id | int | 4 | Identifier of the exposure item | 1 |
| coverage_id | int | 4 | Identifier of the coverage | 3 |
| areaperil_id | int | 4 | Identifier of the locator and peril | 4545 |
| vulnerability_id | int | 4 | Identifier of the vulnerability distribution | 645 |
| group_id | int | 4 | Identifier of the correlaton group | 3 |
The data should be ordered by areaperil_id, vulnerability_id ascending and not contain nulls. item_id must be a contiguous sequence of numbers starting from 1.
$ itemtobin < items.csv > items.bin
$ itemtocsv < items.bin > items.csv
The gulsummaryxref binary is a cross reference file which determines how item or coverage losses from gulcalc output are summed together into at various summary levels in summarycalc. It is required by summarycalc and must have the following location and filename;
The csv file should contain the following fields and include a header row.
| Name | Type | Bytes | Description | Example |
|---|---|---|---|---|
| item_id / coverage_id | int | 4 | Identifier of the item or coverage | 3 |
| summary_id | int | 4 | Identifier of the summary level grouping | 3 |
| summaryset_id | int | 4 | Identifier of the summary set | 1 |
One summary set consists of a common summaryset_id and each item_id being assigned a summary_id. An example is as follows.
| item_id | summary_id | summaryset_id |
|---|---|---|
| 1 | 1 | 1 |
| 2 | 1 | 1 |
| 3 | 1 | 1 |
| 4 | 2 | 1 |
| 5 | 2 | 1 |
| 6 | 2 | 1 |
This shows, for summaryset_id=1, items 1-3 being grouped into summary_id = 1 and items 4-6 being grouped into summary_id = 2. This could be an example of a 'site' level grouping, for example. The summary_ids should be held in a dictionary which contains the description of the ids to make meaning of the output results. For instance;
| summary_id | summaryset_id | summary_desc |
|---|---|---|
| 1 | 1 | site_435 |
| 2 | 1 | site_958 |
This cross reference information is not required in ktools.
Up to 10 summary sets may be provided in gulsummaryxref, depending on the required summary reporting levels for the analysis. Here is an example of the 'site' summary level with summaryset_id=1, plus an 'account' summary level with summaryset_id = 2. In summary set 2, the account summary level includes both sites because all items are assigned a summary_id of 1.
| item_id | summary_id | summaryset_id |
|---|---|---|
| 1 | 1 | 1 |
| 2 | 1 | 1 |
| 3 | 1 | 1 |
| 4 | 2 | 1 |
| 5 | 2 | 1 |
| 6 | 2 | 1 |
| 1 | 1 | 2 |
| 2 | 1 | 2 |
| 3 | 1 | 2 |
| 4 | 1 | 2 |
| 5 | 1 | 2 |
| 6 | 1 | 2 |
$ gulsummaryxreftobin < gulsummaryxref.csv > gulsummaryxref.bin
$ gulsummaryxreftocsv < gulsummaryxref.bin > gulsummaryxref.csv
The fm programme binary file contains the level heirarchy and defines aggregations of losses required to perform a loss calculation, and is required for fmcalc only.
This must have the following location and filename;
The csv file should contain the following fields and include a header row.
| Name | Type | Bytes | Description | Example |
|---|---|---|---|---|
| from_agg_id | int | 4 | Oasis Financial Module from_agg_id | 1 |
| level_id | int | 4 | Oasis Financial Module level_id | 1 |
| to_agg_id | int | 4 | Oasis Financial Module to_agg_id | 1 |
$ fmprogrammetobin < fm_programme.csv > fm_programme.bin
$ fmprogrammetocsv < fm_programme.bin > fm_programme.csv
The fmprofile binary file contains the list of calculation rules with profile values (policytc_ids) that appear in the policytc file. This is required for fmcalc only.
There are two versions of this file and either one or the other can be used at a time.
They must be in the following location with filename formats;
The csv file should contain the following fields and include a header row.
fm_profile
| Name | Type | Bytes | Description | Example |
|---|---|---|---|---|
| policytc_id | int | 4 | Primary key | 34 |
| calcrule_id | int | 4 | The calculation rule that applies to the terms | 12 |
| deductible_1 | int | 4 | First deductible | 0.03 |
| deductible_2 | float | 4 | Second deductible | 50000 |
| deductible_3 | float | 4 | Third deductible | 100000 |
| attachment_1 | float | 4 | Attachment point, or excess | 1000000 |
| limit_1 | float | 4 | Limit | 5000000 |
| share_1 | float | 4 | First proportional share | 0.8 |
| share_2 | float | 4 | Second proportional share | 0.25 |
| share_3 | float | 4 | Third proportional share | 1 |
fm_profile_step
| Name | Type | Bytes | Description | Example |
|---|---|---|---|---|
| policytc_id | int | 4 | Primary key | 34 |
| calcrule_id | int | 4 | The calculation rule that applies to the terms | 12 |
| deductible_1 | int | 4 | First deductible | 0.03 |
| deductible_2 | float | 4 | Second deductible | 50000 |
| deductible_3 | float | 4 | Third deductible | 100000 |
| attachment_1 | float | 4 | Attachment point, or excess | 1000000 |
| limit_1 | float | 4 | First limit | 5000000 |
| share_1 | float | 4 | First proportional share | 0.8 |
| share_2 | float | 4 | Second proportional share | 0.25 |
| share_3 | float | 4 | Third proportional share | 1 |
| step_id | int | 4 | Step number | 1 |
| trigger_start | float | 4 | Start trigger for payout | 0.05 |
| trigger_end | float | 4 | End trigger for payout | 0.15 |
| payout_start | float | 4 | Start payout | 100 |
| payout_end | float | 4 | End payout | 200 |
| limit_2 | float | 4 | Second limit | 3000000 |
| scale_1 | float | 4 | Scaling (inflation) factor 1 | 0.03 |
| scale_2 | float | 4 | Scaling (inflation) factor 2 | 0.2 |
$ fmprofiletobin < fm_profile.csv > fm_profile.bin
$ fmprofiletobin -S < fm_profile_step.csv > fm_profile_step.bin
$ fmprofiletocsv < fm_profile.bin > fm_profile.csv
$ fmprofiletocsv -S < fm_profile_step.bin > fm_profile_step.csv
The fm policytc binary file contains the cross reference between the aggregations of losses defined in the fm programme file at a particular level and the calculation rule that should be applied as defined in the fm profile file. This file is required for fmcalc only.
This must have the following location and filename;
The csv file should contain the following fields and include a header row.
| Name | Type | Bytes | Description | Example |
|---|---|---|---|---|
| layer_id | int | 4 | Oasis Financial Module layer_id | 1 |
| level_id | int | 4 | Oasis Financial Module level_id | 1 |
| agg_id | int | 4 | Oasis Financial Module agg_id | 1 |
| policytc_id | int | 4 | Oasis Financial Module policytc_id | 1 |
$ fmpolicytctobin < fm_policytc.csv > fm_policytc.bin
$ fmpolicytctocsv < fm_policytc.bin > fm_policytc.csv
The fm summary xref binary is a cross reference file which determines how losses from fmcalc output are summed together at various summary levels by summarycalc. It is required by summarycalc and must have the following location and filename;
The csv file should contain the following fields and include a header row.
| Name | Type | Bytes | Description | Example |
|---|---|---|---|---|
| output_id | int | 4 | Identifier of the coverage | 3 |
| summary_id | int | 4 | Identifier of the summary level group for one or more output losses | 1 |
| summaryset_id | int | 4 | Identifier of the summary set (0 to 9 inclusive) | 1 |
One summary set consists of a common summaryset_id and each output_id being assigned a summary_id. An example is as follows.
| output_id | summary_id | summaryset_id |
|---|---|---|
| 1 | 1 | 1 |
| 2 | 2 | 1 |
This shows, for summaryset_id=1, output_id=1 being assigned summary_id = 1 and output_id=2 being assigned summary_id = 2.
If the output_id represents a policy level loss output from fmcalc (the meaning of output_id is defined in the fm xref file) then no further grouping is performed by summarycalc and this is an example of a 'policy' summary level grouping.
Up to 10 summary sets may be provided in this file, depending on the required summary reporting levels for the analysis. Here is an example of the 'policy' summary level with summaryset_id=1, plus an 'account' summary level with summaryset_id = 2. In summary set 2, the 'account' summary level includes both policy's because both output_id's are assigned a summary_id of 1.
| output_id | summary_id | summaryset_id |
|---|---|---|
| 1 | 1 | 1 |
| 2 | 2 | 1 |
| 1 | 1 | 2 |
| 2 | 1 | 2 |
If a more detailed summary level than policy is required for insured losses, then the user should specify in the fm profile file to back-allocate fmcalc losses to items. Then the output_id represents back-allocated policy losses to item, and in the fmsummaryxref file these can be grouped into any summary level, such as site, zipcode, line of business or region, for example. The user needs to define output_id in the fm xref file, and group them together into meaningful summary levels in the fm summary xref file, hence these two files must be consistent with respect to the meaning of output_id.
$ fmsummaryxreftobin < fmsummaryxref.csv > fmsummaryxref.bin
$ fmsummaryxreftocsv < fmsummaryxref.bin > fmsummaryxref.csv
The fmxref binary file contains cross reference data specifying the output_id in the fmcalc as a combination of agg_id and layer_id, and is required by fmcalc.
This must be in the following location with filename format;
The csv file should contain the following fields and include a header row.
| Name | Type | Bytes | Description | Example |
|---|---|---|---|---|
| output_id | int | 4 | Identifier of the output group of losses | 1 |
| agg_id | int | 4 | Identifier of the agg_id to output | 1 |
| layer_id | int | 4 | Identifier of the layer_id to output | 1 |
The data should not contain any nulls.
The output_id represents the summary level at which losses are output from fmcalc, as specified by the user.
There are two cases;
For example, say there are two policy layers (with layer_ids=1 and 2) which applies to the sum of losses from 4 items (the summary level represented by agg_id=1). Without back-allocation, the policy summary level of losses can be represented as two output_id's as follows;
| output_id | agg_id | layer_id |
|---|---|---|
| 1 | 1 | 1 |
| 2 | 1 | 2 |
If the user wants to back-allocate policy losses to the items and output the losses by item and policy, then the item-policy summary level of losses would be represented by 8 output_id's, as follows;
| output_id | agg_id | layer_id |
|---|---|---|
| 1 | 1 | 1 |
| 2 | 2 | 1 |
| 3 | 3 | 1 |
| 4 | 4 | 1 |
| 5 | 1 | 2 |
| 6 | 2 | 2 |
| 7 | 3 | 2 |
| 8 | 4 | 2 |
The fm summary xref file must be consistent with respect to the meaning of output_id in the fmxref file.
$ fmxreftobin < fm_xref.csv > fm_xref.bin
$ fmxreftocsv < fm_xref.bin > fm_xref.csv
The occurrence file is required for certain output components which, in the reference model, are leccalc, pltcalc and aalcalc. In general, some form of event occurence file is required for any output which involves the calculation of loss metrics over a period of time. The occurrence file assigns occurrences of the event_ids to numbered periods. A period can represent any length of time, such as a year, or 2 years for instance. The output metrics such as mean, standard deviation or loss exceedance probabilities are with respect to the chosen period length. Most commonly in catastrophe modelling, the period of interest is a year.
The occurrence file also includes date fields.
The csv file should contain the following fields and include a header row.
| Name | Type | Bytes | Description | Example |
|---|---|---|---|---|
| event_id | int | 4 | The occurrence event_id | 45567 |
| period_no | int | 4 | A numbered period in which the event occurs | 56876 |
| occ_year | int | 4 | the year number of the event occurrence | 56876 |
| occ_month | int | 4 | the month of the event occurrence | 5 |
| occ_day | int | 4 | the day of the event occurrence | 16 |
The occurrence year in this example is a scenario numbered year, which cannot be expressed as a real date in a standard calendar.
In addition, the following fields are optional and should comprise the sixth and seventh column respectively:
| Name | Type | Bytes | Description | Example |
|---|---|---|---|---|
| occ_hour | int | 4 | The hour of the event occurrence | 13 |
| occ_minute | int | 4 | The minute of the event occurrence | 52 |
The date fields are converted to a single number through an algorithm for efficient storage in the binary file. The data type for this field is either an integer when the optional date fields are not included or a long long integer when the these date fields are included. This should not be confused with the deprecated occ_date_id field.
A required parameter is -P, the total number of periods of event occurrences. The total number of periods is held in the header of the binary file and used in output calculations.
$ occurrencetobin -P10000 < occurrence.csv > occurrence.bin
If it is desirable to include the occ_hour and occ_minute fields in the binary file, the -H argument should be given. A flag to signify the presence of these fields is set in the header of the binary file, which is read by other kiools components. If these fields do not exist in the csv file, both are assigned the value of 0 when written to the binary file.
$ occurrencetobin -P10000 -H < occurrence.csv > occurrence.bin
$ occurrencetocsv < occurrence.bin > occurrence.csv
The returnperiods binary file is a list of return periods that the user requires to be included in loss exceedance curve (leccalc) results.
This must be in the following location with filename format;
The csv file should contain the following field and include a header.
| Name | Type | Bytes | Description | Example |
|---|---|---|---|---|
| return_period | int | 4 | Return period | 250 |
$ returnperiodtobin < returnperiods.csv > returnperiods.bin
$ returnperiodtocsv < returnperiods.bin > returnperiods.csv
The periods binary file is a list of all the periods that are in the model and is optional for weighting the periods in the calculation. The file is used in the calculation of the loss exceedance curve (leccalc) and aalcalc results.
This must be in the following location with filename format;
The csv file should contain the following field and include a header.
| Name | Type | Bytes | Description | Example |
|---|---|---|---|---|
| period_no | int | 4 | A numbered period in which the event occurs | 4545 |
| weight | int | 4 | relative weight to P, the maximum period_no | 0.0003 |
All periods must be present in this file (no gaps in period_no from 1 to P).
$ periodstobin < periods.csv > periods.bin
$ periodstocsv < periods.bin > periods.csv


Lorem Ipsum
title
Some quick example text to build on the card title and make up the bulk of the card's content.
Lorem Ipsum
title
Some quick example text to build on the card title and make up the bulk of the card's content.
Lorem Ipsum
title
Some quick example text to build on the card title and make up the bulk of the card's content.
Lorem Ipsum
title
Some quick example text to build on the card title and make up the bulk of the card's content.


--- layout: post title: Bruised Toes date: 2011-11-13 16:58:07.000000000 +00:00 tags: - toes - bruise type: post published: true ---
About two thirds of the way into my long run today I somehow managed to trip over something and severely stub my toes. The result, some lovely blue/purple and tender toes...
I've got quite hideous looking feet to start off with - the stumpy looking middle toes has been that way since I hurt my foot last year - the added colouring doesn't make them any more appealing 🙂
I don't think they're broken as I can move them without any pain. I think they're just a little on the bruised side. Thankfully I was wearing my Merrells. Who knows that my toes would look like had I not been. Hopefully this won't affect my running too much. I managed to finish my run this morning which entailed about another 7km after the stubbing without any discomfort. We'll see how things are tomorrow. Time to go ice them.


Timothy Omotoso Trial Postponed To January
by NT EditorThe sex trafficking case against controversial pastor Timothy Omotoso and two others will continue next year in January.
Omotoso and two alleged accomplices appeared in the Port Elizabeth High Court on Thursday.
The televangelist was behind bars since he was arrested in 2017, while Lusanda Sulani and Zukiswa Sitho – who allegedly recruited young women for sexual exploitation by Omotoso – were out on bail.
The State informed the court it was still awaiting the outcome of a Constitutional Court application brought by Omotoso and his co-accused. They approached the highest court in the country after they were unsuccessful at the Supreme Court of Appeal.
The defence wanted that court to overrule the Port Elizabeth High Court’s decision relating to jurisdiction. It argued the court couldn’t preside over all the charges because some of the alleged offences occurred outside of Port Elizabeth.
The State and the defence were still awaiting feedback from the ConCourt and requested a further postponement.
The trial was expected to resume on 28 January.


{% extends "base.html" %} {% load static from staticfiles %} {% load crispy_forms_tags %} {% load crispy_forms_field %} {% block title %}{{ block.super }}About{% endblock %} {% block navbar-left %} {% include "_navbar.html" with active_link="sign-in-sheet" %} {% endblock %} {% block container %}
Find your name and click the logout button
Click one of the tabs below and choose a log in option
{% include "sign_in_page/sign_in.html" %}


If you are not using DHCP and want a statically configured set of default DNS resolvers, enter their IP addresses in this box.
Separate them with spaces.
As a tool designed to protect your privacy, the DNSCrypt proxy does not log anything about your DNS queries. Nothing about them will be saved to disk ever, and log messages are intentionally kept as generic as possible.
However, you still may want to look at the DNS queries sent by your system. This can be useful in order to spot suspicious activity and to refine your domain blacklists and whitelists.
Checking the "Log DNS queries" box dumps all DNS queries sent by your computer to a file named /var/log/dnscrypt-query.log
The "View log" button opens it with the log viewer application so that you can watch it in real time.
A response to a query containing at least one IP address listed here will be blocked.
This make it easy to block spam sources, hosting services and content providers using a lot of different domain names for a single service.
This can also be useful in order to block DNS rebinding attacks, even for non-private network spaces.
IP addresses can be IPv4 and IPv6 addresses, and must be separated with spaces.
This is a list of domain names to be blocked.
"example.com" will only match this specific name, not "www.example.com".
But wildcards are also supported. "*.example.com" will match any name ending with ".example.com" whereas "ads.*" will match any name beginning with "ads."
Wildcards can also perform substring matching. "*xxx*" will match any name containing the string "xxx".
Patterns to be blocked should be separated with spaces, and the blocking takes effect immediately after you hit the Return key. Flushing your DNS cache is not required.
This feature is only enabled when using DNSCrypt.
Some domain names should not be resolved by a third-party DNS resolver, that may not know about them.
This includes local domain names provided by home routers (like "routerlogin.net"), local domain names provided by operating systems and applications (like ".local" or ".lan"), local domain names served by appliances like st-top boxes, and internal domains used in corporate networks.
Domains listed here will bypass DNSCrypt in order to be sent to the default resolvers.
Do not use a tool like hostip(8), drill(1), unbound-host(1), dig(1) or host(1) in order to check that an exception rule works.
These tools use their own resolution mechanisms that have nothing to do with how others apps on your system are resolving names.
They don't use the OSX-specific stub resolver, they don't use the system-wide DNS cache, they have bugs and limitations that the OS doesn't have (and the opposite is also true), and they don't know a thing about specific resolvers that have to be used for specific domains.
Use actual apps, or even a command like ping(8).


3 overrides of CanConvertFrom
System.Management.Automation (3)
engine\LanguagePrimitives.cs (2)
178
public override bool
CanConvertFrom
(object sourceValue, Type destinationType)
1971
public override bool
CanConvertFrom
(object sourceValue, Type destinationType)
engine\serialization.cs (1)
6782
public override bool
CanConvertFrom
(object sourceValue, Type destinationType)
1 reference to CanConvertFrom
System.Management.Automation (1)
engine\LanguagePrimitives.cs (1)
89
return this.
CanConvertFrom
(GetSourceValueAsObject(sourceValue), destinationType);


Allows user to output a digital PWM signal. Parameters are:
Duty Cycle: Enter from 0 to 100%
Frequency: Enter Hz
Active Edge: 0 = Low, 1 = High
Sinewave Generation
Allows user to output an analog sinewave signal. Parameters are:
Frequency: Enter Hz
Sinewave Offset: Enter from +/- 128
Amplitude: Peak to Peak from +/- 128
Analog PWM Measurement
Allows user to measure an analog PWM signal. Parameters are:
Threshold Level: This value is compared against the analog PWM signal to determine if the signal is high or low. Enter from +/- 128.
Timeout: The number of ticks of the owning FPGA loop to acquire without seeing a level transition before reseting the outputs.
Active Edge: 0 = Low, 1 = High
Results from this core are:
Frequency: In Hz
Period: In Seconds
Duty Cycle: In Percent (%)
Active Time: In Seconds
Active Voltage: Maximum voltage level during the active edge of the measurement. NOTE: If the active edge is low (0), then the minimum voltage level is used.
Inactive Voltage: Minimum voltage level during the inactive edge of the measurement. NOTE: If the active edge is low (0), then the maximum voltage level is used.
Digital PWM Measurement
Allows user to measure a digital PWM signal. Parameters are:
Timeout: The number of ticks of the owning FPGA loop to acquire without seeing a level transition before reseting the outputs.
Active Edge: 0 = Low, 1 = High
Results from this core are:
Frequency: In Hz
Period: In Seconds
Duty Cycle: In Percent (%)
Active Time: In Seconds
Wheel Speed Sensor Generation
Allows user to output a digital pattern to simulate Wheel Speed Sensors. Parameters are:
Speed: Wheel speed in km/hr
Data: 8-bit data to be transmitted by sensor
PPR: Wheel Speed Sensor Pulses per Revolution of Wheel
WD: Wheel diameter in mm
Type: Wheel Speed Sensor Type
Quadrature Encoder Measurement
Allows user to measure position using a digital quadrature encoder. Parameters are:
Direction: 0 = Increments on A leads B, 1 = Increments on B leads A
Reset Value: The value to reset the position to once the encoder index is found.
Reset A State: The state the A signal must be at for a reset to occur.
Reset B State: The state the B signal must be at for a reset to occur.
Reset Z State: The state the Z signal must be at for a reset to occur.


Focal length determines the field of view and the size of the lens. A longer focal length will call for a longer lens (with exception of mirror based lenses) and will give us a narrower field of view. This will make the subject appear more close up and is useful for photographying subjects that are small and far away.
A longer focal length will also mean there will be less difference in size change with distance.