Posting to GRASSLIST in the hope to solicit more discussion/ideas.
On Tue, 16 Jan 2001 21:04:11 -0700, Roger S. Miller wrote:
"Eric G . Miller" wrote:
On Fri, Jan 16, 1998 at 05:23:12PM +0000, Rick Gagne wrote:
> I am starting up a large urban land use groundwater quality study (40
> km by 60 km study area, 50 m cell size, 3000 wells to be sampled 10
> times over 15 years) in Nova Scotia, Canada, for which GRASS is
> beautifully suited.[snip]
Quite a project. What database program will you (Rick Gagne) be using?
I was thinking PostgreSQL. That's why I was so pleased to see it get integrated to
GRASS.
> I understand that someone did some work to integrate MODFLOW with
> GRASS (version 3.0?). Does anybody know what may have come of this
> work? Has anyone tried to integrate groundwater models (MODFLOW in
> particular) with GRASS versions 4 or 5? Finally (a concept question
> for those with knowledge of the GRASS inner workings and direction of
> development), would it be difficult to write code to integrate
> MODFLOW, MODPATH and perhaps other related USGS groundwater
migration
> model programs with some future version of GRASS?
I'll try to take a look at the MODFLOW, etc... programs. I'm thinking
they might have alot of DOS'isms which might make it difficult to
compile under unix boxen. I have a few colleagues who are familiar with
MODFLOW who could also benefit from such an interface. Definitely a
worthy companion to grid3 functionality...MODFLOW (at least through the MODFLOW96 version) is written in FORTRAN,
and I think it's fully compliant with the ansi F77 standard. Some of the USGS
support programs may contain optional features unique to Lahey FORTRAN.
USGS uses MODFLOW internally on DGUX and other unix-like systems.
I think you're right. In fact, in addition to DOS, the USGS distributes MODFLOW-96
compiled for DGUX, SGI and Sun, but not Linux. Also, to date they seem to have
MODFLOW-2000 available as a binary compiled for DOS (or Windoze :-)) only.
Do you know anything more about MODFLOW 2000 (it became available in Aug.
2000)? And what about source code . . . I haven't seen any reference to it on the
USGS Web site . . . have you?
One of my main uses for Grass is to support large MODFLOW applications.
So far I've only used it as a post-processor, and then only once. It
worked very well, with fairly minimal programming needed. The model I
worked with was originally built with a custom interface to ARCINFO.
The model grid used a variable cell size and it wasn't oriented with
geographic coordinates, so there was no possible direct correspondence
between raster cells and model cells.
Don't you wish geologic trends and hydraulic anisotropies followed map
boundaries! And who said geologists were borring?
Briefly, I constructed a cell map of the model grid from a vector map
representation of the model grid using v.to.rast - I set the raster cell
size so that the raster map gave about 100 cells to the smallest model
cell. The vector map was built so that v.alabel would label the model
cells in a known sequence. Those area labels became the categories in
the resulting raster map. Once the raster map of the grid was set up,
any output from MODFLOW could be rewritten as reclass rules for
r.reclass and displayed easily and efficiently. I put the reclass rule
files into a pgsql database and was able to turn out analysis after
analysis on demand, without much delay and with matching illustrations.
All in all I thought the process was impressively simple and easy.
Neat approach! I would have tried to rotate grids, likely without success. Your
approach gets around the issue of variable grid size employed in GW modeling,
and would make it easy indeed to "automate" output from multiple runs.
All(?) MODFLOW post-processors use its unformatted sequential access
output files. The structure of FORTRAN unformatted sequential access
files isn't well-specified, and can differ from compiler to compiler --
I've run across 3 or 4 variations. Generally MODFLOW and any program
that is used to postprocess MODFLOW output need to be compiled with the
same compiler, or a *whole* lot of work might be needed to interpret
from one file structure to another, and from one floating-point format
to another.
Are work-arounds possible to allow a close mariage of MODFLOW with GRASS?
I have not yet used Grass as a pre-processor for MODFLOW.
That's where it would be very useful to me!
Conceptually, it seems like it would be easy to do *if* the model grid has a
constant cell size and if the grid is oriented with geographic coordinates. The
general case might be more difficult. I'd love to hear ideas.
Me too!
Regards,
Rick
RG Hydro-Environmental Ltd.
WaterWatch ..... independent groundwater research
Richard Gagne, P.Geo., President
PO Box 25099
Halifax, NS Canada B3M 4H4
e-mail: rghydro@waterwatch.com
phone: (902) 457-7010
fax: (902) 457-3934