Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add user control of oldctlfile in profiles #23

Open
2 tasks
iantaylor-NOAA opened this issue Jun 16, 2023 · 2 comments
Open
2 tasks

Add user control of oldctlfile in profiles #23

iantaylor-NOAA opened this issue Jun 16, 2023 · 2 comments
Labels
enhancement New feature or request

Comments

@iantaylor-NOAA
Copy link
Contributor

The profile wrapper is great, but for petrale we're having an issue of convergence which I think is related to the sequence of counting down from the estimated value then counting up, all the while using the control.ss_new for the oldctlfile input, which means that the initial values for the non-dev parameters in each step in the profile are the estimated values from the previous step. In general this is a good thing as it improves estimation, but it's a problem when there's a big jump in the parameter.

For a petrale M profile, {nwfscDiag} created the vector below, and estimation with M = 0.142675 starting from the estimated values from the previous M = 0.09 step led to non-converged estimates that did not match the base model with that same M.
[1] 0.140000 0.130000 0.120000 0.110000 0.100000 0.090000 0.142675 0.150000 0.160000 0.170000 0.180000 0.190000

In the profile_control branch I have added user control of the oldctlfile input so that we can change to something like petrale_control.ss for all steps in the profile, rather than the control from the previous run.

A few alternative approaches to this problem worth thinking about (and/or splitting into a separate issue) are:

  • run separate profiles, first counting down from the estimated value, then counting up, where both would use oldctlfile = "control.ss_new". This would remove the discontinuity that is messing up petrale profiles, and
  • use the original model with estimated parameter rather than re-running the profile with the parameter fixed at the estimated value so save a little time. Maybe the re-run was driven by the
    need for matching settings related to the prior (issue inclusion of priors in likelihood? #6).
@iantaylor-NOAA iantaylor-NOAA added the enhancement New feature or request label Jun 16, 2023
@chantelwetzel-noaa
Copy link
Contributor

Thanks @iantaylor-NOAA. I distinctly remember doing profiles for petrale sole in 2019 was particularly difficult with many runs not converging. I like your second suggestion and think that this could be done by the package fairly easily. While I definitely think that finding an approach that produced converged runs reliably is the goal, I want to bring to your attention the rerun_profile_vals function if you were not aware. This function reruns specific values and then does all the processing and plotting again. This function has an input of run_num which corresponds to the run number for the non-converged run that can be found in the csv with "results" at the end of the name.

@iantaylor-NOAA
Copy link
Contributor Author

@chantelwetzel-noaa, thank you for the tip on rerun_profile_vals(). I remember the discussions when you created that function but forgot that it existed. Running all the petrale models from the same starting values instead of control.ss_new did not magically fix the non-convergence of a few models in each profile so I will give re-running a try.

iantaylor-NOAA added a commit that referenced this issue Jun 20, 2023
- also better implement control of oldctlfile and newctlfile
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

2 participants