Tables 6-10 has 2008 hardwired as the start year - make it last.data.yr-9?

[andrew-edwards]

This refers to main.us.cp.age.data.table etc. in main-tables.rnw: https://github.com/cgrandin/hake-assessment/blob/master/doc/main-tables/main-tables.rnw

I seem to think there may have been a reason for starting all the tables in 2008, rather than always doing the last 9 (or whatever) years.

Either way, have to change the start.year values or un-hardwire the 9 in second bullet of data section https://github.com/cgrandin/hake-assessment/blob/master/doc/data-section/data.rnw (currently line 16).

Easy fix, just need to decide if we want to keep doing from 2008 (maybe this year, then do last 10 years in the future).

[iantaylor-NOAA]

Aaron can speak to this better, but the data extraction code he and I inherited from Allan is hardwired to extract just values from 2008 onward, so that's been a logical place to start. I like the idea of 2008 - 2017 as a 10 year period for this year, and then continuing with the pattern of just the past 10 years into the future.

[andrew-edwards]

Okay, I can switch to 'last 10 years'.

[aaronmberger-nwfsc]

Yeah, Ian's right that it defaults back to our data extraction code and when our fleets where renamed to CP and Motherships from U.S.-at-Sea. I also like the idea of just showing the most recent 10 years...

[andrew-edwards]

Great. Can't do it until Google data folders updated so that we have 10 years of data.

[iantaylor-NOAA]

OK, I just uploaded a bunch of files from the U.S. fishery data to Google drive data folder. I didn't bother to filter for only those that we typically use. @aaronmberger, feel free to check that these match yours.

[iantaylor-NOAA]

Correction, I just noticed that the date modified for my files was from December, so I never ran the processing code after doing the extraction. I just removed my files from Google Drive (although the format would still have been accurate even if the numbers weren't final).

@aaronmberger has the correct csv files for the U.S. Fishery. It probably makes sense to upload the monthly files as well as annual summaries in case we have time to add additional figures, perhaps for presentations if not the document, as noted in issue #266.

[aaronmberger-nwfsc]

I will try to update all the data files tonight or first thing tomorrow -> got side-tracked

[aaronmberger-nwfsc]

All the data files have been updated except the following:

• ovary-samples.csv (values for 2017 need to be entered, Ian do you have these?)
• survey-comparison (I could not locate some of the entries, e.g., CV on no extrap 2017 survey, so may need to check with Rebecca)
• survey-history (a few entries need filling in, may need assistance from survey folks)

[andrew-edwards]

Great. So Aaron changed the GitHub ones in commit 7b1e2275 . Ian was talking about Google Drive folder. So just to clarify - the data get loaded to the Google Drive (to be shared to use for models, presumably), and then when that's final the GitHub data folder gets updated (as per #320). Is the Google Drive step strictly necessary? I'm thinking it likely is, just not quite sure why.

[aaronmberger-nwfsc]

right, the data is now also on the google drive

[iantaylor-NOAA]

I'm good with skipping the Google Drive folder in the future although there may be files that we don't necessarily use for the document that could be stored there just in case of future needs.

[andrew-edwards]

Great Aaron - tables build fine with the updated data. Ian - yes, maybe just keep it for files that aren't in the build. I'll finalise this issue and close it.

[aaronmberger-nwfsc]

It is nice to have a spot where we all can access files, that may or may not be explicitly used in the assessment build. It only takes a few seconds to copy those over to the drive - I just forgot that step!

[andrew-edwards]

Fixed, though still have Issue #332 which is related to these tables.

[cgrandin]

I am still working on uploading the Canadian data files - the age files changed format and split into 3 files instead of one which I have to write new code to account for.

[andrew-edwards]

Yes, I think that might automatically fix #332.