trap for duplicate index observations

[iantaylor-NOAA]

As discussed in pfmc-assessments/lingcod#59 (comment), the SS model files in lingcod_model_with_error.zip
from the still-in-process-with-lots-left-to-do lingcod assessment produced the following error.

Initial statistics: 1 variables; iteration 0; function evaluation 0; phase 1
Function value   1.3995186e+05; maximum gradient component mag  -3.9184e+04
Var   Value    Gradient   |Var   Value    Gradient   |Var   Value    Gradient
  1 -0.05710  -3.9184e+04 |
1 2 -log(L): 141340  Spbio: 63999.6 47363.9
1 3 -log(L): 143445  Spbio: 63999.4 47363.7
1 4 -log(L): 146155  Spbio: 63999.4 47363.7

Function minimizer: Step size  too small -- ialph=11 5 -log(L): 149373  Spbio: 63999.6 47363.9
1 5 -log(L): 149373  between
2 6 -log(L): 153012  Spbio: 63999.6 47363.9

Dave Fournier said (on ADMB Users email list in 2010)

It means that the function minimizer can not find a step size which decreases the function.

Indeed the -log(L) just rises steadily.

I tracked it down to duplicate index observations added by accident. The fleet 4 index with comments like "#_index_recORCPFV" (starting on line 584 of ling_data.ss) should have had negative year associated with them.

I don't know if this is a general property of any model with duplicate index observations for the same fleet/year, but stopping or warning when duplicates occur would help track down the error.

[Rick-Methot-NOAA]

this code in readdata should have produced a warning:

    if(data_time(ALK_time,f,1)<0.0)  //  so first occurrence of data at ALK_time,f
      {data_time(ALK_time,f)(1,3)=timing_r_result(1,3);}  // real_month,fraction of season, year.fraction
    else if (timing_r_result(1) !=  data_time(ALK_time,f,1))
      {N_warn++;  warning<<N_warn<<" "<<"SURVEY: data_month already set for y,s,f: "<<y<<" "<<s<<" "<<f<<" to real month: "<< data_time(ALK_time,f,1)<<"  but read value is: "<<real_month<<endl;}

[Rick-Methot-NOAA]

verify that the code is not producing a warning on duplicate observations and that the expected value for the second observation is not correctly produced.

[Rick-Methot-NOAA]

Actually, the warning is not about duplicate observations, rather to details of calculating timing.
SS is OK if a second yr,month,fleet is in a separate subseas from the first obs.
The code in SS_expval has this line:
j=have_data(ALK_time,f,data_type,1); // for now, only one observations is allowed for surveys

So, I will change ss_readdata to produce a warning if there is a second obs created for an already assigned time.
Note that most other datatypes allow for duplicate observations.

ALSO, removing some leading spaces in report.sso

[iantaylor-NOAA]

Thanks for checking this out, @Rick-Methot-NOAA. Your explanation makes sense.

[Rick-Methot-NOAA]

this commit also includes merger with small branch to remove some leading spaces in report.sso that interfere with excel reads, also some modifications to warnings during catch record read.