Jump to content
GMS, SMS, and WMS User Forum


  • Content Count

  • Joined

  • Last visited

Community Reputation

0 Neutral

About julian.weir

  • Rank
    Senior Member

Profile Information

  • Gender
  • Location
    Christchurch, New Zealand

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. I had the same problem, and the helpful guys at USGS helped me solve it. I was able to replicate the NWT solution by setting all layer types to 'Convertible Upstream' (in the LPF Package options) and using the '(1) Newton with Delta-Bar-Delta' nonlinear solution method (under the SMS solver options). When theses are selected, it reverts to the equivalent of MODFLOW-NWT, and I understand that the cell wetting options are not used. Hope that helps.
  2. Thanks Alan, that's helpful to know.
  3. 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.
  4. 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.
  5. 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.
  6. 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
  7. 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.
  8. 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.
  9. Thanks Greg. I'll look into that if the updates don't do the trick. I appreciate your help.
  10. 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?
  11. 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.
  12. 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.
  13. 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.
  14. 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.
  • Create New...