12 The JurisdictionHS File or Package

12.1 Use an R source File or an R Package?

The abalone harvest strategies that have been implemented in different jurisdictions around Australia differ markedly from each other and do so in multiple ways. Initially, in the early planning stage of the MSE R package (aMSE), it was envisaged that each harvest strategy would be included as a series of R functions within the package. However, it quickly became apparent that such an approach would fix each harvest strategy in a single configuration, which would defeat one of the major advantages of an MSE framework. Thus, it was decided that a better approach would be:

Each jurisdiction to develop and maintain a separate R package that encapsulates all the functions required by their respective harvest strategies and their interaction with aMSE. The use of an R package is likely to be the most efficient option and would help ensure maintenance and modification of the HS within the MSE would adhere to good practices with respect to documentation and transparency. This would also aid each jurisdiction in simplifying the task of becoming more transparent, defensible, and open about each harvest strategy.

However, a viable option, especially when under development, would be:

To have each jurisdictions harvest strategy (HS) defined as a series of functions and constants in a separate R source file that could be source’d into the R environment prior to running the MSE,

The Tasmanian implementation of the MSE started by using a source R file but has moved the functions developed into its own defined R package TasHS. The list of constants used by the TasHS (defined as hsargs within aMSE see later) must still be defined as a global variable when running the MSE.

12.1.1 Important Caveat

It must be emphasized here that any statement in this document concerning the structure and operation of the Tasmanian harvest strategy, which will be used as an example, must not be taken as a formal statement of the HS. That can be found in the actual harvest strategy document (Bradshaw, 2018), which is currently undergoing changes as a result of a formal review as well as suggested changes as a result of the MSE testing. Thus, whatever description is given here must not be taken as “the” Tasmanian harvest strategy at any future time. For details of the implementation of the Tasmanian harvest strategy, read Bradshaw (2018) and the separate documentation to the TasHS R package.

This chapter/section is going to be more technical than others as it involves a description of the interaction between the HS functions and the internal functions running the replicate projections within the aMSE R package.

12.1.2 Where the Harvest Strategy is used in aMSE

Running a scenario within aMSE entails first conditioning the Operating Model within the MSE using biological information relating to maturity, growth, natural mortality, and other productivity related factors. Then any historical fishery data involving catches, catch rates, survey results, and catch sampling results can be used to further condition the model so that its dynamics more closely match the observed dynamics of the fishery being explored. The conditioning period is taken to be that period over which the harvest strategy being tested was not applied (within the aMSE code, this is denoted as a period of hyrs, as in history years). Thus, the assumption is that the harvest strategy begins in the first year of the projections (hyrs + 1) and will continue to be applied in each year of the projections. In Tasmania, the harvest strategy was used informally by the Institute of Marine and Antarctic Sciences (IMAS) to recommend aspirational catches for each statistical block (sau) since 2016 and used formally to identify the block aspirational catches since 2020. Thus, if using data up to the end of 2020, one could start the predictions from 2020 or from 2021. For comparability with other jurisdictions 2021 is used so the assumption is that the HS is used from the start of projections.

The stock dynamics, within the model, are stored in an object called zoneDP (as in zone Dynamics + Projections; see the R_object_structure chapter). For each year (and replicate) within each population, these dynamics are updated to contain another year of the dynamics, which involves the cycle of half of natural mortality, growth, fishing mortality, the second half of natural mortality, and recruitment (with larval movement).

At the start of each year of the projections, within the function doprojections(), data required by the particular harvest strategy being applied is sampled from the MSE’s zoneDP object.

Depending on the HS there may be a need to obtain samples of one or more of:

the commercial cpue,
any available fishery independent index of abundance,
the numbers-at-size in the commercial catch, and
the numbers-at-size predicted for a fishery independent survey, if available.

In addition, the actual catches and the aspirational catches are also required, though these are expected to be the same in South Australia. Currently, no other data streams are supported by the aMSE’s operating model. All these are included in the MSE function doprojections() using the following code.

  hcrout <- makeouthcr(glb,hsargs)  # make an object ready to be filled
