I would like to propose we move away from using ycs_years to reference the ycs_values parameters. Currently Casal2 follows CASAL's convention of referencing ycs_values by ycs_years which are the years of the corresponding spawning events. This causes problems and confusion in the code base for time-varying and projections classes.
My suggestion is ycs_years can remain as an subcommand, but the ycs_values will be referenced by the recruitment year not spawning year. This is a departure from CASAL and will cause some translation pain, but in the long run it will lead to a more robust code base.
currently a model that has the following ycs_values
process[Recruit].ycs_values{1990:2000}
and a @y_enter 2. Then the ycs value will need to be changed to be referenced as
process[Recruit].ycs_values{1992:2002}
One proposed change is to change the subcommand names way from ycs_values to recruitment_multiplier The point is to avoid confusion with this subtle change. Now users will have actively look for the solution.
I would like to propose we move away from using ycs_years to reference the ycs_values parameters. Currently Casal2 follows CASAL's convention of referencing ycs_values by ycs_years which are the years of the corresponding spawning events. This causes problems and confusion in the code base for time-varying and projections classes.
My suggestion is ycs_years can remain as an subcommand, but the ycs_values will be referenced by the recruitment year not spawning year. This is a departure from CASAL and will cause some translation pain, but in the long run it will lead to a more robust code base.
currently a model that has the following ycs_values
and a
@y_enter 2. Then the ycs value will need to be changed to be referenced asOne proposed change is to change the subcommand names way from
ycs_valuestorecruitment_multiplierThe point is to avoid confusion with this subtle change. Now users will have actively look for the solution.