• Content count

  • Joined

  • Last visited

Community Reputation

0 Neutral

About julian.weir

  • Rank
  • Birthday

Contact Methods

  • ICQ

Profile Information

  • Gender
  • Location
    Christchurch, New Zealand
  1. Thanks Sean. I'll look into that more and see if the extra effort is worth it, or whether I just roll back to an earlier version of MODFLOW. There are other limitations with USG there seems too, such as no PEST-ASP module.
  2. Hello. Through recent discussions with Alan, it looks like the SFR2 package will only map to a single MODFLOW layer (layer 1). A recent MODFLOW-USG model that I have developed has layer 1 pinching out at the surface and then layer 2 carries on (at the surface), and similar for deeper layers. Can the SFR2 package therefore be modified to allow mapping to any surface layer (i.e. layers 2 and below that outcrop)? That is, any cell that appears on the surface, regardless of the layer assignment. Using the automatic layer assignment of 'auto assign to one cell' might be a way to do this. Thanks.
  3. Thanks Alan. I'll submit a feature request regarding the SFR2 mapping. Regarding the RCH mapping, I'm still not sure if the lack of mapping to surface layers 2 (or higher) is a GMS limitation or a MODFLOW-USG limitation. If it is a GMS limitation only, then I could also add that as a feature request. But if it is a MODFLOW-USG limitation, then I would have to look more at an alternative workaround (or roll back to MODFLOW-NWT or similar). That 'Layer Assignment' link is useful. At the very bottom it states that with MODFLOW-USG, the specified layer option is not supported by Map > MODFLOW with RCH package. So perhaps it is a MODFLOW-USG limitation (i.e only layer 1, and not auto assign to 1 cell). Can you confirm please? Thanks. Thanks also Sean for the suggestion. I would have thought that that is what GMS would do when generating a grid (set the upper most cells all to layer 1, regardless of the material properties). It'll be quite a lot of work to manually assign a new top layer to the various material properties, but it could be done. But I think I may still be stuck with a thin upper layer that then causes potential issues with SFR2 package inverts passing below the lower elevations of the cells.
  4. Hi all. I have a problem mapping recharge to MODFLOW-USG within GMS (version 10.2.4). My MODFLOW-USG model has multiple layers. Layer 1 pinches out to expose layer 2 at the surface, and similar for deeper layers (that's how GMS created the 3D grid from horizons and TINS etc). When I map recharge to MODFLOW (steady state rates for now, but will use transient rates later), GMS maps the recharge fine to the surface where layer 1 is exposed, but will not map anything to the surface where layer 2 (and below) is exposed. So only part of the recharge is mapped to MODFLOW. I have discussed this with GMS support, and they have suggested that I add a thin upper layer (a new layer 1) to the model over the whole model domain, and set this layer to inactive. Recharge would then map to this new layer 1, and pass through this inactive layer (if the right settings are selected) to the first active cell below. However, I also have a SFR2 coverage that needs to map to the uppermost layer, and this will not map to inactive cells. This also creates errors with river bed inverts passing below the bottom elevation of layer 1 cells. I therefore don't think this is a suitable solution. GMS support have been very helpful, but they are very busy and response times are long. Therefore, I was wondering if anybody else has had this issue arise, and if they have found an alternative work around. Is it a GMS mapping problem or a MODFLOW-USG limitation? I would have thought that having underlying layers outcrop to the surface is not uncommon, and so it would be unusual for MODFLOW-USG to not support this. Any help would be appreciated. Thanks.
  5. Thanks Alan. Adding that as a feature request would be great. Calibrating to aquifer leakage (to/from the SFR2 package) or to river flows directly (or preferably to both) would make a big difference reducing non uniqueness. And within the GUI makes things so much easier. We can currently view leakage and river flows from the SFR2 package within GMS (via the CCF and CCF2 output files), so presumably it wouldn't take too much effort to add these as calibration data sets. The STR package currently permits automated calibration (within GMS) to aquifer leakage. Within MODFLOW-USG would be fine. Having said that, I'm having problems mapping the SFR2 package to MODFLOW-USG. I've emailed support, but they have been very busy recently.
  6. Hi Alan. Is it currently possible to use PEST to calibrate to river flows calculated via the SFR2 package while running a MODFLOW-USG model within GMS? Or does your above comment refer to running PEST and MODFLOW-USG outside GMS? Thanks.
  7. Adding the ability to calibrate transport withe the PEST suite would be an excellent improvement to GMS' interface. Having the ability to calibrate both flow (MODFLOW) and transport (MT3DMS) at the same time, within the GUI, would make a big improvement to reducing model non-uniqueness. It would be great if you would give this high priority to include in GMS as it is something we've been asking for a few years now. I understand Groundwater Vistas has the ability to do this. Thanks.
  8. Yes, this would be very helpful. Even better, add solute surface water routing to the MT3DMS interface with MODFLOW-USG (or MODFLOW-2005) so that mass can transfer between, and mix with, groundwater and streams within an SFR2 network.
  9. Yes, this would be an excellent improvement to GMS' PEST interface. Having the ability to calibrate both flow (MODFLOW) and transport (MT3DMS) at the same time, within the GUI, would make a big improvement to reducing model non-uniqueness. It would be great if you would give this high priority to include in GMS as it is something we've been asking for a few years now. I understand Groundwater Vistas has the ability to do this. Thanks.
  10. I agree. It woud be really great to interface MT3D with PEST through GMS. Given it can be done outside GMS relatively easily, I would envisage it wouldn't take too much effort to interface within GSM too. Thanks.
  11. I agree. It would be great to be able to simulate steady state transport. The modifications to the MT3DMS input files to run steady state are quite simple, so presumably it would be simple to add to GMS as well.
  12. I have the same re-setting issue. When the project is closed and then re-opened, GMS will reset all zones to a default of 1. GMS advised that it is a bug, and they are currently working on fixing it. Though I understand that the problem in my 1st post isn't related to this.
  13. Hi. Has anybody had any issues with MODFLOW's zone budget? I am running a very simple model in GSM v 7.0. The model is multilayer with constant heads all equal to the initial conditions. This results in all water levels being the same in all layers, and all flat. Model layers and land surface are all flat too. I run a transient model with no pumping or recharge (no stresses at all) and predicted water levels are flat (as expected). However, the zone budget reports significant changes in storage in the upper layer. Ins and Outs are misbalanced too. I would expect small calculation errors, but the errors returning are quite large. Has anybody else come across this or have any suggestions for correcting? Is it a zone budget bug? Different solvers and different iteration criteria make little difference. Thanks in advance.