# Within aMSE, in the function doprojections is the following loop
  for (year in startyr:endyr) {   # startyr = hyrs+1, endyr = hyrs + pyrs
    if (verbose) cat(year,"   ")  # indicate status of run by year countdown
    for (iter in 1:reps) { # reps = number of replicate projections used
      hcrdata <- getdata(sampleCE,sampleFIS,sampleNaS, # generate the data 
                         sauCPUE=zoneDP$cesau[,,iter], # needed by the HS by
                         sauacatch=zoneDP$acatch[,,iter], # calling getdata
                         sauNAS=list(Nt=zoneDP$Nt[,,,iter],
                         catchN=zoneDP$catchN[,,,iter],
                         NumNe=zoneDP$NumNe[,,,iter]),
                         year=year,decrement=hsargs$decrement)
      hcrout <- hcrfun(hcrdata,hsargs,saunames=glb$saunames) # run the hcr
      popC <- calcpopC(hcrout,exb=zoneDP$exploitB[year-1,,iter], # hcr output
                       sauindex,sigmab=sigmab) #= acatch by SAU or TAC by zone
      # calcpopC has a fleet dynamics model that subdivides the acatch or TAC
      # among the populations within each SAU
    # ...  other code
    }
    # ...  other code
}

The functions relating to the harvest strategy (HS) used in the projections within aMSE have specific names. However, this is not a constraint on the user as some of the arguments of the function doprojections() are the names given to the functions representing sampleCE(), sampleFIS(), and sampleNAS(), each of which can be named as the user wishes (see the help file for doprojections() or do_MSE()). The same thing goes for the getdata() function, which calls the three sampling functions. In TasHS, the function that does the data sampling is called tasdata() and, hence, one of the arguments of do_MSE() and then doprojections(), which is inside do_MSE(), is therefore set as ‘getdata = tasdata’.

Also included in the HS package or source file is the hcrfun, which in Tasmania is the mcdahcr() function this takes the input data from getdata(), runs the implementation of the HS and outputs, at least, the predicted TAC by zone or aspirational catch by SAU, or both. This output is then put into the calcpopC() function (in Tas this is calcexpectpopC()), which uses a relatively simple model of the fleet dynamics (how the divers distribute the quota they have available to them) to determine how the aspirational TAC or acatches by SAU are subdivided among the populations within each SAU. Ideally, the predicted catch by SAU, which is all that can be observed in the real fishery, should approximate how the catches are distributed among the real SAU. This is less difficult to arrange in Tasmania now that there have been meta-rules included in the HS that constrain how far the divers may deviate from the proposed aspirational catch per SAU (statistical block in Tas). That also allows for diagnostic plots of the predicted deviations to be generated from the projections that are used to monitor the MSE simulation performance.

The idea being used is that the getdata() function has arguments that define each of these functions, and also has arguments that reference particular data fields from the dynamic object (zoneDP) so that the data required by the harvest strategy can be sampled or generated by each of the three ‘sample’ functions. Within the doprojections() function the structure of zoneDP consists of:

..$ SAU : num [1:56] 6 6 6 7 7 7 8 8 8 8 …
..$ matureB : num [1:88, 1:56, 1:100] 322 321 320 315 301 …
..$ exploitB: num [1:88, 1:56, 1:100] 281 305 303 298 284 …
..$ midyexpB: num [1:88, 1:56, 1:100] 303 330 329 328 323 …
..$ catch : num [1:88, 1:56, 1:100] 0 0.719 1.441 5.763 15.85 …
..$ acatch : num [1:88, 1:8, 1:100] 0 1 2 8 22 …
..$ harvestR: num [1:88, 1:56, 1:100] 0 0.00236 0.00475 0.01932 …
..$ cpue : num [1:88, 1:56, 1:100] 359 390 389 385 373 …
..$ cesau : num [1:88, 1:8, 1:100] 0 386 385 381 369 …
..$ catsau : num [1:88, 1:8, 1:100] 0 1 2 8 22 …
..$ recruit : num [1:88, 1:56, 1:100] 161023 160996 160943 160725 …
..$ deplsB : num [1:88, 1:56, 1:100] 1 0.998 0.994 0.978 0.934 …
..$ depleB : num [1:88, 1:56, 1:100] 0.853 1.084 1.079 1.061 1.011 …
..$ Nt : num [1:105, 1:88, 1:56, 1:100] 1.61e+05 1.97e-06 …
..$ catchN: num [1:105, 1:88, 1:56, 1:100] 0 0 0 0 0 0 0 0 0 0 …
..$ NumNe : num [1:105, 1:88, 1:56, 1:100] 1.61e+05 1.97e-06 …
..$ TAC : num [1:88, 1:100] 0 20 86 290 775 …

