create system to provide parameter types and minmax bounds

[k-doering-NOAA]

Imported from redmine, Issue #77270 Opened by @iantaylor-NOAA on 2020-04-01 Status when imported: New

The issue that Dan Fu reported (files attached to #77268) was caused by use_dev = 1 values for the Spline_Knot parameters. The user manual notes "These must be held constant (not estimated, e.g., negative phase value) during a model run" but it would be good to check for either positive phase or use_dev > 0 and exit with a warning.

I think I could figure out how to do this in SS_readcontrol_324.tpl and SS_readcontrol_330.tpl by following logic similar to that under "check on conversion of retention parameter". However, perhaps this should be done in a more comprehensive way to check any selectivity parameters which should not be estimated, such as the bin range parameters for Pattern = 5.

@richard.methot, feel free to assign to me with any guidance you have if you prefer that I tackle this.

[k-doering-NOAA]

comment from @RickMethot on 2020-04-01: There is no generic way to do this, you need to look at the details of each selectivity function to know where to do it. So I suggest you go for it with these spline knot parameters. Others can be done on a case-by-case basis

On Wed, Apr 1, 2020 at 3:57 PM [email protected] wrote:

[Rick-Methot-NOAA]

The issue here is that in SS_readcontrol, the code only knows what each parameter does when it is assigning parameter names. And it creates those names in a code section that precedes the reading of the parameter lines. When code does other things (like phase checks), it does so generically for all parameters.

So the fix would be to create a new vector containing an element for each parameter and assign that element a value that flags whether or not that parameter can be estimated. It should also be possible to assign at the same time a logical min and max for the parameter. Everytime a new parameter is created in ss_readcontrol, a label added to the end of the adstring_array, parmlabel. The same logic could be used to push a code for estimability. It should also be possible to assign at the same time a logical min and max for the parameter. The code sequence to do this would need to be added in every place a parameter label is created; I count 216 instances of ParmLabel+= :(

There is a start to this already in the code. Look at the quantities Parm_info and Parm_minmax in SS_global and in SS_readcontrol. This is very incomplete implementation.

Parameter types to consider: 1 - normal (parameter has an easily interpretable meaning, like M) 2 - parameter is ln(quantity) 3 - parameter is logit 4 - quantity is a code, not a parameter, so phase must be negative 5 - other

MinMax types to consider: 1 - value must be >0.0 2 - value must be >= 0.0 3 - value must be >=0.0 and <=1.0

[google_sheet ] (https://docs.google.com/spreadsheets/d/1VwSeSziSD2dy-umRKMM5lc5h52QJbZ8qCwT4n8sPgqU/edit#gid=0) for brainstorming values to insert into code

note that this is duplicate of issue #40

[Rick-Methot-NOAA]

SS3_parmlabels.txt

[iantaylor-NOAA]

I took a quick look at the spreadsheet of ParmLabels and categorized 47 of the 216 entries. I think it won't be too hard to fill in the rest if we chip away little by little. Edit: here's the link from the comment above: https://docs.google.com/spreadsheets/d/1VwSeSziSD2dy-umRKMM5lc5h52QJbZ8qCwT4n8sPgqU/edit#gid=0

[Rick-Methot-NOAA]

Thanks Ian. Please add additional categories as needed.