Jump to content
GMS, SMS, and WMS User Forum

julian.weir

Members
  • Content Count

    23
  • Joined

  • Last visited

Everything posted by julian.weir

  1. Thanks Alan, that's helpful to know.
  2. Hi all, I am attempting to run a MT3DMS simulation (and eventually SEAWAT, too) with MODFLOW-NWT, and MT3DMS reports this error: Error Reading Flow-Transport Link File Possibly Caused by: 1. Incompatible Styles of Unformatted Files Used by MODFLOW and MT3DMS; 2. Unformatted Flow-Transport Link File Saved by Verison 1 of LinkMT3D Package Which Is No Longer Supported by MT3DMS. Has anyone come across this before and has a suggestion on how to fix? It may be related to a GMS bug (I am using version 10.3.5, 64-bit) as I have tried an older model that successfully ran MT3DMS last year on an earlier version of GMS, but that model now reports the same error. I have contacted GMS support, but they are very busy and slow to respond, so I thought I’d ask the user forum to see if anyone had a solution. Thanks.
  3. I have had a similar error return when mapping coverages to MODFLOW. I'm waiting for technical support to reply, but it is an error that takes a while to reproduce due to the large model.
  4. Hi all, Has anyone had problems using the 'Redistribute' tool in GMS? I have a model that I am attempting to refine along a few rows of cells (I want to double the cell resolution in some areas). I have tried with about 2 or 3 rows of cells successfully, but when I try any more rows than this, MODFLOW does not run - it crashes after writing the layer option information in the *.out file. GMS' model checker does not report any problems. Any tips on where else to look to problem find? Thanks.
  5. Hi Jonas. I’ve experienced similar unusual responses when using PEST within GMS, with and without SVD and SVD Assist. Sometimes PEST will reduce my error nicely; other times it gets nowhere. Yet, when it goes nowhere I can manually adjust parameters myself and reduce the error. I’m not sure of the reasons, but it may be related to GMS and it writing the MODFLOW files from pilot points. I’ve had particular problems using kriging interpolation, so much so that I have now switched to IDW interpolation. While I now have less problems, I still experience unusual PEST behaviour. It’s a problem I’ve experience on and off for several years now. I’d be interested to see if others have had any similar problems. My models are with Aquaveo support, but the problem can’t be consistently repeated, so it is difficult to fix. Have you tried importing the optimal parameters from the PEST run into another forward run? Perhaps PEST is writing the new *.par file o.k., but GMS is not updating the screen with the final result (I note GMS’ printing of the *.rec file shows a mixed up version of the actual *.rec file). Try importing the *.par file and running a forward run (saving as a new model name in case something goes weird) then see how the new result looks. Regards, Julian
  6. Yes, I have the latest nightly build. But they are still trying to find the problem, so the build won't include any fix yet. Thanks.
  7. Hi Jonas. Did you solve your problem? I'm having similar issues with my kriging whereby GMS appears to not be writing the Kh values for MODFLOW. Tech support are looking into it, but it may take a while. So I was wondering if you had a solution. Thanks.
  8. Thanks Greg. I'll look into that if the updates don't do the trick. I appreciate your help.
  9. Hi Alan. Thanks for your response on mapping SFR2 to multiple surface layers. It will be good to have that available in the next release of GMS. Would it be possible to look at doing the same for recharge mapping too?
  10. 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.
  11. 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.
  12. 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.
  13. 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.
  14. 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.
  15. 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.
  16. 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.
  17. 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.
  18. 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.
  19. 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.
  20. 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.
  21. 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.
  22. 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.
×
×
  • Create New...