Obviously, if one looks at this after a given run the values seen will differ from these, but the structure remains the same (in this case the 88 will reflect the hyrs + pyrs, the 56 the number of populations used, the 100 the number of replicates used, and the 105 the number of size classes used).

The 4-dimensional arrays holding the numbers-at-size arrays are removed from zoneDP and put into NAS after being output from do_MSE(). However, within doprojections() each object can be individually referenced by population or iteration. Note, in the code above the data pushed into getdata is zoneDP$cesau, zoneDP$acatch, and zoneDP$NAS (a combination of Nt and catchN).

12.1.3 Inclusion of a Jurisdiction’s HS

If using a source file then the constants needed by the HS functions could be included in the source file. If using a library (R package) then either a source file only containing the constants could be used or the hsargs list could be entered explicitly in the R code used to run an MSE scenario in aMSE. For example:

# hsfile <- "TasHS1_Tas.R"
# source(paste0(rundir,"/",hsfile)) # if using a source file of R functions
library(TasHS)                    # if using an independent R library the HS
# constants in a list still need to be made into a global list object
hsargs <- list(mult=0.1, # expansion factor for cpue range when calc the targqnt
               wid = 4, # number of years in the grad4 PM
               targqnt = 0.55, # quantile defining the cpue target
               maxtarg = c(150,150,150,150,150,150,150,150), # max cpue Target
               pmwts = c(0.65,0.25,0.1),  # relative weights of PMs
               hcr = c(0.25,0.75,0.8,0.85,0.9,1,1.05,1.1,1.15,1.2),# multipliers
               hcrm3 = c(0.25,0.75,0.8,0.85,0.9,1,1.1,1.15,1.2,1.25), 
               startCE = 2000, # used in constant reference period HS
               endCE = 2011,   # used in constant reference period HS
               metRunder = 0,  # should the metarules be used. o =
               metRover = 0,   # use metarules
               decrement=1, # use fishery data up to the end of the time series
               pmwtSwitch = 0, # number of years after reaching the targCE to
               stablewts = c(0.4, 0.5, 0.1), # replace pmwts with stablewts
               hcrname="mcdahcr",     # the name of the HCR used
               printmat=NULL)   # An option required in some jurisdictions
# This approach would place the functions making up the Tasmanian Harvest Strategy
# into the main R environment ready for use in a Tasmanian setting.

Each of the members of hsargs fulfils a specific task within the harvest strategy. In the case of the Tasmanian HS the items within hsargs have the following intentions:

mult the multiplier on the performance measure bounds to expand them both upwards and downwards. default value = 0.1 = 10 percent increase and decrease.
wid the number of years over which to calculate the gradient, default value = 4, meaning four years.
targqnt what quantile of the distribution of cpue to use as the target, default value = 0.55.
maxtarg is the maximum cpue target for each sau, this will vary depending on which sau one is working with.
pmwts what weights to give to each of the performance measures. Their order is targetCE, grad4, and grad1 with default values = c(0.65, 0.25,0.1).
hcr is used to translate the overall score between 0 - 10, into a multiplier for the previous aspirational catch.
hcrm3 multipliers used instead of hcr when meta-rule 3 is active.
startCE is the starting year for CPUE used in Tasmania, the default = 1992. Also used as the start year when using constrefhcr() instead of mcdahcr()
endCE the final year of CPUE used in Tasmania when using the constrefhcr, otherwise it is ignored.
metRunder = 2 meta rule 1, when the cpue is below the targCPUE how many consecutive years must cpue rise before a reduction is NOT made. If set to zero then meta-rule 1 is not used.
metRover = 2 meta rule 2, how many consecutive years of increase above the targCPUE must cpue occur before an increase can be made. If set to zero then meta-rule 2 is not used.
decrement = 1 working in the year after the data are available, if decrement = 1 means use all data up to the latest year even if only partial (as in TAS). Using decrement = 2 means omit the final (partial) year of data from the assessment (as in SA).
pmwtSwitch = 4 how many consecutive years of increase above the targCPUE must occur before switching the performance measure weights from pmwts to stablewts and switching the acatch multipliers from hcr to hcr3. If pmwtSwitch = 0 then no change is made to the PM weights or to the acatch multipliers.
stablewts = c(0.4,0.5,0.1), what performance measure weights should be used once pmwtSwitch is triggered.
hcrname = “constantrefhcr” the name of the harvest control rule used. Alternatives in Tasmania could be consthcr() (a constant catch HS) and mcdahcr(), that used a constant reference period defined by startCE and endCE.
printmat = NULL an option to print out a matrix during development, only used in some jurisdictions.

