Problem Statement

NOTE for former competitors: This contest is a repost, however we have made changes in the problem statement. Please read it carefully.

Background

Customer is seeking to optimize a dynamic fluid algorithm to help better model and predict characteristic efficiencies for solutions that are ultimately tested and brought to market. The current solution exists in Octave/Matlab and the customer is looking for a re-factored algorithm in alternative software languages that compute at a significantly higher speed, while remaining accurate.

Prizes

1st : $7,000

2nd : $4,000

3rd : $2,000

4th : $1,000

Milestone prizes:

• First 2 participants who receives a score greater than 2,500,000 on the provisional test cases receives $250 each
• First participant who receives a score greater than 4,400,000, 4,720,000, 4,814,000, 4,860,000, 4,888,000, and 4,910,000 will each receives $500. These scores are approximately 5x, 10, 15x, 20x, 25x, and 30x performance improvements compared to the baseline solution.

You can win multiple milestone prizes, even with one submission.

Please be aware that that evaluation of the submissions is a manual process for this contest and if you make multiple submissions between two evaluations, only your last submission date counts.

Task

Your task in this contest is to improve the performance of the customer's benchmark solution while you maintain the overall accuracy.

The simulation is of a certain class of fluid-flow problems. Therefore, the simulation needs to match the benchmark solution in several variables (e.g. concentration, velocity) at several time points.

Competitors do not have to implement the "relative stopping criteria", and can ignore any references to "stoprel" or "plotfn".

The algorithm that needs to be tuned is proprietary code (written in Octave/Matlab). The simulation utilizes the Lattice Boltzmann Method (LBM) of fluid flow. You can find the following resources useful:

• Palabos
• OpenLB
• Sailfish

The solution should be GPU-optimized code. Evaluation will be done on Standard_NC12 Azure virtual machines.

Specification of the docker host VM

Ubuntu 18.04.1 LTS (GNU/Linux 4.15.0-1035-azure x86_64)
Docker version 18.09.0, build 4d60db4
NVIDIA Docker 2.0 installed
NVIDIA Driver Version: 410.79
CUDA Version: 10.0

Benchmark solution

You can download current Octave/Matlab solution from here.

You can check out the current solution by following these steps:

1. Copy lbmst.m file and jsonlab folder to one of the test case folders
2. Cd into that folder
3. Run the following command from terminal

octave --no-gui --eval "lbmst('<<test case name>>.json')" --no-line-editing -V -f

1. See the files generated in the res folder

Input files

You can find the training data here.

The .json file is the main input deck specifying the dimensions of the domain, boundary conditions, material characteristics and reporting information. Among the details are domain specifications which are in named binary files described next. A detailed description of the .json input file specification can be found in the APPENDIX at the end of the problem statement.

All .dt files are binary files containing the domain values at each lattice points. All binaries are arrays of double-precision floats, whose dimensions depend on the variables (see the JSON file definition above).

For a complete understanding of the input files please refer to the benchmark solution.

Output files

At specified time increments, the current states of the field variables (e.g. density) are written to disk as binary files in the same format as the initial conditions in the .dt files.

At every time increment (or less often, depending on the sampling frequency) various summary metrics are calculated and written to a CSV file. You may find this a convenient first check as you implement new capability.

Both CSV and DT files need to be created.

For a complete understanding of the output files please refer to the benchmark solution.

Submission

There will be 22 training test cases, 14 provisioning test cases, and 7 system testing test cases. System testing will include both provisioning and system testing test cases.

Timeout for running provisioning test cases is 50 minutes. For system testing it is 70 minutes.

Benchmark score for traning data is 1,245,589. For provisioning it is 2,182,534, and for system testing it is 1,387,444. See scoring details below in the Scoring section.

For manual evaluation

Your solution must be able to evaluated by building and running a docker image. We're going to invoke the following docker commands:

docker build -t "$YOUR_DOCKER_IMAGE" "$YOUR_SUBMISSION_FODLER"

For each test case we will invoke:

docker run --runtime=nvidia --name eval -v "$TESTCASE_FOLDER":/test:ro -v "$RESULT_FOLDER":/result "$YOUR_DOCKER_IMAGE"

Running time is going to be extracted the following way:

START=$(docker inspect --format='{{.State.StartedAt}}' eval)
STOP=$(docker inspect --format='{{.State.FinishedAt}}' eval)
START_TIMESTAMP=$(date --date=$START +%s%N)
STOP_TIMESTAMP=$(date --date=$STOP +%s%N)

RESULT=$((($STOP_TIMESTAMP-$START_TIMESTAMP)/1000000))
echo "$RESULT" milliseconds

docker container rm eval

The content of the /test folder as follows:

|-- test
    |-- *.dt
    |-- <<test case name>>.json

The content of the /result folder should be as follows:

|-- result
    |-- *.dt
    |-- <<test case name>>.csv

For the TopCoder platform

You're required to implement one method, getURL() that returns a String corresponding to the URL of your answer (.zip) for direct download.

The zip file must contains everything we need to build a docker image from your code and be able to evaluate test cases as described above.

|-- submission.zip
    |-- Dockerfile
    |-- *.* (files needed for your solution to build and run)

You may upload your .zip file to a cloud hosting service such as Dropbox which can provide a direct link to your .zip file. To create a direct sharing link in Dropbox, right click on the uploaded file and select share. You should be able to copy a link to this specific file which ends with the tag "?dl=0". This URL will point directly to your file if you change this tag to "?dl=1". You can then use this link in your getURL() function. You can use any other way to share your result file but make sure the link you provide should open the filestream directly.

Scoring

