Comments (3)
Example usgs.model.reference file contents:
xul 2.019602961259E+005
yul 1.913295711065E+005
rotation 3.200000000000E+001
length_units meters
time_units days
start_date 12/30/1899
start_time 0:0:0
model MODFLOW-OWM
epsg
Example of corresponding discretization file dataset 0:
# Discretization File created on 2019-06-18 by ModelMuse version 3.10.0.59.
# Upper left corner: (201960.296125871, 191329.571106547)
# Lower left corner: (205298.78749054, 185986.868100761)
# Upper right corner: (219684.50133554, 202404.883729021)
# Lower right corner: (223022.992700209, 197062.180723235)
# Grid angle (in degrees counterclockwise): 32
from rmodflow.
I suggest including everything in the dis file. Keeping the metadata in a separate *.prj makes little sense since 1) it needs to be created everytime (i.e. it is not created by MODFLOW or by a GIS) and 2) in every use of it (e.g. plotting and converting) a dis object is required anyway. The prj information could be provided as arguments in the call to rmf_create_dis
with sensible defaults:
rmf_create_dis(origin = c(0, 0), cornercoord = FALSE, llcoordinate= TRUE, crs = NULL, rotation = 0)
where crs
plays nicely with sf::st_crs()
. Setting these arguments on an existing dis object would be as easy as creating list elements:
dis$rotation <- -12
dis$crs <- sf::st_crs(31370)
or we could have a function for that:
dis <- rmf_set_projection(dis = dis, rotation = -12, crs = sf::st_crs(31370))
which returns the dis object for easier piping.
Reading and writing would then also go through the discretization file. Reading/writing additional arguments from data set 1 (OWHM style) shouldn't be a problem since the discretization file is always in free-format. So this can be used for all models. The epsg code could also be added to data set 1.
The difficulty would then be in handling the ModelMuse format. I'm not that familiar with ModelMuse. Are these comments always written or are there cases when ModelMuse doesn't write this information? Does ModelMuse read this metadata directly from the comments in the dis file or does it also need the usgs.model.reference file?
If everything is contained in the dis file, rmf_read/write_dis()
can read/write this information in the header comments in addition to reading/writing it in data set 1. The issue is that we would then include the prj metadata twice, once in the comments and once in data set 1 and the crs should still be read/written from/to the usgs.model.reference file.
As a more general question, do you envision RMODFLOW to handle GUI specific files such as usgs.model.reference ?
from rmodflow.
Have to look more deeply into the ModelMuse comments in dataset 0. But to answer your last question: No, except maybe ModelMuse (since it is also USGS and open source). But only reading then I would say, just to be able to get these details from USGS models that are available online and could be used as examples in the package for instance (meaning we can then easily insert these in the discretization file; see also #6).
For the function to inject the details in the file, I was thinking about one that does not read in and process the file. Just one that inserts the comments in the first few lines of the file on disk. But doing it in a pipe chain makes sense as well (maybe both can even be implemented through S3).
Note I have also been thinking about rotation center, a url, citation, and next to crs maybe also epsg as potential metadata. Some of these would probably be more appropriate as part of the name file, which can also have (max 300 character) comment lines ...
from rmodflow.
Related Issues (18)
- Error reading .dis file HOT 2
- RMODFLOW extension packages
- Consistency with ModelMuse HOT 2
- Add examples in function documentation
- Replace akima dependency HOT 4
- Speed-up reading/writing arrays
- Reading recharge package fails when time-varying parameters are present HOT 3
- Weighted goodness-of-fit measures for use in optimization
- Automatic installation of MODFLOW variants, and finding paths to executables
- Package object structure: Dimensions, and maybe other things HOT 5
- Consistent S3 class names HOT 2
- Bug in rmf_create_hob (and rmf_write_hob) when dealing with transient observations HOT 1
- RGDAL Dependency Future HOT 2
- Basic MODFLOW package/file object functions HOT 5
- Install codes and example models HOT 1
- Execute, optimize, analyze HOT 2
- rmf_convert_grid_to_xyz works not correctly HOT 3
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from rmodflow.