Jump to content
GMS, SMS, and WMS User Forum

Bruce Campbell

Members
  • Content Count

    114
  • Joined

  • Last visited

Everything posted by Bruce Campbell

  1. Hi -- I'm having trouble getting all of the water level residuals out of a multi-layer transient MODFLOW model in GMS 10.3.8. I need to get the residuals out layer-by-layer. For instance, in the surficial layer of the model, I have 224 observation points but the number of water levels associated with each point varies. There may be only 1 water level with a observation point or there may be 100's of water levels with another observation point over a period of time simulated by the model. When I go through the Plot Wizard, I can get one residual per observation point but can't see a way to get multiple residuals for the observation points with more than one one water level. Most likely I'm missing something. I can get all of the water level residuals in the PEST output, however, PEST renames the observation points and seems to jumble them up. I'm working with about 20,000 water levels in this case. I've tried sorting and data base queries but there are many duplicate water levels and this hasn't worked. Any ideas would be appreciated.
  2. Hi Sylvain -- I've had good results using a 2-D grid. I) create a 2-D grid from the 3-D grid 2) do a linear (or other type) interpolation of your raster recharge data to the to 2-D grid. These will stack up for your 120 rasters under the 2-D grid 3) Go to MODFLOW -> Optional Packages -> Recharge and the use the 2D Dataset - > Array to put the 120 datasets into the model at the appropriate stress period
  3. Hi Michal -- I do all of my pest work outside of GMS. I set up the pilot points and other variables in GMS, save and run the files - up to the point where the *.PST file is written. I stop the execution in GMS and do all of the PEST work in DOS prompt windows. The *.PST file usually requires extensive edits but when I get in all back together, PEST works fine.
  4. Hi -- Wanted to see if an attribute could be added to the water-level observation coverage indicating a PEST observation group. Of course. this would have to travel through the PEST setup process and end up in the *.PST file, somehow. In conversations with John Doherty, he recommends putting the water-level observations into groups - by aquifer / model layer / other, to help with the PEST process. I've tried to think of way to edit the *.PST file but haven't been successful.
  5. Hi Michal -- I've had this same problem. What I've done is interpolate the pilot point values to a 2-D grid (hopefully, the same as the model 3-D grid) and then import the interpolated values into the corresponding model layer input. For example, horizontal hydraulic conductivity pilot points for the models surficial layer are interpolated to the 2-D grid then in your MODFLOW package, use the "2D Dataset -> Layer" command to place the interpolated horizontal hydraulic conductivity values into layer 1 of the model. Do this for all of your pilot point sets. Remove all other PEST variables, set up the GMS files for a forward run and try the export to native text again. From what I've seen, GMS does not export files with PEST inputs.
  6. Hi Petra -- Sounds like a good compromise to reduce the number of model cells. Groundwater modeling always seems to be a series of compromises... Here's the NWT solver settings that Rich passed along. I went back and looked at his description of the settings and he wrote that these settings would be a good starting point for large NWT models, 1.0E-1 1500.0 100 1.0e-8 2 1 1 SPECIFIED CONTINUE 0.90 0.00001 0.000 0.10 0 50 3.0 0.9 linmeth=1 (GMRES); =2 (xmd) 1 0 3 7 1 0.0 1 5.0E-3 1.0e-3 100 XMD I've had good results with these settings and was able to reduce my runtimes. The first 2 (the closure criteria) are probably the most model-specific.
  7. Hi Petra -- I've been struggling with long run times for a couple of large (up to about 8 million active cell) models, also. I'm doing PEST parameter estimation calibration runs across my local network and see differences in run times depending on the computer capabilities. On older machines (4-5 years old) the run times are usually around 10 hours. On a brand new machine (Dell Latitude - lots of RAM and a fast processor) the run times are about 4 hours. I'm using MODFLOW-NWT and have a unconfined surficial layer and have gotten very good results. I suspect the difference in run times you see from HUF as compared to NWT is the ability of NWT to handle dry and flooded cells better than HUF. If you don't already have one, suggest you get a new fast machine with at least 32 GB of RAM. Also, I've been back and forth with Rich Niswonger, one of the authors of the NWT code on my large model solver settings. He's run the model(s) and suggested a set of NWT solver settings for my models. Would be glad to post them here, if you would like to have them.
  8. Hi -- Wanted to see if there was a way to designate PEST observation groups directly in GMS. I have tried editing the *.pst file after it's created by GMS but with about 92,000 head observations (from multiple map coverages representing multiple model layers) it quickly becomes problematic.
  9. Hi Sean -- I did the SFR2 package construction all in GMS. The segments have to be in order - from upstream to downstream and the GMS MAP module programming does a good job of this. The trick I found was having a good DEM and matching flowlines to work with. Even with all the prep work we did, there we still some segments that had to fixed by hand.
  10. I'm running with about 8,000 segments in the larger of the 2 model I'm working on. I don't think the type of topography is that important, just get the closed depressions out and make the flowlines match the DEM
  11. Hi Sean -- What we did recently to get the SFR2 package running was mainly a GIS exercise. We simplified and put all of the streams in a "blanket" type surficial layer that covers the entire active model area. Then we put a Digital Elevation Model (DEM) together of the land surface altitudes and and made it match the model grid - grid-wise. Next, use GIS magic to get the sinks (closed topographic) areas out of the DEM. Use more GIS magic to create flowlines from the DEM. We didn't have any luck with the National Hydrography Dataset - the flowlines don't match the topography and you get some arcs with the downstream ends higher than the upstream ends. When all of the GIS work was done (it's fairly high-level work) we had a DEM and flowlines that world match and work in GMS and were able to get functioning SFR2 packages. There are several advantages to the SFR2 package over the Drain or River packages - the primary one being the removal of the "infinite" term in the equation that lets the Drain and River packages take or add as much water as the head differences and conductivity allows. The SFR2 budget is limited to the groundwater that has been discharged to the stream and any surface water volumes that are directly applied.
  12. FYI - A new version of MODFLOW was posted on the USGS page yesterday: https://water.usgs.gov/ogw/modflow/6beta.html
  13. Hi -- I'm using PEST to estimate MODFLOW Drain Package conductance terms. I have a number of stream gages where I have analysed the data and calculated the groundwater baseflow component and I'm using these data as observations in PEST. In several of the basins, I have 2 (or more) gages and have a question about the PEST variable. In the stream arcs, I'm setting up a negative number in the attribute table for the conductance term (-201, -202, etc). What is the best procedure to use for having the 2 gages in the same basin. What I've done in the past is have 2 separate variables for the 2 gages. However, it seems like that cuts the simulated flow term at the lower gage. Does anyone have a better procedure?
  14. By any chance is there a Linux-compiled version of the MODFLOW-NWT_h5_64 executable available? I wanted to use a cloud environment to calibrate a GMS created model but the cloud operating system is Linux.
  15. Hi Michael -- Thanks for the quick response. How about the name of a well or observation point - I have some long names from our database. As much as 30-50 characters with punctuation such as parentheses, pound signs, and periods. Could these long names be a problem? I can replace them with simple consecutive numbers.
  16. Hi -- How many significant figures does GMS use when assigning coordinate locations for groundwater level observations? I've got a little over 400,000 groundwater level observations in a GMS 10.1.4 model and having trouble using PEST outside of GMS. I think what's happening is GMS is creating duplicate locations for the wells. I have 8 significant figures on the X and Y coordinates and there are no duplicates. However, if GMS is only using the first 2 or 3 of these significant figures in the coordinates, I'll have lots of duplicates.
  17. Hi -- I'm using GMS 10.1.4 and having trouble with how GMS is assigning the elevations to SFR2 segments. 1) I have all of the SFR2 arcs in the top layer. 2) Created the top elevation of the top layer and the SFR2 "Elevup" and "Elevdn" from the same raster. 3) Interpolated the raster to a 2D Grid and imported that into the Top Elevations for Layer 1 4) Used same raster for the "Elevup" and Elevdn" fields in the SFR2 attribute table in the Map Module. Mapped the coverage to MODFLOW The problem I'm having seems to center on how the SFR2 elevations are produced when the "Map to MODFLOW" comand is run. I'm getting thousands of errors - "the stream elevation is below the cell bottom" When I check the raster (the same one is used to produce the top elevation of the upper layer and the SFR2 "Elevup" and Elevdn") the top elevation honors the raster. However, the elevations produced from the raster by the SFR2 process (Map to MODFLOW) are, in many cases lower or much lower than the raster. Ideally, I would think that the two different elevations 1) the top of the top layer and 2) the SFR2 segment elevations would match closely, since they were derived from the same raster. Any insights would be appreciated.
  18. Hi -- There's a new version of MODFLOW-NWT that was posted on the USGS Office of Groundwater web page this month: http://water.usgs.gov/ogw/modflow-nwt/ This is version 1.1.2 I noticed the H5 version in GMS is 1.0.9
  19. Got a solution using the Multi-Node Well1 (MNW!) package. Set the MNW1 package coverage up using the top and bottom of the well screen(s) and map the coverage to MODFLOW. Switch to the IJK view mode in the MODFLOW MNW1 package and there are the layer assignments (K). I J K Name 475 513 3 AK- 28 396 536 3 AK- 30 478 62 3 AK- 31 476 59 3 AK- 32 292 261 5 AK- 36 274 298 5 AK- 37 384 198 3 AK- 38 243 291 3 AK- 41
  20. I've got several thousand wells with single or multiple groundwater levels that I want to use for model calibration purposes. The problem is assigning the wells to the 5 aquifers in the model. I have coordinates and the altitude of the top of the top screen and the altitude of the bottom of the bottom screen. We constructed the framework for the model in ARCHydro so I don't have solids in GMS. Is there an automated way to assign the wells to the aquifers or is it one-by-one by hand? But maybe there's a way to do it ARCHydro?
  21. Hi -- I've got an existing GMS MODFLOW model with a lot (hundreds) of wells that have associated transient pumping data. The model is about 8 years out of date and I need to add new water-use data to the existing wells in the GMS files. Was thinking I could export the data from the Map coverages and maybe pull the old data into an Access database and put the new data together with the old data. However, when I export the coverage with the old data from GMS and take a look at the *.dbf file, all of the flow rates are 0.0. Any ideas?
  22. Thanks Bill, this worked very well. I didn't notice it in the Global Options menu. Probably lot's of things in there I'm missing!
  23. Hi -- Have a suggestion for assigning the altitudes for the various MODFLOW surface-water packages such as SFR2, STR, DRN, or RIV. In simple models this is usually not a problem but in more complex models with topography that varies across the model, it's a challenge. Using TIN's to assign the altitudes works well usually but I've had it lead to problems with hundreds to thousands of model cells when the process assigns the surface water feature to a altitude below the bottom of the cell. I suspect this is caused by the various interpolation steps required to get the cell altitudes into a TIN and then into a MODFLOW input file. I've got a Python script that goes through the discretization file and pulls the top of each cell that has a surface water feature (streams or rivers) and uses the top of the cell altitude directly to build the MODFLOW input without any interpolation. Of course doing this means it's an extra chore to get these data back into GMS and use the functionality of the program. Just an idea, but seems like a better way to assign the altitudes without multiple interpretation steps.
  24. Hi -- I've got something that looks like a bug when I run the "Export Native Text" command. The problem is in the file that's output for the STR package. The STR inputs for Discharge, Conductance and the Top and Bottom altitudes for the individual stream reaches are pushed together without spaces. Here's an example from the beginning of the file: 70883 14353 3 0 0 128390.4 740 0 70883 0 0 8 8 76 1 1 0.0313.580463 7448.3589313.579456313.580463 8 7 76 1 2 0.0344.32457613513.4918344.323569344.324576 8 7 75 1 3 0.0316.22881841210.9933 316.22781316.228818 8 7 74 1 4 0.0292.13801741757.7071 292.13701292.138017 8 7 73 1 5 0.0272.52672941382.5175272.525722272.526729 This gives an error when I attempt to run the model outside of GMS.
×
×
  • Create New...