12.2 What Must be Included in the HS File or Package

All harvest strategies (HS) have arguments, settings and other constants that can be altered to influence the performance of the HS (hence hsargs). The Tasmanian HS uses the list as described in the code sequence just above. If, somehow, the HS does not require such constants then hsargs should be set = NULL as hsargs is still required as a global variable by the aMSE code.

The TasHS package currently contains 23 functions but, in terms of interacting with the MSE only eight are used directly. The other fifteen are used by these interacting functions. Within the HS file all of these functions can be called whatever the programmer wishes as they are referenced as arguments for functions within aMSE.

The eight required functions are always needed, even if the data they are supposed to generate is not used. In such cases then a simple function returning NULL will suffice. For example, if no FIS data is currently used in an HS then one might include a function:

tasFIS <- function() { # currently no FIS data is used in TAS
  return(NULL)          # though this may change
} # end of tasFIS

The first three of the required functions are the sampling functions that take output from the operating model and sample the respective data for input into the selected jurisdictions HS. The fourth and fifth functions use the first three to sample simulated fishery data from the MSE projections and then run the harvest control rule. The sixth required function uses the outputs from hcrfun to generate the expected or aspirational catches by sau and by zone, the sum of the sau catches should equal the total zone catch and both are the same as the expected TAC. The last two functions relate to extracting the internal components of the harvest control rule (the scores and weights, etc) so that the operation of the hcr can be monitored. The makeouthcr() function is designed to capture the hcr information as it is generated, while the HSPMs() is used to reconstruct the hcr components after all projections are completed (which is likely to be more efficient computationally, especially if it is not required!).

The eight function names in the listing below are the names as defined in the code base of aMSE. The names used in each jurisdiction can be anything. The start of the call to do_MSE() illustrates how each of the following is an argument in the do_MSE() function and how this provides the opportunity to allocate each of these functions that are internal to aMSE to jurisdiction specific functions residing in an external source file or R package. The eight functions after hsargs, from hcrfun downwards, all need a definition within the jurisdiction’s R package or R source file, even if they only return NULL. Details are given below but are also available in the help for ?do_MSE.

out <- do_MSE(rundir,controlfile, # needs a global definition
              hsargs=hsargs,    # defined as global object, see above
              hcrfun=mcdahcr,   # the main HS function from TasHS
              sampleCE=tasCPUE, # processes cpue data, from TasHS
              sampleFIS=tasFIS, # processes FIS data (see above), from TasHS
              sampleNaS=tasNaS, # processes Numbers-at-Size data, from TasHS
              getdata=tasdata,  # extracts data from zoneDP objects, from TasHS
              calcpopC=calcexpectpopC, #spreads SAU acatch across populations
              makeouthcr=makeouthcr, # generates updateable HS stats object
              fleetdyn=NULL, # an optional function defining the fleet dynamics 
              scoreplot=plotfinalscores, # plots hcr and total scores from HS 
              plotmultflags=plotmultandflags,#plots TAC/acatch multipliers and 
                                             # meta rule flags
              ...
              ...
      
)

