Basic MODFLOW package/file object functions

[rogiersbart]

Basic MODFLOW package/file object functions

[cneyens]

In terms of rmf_build_*, there are currently some rmf_as_* functions that handle this? Not really a verb, but more in line with tidy packages (tibble, sf, ...). These don't really build rmf_packages directly, but rather convert existing rmf building blocks (rmf_arrays and rmf_lists) to other data types and rmf specific classes.

I think it's best to have a separate discussion on building objects from spatial data. For starters, I suggest using stars over raster. As great as raster is, it can not handle affine grids or variable cell-sizes all that well; two things that are common in MODFLOW models. Also, a.t.m. stars is better integrated with sf.

S3 methods for plotting and printing were on my to-do list as well.

I can get to work on that list of packages and corresponding RMODFLOW implementation status?

[rogiersbart]

Whatever works for you Cas. I'm just putting this out here to enable some discussion on the way forward. By no means I'm asking anyone to invest time in this. But I would be grateful if you could do so of course.

Concerning the rmf_build_* thing: Just to make sure you get what I mean: the functions would create the RMODFLOW objects (dis, lpf, etc) from sp, sf, raster or stars objects. So the user comes with a spatial data object and we process it with the function into an RMODFLOW object. Much like your idea:

sf::st_read("river.shp") %>%
 rmf_create_list(kper = 1:dis$nper, dis = dis) %>%
 rmf_create_riv(dis = dis)

But then maybe rather with a single function call (which can be a wrapper around the functions above?):

sf::st_read("river.shp") %>%
  rmf_build_riv(dis = dis)

In the long run, when we have some functionality on the full MODFLOW level (not individual packages/files), it could something like:

my_model <- rmf_create() %>%
  rmf_add_dis() %>%
  rmf_add_bas() %>%
  rmf_add_lpf() %>%
  rmf_add_riv(sf::st_read("river.shp"))

Where the last function would wrap rmf_build_riv() and get some required details from other packages (dis, time discretization from bas maybe, start time from dis dataset 0?, etc.). Just thinking out loud here ...
Of course we can require the user to do this with sf or stars, but probably enabling sp and raster is not so difficult as well (at least raster is still used a lot I think). The rmf_as_* functions do things the other way around, they take an RMODFLOW object and convert it to e.g. a tibble or sf object, so that we can easily make use of e.g. spatial data visualization or data frame manipulation from other packages.

The internal representation of RMODFLOW arrays is another thing. Probably stars is the best candidate for the future there, if we would decide to change it. I have considered dplyr::tbl_cube() in the past, but I did not go there because support seemed still experimental, and there is definitely no widespread use of it (still the case as far as I know).

[rogiersbart]

I did just assign the issue to you however ... 😉 But don't feel obligated. Just want to try out some more github features. By the way, you should have access to my repo. As long as we merge things to develop by pull requests with some code review, I think you can just work directly in my repo as well (this should go two ways really (i.e. I should do pull requests myself, and you should review my code). No problem of course if you keep on working in your fork for now.

[cneyens]

Feel free to assign me to these issues Bart. I'm more then happy to help when I can find the time.

Concerning the rmf_as_* & rmf_build_* thing: I was talking more about semantics. I think the tidyverse uses the as keyword in functions that convert between different data types/classes.

I understand that your rmf_as_* functions take a RMODFLOW object and convert it to spatial or tibble objects. Conversely, I wrote rmf_as_list and rmf_as_array S3 functions that take their input (right now only RMODFLOW objects, i.e. rmf_list and RMODFLOW arrays) and convert them to rmf_list and RMODFLOW arrays, respectively. These S3 functions could be expanded to include, e.g. rmf_as_list.sf to convert sf to rmf_list which can then be used as building blocks for the MODFLOW packages.
Following this logic, I did make a mistake in my comment on cneyens#1 which you repeated above. The correct function calls atm would be (rmf_as_list instead of rmf_create_list):

sf::st_read("river.shp") %>%
  rmf_as_list(kper = 1:dis$nper, dis = dis) %>%
  rmf_create_riv(dis = dis)

But again, these are just semantics...

On raster vs. stars: raster is for sure still more widely used than stars. Stars is also not aiming to be a full replacement of raster as far as I know (unlike sf for sp). But I do wonder how raster will then deal with e.g. rotated MODFLOW grids. For internal representation: stars objects are actually a generalized form of a dplyr::tbl_cube().

Edit: maybe also worthwhile to check out terra which will in fact act as a replacement for raster (same author).

[cneyens]

I've added a wiki on this: https://github.com/rogiersbart/RMODFLOW/wiki/Overview-of-supported-MODFLOW-packages