oasislmf / oasispiwind

Toy UK windstorm model

OasisLMF

The oasislmf Python package, loosely called the model development kit (MDK) or the MDK package, provides a command line toolkit for developing, testing and running Oasis models end-to-end locally, or remotely via the Oasis API. It can generate ground-up losses (GUL), direct/insured losses (IL) and reinsurance losses (RIL). It can also generate deterministic losses at all these levels.

Versioning and Updates

Current Stable Versions

• 1.15.x stable/1.15.x From Feb 2021
• 1.23.x stable/1.23.x From Dec 2021
• 1.26.x stable/1.26.x From Jun 2022
• 1.27.x stable/1.27.x From Jan 2023
• 1.28.x (Up comming) July 2023

Release Schedule

Until end of 2023 Until the year 2023, we will be following a six-month release cycle for our stable versions. During each six-month period, we will release a new stable version with added features. These updates will adhere to the Semantic Versioning (semver) format and will increment the minor version number. That version of oaisislmf is then 'frozen' into a branch matching the new version number, so on release 1.28.0 the code base is copied to a branch stable/1.28.x where backported features and fixes are applied.

After 2023 Starting from 2023, we will transition to a yearly release cycle for our stable versions. Each year, we will release a new stable version with additional features.

Monthly Updates

Every month, we will provide updates to the latest stable version. These updates will include new compatible features and bug fixes, ensuring that our software remains up-to-date and reliable.

During the monthly update, if any bug fixes are required, they will also be applied to the older stable versions. This approach guarantees that all stable versions receive necessary bug fixes, while maintaining a consistent output numbers for that stable version.

Features

For running models locally the CLI provides a model subcommand with the following options:

• model generate-exposure-pre-analysis: generate new Exposure input using user custom code (ex: geo-coding, exposure enhancement, or dis-aggregation...)
• model generate-keys: generates Oasis keys files from model lookups; these are essentially line items of (location ID, peril ID, coverage type ID, area peril ID, vulnerability ID) where peril ID and coverage type ID span the full set of perils and coverage types that the model supports; if the lookup is for a complex/custom model the keys file will have the same format except that area peril ID and vulnerability ID are replaced by a model data JSON string
• model generate-oasis-files: generates the Oasis input CSV files for losses (GUL, GUL + IL, or GUL + IL + RIL); it requires the provision of source exposure and optionally source accounts and reinsurance info. and scope files (in OED format), as well as assets for instantiating model lookups and generating keys files
• model generate-losses: generates losses (GUL, or GUL + IL, or GUL + IL + RIL) from a set of pre-existing Oasis files
• model run: runs the model from start to finish by generating losses (GUL, or GUL + IL, or GUL + IL + RIL) from the source exposure, and optionally source accounts and reinsurance info. and scope files (in OED or RMS format), as well as assets related to lookup instantiation and keys file generation

The optional --summarise-exposure flag can be issued with model generate-oasis-files and model run to generate a summary of Total Insured Values (TIVs) grouped by coverage type and peril. This produces the exposure_summary_report.json file.

For remote model execution the api subcommand provides the following main subcommand:

• api run: runs the model remotely (same as model run) but via the Oasis API

For generating deterministic losses an exposure run subcommand is available:

• exposure run: generates deterministic losses (GUL, or GUL + IL, or GUL + IL + RIL)

The reusable libraries are organised into several sub-packages, the most relevant of which from a model developer or user's perspective are:

• api_client
• model_preparation
• model_execution
• utils

Minimum Python Requirements

Starting from 1st January 2019, Pandas will no longer be supporting Python 2. As Pandas is a key dependency of the MDK we are dropping Python 2 (2.7) support as of this release (1.3.4). The last version which still supports Python 2.7 is version 1.3.3 (published 12/03/2019).

Also for this release (and all future releases) a minimum of Python 3.8 is required.

Installation

The latest released version of the package, or a specific package version, can be installed using pip:

pip install oasislmf[==<version string>]

Alternatively you can install the latest development version using:

pip install git+{https,ssh}://[email protected]/OasisLMF/OasisLMF

You can also install from a specific branch <branch name> using:

pip install [-v] git+{https,ssh}://[email protected]/OasisLMF/OasisLMF.git@<branch name>#egg=oasislmf

Enable Bash completion

