* Fishery. This object stores data about each fishery, including a list of FisheryUnits. Each fishery object also has a method to "takeHarvests."

* FisheryUnit. A Fishery can encompass several regions, so a FisheryUnit object is created for each one. Each FisheryUnit has pointers to the Fishery and Region objects it represents, along with a list of HVMort objects (one for each cohort that can be harvested within the FisheryUnit). Each FisheryUnit also has a "Harvest(E)" method, for which an effort scalar "E" is an argument.

* HVMort. This ("Harvest Mortality") object represents the interaction of fishing activity on a single cohort in a single region. It has pointers to the fishery, region, and cohort it represents. It also has a HarvestProcess object to describe mathematically the interaction between fishing effort and the cohort. Its most important method is "Harvest(E)", which directs the computation of fishing mortalities for the associated cohort.

* HarvestProcess. Each HarvestProcess object is derived from an abstract base class that contains a method called "ComputeCatch(E)", where the relative effort scalar "E" is passed in as an argument. The method can differ for each object. For example, when configured to simulate the PSC Chinook Model, all harvest processes use the following equation for legal catch (from PSC chinook model subroutine CatchByFish):

   C = N*HR*E*(1-PNV)

where

   C = legal catch;
   N = cohort abundance;
   HR = base period harvest rate;
   E = relative effort level (ie "FP" in CatchByFish);
   PNV = proportion non-vulnerable.

In a different configuration, some HarvestProcess objects might use an equation like:

   C = N*(1 - exp(q*E))

where

   q = catchability coefficient;
   E = relative effort level.

The important point is that each HVMort can have a different type of ComputeCatch(E) equation, including algorithms for selective fisheries, bag limit fisheries, etc.

* FisheryManager. A model configuration has only one FisheryManager object. This object stores the management policies assigned to each FisheryUnit. For example, one FisheryUnit might have a fixed harvest rate policy, but another might have a forced catch quota policy, while a third might have a fixed escapement policy. The FisheryManager has a method to "takeHarvests".

* FisheryPolicy. Each FisheryPolicy object is derived from an abstract base class that has an EffortScalar (E) as its most important data item. It also has "harvest" method that contains the algorithm for adjusting the effort level to meet the policy goal (eg achieving a catch quota).

* HarvestManager. A model configuration has only one HarvestManager object. This object stores all the parameters required by the HarvestProcess objects, such as the base period harvest rates, FPs, and PNVs.

During program execution, the FisheryManager is called during each timestep. If active during that timestep, it computes fishing mortalities as follows:

a. Loop through the list of Fishery objects in the model and instruct each fishery to compute harvests;

b. Each fishery loops through its list of FisheryUnits and directs each FisheryUnit to compute harvests;

c. Each FisheryUnit asks the FisheryManager to pass back the FisheryPolicy it should use during this timestep;

d. The FisheryPolicy then directs the FisheryUnit to compute its fishing mortalities using effort level E (E = 1 on the first pass);

e. The FisheryUnit loops through its list of HVMort objects and directs each to compute its fishing mortalities using effort level E;

f. Each HVMort object passes the effort level E into the ComputeCatch method of its HarvestProcess object to compute the fishing mortalities for each cohort.

g. Once all the HVMort objects for a FisheryUnit have computed their harvests, the FisheryPolicy object uses it "harvest" algorithm to make any adjustments to the effort level. If adjustments are required to meet the policy objective, steps d through f are repeated until the objective is satisfied.


3. Results of multi-phase catch ceiling algorithm test.

Some fisheries in the PSC Chinook Model that are controlled by catch ceilings have harvests in both the preterminal and terminal time steps (we call these multi-phase ceiling fisheries). The algorithm used to compute catches for these fisheries assumes (1) a single catch ceiling that covers both time steps, and (2) that the input fishing effort levels in both time steps are adjusted by the same relative amounts in order meet the catch ceiling. There is no analytical solution for catches in multi-phase ceiling fisheries, because any change in the preterminal effort changes the stock abundances vulnerable to terminal effort. Instead, the algorithm iterates over both time steps, and on each iteration scales the effort levels in the preterminal and terminal timesteps by the same relative amount until the total catch from both timesteps equals the desired catch ceiling.