Both CSV and DT files need to be created. They both are validated that they are correct within a tolerance. The DT files each must have both relative and absolute error less than 1e-6 for each value. The CSV file is checked to produce the same number of lines/steps as well as the same columns in order, but also for accuracy of all the columns as well. The CSV file can have a maximum of 1e-2 relative and absolute error for each column, because it may have lower precision.

The following formula is used to check the accuracy:

|x - \hat{x}| < tolerance OR (|x| > 1e-9 AND |x - \hat{x}| / |x| < tolerance) where x is the benchmark value and \hat{x} is the output of the contestant's solution

Final score is calculated as follows: if we fail to build or run your submission you get a score of -1. If your submission fails to produce the right output or fail the accuracy check of any test cases your final score is 10,000 * number_of_test_cases_passing_accuracy_and_output_check. Otherwise, you final score is 5,000,000 - total_time_needed_to_run_all_the_test_cases_in_milliseconds.

Evaluating your submission

Evaluation is going to be done in two parts:

1. Whenever you make a submission you will get a score of 0.
2. Once a day we manually evaluate all submissions with a score of 0 by running your docker image on the provisioning test cases and update leaderboard based on the results. Your score will be as stated above.

Requirements to win a prize

In order to receive a prize, you must do all the following after system testing is done:

• You must be ranked in the TOP 4.
• You must obtain a final score greater than 4,640,000
• The customer is seeking a GPU-optimized solution. Pure CPU algorithms will not meet the criteria.
• Once the final scores are posted and winners are announced, the prize winner candidates have 3 days to submit a report outlining their final algorithm explaining the logic behind and steps to. If your report is not sufficient, you will be contacted for clarifying questions. If your report is not complete, or able to sufficiently demonstrate a working system, your submission may be rejected. Reports will be reviewed for technical merit, but will not be judged on the writing style, grammar, or language.
• If you place in a prize-winning rank but fail to do any of the above, then you will not receive a prize, and it will be awarded to the contestant with the next best performance who did all of the above.

APPENDIX

JSON file format

The JSON file has the following key:value pairs:

• "dim": dimensions of the computational domain, in lattice units [Ny,Nx,Nz]
• "nphase": the number of phases (maximum 4)
• "tsim": the number of time steps
• "increment" (opt): a list of integers of the time steps where the domain variables are written to disk
• "domain": a dictionary of properties and the file names of the binary files containing the domain values at each lattice points. Definitions and dimensions are shown below.
  • "density": density of fluids [Ny,Nx,Nz,nphase]
  • "porosity": porosity [Ny,Nx,Nz,nphase]
  • "ns": scattering [Ny,Nx,Nz,nphase]
  • "tau": relaxation [Ny,Nx,Nz,nphase]
  • "gravity": gravity [Ny,Nx,Nz,nphase,3]
  • "G" (opt): fluid-fluid interaction [Ny,Nx,Nz,npairs] where npairs is number of fluid interaction pairs (choose(nphase,2)). Default: [].
  • "Gads" (opt): fluid-solid interaction [Ny,Nx,Nz,nphase]. Default: [].
  • "rhoWall" (opt): effective wall density [Ny,Nx,Nz,nphase]
  • "solidMass" (opt):solid mass of each component [Ny,Nx,Nz,ncomp] where ncomp is the number of components determined from the swelling.comp object.
  • "thickness" (opt): thickness [Ny,Nx,Nz]
  • "PSM" (opt): mechanical property [Ny,Nx,Nz]
  • "externalStress" (opt): external stress [Ny,Nx,Nz]
• "YI" (opt): list of list dicts of concentration boundary conditions. Default: []. The length of the top-most list will correspond to the number of phases. Each dict contains a definition for a single boundary condition.
  • "bytype": "conc" only one currently supported.
  • "val": float.
  • "bcfromdir": string of direction ("center").
  • "idx": list of indices
  • "active": null or list of lists. This specifies N "stages" where a condition turns on (1) or off (0). Nx2 matrix of [[time, on/off]; [time, on/off];...]
  • "activeMass": null or list of lists. This specifies N "stages" of either fluid influx or wait periods. If a fluid influx stage, the row is [-1 mass_influx]; If a wait, the row is [time_wait 0].
  • "rampTime": float for how long the transition is from on/off.
• "ZH" (opt): list of dicts of pressure-velocity boundary conditions. Similar to YI, with the following exceptions.
  • "bctype": pressure ("pres") or velocity ("vel")
  • "val": if pressure, this is a scalar. If a velocity, this is a list (floats for each direction).
  • "bcfromdir": "north","south","east","west".
• "rhoFluid": density of the fluid [nphase]
• "flowMode": mode of flow [nphase] or [Ny,Nx,Nz,nphase]
• "activePhase": boolean flag [nphase] for whether a phase is passively (0) or actively (1) convected.
• "roi" (opt): a dictionary of a region of interest summary variable.
  • "label": name of the summary variable for the history request.
  • "var": the field variable name
  • "stat": the statistical measure (quantile, mean, std)
  • "idx": list of indices which to aggregate the measure over.
• "swelling" (opt): dictionary of swelling component properties. Default: [].
  • "gamma": surface tension [scalar float]
  • "nu": viscosity [scalar float]
  • "mu": viscosity2 [scalar float]
  • "T": parameter related to permeability [scalar float]
  • "comp": list of list of dicts related to each solid component.
• "shape": shape factor [float]
• "rho": dry density [float]
• "radius": dry radius [float]
• "timeConstant": swelling time constant [float]
• "capacity": swelling capacity [float]
• "contactAngle": contact angle of solid [float]
• "history" (opt): dict with "results" key and value of list of strings of parameters to be recorded in CSV at the samplingFrequency.
• "samplingFrequency" (opt): what frequency to write summary information to CSV. Default: 1.

Definition

Examples