Bash completion is a functionality which bash helps users type their commands by presenting possible options when users press the tab key while typing a command.

Once oasislmf is installed you'll need to be activate the feature by sourcing a bash file. (only needs to be run once)

Local

oasislmf admin enable-bash-complete

Global

echo 'complete -C completer_oasislmf oasislmf' | sudo tee /usr/share/bash-completion/completions/oasislmf

Dependencies

System

The package provides a built-in lookup framework (oasislmf.model_preparation.lookup.OasisLookup) which uses the Rtree Python package, which in turn requires the libspatialindex spatial indexing C library.

https://libspatialindex.github.io/index.html

Linux users can install the development version of libspatialindex from the command line using apt.

[sudo] apt install -y libspatialindex-dev

and OS X users can do the same via brew.

brew install spatialindex

The PiWind demonstration model uses the built-in lookup framework, therefore running PiWind or any model which uses the built-in lookup, requires that you install libspatialindex.

GNU/Linux

For GNU/Linux the following is a specific list of required system libraries

• Debian: g++ compiler build-essential, libtool, zlib1g-dev autoconf on debian distros

  sudo apt install g++ build-essential libtool zlib1g-dev autoconf

• Red Hat: 'Development Tools' and zlib-devel

Python

Package Python dependencies are controlled by pip-tools. To install the development dependencies first, install pip-tools using:

pip install pip-tools

and run:

pip-sync

To add new dependencies to the development requirements add the package name to requirements.in or to add a new dependency to the installed package add the package name to requirements-package.in. Version specifiers can be supplied to the packages but these should be kept as loose as possible so that all packages can be easily updated and there will be fewer conflict when installing.

After adding packages to either *.in file:

pip-compile && pip-sync

should be ran ensuring the development dependencies are kept up to date.

ods_tools

OasisLMF uses the ods_tools package to read exposure files and the setting files The version compatible with each OasisLMF is manage in the requirement files. below is the summary:

• OasisLMF 1.23.x or before => no ods_tools
• OasisLMF 1.26.x => use ods_tools 2.3.2
• OasisLMF 1.27.0 => use ods_tools 3.0.0 or later
• OasisLMF 1.27.1 => use ods_tools 3.0.0 or later
• OasisLMF 1.27.2 => use ods_tools 3.0.4 or later

pandas

Pandas has released its major version number 2 breaking some of the compatibility with the 1st version Therefore, for all version of OasisLMF <= 1.27.2, the latest supported version for pandas is 1.5.3 Support for pandas 2, starts from version 1.27.3

Testing

To test the code style run:

flake8

To test against all supported python versions run:

tox

To test against your currently installed version of python run:

py.test

To run the full test suite run:

./runtests.sh

Publishing

Before publishing the latest version of the package make you sure increment the __version__ value in oasislmf/__init__.py, and commit the change. You'll also need to install the twine Python package which setuptools uses for publishing packages on PyPI. If publishing wheels then you'll also need to install the wheel Python package.

Using the publish subcommand in setup.py

The distribution format can be either a source distribution or a platform-specific wheel. To publish the source distribution package run:

python setup.py publish --sdist

or to publish the platform specific wheel run:

python setup.py publish --wheel

Creating a bdist for another platform

To create a distribution for a non-host platform use the --plat-name flag:

 python setup.py bdist_wheel --plat-name Linux_x86_64

 or

 python setup.py bdist_wheel --plat-name Darwin_x86_64

Manually publishing, with a GPG signature

The first step is to create the distribution package with the desired format: for the source distribution run:

python setup.py sdist

which will create a .tar.gz file in the dist subfolder, or for the platform specific wheel run:

python setup.py bdist_wheel

which will create .whl file in the dist subfolder. To attach a GPG signature using your default private key you can then run:

gpg --detach-sign -a dist/<package file name>.{tar.gz,whl}

This will create .asc signature file named <package file name>.{tar.gz,whl}.asc in dist. You can just publish the package with the signature using:

twine upload dist/<package file name>.{tar.gz,whl} dist/<package file name>.{tar.gz,whl}.asc

Documentation

• Issues
• Releases
• General Oasis documentation
• Model Development Kit (MDK)
• Modules

License

The code in this project is licensed under BSD 3-clause license.

oasispiwind's Issues

allocation rule set to 1 in image

