[Feature]: add checks to identify growth parameter that cause negative length-at-age and better enable use of negative Amin as t0

[Rick-Methot-NOAA]

Describe the solution you would like.

SS3 growth equations use the Lmin parameter as the fish length at this age:
0 #_Age(post-settlement) for L1 (aka Amin).

So, if the Lmin is set to 0.0, then Amin is identical to t0, per the original parameterization of the growth model.

SS3 works in the above configuration, but it is a non-transparent way to achieve the t0 approach.

Also, if the user does not fix Lmin at 0.0, then the 3.30.24 trap for negative lengths is accidentally triggered.

Add check in readcontrol to identify Lmin values, or lower bound on Lmin, that would cause negative length-at-age.
Also flag Lmin < len_bins(1) as that can cause declining size-at-age below Amin.
Not all situations causing negative length-at-age are caught by the readcontrol test.
Also add a test in prelim calcs that explicitly checks for negative length-at-age (FATAL)
and a test for declining length-at-age.
Repeat that test in write_report to test the final parameter values.
Note that no test occurs during MLE or MCMC estimation.

Describe alternatives you have considered

continuing with current approach

Statistical validity, if applicable

NA

Describe if this is needed for a management application

probably

Additional context

No response

[shcaba]

The 3.30.24 trap for negative lengths can be triggered if there is sex-specific differences in growth, thus the male Lmin may be negative when its t0 is larger than the female. You can also get -Lmin when estimating Lmin from a negative Amin value.
The ultimate issue to avoid is when the realized t0>0, which creates negative lengths below t0.
One solution could be to override the negative Lmin trap when Amin is <=0. This does not guarantee that t0 won't be >0 and thus lengths won't negative, but it would allow for the t0 approach while also avoiding -Lmin values when Amin>0.

[iantaylor-NOAA]

Given that Amin isn't estimable, I don't see how this non-intuitive approach is helpful unless you're fixing growth, in which case couldn't you just derive the value of L_at_Amin for some positive Amin value? Even if you are estimating L_at_Amax and/or k, then I would guess that fixing L_at_Amin at the external growth curve would be more reliable than fixing L_at_Amin at 0 and Amax at t0 in terms of providing reasonable estimates.

[shcaba]

Setting Amin to t0 and putting Lmin at 0 (which I don't think is non-intuitive, as it is logical, but maybe just unfamiliar) will start the model at the external t0 value, which I think is intuitive and very useful for many users. Folks may not have thought to do this simple approach, so some wording either in the control.ss_new and/or handbook could highlight this approach.

One can then estimate t0 if you want all 3 VBGF parameters estimated, so starting at a negative value has not been an issue. But the new trigger does block this approach in the attempt to stop what is ultimately t0 values >0 (which should be blocked). It also blocks the estimation of males relative to the Amin, as there is only one Amin that both sexes are conditioned on.

I do not think there is anything needed in the internal treatment of Amin or Lmin, as SS3 already has this great flexibility (e.g., estimating Amin is not needed). I just think the new trigger has blocked the ability to have this t0 flexibility when trying to stop what is a rarer occurence of having negative lengths (caused by positive t0 values). Again I think that by turning off the current Lmin trigger when Amin is <=0 would solve many of the issues, while still guarding against the real problem when Amin is >0 that may lead .

[Rick-Methot-NOAA]

SS3 was not built using the traditional t0 formula. Instead it was built and document around the Amin and L@Amin approach per Schnute. The output calculation of t0 is derived from the curve, but never used internally.

The test is applied when the parameters are first read. The trap is only applied to females because the male parameter could be a negative offset from the female.
The test is not applied if Amin is < 0 to allow you to use the t0 approach, but that breaks if you use a non-traditional t0 that is > 0.
The SS3 code is quite complex regarding growth at the earliest ages and the linear growth below Amin is part of that. I doubt I could make any change without spending a month debugging it.

[shcaba]

Yes, I definitely don't suggest any complex rooting out of all the scenarios for each growth curve.
In order to maintain the very useful t0 approach (which I would argue is used more often than one encounters negative lengths), I would simply stop the Lmin trap and instead use a strong warning if negative lengths (which I believe is the ultimate issue) are found in the model.
There are other similar warnings presented to the user that suggest that certain model behavior may lead to unrealiable derived outputs that SS3 users are used to looking at.

[Rick-Methot-NOAA]

Jason,
Here is the complete code associated with the test. It already is only applied when Amin is <0. Some of your input suggested that you saw possibility of Amin > 0 still needing to allow L@Amin <0. I hope that is not true, but I'm open to seeing the logic for such a situation:

     if ( gp == 1 && WTage_rd == 0 && AFIX >= 0.0)
      {
        if (MGparm_1(Ip,1) < len_bins(1))
        {
          warnstream << "parm min for Lmin: " << MGparm_1(Ip,1) << " cannot be less than population min length bin " << len_bins(1);
          write_message (FATAL, 0); // EXIT!
        }
        if (MGparm_1(Ip,3) < len_bins(1))
        {
          warnstream << "parm init value for Lmin: " << MGparm_1(Ip,3) << " cannot be less than population min length bin " << len_bins(1);
          write_message (FATAL, 0); // EXIT!
        }
      }

The reason I test against len_bin(1) and not 0 is to prevent the resultant L@A to decrease from age 0, which you can see happening in Vlada's example