The NMFS Coast Model allows catch ceilings to be specified for individual timesteps and regions, but does not have an algorithm to ensure equal relative effort levels across timesteps. Thus, the NMFS Coast Model algorithm works fine for ceilinged fisheries that have catches only in one timestep/region (we call these single-phase ceiling fisheries), but does not work for multi-phase ceiling fisheries (i.e., does not always give the same catches as the PSC Chinook Model).

We were interested in knowing the extent of the differences between the two algorithms. This report describes a simple, but informative, experiment to gain insight into the differences.

We prepared a *.cei file that included 16 fisheries, four of which were multi-phase ceiling fisheries (Alaska Net, Northern Net, Central Net, and WCVI Sport). The base period was defined to be 1979-1984. From 1985-1994, ceilings were forced (i.e., model catches were required to equal the ceiling exactly) for all but two fisheries (North and South Puget Sound Sport), which were forced from 1985-1993. Catch ceilings during the period 1995-1997 were unforced and set extremely high to simulate fishery policy (FP) control (i.e., model catches were always below the ceiling and were not adjusted upward to equal the ceiling; thus, the ceilings had no effect). For 1998 and beyond, ceilings were unforced and set to the average 1991-1994 catches.

Both the PSC Chinook Model and the NMFS Coast Model were run using the same *.cei file data. A catch file (*cat.prn) and escapement file (*esc.prn) were printed for each model. The absolute values of the catch and escapement differences between models were computed.

Tables 1 and 2 give the percentage change from the PSC Chinook Model to the NMFS Coast Model for catches and escapements. (These tables are not included in the email version of the minutes, but will be available on web site discussion page.) The catch results are summarized below:

· Both models gave the same results for the base period 1979-1984;
· Catches in all ceilinged fisheries were the same when the ceilings were forced;
· Catches in all ceilinged fisheries were not the same when ceilings were unforced and set very high (1995-1997);
· Beyond 1997, catches in some ceilinged fisheries were the same, but in others were off by small amounts (the primary exception was the WCVI Sport fishery which had catches up to 10% off);
· Catches in all non-ceilinged fisheries were not the same for all years beyond the base period.

The escapement results are summarized below:

· Escapments were different for all years beyond the base period;
· The greatest differences were in the WCVI stocks (RBT and RBH), which were up to 14% off during the period 1985-1993;
· The GSQ stock also was off by up to 12% during the period 1985-1994.

When ceilings are forced, the PSC Chinook Model algorithm maintains a constant relative EFFORT level between the preterminal and terminal timesteps, whereas the NMFS Coast Model algorithm maintains a constant relative CATCH level between the preterminal and terminal timesteps. Thus, as long as catch ceilings are forced, both algorithms give the same total catch, even for the multi-phase ceiling fisheries (e.g., 1985-1994 period in Table 1). However, each algorithm will distribute the total catch differently between the preterminal and terminal timesteps for the multi-phase ceiling fisheries due to the different assumptions. The difference in catch distribution in the multi-phase ceiling fisheries affects the relative abundances of the stocks, leading to differences in catches in non-ceilinged fisheries and to differences in spawning escapements for individual stocks. The abundance and escapement differences are most pronounced for stocks that are heavily harvested by a multi-phase ceiling fishery, such as the RBH and RBT stocks in the WCVI Sport fishery.

When ceilings are not forced, the effects on catches can be variable, depending on the level of the ceiling. If the ceiling is very low such that the unconstrained model catch in a multi-phase ceiling fishery is always above both the associated preterminal and terminal ceilings in the NMFS Coast Model, the net effect is the same as when ceilings are forced because the catches always have to be reduced to meet the ceiling. For example, during the period 1998-2005 the catches for fisheries 1-3, 5-9, and 21 were identical for both models. For the other ceilinged fisheries, the catches were generally different by a small amount (less than one percent), except for the WCVI Sport fishery, which had differences up to 10%.