update the oasislmf_deploy.json file to set the allocation rule to 1 in the published image

CI retry not working when waiting for model to become ready

The r.raise_for_status() call might be triggering an exception which prevents urllib3.util.retry from running the retry.

Switch assert oasis_client.models.get(1) to calling the URL directly, without the oasis-client, like here:

OasisPiWind/tests/modelcheck.py

Lines 79 to 80 in c1c116f

	api_url = f"http://{server.hostname}:{server.host_port}"
	assert request_session.get(f"{api_url}/healthcheck/")

tests/modelcheck.py:90: 
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 
/opt/hostedtoolcache/Python/3.10.13/x64/lib/python3.10/site-packages/oasislmf/platform_api/client.py:48: in get
    return self.session.get(urljoin(self.url_endpoint, f'{ID}/'))
/opt/hostedtoolcache/Python/3.10.13/x64/lib/python3.10/site-packages/oasislmf/platform_api/session.py:158: in get
    raise e
/opt/hostedtoolcache/Python/3.10.13/x64/lib/python3.10/site-packages/oasislmf/platform_api/session.py:151: in get
    r.raise_for_status()
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 

self = <Response [404]>

    def raise_for_status(self):
        """Raises :class:`HTTPError`, if one occurred."""
    
        http_error_msg = ""
        if isinstance(self.reason, bytes):
            # We attempt to decode utf-8 first because some servers
            # choose to localize their reason strings. If the string
            # isn't utf-8, we fall back to iso-8859-1 for all other
            # encodings. (See PR #3538)
            try:
                reason = self.reason.decode("utf-8")
            except UnicodeDecodeError:
                reason = self.reason.decode("iso-8859-1")
        else:
            reason = self.reason
    
        if 400 <= self.status_code < 500:
            http_error_msg = (
                f"{self.status_code} Client Error: {reason} for url: {self.url}"
            )
    
        elif 500 <= self.status_code < 600:
            http_error_msg = (
                f"{self.status_code} Server Error: {reason} for url: {self.url}"
            )
    
        if http_error_msg:
>           raise HTTPError(http_error_msg, response=self)
E           requests.exceptions.HTTPError: 404 Client Error: Not Found for url: http://0.0.0.0:8000/V1/models/1/

Example exposure files - not to spec

OED MDK configuration

An OED version of the MDK configuration file (oasislmf.json) is required to run PiWind using OED data.

Makefile in https://github.com/OasisLMF/OasisPiWind/tree/master/model_data/PiWind outdated

• quantile.bin is not among the targets
• occurrence_lt is called occurrence

PiWind postcode model

Features to add;

Tasks

Beta Give feedback

1. Model files for vulnerability uncertainty
2. Postcode aggregate footprint containing intensity uncertainty
3. Postcode lookup in keys logic
4. Hierarchal areaperil lookup (lat-lon, then postcode) (NOT DONE)
5. Correlation settings in model_settings.json
6. Exposure Pre-Analysis hook for enhanced disaggregation
7. Exposures with NumberOfBuildings > 1 and IsAggregate =1
8. Documentation

Multi-peril multi-coverage numerical testing for Oasis platform control results set

Ben to triage

Error running running_piwind.ipynb with python 3.5.5

In running running_piwind.ipynb, with python 3.5.5 and Jupyter notebook 4.2.3

For cell 16:

! rm -rf /tmp/analysis_test
! oasislmf model run -C oasislmf.json -r /tmp/analysis_test

the following error:

Creating temporary folder /tmp/analysis_test/tmp for Oasis files
Getting model info and creating lookup service instance
STARTED: keys_server.PiWind.PiWindKeysLookup.__init__
STARTED: oasislmf.keys.lookup.__init__
COMPLETED: oasislmf.keys.lookup.__init__ in 0.0s
COMPLETED: keys_server.PiWind.PiWindKeysLookup.__init__ in 0.05s
	{'model_id': 'PiWind', 'supplier_id': 'OasisLMF', 'model_version_id': '0.0.0.1'}, <keys_server.PiWind.PiWindKeysLookup.PiWindKeysLookup object at 0x7f385d007be0>
