Growth (VBGF) and Age-Length Key Data

Required columns: 'Length' in millimeters (mm) and 'Age' in years.
Leave a box empty to draw a new seed each run. Please enter the seed reported on the right to repeat an earlier run exactly.
Optional: Upload Your Own ALK
Use the button above to generate an ALK from the uploaded length-age data. You may instead upload your own ALK to replace the generated table.
Required columns: 'Age' in years, 'n' as the sample count, 'Length' as mean length in mm, and 'Lengthsd' as standard deviation in mm.

Welcome to the sportfish IBM model!

Please verify your data inputs here before proceeding (upload the data, set parameters and click each button on the left).

                          

VBGF bootstrap parameter distributions


                          

Age-Length Key Data

Please review the automatically generated or uploaded ALK currently selected for mortality estimation and population initialization.

Global Parameters

About Global Parameters

Use this step to define the simulation timeline, density-dependent processes, angler-retention behavior, natural mortality, life-history settings, stock–recruitment parameters, and population initialization.

Common units and scales: Fish lengths and size thresholds are entered in millimeters (mm); ages and simulation durations are entered in years; months are entered as integers from 1 to 12; probabilities and proportions range from 0 to 1; and lake area is entered in hectares (ha). Additional units are shown beside the relevant inputs.

Brief guidance only: The descriptions provided in the app are intended as a quick overview. See the user manual for complete variable definitions, equations, recommended ranges, and worked examples.
'Before policy' = Burn in years + Stable years combined.
Please see the user manual for definitions, equations, units, and descriptions of the density-dependent survival and growth parameters.

Density-dependent survival

Density-dependent growth — Adult fish

Density-dependent growth — Juvenile fish

How retention is modeled: After a vulnerable fish is encountered, the model calculates the angler's probability of retaining that fish. The retention inputs below describe angler willingness to retain a fish based on its length. Size-limit legality and compliance are applied separately during policy simulations. Fish lengths on this page are in millimeters (mm).

Retention Probability Curve

Retention-curve parameter definitions

p(L) = p_max / [1 + exp{-slope × (L - L50)}]

  • L50 (mm): The fish length at which retention probability equals one-half of p_max.
  • p_max: The maximum retention probability approached for large fish. Please enter a value from 0 to 1.
  • Slope (per mm): Controls how rapidly retention probability increases with fish length around L50. Larger values produce a steeper curve.

Fixed Retention Probability

When the retention curve is disabled, this probability is applied equally to encountered fish of all lengths before size-limit legality and compliance are considered.

Monthly Fishing-Effort Weights

Please enter 12 non-negative relative weights in calendar order, beginning with January. The model divides each weight by the sum of all 12 weights, so only their relative values matter. At least one weight must be greater than 0.

For equal fishing effort in every month, copy and paste:

1,1,1,1,1,1,1,1,1,1,1,1

Note: On this page, M refers to the Instantaneous Natural Mortality coefficient .

Part A: Juvenile Natural Mortality

Applied to fish younger than the 'Transition Age' (defined in 'Other' tab).

Part B: Adult Natural Mortality

1. Configure Estimation
Leave empty to draw a new seed each run. Please enter the seed reported on the right to repeat an earlier run exactly.

2. Assumed Relationship
Direct Input Mode
Applied uniformly to all adult fish.



                                

Z Estimation Results


                                        

Statistical Summary:

                                      

Total mortality Estimation Status

Z Estimation Plot is Not Available

You are using a fixed adult natural mortality cofficent.

PSD Size Thresholds (mm)

Define length thresholds for Stock, Quality, Preferred, Memorable, Trophy.

Life History & Recruitment Logic

1. Vulnerability Mode
Selected: Length-based. Fish become vulnerable to fishing when they reach 'Stock Size'.
Age-based. Fish become vulnerable to fishing only when they reach the Fishery Recruit Age (see below). Younger fish (below or equal to this age) are protected from fishing regardless of size.

2. Critical Life History Ages
Click here for parameter definitions
  • Maturity age: Age at which fish start contributing to Spawning Biomass (used in R-S relationship).
  • Transition age: Age when biology changes from Juvenile to Adult (used for applying Natural Mortality and as the full recruitment age in Catch Curve analysis).
  • Recruit age (fishery): Reference age used for (i) recruit-related output summaries (e.g., recruit density / fishery recruit abundance) and (ii) when vulnerability Mode = Age-based Fish younger than this age are excluded from fishing encounters in age-based mode.