sampleCE() is used to sample or select data from the cpue predicted by the MSE. It should also include uncertainty (variability) from the predicted cpue by sau. The output from sampleCE should be the projected cpue data used by the HS function (see hcrfun).
sampleNaS() is used to sample numbers-at-size data from the commercial catch if it is used in the HS. If such data is not used in the HS a function is still required but it can simply return NULL. The output should be the numbers-at-size data expected to be used by the HS function (see hcrfun).
sampleFIS() is used to sample both cpue and numbers-at-size as if they came from fishery independent surveys. Again, if such data is not used then a function is still required but it can simply return NULL (as in tasFIS() immediately above). The output should be any FIS data used by the HS function (see hcrfun).
getdata() calls the three sampling functions as arguments and must expect to receive for each sau, the projected years in each replicate of: 1) the predicted time series of cpue, the time series of expected catches, and a large object containing the expected distribution of the numbers-at-size in the commercial catches, the numbers-at-size in the population prior to fishing mortality, and the numbers-at-size in the population after fishing mortality. The latter two would be needed if a fishery independent survey were to be used. The output from getdata() should be a list containing the data needed by the jurisdictions HS. It should take on the format that suits the programmer as it is they who will be writing the getdata and hcrfun functions. For example, in TasHS, the output of getdata() is a list of the cpue data used, the years used, and the aspirational catches in each sau.
hcrfun() this is the function that represents the harvest control rule. It should take in the output from getdata() and whatever else it requires. It will likely use other functions from the HS file to conduct the calculations required to implement the harvest strategy and its harvest control rule. Its outputs must include, at least, a TAC for the simulated zone in the following year of projections, as well as the expected or aspirational catches for each sau. The Tasmanian HS generates aspirational catches for each sau and sums those to produce a TAC for the simulated zone. The South Australian HS only generates a predicted TAC so it could set the aspirational catches = NULL. Nevertheless, the simulation requires that the total catch is distributed among the available sau and this will likely require the dive fleet dynamics to be modelled so that how effort and subsequent catch is distributed can be estimated. Even where aspirational catches are estimated directly, when a fishery operates there is invariably noise associated with such caches and the actual catches by sau differ from the aspirational catches. The final required function is used to model what catches will actually be taken from each sau in the following projection year. In the outputs from the MSE, this is the difference between the acatch (aspirational catches per sau) and the catch (the actual catch per sau).
calcpopC() a function that takes the output from the hcrfun (at least the aspirational catches and TAC) and estimates the actual catches per sau. This may entail application of some dive fleet dynamics to decide the distribution of catches/effort, as well as the application of noise to include uncertainty in the simulations. Even if management in a jurisdiction only generates a zone-wide TAC the projections require a method for predicting the actual catches taken from each sau (which then need to be distributed across each sau’s populations).
makeouthcr() function (which by chance has an identical name in TasHS) should be designed to harvest the hcr scores while the projections are proceeding. This option sounds sensible but has the disadvantage that it will lead to large R objects, needed to store each iteration’s hcr outputs, being passed back and forth between aMSE and the external functions. If these objects become very large, which is very possible if the data includes the size-composition data, this will become very inefficient.
fleetdyn() a function that defines the fleetdynamics used by aMSE to describe how the aspirational catches are then distributed across the sau. If not used, as is currently the case in Tasmania, then set this to NULL.
scoreplot() plots the hcr scores and final scores. This will be unique to each jurisdiction’s harvest strategy and should be included in either the same source file or package as the harvest strategy itself, or a separate source file to be included when defining each scenario.
plotmultflags() like scoreplot this will be unique to each jurisdiction’s harvest strategy and should be included in either the same source file or package as the harvest strategy itself.

12.3 Outputs from Each Harvest Strategy

12.3.1 aMSE Implementation

A typical scenario run of the aMSE software, after the initial setup of directories, and populating hsargs, might appear as follows:

out <- do_MSE(rundir,controlfile,hsargs=hsargs,hcrfun=mcdahcr,  
              sampleCE=tasCPUE,sampleFIS=tasFIS,sampleNaS=tasNaS,
              ...)

The important part is the generation of the out object (a long list of result objects), which can then be used for plots and eventually within comparisons with other scenarios.

The primary object relating to the harvest control rule performance is termed outhcr, as in ‘output of the harvest control rule’. The different harvest strategies implemented in South Australia, Tasmania, and Victoria, all have different outputs from their harvest strategies.

12.3.2 Tasmania

outhcr for Tasmania is a list of eight 3D arrays of dimension projection_years x SAU x replicates.

g1s : num [1:30, 1:8, 1:250] 3.612 8.985 … gradient 1 scores
g4s : num [1:30, 1:8, 1:250] 6.074 6.171 … gradient 4 scores
targsc : num [1:30, 1:8, 1:250] 2.442 3.759 … target cpue scores
finalsc : num [1:30, 1:8, 1:250] 3.467 4.885 … final combined scores
index : num [1:30, 1:8, 1:250] 4 5 1 2 2 4 … TAC mult index from hsargs
catchmult: num [1:30, 1:8, 1:250] 0.85 0.9 … TAC multiplier value
metaflag : num [1:30, 1:8, 1:250] 0 0 0 0 0 0 … which metarule occurred
cetarg : num [1:30, 1:8, 1:250] 121 121 120 … the CPUE target