Creating Oasis model object
	<class 'oasislmf.models.model.OasisModel'>: {'_model_version_id': '0.0.0.1', '_model_id': 'PiWind', '_supplier_id': 'OasisLMF', '_key': 'OasisLMF/PiWind/0.0.0.1', '_resources': {'canonical_exposures_profile': {'WSCV5VAL': {}, 'COUNTYCODE': {}, 'YEARUPGRAD': {}, 'WSCV5DED': {}, 'WSCV7LIMIT': {}, 'NUMBLDGS': {}, 'BLDGCLASS': {}, 'WSCV1LIMIT': {'PerilID': 1, 'FMTermGroupID': 1, 'CoverageTypeID': 1, 'ProfileType': 'Loc', 'FMTermType': 'Limit', 'ProfileElementName': 'WSCV1LIMIT', 'FMLevel': 1, 'FMLevelName': 'Coverage', 'FieldName': 'CoverageLimit'}, 'COND1NAME': {'FieldName': 'SubLimitReference', 'ProfileElementName': 'COND1NAME'}, 'COND1TYPE': {}, 'WSCV3DED': {}, 'COND1DEDUCTIBLE': {'DeductibleType': 'B', 'FMTermGroupID': 1, 'ProfileType': 'Loc', 'FMTermType': 'Deductible', 'ProfileElementName': 'COND1DEDUCTIBLE', 'FMLevel': 4, 'FMLevelName': 'Sublimit', 'FieldName': 'SubLimitDeductible'}, 'CITYCODE': {}, 'WSCV1VAL': {'PerilID': 1, 'FMTermGroupID': 1, 'CoverageTypeID': 1, 'ProfileType': 'Loc', 'FMTermType': 'TIV', 'ProfileElementName': 'WSCV1VAL', 'FMLevel': 1, 'FMLevelName': 'Coverage', 'FieldName': 'TIV'}, 'POSTALCODE': {}, 'WSSITELIM': {'FMTermGroupID': 1, 'ProfileType': 'Loc', 'FMTermType': 'Limit', 'ProfileElementName': 'WSSITELIM', 'FMLevel': 3, 'FMLevelName': 'Site', 'FieldName': 'SiteLimit'}, 'ADDRMATCH': {}, 'LATITUDE': {}, 'WSCV2VAL': {}, 'ROOFGEOM': {}, 'CNTRYCODE': {}, 'WSCV6LIMIT': {}, 'WSCV3LIMIT': {}, 'WSCV8DED': {}, 'WSCV9DED': {}, 'WSCV4LIMIT': {'PerilID': 1, 'FMTermGroupID': 2, 'CoverageTypeID': 1, 'ProfileType': 'Loc', 'FMTermType': 'Limit', 'ProfileElementName': 'WSCV4LIMIT', 'FMLevel': 1, 'FMLevelName': 'Coverage', 'FieldName': 'CoverageLimit'}, 'COND1LIMIT': {'FMTermGroupID': 1, 'ProfileType': 'Loc', 'FMTermType': 'Limit', 'ProfileElementName': 'COND1LIMIT', 'FMLevel': 4, 'FMLevelName': 'Sublimit', 'FieldName': 'SubLimitLimit'}, 'WSCV7VAL': {}, 'WSCV9LIMIT': {}, 'CNTRYSCHEME': {}, 'STATE': {}, 'WSCV9VAL': {}, 'CITY': {}, 'WSCOMBINEDDED': {'DeductibleType': 'B', 'FMTermGroupID': 1, 'ProfileType': 'Loc', 'FMTermType': 'Deductible', 'ProfileElementName': 'WSCOMBINEDDED', 'FMLevel': 2, 'FMLevelName': 'Combined', 'FieldName': 'CombinedDeductible'}, 'WSCV2DED': {}, 'WSCV3VAL': {}, 'LOCNUM': {}, 'WSCV1DED': {'PerilID': 1, 'DeductibleType': 'B', 'CoverageTypeID': 1, 'FMTermGroupID': 1, 'FMTermType': 'Deductible', 'ProfileElementName': 'WSCV1DED', 'ProfileType': 'Loc', 'FMLevel': 1, 'FMLevelName': 'Coverage', 'FieldName': 'CoverageDeductible'}, 'OCCSCHEME': {}, 'WSCV5LIMIT': {}, 'WSCV6DED': {}, 'WSCV4DED': {'PerilID': 1, 'DeductibleType': 'B', 'CoverageTypeID': 1, 'FMTermGroupID': 2, 'FMTermType': 'Deductible', 'ProfileElementName': 'WSCV4DED', 'ProfileType': 'Loc', 'FMLevel': 1, 'FMLevelName': 'Coverage', 'FieldName': 'CoverageDeductible'}, 'YEARBUILT': {}, 'WSCV2LIMIT': {}, 'WSCV10LMT': {}, 'WSCV4VAL': {'PerilID': 1, 'FMTermGroupID': 2, 'CoverageTypeID': 1, 'ProfileType': 'Loc', 'FMTermType': 'TIV', 'ProfileElementName': 'WSCV4VAL', 'FMLevel': 1, 'FMLevelName': 'Coverage', 'FieldName': 'TIV'}, 'STATECODE': {}, 'COUNTRY': {}, 'OCCTYPE': {}, 'WSCV6VAL': {}, 'WSCV10DED': {}, 'BLDGSCHEME': {}, 'WSCV8LIMIT': {}, 'NUMSTORIES': {}, 'COUNTRYGEOID': {}, 'WSSITEDED': {'DeductibleType': 'B', 'FMTermGroupID': 1, 'ProfileType': 'Loc', 'FMTermType': 'Deductible', 'ProfileElementName': 'WSSITEDED', 'FMLevel': 3, 'FMLevelName': 'Site', 'FieldName': 'SiteDeductible'}, 'WSCV10VAL': {}, 'WSCV7DED': {}, 'ACCNTNUM': {'FieldName': 'AccountNumber', 'ProfileType': 'Loc', 'ProfileElementName': 'ACCNTNUM'}, 'WSCV8VAL': {}, 'ROW_ID': {'FieldName': 'LocationID', 'ProfileType': 'Loc', 'ProfileElementName': 'ROW_ID'}, 'WSCOMBINEDLIM': {'FMTermGroupID': 1, 'ProfileType': 'Loc', 'FMTermType': 'Limit', 'ProfileElementName': 'WSCOMBINEDLIM', 'FMLevel': 2, 'FMLevelName': 'Combined', 'FieldName': 'CombinedLimit'}, 'COUNTY': {}, 'LONGITUDE': {}, 'CRESTA': {}}, 'source_exposures_validation_file_path': '/home/bloemkoli/OasisPiWind/flamingo/PiWind/Files/ValidationFiles/Generic_Windstorm_SourceLoc.xsd', 'oasis_files_path': '/tmp/analysis_test/tmp', 'lookup': <keys_server.PiWind.PiWindKeysLookup.PiWindKeysLookup object at 0x7f385d007be0>, 'source_exposures_file_path': '/home/bloemkoli/OasisPiWind/tests/data/SourceLocPiWind10K.csv', 'canonical_exposures_validation_file_path': '/home/bloemkoli/OasisPiWind/flamingo/PiWind/Files/ValidationFiles/Generic_Windstorm_CanLoc_B.xsd', 'canonical_exposures_profile_json_path': '/home/bloemkoli/OasisPiWind/oasislmf-piwind-canonical-loc-profile.json', 'source_to_canonical_exposures_transformation_file_path': '/home/bloemkoli/OasisPiWind/flamingo/PiWind/Files/TransformationFiles/MappingMapToGeneric_Windstorm_CanLoc_A.xslt', 'oasis_files_pipeline': <class 'oasislmf.exposures.pipeline.OasisFilesPipeline'>: {'_model_exposures_file_path': None, '_model_key': 'OasisLMF/PiWind/0.0.0.1', '_oasis_files': {'gulsummaryxref': None, 'coverages': None, 'items': None}, '_items_file_path': None, '_source_exposures_file_path': None, '_keys_error_file_path': None, '_gulsummaryxref_file_path': None, '_coverages_file_path': None, '_canonical_exposures_file_path': None, '_keys_file_path': None, '_file_paths': ('source_exposures_file_path', 'canonical_exposures_file_path', 'model_exposures_file_path', 'keys_file_path', 'keys_error_file_path', 'items_file_path', 'coverages_file_path', 'gulsummaryxref_file_path')}, 'canonical_to_model_exposures_transformation_file_path': '/home/bloemkoli/OasisPiWind/flamingo/PiWind/Files/TransformationFiles/MappingMapTopiwind_modelloc.xslt'}}: OasisLMF/PiWind/0.0.0.1
