HYCOM-related likelihoods

[marosteg]

Running into a problem on 'dev' branch with calculating HYCOM-related likelihoods for data from 2019 and 2020 (presumably after the 2018-11-20 end of GOFS 3.0).

In calc.ohc.par (as an example), I've isolated the issue as a mismatch in the size of the latitude dimension among L.ohc (where it is correct) and lik.ohc (where it is incorrect). Notably, on line 138:

dat <- RNetCDF::var.get.nc(nc, temp.idx) * scale + offset

This yields the correct longitude dimension size, dim(dat)[1], but the incorrect latitude dimension size, dim(dat)[2], relative to line 119:

lat <- RNetCDF::var.get.nc(nc1, lat.idx)

This mismatch ultimately results in an error on lines 242-244 where the incorrectly sized lik.ohc is assigned into the correctly sized L.ohc:

for(i in 1:T){
    L.ohc[,,i] = lik.ohc[[i]]
  }

[camrinbraun]

Indeed this issue is coming from dim issues in HYCOM itself. In get.hycom we ask for HYCOM experiment GLBu0.08/expt_93.0 for before 2018-11-20 and for GLBy0.08/expt_93.0 after that, based on HYCOM date availability. The former is a uniform .08 global grid while the latter is 0.08 deg lon x 0.04 deg lat grid. So that's the issue. Feeling like I've solved this somewhere, just have to remember where...

[camrinbraun]

forget any hycom-based calculations for a minute. we have to solve the resolution issue at the source. in your call to get.env() try downloading an example day of problematic HYCOM (e.g. in 2019) using the template argument to get.env() which is an experimental feature that should resample the downloaded .08 x .04 HYCOM to whatever raster template you provide which in this case should be an older .08 x .08 HYCOM grid. So something like:

old_hycom <- raster::raster('hycom_2018-01-01.nc') ## this does NOT need to be the full HYCOM brick (3d) just the 2d raster is fine
get.env(all the input stuff you normally put, template=old_hycom)

[marosteg]

Yeah, that solved it. New raster has the correct dimensions. But this raises a big question for me. If we do a project only with data from the later HYCOM version, are our movement kernels and grid unit based calculations accounting for that different resolution? Everything was designed when HYCOM was 0.8 x 0.8 but now its 0.8 x 0.4. So if we use only new HYCOM in an upcoming study, shouldn't we just force it to always give us the data in 0.8 x 0.8? Or do we have internal catches to compensate for that grid unit size change?

[galuardi]

i think resampling to a regular grid is best. We're taking the centroid of cells as positions which would skew things latitudinally. Resampling should allow the movement kernel to have the proper influence on likelihood; without doing that it seems precision would be sacrificed.

does anyone know why this change was made?? Perhaps the gurus found that HYCOM performs better with lower latitudinal precision..

[camrinbraun]

maybe the way forward is to include a hycom template grid with the package data. anytime someone asks for a modern HYCOM grid with the weird resolution, it gets auto resampled and a warning is pushed notifying of the change. that way all downstream stuff remains unchanged.