12.3.3 South Australia

outhcr for South Australia is a list of 12 3D arrays of dimension projection_years x SAU x replicates. The cesau and catch are included in their outhcr for convenience.

cesau : num [1:30, 1:8, 1:250] 100.5 94.4 113.9 34.9 45.2 …
CPUE_score : num [1:30, 1:8, 1:250] 0.607 0 2.519 0 0 …
FIS_score : num [1:30, 1:8, 1:250] NA NA NA NA NA NA NA NA NA NA …
Combined_score : num [1:30, 1:8, 1:250] 0.607 0 2.519 0 0 …
Score_carried : num [1:30, 1:8, 1:250] 0 0 0 0 0 0 0 0 0 0 …
catch : num [1:30, 1:8, 1:250] 16 7 0.619 0.621 2.292 …
prop_TAC : num [1:30, 1:8, 1:250] 0.0282 0.0267 0.0255 0.026 0.027 …
Weighted_SAU_score: num [1:30, 1:8, 1:250] 0.0171 0 0.0643 0 0 …
Zone_score : num [1:30, 1:8, 1:250] 0.972 0.298 1.077 0 0 …
Adjustment : num [1:30, 1:8, 1:250] 0.02 0.02 0.117 0.02 0.02 …
Base_TACC : num [1:30, 1:8, 1:250] 1141 1141 1141 1141 1141 …
TACC : num [1:30, 1:8, 1:250] 22.2 22.7 81.4 21 21.3 …

12.3.4 Victoria

outhcr for South Australia is a list of 28 3D arrays of dimension projection_years x SAU x replicates.

Limit : num [1:30, 1:8, 1:250] 80 80 80 …
Thres : num [1:30, 1:8, 1:250] 120 120 …
Target : num [1:30, 1:8, 1:250] 170 170 …
Mean.CPUE.5 : num [1:30, 1:8, 1:250] 101.3 82.3 …
Mean.CPUE.4 : num [1:30, 1:8, 1:250] 82.3 78 88 …
Mean.CPUE.3 : num [1:30, 1:8, 1:250] 78 88 96.8 …
Mean.CPUE.2 : num [1:30, 1:8, 1:250] 88 96.8 …
Mean.CPUE.1 : num [1:30, 1:8, 1:250] 96.8 100.5 …
Mean.CPUE.0 : num [1:30, 1:8, 1:250] 100.5 94.4 …
CurrentStatus : chr [1:30, 1:8, 1:250] “Limit to Threshold” …
Years.At.Current.Status: num [1:30, 1:8, 1:250] 3 4 5 1 2 …
CCROld : chr [1:30, 1:8, 1:250] “1” “1” …
CCR : chr [1:30, 1:8, 1:250] “1” “1” …
yr4Gradient : num [1:30, 1:8, 1:250] 9.62 2.49 …
PrimaryIndicator : chr [1:30, 1:8, 1:250] “Increasing” …
yr2ratio : num [1:30, 1:8, 1:250] 3.8 -6.1 16.7 …
SecondaryIndicator : chr [1:30, 1:8, 1:250] “Stable” …
PrimaryCategory : chr [1:30, 1:8, 1:250] “Increasing” …
FinalCategory : chr [1:30, 1:8, 1:250] “Increasing” …
OT : num [1:30, 1:8, 1:250] 7 7.84 7.42 …
OT.lower : num [1:30, 1:8, 1:250] 7 6.66 7.05 …
OT.upper : num [1:30, 1:8, 1:250] 8.05 7.45 …
acatch : num [1:30, 1:8, 1:250] 7.84 7.42 …
TAC : num [1:30, 1:8, 1:250] 473 382 364 …
boundup : num [1:30, 1:8, 1:250] -5 -5 -5 -5 …
boundown : num [1:30, 1:8, 1:250] 5 5 5 5 5 5 …
boundratioup : num [1:30, 1:8, 1:250] -5 -5 -5 -5 …
boundratiodown : num [1:30, 1:8, 1:250] 5 5 5 5 5 5 5 …