3. Reproduction & Stock–Recruitment Relationship
R–S parameter definitions
  • R: Recruitment density produced during the spawning event.
  • S: Spawning-stock density at the spawning event.
  • R–S alpha: The density-independent recruitment-rate parameter. It controls recruitment at low spawning-stock density.
  • R–S beta: The density-dependent coefficient. It controls how strongly recruitment is reduced as spawning-stock density increases.
  • Ricker model: R = alpha × S × exp(-beta × S)
  • Beverton–Holt model: R = alpha × S / (1 + beta × S)
Recruits entry month<Spawn month is allowed. If so, new fish will enter population in the next year

Environment & Initialization

Basic physical settings for the simulation.

Validation & Submission




                      

Experiment Design

About Experiment Design

Use this step to define management size-limit scenarios, uncertainty combinations, annual angler-encounter proportions, release-mortality rates, and size-specific compliance assumptions included in the simulation experiment.

Common units and scales: All fish-length thresholds are entered in millimeters (mm). Annual angler encounter, release mortality, and compliance are entered as proportions from 0 to 1. Scenario names are user-defined labels.

Brief guidance only: The descriptions and examples provided in the app are intended as a quick overview. See the user manual for complete variable definitions, equations, recommended ranges, and experiment-design guidance.
Example:
scenario_name,min_len_mm,max_len_mm
Minimum_9,228.6,1000
HarvestSlot_8_12,203.2,304.8
ProtectiveSlot_8_12,304.8,203.2

Tips:

1. All fish lengths must be entered in millimeters (mm).

2. Minimum-length limit:
   Enter the minimum legal length in min_len_mm and a sufficiently large upper value in max_len_mm.
   Example: Minimum_9,228.6,1000

3. Harvest slot:
   Fish within the interval may be retained. Enter the lower boundary in min_len_mm and the upper boundary in max_len_mm.
   Example: HarvestSlot_8_12,203.2,304.8

4. Protective slot:
   Fish within the interval are protected, while fish outside the interval may be retained. Enter the upper boundary in min_len_mm and the lower boundary in max_len_mm.
   Example: ProtectiveSlot_8_12,304.8,203.2

5. The scenario_name column can be named at your discretion.
Multiple comma-separated values may be entered for the applicable experiment-design inputs.
Uncertainty
Reminder: RM is catch-and-release mortality, the probability that a fish dies after being released because it is not legally retained under a size limit.
When values other than 0 are entered, the model adds 0 automatically as a baseline comparison. When only 0 is entered, release mortality is not included.
Policy Inputs
Selecting 'No' applies the size-specific compliance probabilities defined below rather than assuming zero compliance.
Compliance by Size Threshold
Example: Breakpoints entered as “0,200,300” with compliance probabilities entered as “0.7,0.5,0.3” indicate that anglers comply with harvest regulations 70% of the time for fish < 200 mm, 50% of the time for fish from 200 to < 300 mm, and 30% of the time for fish ≥ 300 mm.

Validation & Submission

Please click the button after you determine all sub-panel parameter entry.


                      

Design Preview

Run control

Run on Google Cloud

Runs the simulation on a machine you rent in your own Google Cloud project instead of on this computer. Useful when the population is too large for local memory, or when you would rather not tie up this machine. You are billed by Google for the time the machine runs.
The key stays on this computer. It is never saved into a settings file.
Please choose a machine type in the Google Cloud console that suits your memory and core needs. The container image is produced by this package's GitHub workflow and must be public so Batch can pull it without storing GitHub credentials.


                        

Parallel acceleration

These three methods increase speed by running work concurrently. They may be combined, but their CPU and memory demands also multiply.

                          
                        
1. Replicate parallelism
Runs different repetitions and scenarios simultaneously in separate R worker processes. These are processes, not threads and not a direct request for the same number of CPU cores.

Most useful when: the experiment contains many uncertainty scenarios or iterations that can be completed independently.

Across repetitions
2. Policy parallelism
Uses multiple threads to run management-policy combinations concurrently inside each active replicate worker.

Most useful when: each scenario contains many size-limit or management-policy conditions, such as different compliance or release-mortality assumptions.

Policy combinations will run sequentially.
3. Individual parallelism
Uses OpenMP threads inside each policy calculation to split fish-level survival calculations at each monthly time step.

Most useful when: a single model contains a large fish population and monthly fish-level survival calculations account for much of the runtime.

The standard simulation engine will be used.

Non-parallel acceleration

This method reduces the amount of simulation work without creating additional CPU workers or threads.
Reduced-memory early-life simulation

Newly recruited fish are initially tracked as a group rather than stored as separate individual fish records to speed-up the simulation and save memory.

During this period, the model still applies monthly survival but records the growth history needed to reconstruct individual fish lengths later.

