[Feature]: Multivariate-Tweedie for age/length compositional likelihood

[James-Thorson-NOAA]

I'm leading a paper with Tim Miller and Brian Stock, introducing a new "multivariate-Tweedie" likelihood for fitting age/length composition data. It is essentially a more flexible alternative to the Dirichlet-multinomial, and appears to have some useful pros and cons relative to the DM. It internally relies upon a dtweedie likeliood, which Johnoel is adding the ADMB-13, so it should be feasible to implement in SS3 by this summer.

Does anyone have sufficient time and interest to work with me to get it implemented (both in logical code, and with a thoughtful user-interface) in SS3?

[Edit: task list below added by Ian on March 24.]
To-do list for MV Tweedie likelihood based on comments above:

• create new MV-Tweedie-complike branch to host changes code
• add new likelihood calculation to SS_objfun.tpl and create a pull request (Mv tweedie complike #278)
• wait until ADMB 13 is released which will include the dtweedie function: Adding dtweedie admb-project/admb#234
• double check likelihood calculation added to SS_objfun.tpl by @James-Thorson-NOAA
• see what parameters need to be created in SS_readdata_330.tpl
• name parameters in SS_readcontrol_330.tpl (two for mvtweedie compared with one for DM)
• check everything else is handled automatically (reporting and write_ssnew)
• document the changes in the SS3 User Manual
  • generalized size frequency section already updated in nmfs-ost/ss3-doc@28dd822
• apply any parallel changes to DM likelihood (discussed in Provide more informative names for Dirichlet-Multinomial parameters #185 and bin-specific comp logL wrong in compreport for D-M; make comp logL code modular with function #219)
• modify r4ss to work with models that use MV Tweedie

[iantaylor-NOAA]

I don't think I can do this without help from others on the SS3 team, but am happy to be involved.

[zandjyo]

I am all in support of anything that gets us away from the art involved in choosing input sample sizes and data weighting. Probably not much help on the logical code side of things, but could put some thought into user-interface and diagnostics once I get my head around what you are doing.

[Rick-Methot-NOAA]

Jim,
The interface should be a straightforward extension of current interface for selecting DM. I can assure that will happen.

[James-Thorson-NOAA]

yeah, it'll have two parameters instead of one ... if someone could make a dev branch or something with those named parameters, I could do a PR with the added code. Or is there some other preferred way to proceed ... perhaps instead I could just providing the code-snippet for the likelihood in this Issue thread?

[Rick-Methot-NOAA]

branch MV-Tweedie-complike has been created and you can do PR to it.
search in read_data and in SS_objfun for text = MV_Tweedie to get started adding code

[Rick-Methot-NOAA]

I did not intend to fast-track this. I just wanted there to be a branch on which development could happen. Only git collision I foresee is with the request to rename the D-M parameters.

[James-Thorson-NOAA]

By read_data I assume you mean "SS_readdata_330.tpl" ... I just opened this and can't easily make sense of it. So a few questions:

1. Would it still be helpful if I can make the changes in SS_objfun but not SS_readdata_330?
2. If yes to Q1, could someone provide me with syntax to extract the parameters from the various inputs, e.g., analogous to how the DM does is using lines:

        if(Comp_Err_L(f)==1) dirichlet_Parm=mfexp(selparm(Comp_Err_Parm_Start+Comp_Err_L2(f)))*nsamp_l(f,i);
        if(Comp_Err_L(f)==2) dirichlet_Parm=mfexp(selparm(Comp_Err_Parm_Start+Comp_Err_L2(f)));

...?

[Rick-Methot-NOAA]

Jim,
If you can start by working in SS_objfun.tpl. When you push that, I can see what parameters need to be created in SS_readdata330.tpl, and then named in ss_readcontrol330.tpl. Everything else should be handled automatically (reporting and write_ssnew).