The WCVI Sport fishery is an interesting case that deserves further discussion. During the period of forced ceilings (1985-1994), the total catch in the WCVI Sport fishery is the same under both algorithms, but the distribution of the catch is probably very different. This large difference in distribution leads to the large differences in escapements for the RBH and RBT stocks during this period. Once the ceilings become unforced, the catch differences between the two algorithms are large due to the large differences in stock abundances. One unexplained anomaly is that the catch differences are very small during the first three years (1995-1997) of the unforced ceilings.



4. Safe-guarded secant equation solver.

Since each HarvestProcess object can have a different type of algorithm to compute legal catch at the cohort level, a FisheryPolicy object that has a catch quota objective requires a general algorithm that will adjust the effort level in a fishery to meet the quota. Mathematically, we have the following problem:

Find E such that

   C = F(E) = K

where

   C = total catch in a fishery;
   E = relative effort level in the fishery;
   K = desired catch quota;
   F(E) = unknown function.

The unknown function F(E) is the sum of all the unknown HarvestProcess functions for each cohort. The problem can be restated as follows:

Find E such that

   G(E) = F(E) - K = 0.

David Salinger (applied mathematician with Columbia Basin Research) has written and tested code to solve this problem, using what is called the "Safe-Guarded Secant Method." The code is similar to the secant method used in Function RTSEC in Numerical Recipes. One nice feature of this algorithm is that if F(E) is linear (as is the case for the PSC Chinook Model), then the safe-guarded secant method solves in a single iteration, just as the PSC Chinook Model algorithm does. This algorithm will be incorporated into the code in the near future.


5. Production processes code update.

Jim reviewed the different types of production processes used in the PSC chinook model. The two main categories are "hatchery" and "natural", and within each of these categories are "no enhancement" and "enhancement" options. Jim showed that, for all but one stock, the overall production process for a given stock in a given year can be described as either a Ricker function, a Linear function, or some combination of these two functions for different segments of the available spawners. One stock uses natural production with enhancement (i.e., supplementation) and requires a separate algorithm called "EnhancedRicker".

In the new code, each stock has a separate ProductionProcess object for each year. This object contains all the information to compute AgeOneFish from available spawners. In the PSC Chinook Model, the data required to compute production for a given stock may be scattered among several files. In the new code, all the information is consolidated into a single data file. A utility program gathers data from existing files and creates a new token based data file in which the production process for each stock in each year is given as a combination of functions. Examples follow:

* Hatchery Production, No Enhancement:
  Year 1985 #For stock: SPR
    Production Linear 0 6293.42990413514 0.24763225 164.186011245499
  end Year

Linear Parameters:
  Minimum spawners (e.g., 0)
  Maximum spawners (e.g., 6293.4299)
  EV scalar (e.g., 0.2476)
  Slope (e.g., 164.186)


* Hatchery Production, With Enhancement:
  Year 1991 #For stock: RBH
    Production Linear 0 6472 0.10422118 250.635577084189
    Production Linear 6472 14073.0207135901 0.10422118 94.0663138467215
  end Year

NOTE: Slope of function is lower when spawner exceed 6472 (i.e., 250.54 vs 94.07).


* Natural Production, No Enhancement:
  Year 1984 #For stock: AKS
    Production Ricker 0 13148.5429992893 0.0727296397 1.4 18407.960199005 0.173581873724499
  end Year

Ricker Parameters:
  Minimum spawners (e.g., 0)
  Maximum spawners (e.g., 13148.5)
  EV Scalar (e.g., 0.0727)
  Ricker A (e.g., 1.4)
  Ricker B (e.g., 18407.96)
  RecruitAtAgeOne (e.g., 0.1736)


* Hatchery Production, With Enhancement, Excess Natural Spawners:
  Year 1983 #For stock: GSH
    Production Linear 0 5318 0.811555445 101.088866871763
    Production Linear 5318 7387.09069865999 0.811555445 17.5666110352434
    Production Ricker 7387.09069865999 12387.09069866 0.811555445 4.616 79656.4622144751 0.18442657373674
  end Year


* Natural Production, With Enhancement:
  Year 1991 #For stock: GST
    Production EnhancedRicker 0 24822.830231996 0.271089375 3.209 79656.4622144751 0.18151375096647 1 4.616 0.0659 0.3 4604976
  end Year

