[48hrs] Quartz Energy - Water saturation estimate API updates challenge

Challenge Objectives

 

• Flask Rest API updates

 

Project Background

• Our client has developed a specific method of estimating irreducible water saturation from capillary pressure data

• All the calculations are currently in an Excel workbook - our goal is to create an API to store and process the data, i.e. move the calculations from Excel into the codebase.

• In this challenge, we’ll make updates to the calculations and the output format

 

Technology Stack

 

• Python 3

• Flask

• Flask-Restplus

• MongoDB

 

Code access

 

The base code is available in the project repository. See forums for repository access details. Calculation specification document and sample Excel file are available in the forums. We recommend reading these files before moving on to the next section of the challenge spec.

 

Individual requirements

 

1. Add additional output to the calculations response
   We need to add Swirr[i], Pe[i] and lambda[i] values to the response - these values are already calculated in the current code so the task is just adding them to the response and updating swagger/postman/docs/tests. Also, we need to add two more charts to the output:
   * Swn[i], Capilary Pressure
   * Sw[i], lambda[i]

2. Update lambda calculation
   Current lambda calculation takes into account all the positive lambda values and that causes poor fit of pc_model values to the original water saturation values. lambda[i] values to calculate the final lambda value are chosen manually in excel and we don’t have an exact criteria, so for this challenge we need to consider lambda[i] values that are within one standard deviation (negative values should still not be used). This should get rid of most lambda[i] outlier values. Also, test the calculation with all the examples provided in the excel input to check if there are any cases where our calculations produce a bad fit to the original data (see the screenshot in the forums for an example of a bad fit)

 

General requirements

 

• Unit tests are required for all endpoints.

• All endpoints should be annotated with Swagger annotations and swagger UI should be served by the API.

• All configuration parameters should be extracted to a common settings module. Sensitive configuration parameters should be set from environment variables (DB URL, credentials, etc).

• Please make sure your code is well-documented. Use the following style guides Google Python Style Guide, Python Style Guide, and Docstring Conventions. Code linter is required. Please make sure it is well-engineered but not over-engineered (YAGNI and KISS) solution. We're looking for well-structured and tested code. Well-structured code follows good design principles like the SOLID principles and well-tested code has comprehensive unit tests.

• The code should be implemented using Python3 only.

 

What To Submit

 

• All source code

• Deployment guide

• Postman collection containing sample calls for all endpoints (success/failure)

• Verification guide - how to set up the environment, start the API, and verification screenshots

• The unit tests coverage report

 

Scoring Methodology

 

Contest Specification Requirements(60% weightage)

 

·       Have all major specification requirements been met?

Score: 0-9

Major requirements are:

·       all endpoints are implemented correctly and return the correct data and codes, etc,

·       all DB models are defined and contain correct attributes and data types

·       Unit tests - minimum coverage 80%

                       Have all major specification requirements been met?

Score: 0-3

Minor requirements are:

 

·       Postman collection

·       Swagger annotations

 

Best Practices & Comments(30% weightage)

 

·       Does the submission follow standard best practices?

Score: 0-3

This section includes the PEP-8 code style, linter, patterns usage, code comments

Please make sure your code is well-documented. Use the following style guides Google Python Style Guide, Python Style Guide, and Docstring Conventions. Code linter is required. Please make sure it is well-engineered but not over-engineered (YAGNI and KISS) solution. We're looking for well-structured and tested code. Well-structured code follows good design principles like the SOLID principles and well-tested code has comprehensive unit tests.

 

Deployment and verification guide (10% weightage)

 

·       Does the deployment guide contain everything needed to successfully configure and deploy the API?

Score: 0-3

 

Final Submission Guidelines

See above.