Setting up Oasis files directory for model OasisLMF/PiWind/0.0.0.1
Generating Oasis files for model
Checking output files directory exists for model
Checking for source exposures file
Copying source exposures file to input files directory
Generating canonical exposures file /tmp/analysis_test/tmp/canexp-20180620134838.csv
Generating model exposures file /tmp/analysis_test/tmp/modexp-20180620134838.csv
Generating keys file /tmp/analysis_test/tmp/oasiskeys-20180620134838.csv and keys error file /tmp/analysis_test/tmp/oasiskeys-errors-20180620134838.csv
keys_file_path=/tmp/analysis_test/tmp/oasiskeys-20180620134838.csv, keys_error_file_path=/tmp/analysis_test/tmp/oasiskeys-errors-20180620134838.csv
keys=<generator object OasisKeysLookupFactory.get_keys at 0x7f385cfaeeb8>
STARTED: keys_server.PiWind.PiWindKeysLookup.process_locations
COMPLETED: keys_server.PiWind.PiWindKeysLookup.process_locations in 0.0s
Generating Oasis files for model
Traceback (most recent call last):
  File "/home/bloemkoli/anaconda3/bin/oasislmf", line 7, in <module>
    sys.exit(RootCmd().run())
  File "/home/bloemkoli/anaconda3/lib/python3.5/site-packages/oasislmf/cmd/root.py", line 36, in run
    return super(OasisBaseCommand, self).run(args=args)
  File "/home/bloemkoli/anaconda3/lib/python3.5/site-packages/argparsetree/cmd.py", line 159, in run
    return cmd_cls(sub_command_name).run(args)
  File "/home/bloemkoli/anaconda3/lib/python3.5/site-packages/argparsetree/cmd.py", line 159, in run
    return cmd_cls(sub_command_name).run(args)
  File "/home/bloemkoli/anaconda3/lib/python3.5/site-packages/argparsetree/cmd.py", line 161, in run
    return self.action(args) or 0
  File "/home/bloemkoli/anaconda3/lib/python3.5/site-packages/oasislmf/cmd/model.py", line 621, in action
    gen_oasis_files_cmd.action(args)
  File "/home/bloemkoli/anaconda3/lib/python3.5/site-packages/oasislmf/cmd/model.py", line 407, in action
    logger=self.logger,
  File "/home/bloemkoli/anaconda3/lib/python3.5/site-packages/oasislmf/exposures/manager.py", line 687, in start_files_pipeline
    return self.generate_oasis_files(oasis_model=oasis_model, **kwargs)
  File "/home/bloemkoli/anaconda3/lib/python3.5/site-packages/oasislmf/exposures/manager.py", line 594, in generate_oasis_files
    data_frame = self.load_master_data_frame(**kwargs)
  File "/home/bloemkoli/anaconda3/lib/python3.5/site-packages/oasislmf/exposures/manager.py", line 464, in load_master_data_frame
    [v for v in six.itervalues(canonical_exposures_profile) if v and v.get('FieldName').lower() == 'tiv']