Enhanced Ricker Parameters:
  Minimum spawners (e.g., 0)
  Maximum spawners (e.g., 24822.8)
  EV Scalar (e.g., 0.271)
  Ricker A (e.g., 3.209)
  Ricker B (e.g., 79656)
  RecruitAtAgeOne (e.g., 0.1815)
  Density Dep Flag (e.g., 1 = density dependence on)
  Productivity Parameter (e.g., 4.616)
  SmoltAtAgeOne (e.g., 0.0659)
  MaxBroodProportion (e.g., 0.3)
  SmoltProductionChange (e.g., 4604976)


Troy also has created a CohortGenerator that is used to determine how many distinct cohorts to divide the AgeOneFish into. Currently, there is just one cohort. However, this option will be important for selective fishery management when fish from a given brood year may be divided into more than one distinct cohort. Future versions of the model may require input parameters to specify how smolts from a given brood are to be modeled as separate cohorts for sex or growth, for example.


6. Input/output methods and utilities.

Jim Norris distributed and discussed the following memo on a proposed data standard for salmon models (this memo also was posted on the discussion page in November).

------ Start Memo --------------

Proposed Salmon Model Data Communication Standard

Background.

Many computer programs and models are used by Pacific salmon researchers and managers. There is a need to communicate information between programs and from individual programs to users. Currently (Nov 1998), there are three general data communication methods:

(1) raw data from one program is used by other programs for further analysis (e.g., FRAM to TAMM communication);

(2) raw data from one program is used by auxiliary programs to create formatted reports (e.g., PSC Chinook Model raw data dump); or

(3) each program creates model specific formatted reports (e.g., PSC Chinook Model and FRAM reports).

Users of the PSC Chinook Model report that the raw data dump technique has been an effective method of creating reports and analyzing output data. My thought is that data communication within and between programs may be improved by creating a Data Communication Standard. Communicating salmon model data between programs and users is similar to communicating navigation data between different types of navigation devices produced by different manufacturers. The National Marine Electronics Associated (NMEA) adopted a voluntary data interfacing standard (called NMEA 0183) to solve this problem. The NMEA 0183 standard insures that a vessel owner can purchase different brands and types of navigation devices (e.g., Furuno Loran C, Northstar GPS, Simrad Depth Sounder, Wood Freeman Autopilot) and be confident that these devices can communicate with each other.

I propose a similar type of data communication standard for salmon models. The sections below outline the idea. Check it out and let me know if you have any suggestions or comments. We plan to try a test implementation of this system during the next month.


The NMEA 0183 Standard.

The basic idea behind the NMEA 0183 standard is to communicate data via standardized "sentences." A data sentence is composed of data fields, the first of which is a sentence identifier. The number and type of data fields is standardized for each type of sentence. For example, all "GPGLL" sentences have four fields (latitude, North or South, longitude, East or West) in addition to the sentence ID and look something like this:

GPGLL,4806.78,N,12245.34,W

Data sentences are streamed from one device to another at periodic intervals. Each device can stream different sentences at different intervals. Receiving devices read each sentence, look at the ID, and then either discard or use the sentence.


Proposed Salmon Model Data Standard.

The basic idea is to stream standardized data sentences from a model to a text file. Then anyone can write a program using any type of software and hardware to read the data stream, extract the data of interest, and use that data as desired (e.g., further analysis or formatted report). The advantage of using standardized data sentences is that users can export any data in any order and at any interval. The disadvantage of this system is that there may be considerable duplication of information in each sentence, thus making for a large output file.


Sample Sentences.

The following sample sentences save data at the lowest possible level.

----- CABN sentence for cohort abundance -----

Field Data Sample
1 Sentence ID CABN
2 Year 1985
3 TimeStep 3 (or TimeStep abbreviation)
4 Region 4 (or region abbreviation)
5 CohortID URB1986WIUUU
6 StartAbn 378947.1438 (a double)

