Construct mesh from domain rather than sample locations

[James-Thorson]

In my experience with VAST, it is a good default to construct the SPDE mesh using evenly spaced locations within the spatial domain, rather than the current default (applying fmesher to the sample locations). This is because the desired abundance index then uses area weighting (not sample weighting), and the SPDE mesh vertex density might be very low in large areas. For example, this arises in the eastern+northern Bering Sea, and in many fishery CPUE analyses.

Is it worth adding a new option for users to pass an sf polygon as data to make_mesh and then defining the mesh based on st_make_grid locations within that domain? That would then more closely match the default behavior in VAST.

[seananderson]

In retrospect, I wish I hadn't got into the business of trying to simplify mesh creation and left it as a user-input as in tinyVAST. I just wish the documentation of the fmesher arguments was better for the user.

fmesher::fm_mesh_2d_inla() with a boundary but no loc specified has a similar outcome with an evenly spaced mesh, but it won't match a grid.

So, sf::st_make_grid() is used and those grid points are fed directly to fmesher::fm_rcdt_2d_inla() as in how the kmeans knots work now? We could add something like that as an option—especially if helps match behaviour with VAST.

Perhaps a helper function that takes an sf polygon, overlays a grid of specified resolution, and extracts knot locations? Then add an argument to make_mesh() that takes specified knot locations?

[James-Thorson]

Yeah, these solutions are simple enough that I don't think it's necessary to directly editing the sdmTMB::make_mesh code (and I hadn't realized fmesher::fm_mesh_2d_inla() with a boundary works that way!) ... I'll plan to keep an eye out for better ways to communicate and document the importance of an evenly dense mesh during unbalanced but spatially expanded CPUE analysis.