search

abennici / StockMonitoringTool

1 stars 3 forks source link

restructure SMT tabs #33

Closed aenieblas closed 3 years ago

aenieblas commented 3 years ago

Assessment steps currently summarised under ELEFAN could be assigned to tab "length-based analysis" or similar to contrast "catch-only methods" such as CMSY.

Note that a following recommendation will split the Elefan code into 4 different steps, which should be separately listed under 'Length-based methods'. These will be supported with introductory text by Tobias

eblondel commented 3 years ago

@aenieblas can we discuss the level of priority and the rationale of this ticket?

aenieblas commented 3 years ago

@eblondel sure - this is derived from tobias's structural recommendations. Agreed that it's not a first priority, and I've changed it to priority 2.

One of the objectives of Tobias's work is to clarify the workflow for length-based methods. One of his recommendations is to remove both Elefan and ElefanSA, as only ElefanGA is the recommended method. Currently, the Elefan workflow in the SMT includes Elefan, natural mortality estimation, length-converted catch curve, and finally YPR. This is where Tobias recommends splitting these into 4 different steps. YPR is already included in the TropFishR package, and we would no longer have need of the FishMethods tabs (@tokami to verify need for SBPR). Thus, 'length-based analysis' would cover these 4 steps, and 'catch-only' would cover CMSY.

tokami commented 3 years ago

There were two rationals in this recommendation, first, calling and grouping the whole workflow of methods - mentioned by Anne-Elise - ELEFAN is misleading and limits flexibility and user-friendliness, second, if the methods were to be split and the methodological structure of the SMT were to be kept, the the list of tabs would be very long and confusing. Thus, methods could be grouped based on their input data requirements and simplify workflow and user-friendliness, e.g. length measurements (at least 1 year) vs catch time series (> 10 years) data.

Some of the further revisions and recommendations (code suggestions from my side) depend on the decision (and implementation) of the structure of the SMT. Or in other words, it would be easier and more meaningful to work on workflow recommendations and descriptions and implement input and output options if the final and desired structure of the SMT is settled and implemented. Therefore, a high priority...

eblondel commented 3 years ago

Thanks @aenieblas and @tokami I got your points, but I think what we need here is the design of a SMT app v2 taking into account your structural recommendations, workflow requirements. This requires structural changes that need further specifications including on design specifications, ideally with a mockup. Such restructuring requires in depth refactoring of the app that requires substantial effort, and planning because no mobilizable effort at short-term is available for this type of substantial change.