[Note: Each cohort will have a unique identifier code composed of the parent stock abbreviation, the brood year (using all four characters), and a string of single character codes representing each remaining cohort property in a fixed order (e.g., W = wild, I = immature, U = unmarked, U = untagged, etc.)]

----- NMRT sentence for natural mortality -----

Field Data Sample
1 Sentence ID NMRT
2 Year 1985
3 TimeStep 3 (or TimeStep abbreviation)
4 Region 4 (or region abbreviation)
5 CohortID URB1986WIUUU
6 Mortality 25.283949 (a double)

----- FMRT sentence for fishing mortality -----

Field Data Sample
1 Sentence ID FMRT
2 Year 1985
3 TimeStep 3 (or TimeStep abbreviation)
4 Region 4 (or region abbreviation)
5 Fishery 2 (or fishery abbreviation)
6 CohortID URB1986WIUUU
7 LegalCat 345.192837 (a double)
8 ShakerMort 43.1288393 (a double)
9 CNRMort 21.1093994 (a double)

----- CMIG sentence for cohort migration -----

Field Data Sample
1 Sentence ID CMIG
2 Year 1985
3 TimeStep 3 (or TimeStep abbreviation)
4 FromRegion 4 (or region abbreviation)
5 ToRegion 6 (or region abbreviation)
6 NumMigrants 25.49304958 (a double)

If space is a problem in the output file, we could create other sentences that aggregate data. For example:

----- SABN sentence for stock abundance in a region -----

Field Data Sample
1 Sentence ID SABN
2 Year 1985
3 TimeStep 3 (or TimeStep abbreviation)
4 Region 4 (or region abbreviation)
5 StockID URB
6 StartAbn 378947.1438 (a double)

------ CLHD sentence for cohort life history data -----

Field Data Sample
1 Sentence ID CLHD
2 Year 1985
3 TimeStep 3 (or TimeStep abbreviation)
4 Region 4 (or region abbreviation)
5 CohortID URB1986WIUUU
6 StartAbn 28394.1928 (a double)
7 NatMort 28.3941928 (a double)
8 TotCat 3564.19283 (a double)
9 TotShakers 32.9238287 (a double)
10 TotCNR 27.3984749 (a double)
11 TotOutMig 283.193993 (a double)
12 TotInMig 11.9384773 (a double)
13 EndAbn ????.????? (a double)

[Note: We could put all data (i.e., morts for each fishery) in a single record if we included a field for the number of fisheries harvesting the cohort in the given TS and Region. That would allow this type of sentence to have a variable number of data fields.]


Generating The Data File.

At the end of each process (e.g., MortalityPorcess, MigrationProcess) during a timestep an OutputGenerator object will have the opportunity to stream data to a data file. The type and frequency of data streaming to the data file is configed by the user at startup. To save space in the data file, null data (e.g., zero catches, zero natural morts, zero migrations) will not be streamed.


Using The Data File.

The data reading program will store data in tables, matrices, or some other structures. These structures will be created on startup, and all entries will be set to zero. Since only non-zero data are streamed to the data file, the reading program will just fill in the non-zero entries.

The advantage of using standardized data sentences is that users of the data file need only know the sentence formats in order to use the data. Any type of computer and language can be used to create a program to read each sentence and then determine what to do with it.

------------ End Memo -----------

The code structure to export data from the Coast model using this type of data standard is in place. Troy has developed a DataRequestManager that can store data at the end of each major process in each timestep. A sample of data output is below:

