Jump to content
GMS, SMS, and WMS User Forum

julian.weir

Members
  • Posts

    27
  • Joined

  • Last visited

Profile Information

  • Gender
    Male
  • Location
    Christchurch, New Zealand

Recent Profile Visitors

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

julian.weir's Achievements

Newbie

Newbie (1/14)

0

Reputation

  1. Yes, it is the observations that I cam comparing. There are differences between the NWT and the USG solutions, but not huge, depending on how the unsaturated cells are treated. There looks to be a consistent bug with how GMS interpolates head to the observation location. I have also received a message from someone else who has experienced the same problem when the observation elevation is specified by either 'Z location' or by 'Use well screen'. And as you have found, setting the option to 'By layer number' does not have this problem. In my case I have hundreds of observations, so it will be very tedious to manually assign the layer number manually for each. I have sent GMS support additional information along these lines, so we'll see what they come back with. It just takes ages (many weeks) for a reply. Thanks.
  2. Thanks for that idea. I have trialled using GMS 10.4 (with MODFLOW-USG 1.5, 2019), GMS 10.3 (with MODFLOW-USG 1.4, 2017) and GMS 10.2 (with MODFLOW-USG 1.3, 2015), and all gave about the same solution, and all had the same large differences between MODFLOW head values and corresponding observations reported by GMS. So, it still looks to be a GMS bug. I'll see what the support team can find.
  3. Hi all. I have recently set up a MODFLOW-USG model, one that was previously constructed as a MODFLOW-NWT model (and worked very well). I have found that the values of heads in some cells calculated by GMS are vastly different to the heads in the cells calculated by MODFLOW. Has anybody found this before? It may have to do with interpolating between unsaturated and saturated cells. I’m not sure if it is a GMS bug or my operating error. I have contacted GMS support and they are looking into it, but they are extremely slow at responding. Any tips would be appreciated. Thanks.
  4. 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.
  5. Thanks Alan, that's helpful to know.
  6. 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.
  7. 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.
  8. 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.
  9. 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
  10. 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.
  11. 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.
  12. Thanks Greg. I'll look into that if the updates don't do the trick. I appreciate your help.
  13. 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?
  14. 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.
  15. 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.
×
×
  • Create New...