[GRASSLIST:1368] (no subject)

Rick Gagne rghydro at waterwatch.com
Sat Jan 17 05:45:19 EST 1998


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 at waterwatch.com
phone: (902) 457-7010
fax: (902) 457-3934




More information about the grass-user mailing list