Before any fish reaches a threshold that requires individual-level length or age processing, the surviving fish are converted into individual records and continue through the full simulation.

How is the automatic duration determined?
  • Stock Size boundary: individual lengths must be available before fish can enter length-based fishing and monthly PSD calculations.
  • Age and biology boundary: group tracking must stop before the earliest applicable Maturity Age, Transition Age, or Fishery Recruit Age (age-based vulnerability mode).
  • Calculated safe duration: the model uses the earlier of the stock-size boundary and the age/biology boundary.
Reduces memory and computation

Confirm Run Control

Review and confirm your run-control and acceleration settings before running the test simulation.


                      

Step 3a: Test Simulation

About Test Simulation

Use this step to check the model setup before starting a full simulation. Test 1 examines model behavior and the selected timeline. Test 2 measures speed and memory use on the computer or Google Cloud machine that will run the model.


Test 1: Model Validation

Test 1 is a short model check. It runs one selected scenario, all policies for that scenario, and one replicate.

Use the diagnostic plot to judge whether the burn-in period allows the population to stabilize, whether the stable period provides an appropriate pre-policy baseline, and whether the policy period is long enough to show the management response.

Test 1 also provides a rough estimate of the full-model calculation time. The estimate is rough because this test runs only one model task and does not measure how much simultaneous workers may slow each other down.


Test 2: Parallel Performance Check

Test 2 takes longer because it runs one model worker alone and then runs several model workers at the same time using the parallel settings confirmed in Step 2.

It measures parallel speed, CPU sharing and memory use. The report helps assess whether the selected computer or Google Cloud machine type is suitable for the planned full simulation and provides a more precise calculation-time estimate than Test 1.

Test 2 is strongly recommended but does not block the full simulation. Starting without a current check means that speed, memory use and machine suitability have not been confirmed.

Balanced check: uses a CPU-balanced sample of the configured replicate workers. It is the quicker and safer option to run first.

Optional full-load check: uses every configured replicate worker. It places a heavier load on the machine but provides the most representative pre-run speed and memory report.

Google Cloud note: machine startup and resource availability are controlled by Google Cloud. A job that remains QUEUED or SCHEDULED, or temporarily fails to start, may indicate limited capacity or quota in the selected region rather than an unsuitable model or machine type.

For technical definitions and calculation details, please see the Help Guide.


Cloud test results

When a cloud test finishes, use View Result on its tab to download the result and draw its report. Choose a download folder with the button below. If no folder is selected, the app uses a temporary folder automatically.


What does this test do?
Runs one selected scenario, all of its policies, and one replicate. It checks model output and provides a rough estimate of the full-model calculation time.


Test 1 Report

                              

Model Validation Plot

This plot shows one simulated trajectory. Use it to determine whether the selected burn-in, stable, and policy periods are long enough for the intended analysis.

What does this test do?
Runs a small amount of the real model using the parallel settings confirmed in Step 2. It checks whether simultaneous model workers improve speed and whether the full plan can fit in memory.

Running this test before the full simulation is strongly recommended.

Speed and Memory Report

The report explains whether the selected parallel settings are efficient, whether the estimated memory use is safe, and approximately how long the full simulation may take.

                                
                                  
                                   For definitions and calculation details, please see the Help Guide.
                                
                              

Simulation Control

For a local run, this is where simulation outputs are saved. For a cloud run, this is where the downloaded archive is extracted. Please click 'Browse' to select a folder, or enter a path manually.

Cloud mode is on.
The simulation runs on your rented machine, so the local run mode below does not apply. Results are first stored in Cloud Storage. When you choose Download and prepare results, they are downloaded and extracted into the folder selected above.




System Log:


                        

Check a previous cloud job

Task Distribution Preview


                        
This shows how iterations will be distributed among cores.

Folder Structure Preview

Output_Folder/
  sim_info.log.txt      <<----Good if there is nothing in this file
  size_<scenario_name>__min<min size in mm>__max<max size in mm>/
    scenario_info.csv
    policy_combos_info.csv
    iter0001_before_policy.csv
    iter0001_policy_1.csv
    iter0001_policy_2.csv
    ...
    iter0002_before_policy.csv
    ...
Data is split: 'before_policy' files contain the pre-policy phase and real burn in phase, 'policy_X' files contain the post-policy phase for each policy combo.

1. Load & Select Data

2. Visualization Controls

In the Result Plot:

  • Blue line: The model burn-in end year. Set this year manually using the “Burn-in years (Blue Line)” field above.
  • Red line: The size-limit policy start year. This value is detected automatically from the loaded simulation data.

Result Plot & Legend


Policy Information and Statistics