CABN, 1994, 1, 1, WCN1992XIXXXX, 249199
CABN, 1994, 1, 1, WCN1993XIXXXX, 432492
CABN, 1994, 1, 1, LYF1989XIXXXX, 0.92099
CABN, 1994, 1, 1, LYF1990XIXXXX, 3819.65
CABN, 1994, 1, 1, LYF1991XIXXXX, 1297
CABN, 1994, 1, 1, LYF1992XIXXXX, 6913.63
CABN, 1994, 1, 1, LYF1993XIXXXX, 16278.3
CABN, 1994, 1, 1, MCB1989XIXXXX, 14337.9
CABN, 1994, 1, 1, MCB1990XIXXXX, 43179.7
CABN, 1994, 1, 1, MCB1991XIXXXX, 278504
CABN, 1994, 1, 1, MCB1992XIXXXX, 396091
CABN, 1994, 1, 1, MCB1993XIXXXX, 764184
FMRT, 1994, 1, 1, 1, AKS1989XIXXXX, 208.646, 0.0195405, 23.8002
FMRT, 1994, 1, 1, 1, AKS1990XIXXXX, 760.973, 0.287332, 87.045
FMRT, 1994, 1, 1, 1, AKS1991XIXXXX, 495.609, 7.4111, 64.7623
FMRT, 1994, 1, 1, 1, NTH1989XIXXXX, 3639.1, 5.43337, 420.799
FMRT, 1994, 1, 1, 1, NTH1990XIXXXX, 5415.74, 89.9963, 717.756
FMRT, 1994, 1, 1, 1, NTH1991XIXXXX, 8930.04, 3259.91, 4660.01
FMRT, 1994, 1, 1, 1, NTH1992XIXXXX, 3408.08, 5434.2, 6460.03
FMRT, 1994, 1, 1, 1, FRE1990XIXXXX, 2249.31, 19.2238, 277.821
FMRT, 1994, 1, 1, 1, FRE1991XIXXXX, 13049.8, 2219.4, 3966.96
FMRT, 1994, 1, 1, 1, FRE1992XIXXXX, 567.835, 2936.55, 3345.72
FMRT, 1994, 1, 1, 1, FRL1990XIXXXX, 420.461, 4.30132, 52.7235

Jim reported that he wrote a Visual Basic utility to read through this output file and create *cat.prn and *esc.prn files, each of which then validated with those produced by the PSC Chinook Model. The size of the output file was about 2.5 MB and the utility required about 25 sec to generate the formatted output files (using a Pentium 133 machine).

There was some discussion about this idea. In general, the meeting group felt this was a good idea, but that it needed to be fine-tuned to meet the needs of each type of model configuration.

Jim emphasized the need to develop standardized stock definitions. He said that some stocks in the FRAM Model have the same names as stocks in the PSC Chinook Model, but used different run aggregations (eg separating Hood Canal runs from South Puget Sound runs) and different CWT data for estimating harvest related parameters. Marianne suggested passing the stock standardization idea along to the PSMFC.


7. Report on PSC CTC project with ESSA and UW.

The PSC has contracted with ESSA of Vancouver, BC to make improvements in the PSC Chinook Model. UW is a subcontractor to ESSA. Currently there are three closely related models:

-- PSC Chinook Model (CTC versions 95, 98, and 99);
-- Crisp Harvest (C++ version of CTC 95);
-- Coast Model (New C++ version of CTC 95).

The PSC Chinook Model is written in QuickBasic and is the model currently used by the Chinook Technical Committee (CTC). Crisp Harvest is a C++ version of the 1995 PSC Chinook Model, and includes an extensive Graphical User Interface (GUI). The "Coast Model" is the code framework developed by this NMFS project during the past 2+ years, and was derived from Crisp Harvest. The Coast Model does not yet have a GUI.

The work plan for this project calls for UW to update the Coast Model to incorporate all the current algorithms used by the PSC Chinook Model (i.e., age specific FPs, Spring chinook aging algorithm, stock specific incidental mortality rates). The new "abundance-based management algorithm" will not be included in this development. ESSA will develop a calibration algorithm, database utilities, and a limited GUI. The basic idea is to develop a CTC version of the Coast Model in parallel with the PSC Chinook Model until all validation checks have been completed and real-time management can be transferred to the Coast Model. The work plan is illustrated below:

  CTC 95 ---------- CTC 98 ----------- CTC 99
   | | |
   | | |
   | | |
   | | |
Crisp Harvest Validate Validate
   | | |
   | | |
   | | |
   v v v
Coast 98/95 ------ Coast 98/98 ------- Coast 99

        UW: Process algorithms
        ESSA: Calibration algorithm
              Database utilities
              Limited GUI


8. Next meeting.

The next model committee meeting was tentatively scheduled for Tuesday March 16, 1999 (location to be determined). Please advise if this date is not acceptable.