TypeError: unorderable types: dict() < dict()

Sandeep Murthy from the oasislmf team indicated to me that:

This appears to be an error caused by this line (#463 in oasislmf/exposures/manager.py)

tiv_fields = tuple(sorted(
    [v for v in six.itervalues(canonical_exposures_profile) if v and v.get('FieldName').lower() == 'tiv']
  ))

So the sort operation is on a list of dicts and it appears as if dicts cannot be so ordered in Python 3,
unlike Python 2 where this causes no problems.

Add a check to pytest to make sure model_settings was posted

After model reg, check the return from models/{id}/settings exists

Cannot build PiWind keys server

Hello,

I am trying to build and run the PiWind model by following the steps given in the documentation. However, I cannot seem to build the keys server docker image.

Sending build context to Docker daemon  9.212MB
Step 1/24 : FROM coreoasis/oasis_base:latest
pull access denied for coreoasis/oasis_base, repository does not exist or may require 'docker login'

I assume that I need to build/get the coreoasis/oasis_base:latest image first but I have no idea regarding how to build or get that. Is there any link to a documentation that would solve this issue?

Cheers,
Tahiry

OS: ubuntu 17.20
Docker: 17.12.1

Edit:
I cannot find the coreoasis/oasis_base repo here.

How can we generate location level loss for PI wind? like if my one location had TIV of 2000$ then how can I generate loss only particular to that loc?

Add tests for gulmc

Duplicate some of the Gulpy + modelpy testing using gulmc

Broken link in README.md

The link to the JSON configuration file in the README currently points to https://github.com/OasisLMF/OasisPiWind/blob/develop/keys_data/PiWind/lookup.json but this is broken.

No `InuringPriority` column in the test RI info. file

@johcarter The test RI info. file that you added

https://github.com/OasisLMF/OasisPiWind/blob/master/tests/data/SourceReinsInfoOEDPiWind.csv

doesn't contain a column named InuringPriority, which is referenced in the RI module in the MDK

https://github.com/OasisLMF/OasisLMF/blob/develop/oasislmf/exposures/reinsurance_layer.py#L44

This is causing the Oasis files generation command to fail, which means the model run command fails.

...
Writing GUL files

Writing FM files
Generating reinsurance files
Traceback (most recent call last):
...
  File "/Users/srm/Documents/sandeep/cst/dev/oasis/OasisLMF/oasislmf-venv/src/oasislmf/oasislmf/cmd/model.py", line 641, in action
    oasis_fp
  File "/Users/srm/Documents/sandeep/cst/dev/oasis/OasisLMF/oasislmf-venv/src/oasislmf/oasislmf/exposures/reinsurance_layer.py", line 109, in generate_files_for_reinsurance
    for inuring_priority in range(1, ri_info_df['InuringPriority'].max() + 1):
  File "/Users/srm/Documents/sandeep/cst/dev/oasis/OasisLMF/oasislmf-venv/lib/python2.7/site-packages/pandas/core/frame.py", line 2139, in __getitem__
    return self._getitem_column(key)
  File "/Users/srm/Documents/sandeep/cst/dev/oasis/OasisLMF/oasislmf-venv/lib/python2.7/site-packages/pandas/core/frame.py", line 2146, in _getitem_column
    return self._get_item_cache(key)
  File "/Users/srm/Documents/sandeep/cst/dev/oasis/OasisLMF/oasislmf-venv/lib/python2.7/site-packages/pandas/core/generic.py", line 1842, in _get_item_cache
    values = self._data.get(item)
  File "/Users/srm/Documents/sandeep/cst/dev/oasis/OasisLMF/oasislmf-venv/lib/python2.7/site-packages/pandas/core/internals.py", line 3843, in get
    loc = self.items.get_loc(item)
  File "/Users/srm/Documents/sandeep/cst/dev/oasis/OasisLMF/oasislmf-venv/lib/python2.7/site-packages/pandas/core/indexes/base.py", line 2527, in get_loc
    return self._engine.get_loc(self._maybe_cast_indexer(key))
  File "pandas/_libs/index.pyx", line 117, in pandas._libs.index.IndexEngine.get_loc
  File "pandas/_libs/index.pyx", line 139, in pandas._libs.index.IndexEngine.get_loc
  File "pandas/_libs/hashtable_class_helper.pxi", line 1265, in pandas._libs.hashtable.PyObjectHashTable.get_item
  File "pandas/_libs/hashtable_class_helper.pxi", line 1273, in pandas._libs.hashtable.PyObjectHashTable.get_item
KeyError: 'InuringPriority'

These kinds of errors can be avoided by having robust code which uses metadata, rather than hardcoded column names, to process the RI source data. The RI backend code should really be using an RI profile, similar to the canonical profiles or aggregation profiles used in the exposure manager. But the RI implementation isn't mine, so I will leave it at that.

PiWind OED files do not match OasisLMF format expectations

The PiWind OED files contain non-string values in the AccNumber and LocNumber columns. When OasisLMF reads these files, it attempts to read these columns as integers, and fails to convert e.g. "L1".

Additionally, SourceLocOEDPiWind2 is missing the PortNumber column.

Happy to submit a PR with versions that do run successfully, but perhaps it's that OasisLMF that needs the changes, not the files.

Warnings raised during installation

When pip installing the requirements the following warnings are reported. The MDK commands still run.

oasislmf 1.3.3 has requirement pandas>=0.24.0, but you'll have pandas 0.22.0 which is incompatible.
oasislmf 1.3.3 has requirement requests>=2.20.0, but you'll have requests 2.18.4 which is incompatible.
oasislmf 1.3.3 has requirement shapely>=1.6.4.post1, but you'll have shapely 1.5.13 which is incompatible.

New PiWind release needed

PiWind OED Input files have been updated in develop branch. They need to be released to fix an error in fmcalc when running latest oasislmf against PiWind master or latest release. Also needs testing.
Issue first raised in
OasisLMF/OasisLMF#312
And by two members

Running PiWind via MDK

Continuation of OasisLMF/OasisLMF#94

Binder fails to run `oasislmf`

running_piwind.ipynb in Binder fails to run the line:

oasislmf model run -C oasislmf.json -r /tmp/analysis_test

returning:

Starting model run (@ 2019-Feb-21 08:42:51)

Creating Oasis files directory /tmp/analysis_test/input/csv
source_exposure_file_path could not be found in the command args or config file (/home/jovyan/oasislmf.json) but is required

This results in the visulisation in the next code block failing with

IOError: File /tmp/analysis_test/output/gul_S1_leccalc_full_uncertainty_aep.csv does not exist

Remove deprecated structure

Remove deprecated structure. Specifically:

• Flamingo
• src/model_execution_worker/OasisLMF/supplier_model_runner.py

Review rest of repo to make sure it is current.

Added update expected results option to CI workflow

Add --update-results flag to pytest, this should bypass the output checks and instead extract the result tars to the expected output directories.

Setting an option on a manual job trigger update-results=True should use pytest_opts to pass that option to pytest

OasisPiWind/.github/workflows/integration.yml

Lines 74 to 77 in 6b0dd47

	pytest_opts:
	description: 'pass extra options to pytest'
	required: false
	type: string

OasisPiWind/.github/workflows/test.yml

Lines 122 to 129 in 6b0dd47

	with:
	piwind_branch: ${{ needs.params.outputs.piwind_branch }}
	ods_package: ${{ needs.params.outputs.ods_package }}
	oasislmf_package: ${{ needs.params.outputs.oasislmf_package }}
	oasislmf_branch: ${{ needs.params.outputs.oasislmf_branch }}
	worker_tag: ${{ needs.params.outputs.platform_version }}
	server_tag: ${{ needs.params.outputs.platform_version }}
	debug_mode: 0

    with:
      pytest_opts: '--update-results'
        ..

See: #119 (comment) and #119 (comment)

Issues with vulnerability file

Validating vulnerability file yields following errors:

$ vulnerabilitytocsv < vulnerability.bin | validatevulnerability 
Vulnerability ID 1: 29 out of 58 intensity bins present
Vulnerability ID 2: 29 out of 58 intensity bins present
Vulnerability ID 3: 29 out of 58 intensity bins present
Vulnerability ID 4: 29 out of 58 intensity bins present
Vulnerability ID 5: 29 out of 58 intensity bins present
Vulnerability ID 6: 29 out of 58 intensity bins present
Some checks have failed. Please edit input file.

Cannot clone submodules.

PiWind README is specifying --recursive in order to clone the repository. However, submodules are not accessible. Is there a plan to open source them in a near future? Thank you.

$ git clone --recursive [email protected]:OasisLMF/OasisPiWind.git
Cloning into 'OasisPiWind'...
...
Submodule 'oasis_build_utils' (git+ssh://[email protected]/OasisLMF/oasis_build_utils) registered for path 'oasis_build_utils'
...
ERROR: Repository not found.
fatal: Could not read from remote repository.

Please make sure you have the correct access rights
and the repository exists.
...
Failed to clone 'oasis_build_utils' a second time, aborting

How to install multiple model files?

PiWind demo model files are copied to flamingo_share/model_data directory. Model files used by ktools have standard names.

How can we add another model to the same server without overriding existing model files?

Update PiWind CI checks to include all of the output reports

Issue OasisLMF/OasisLMF#1283 was missed and released into production because the pltcalc report is not set in the example PiWind tests.

Add an extra test which runs all the output reports so this won't reoccur

Output losses divided on Coverage Type

Can we have losses on Coverage Types? Like one loss for Business Interruption and other for Content of Building and Business Interruption?

update exposures to be valid oed format