Jump to content
GMS, SMS, and WMS User Forum

All Activity

This stream auto-updates

  1. Last week
  2. Hello, I am encountering an error where, when I try to register my copy of GMS (Groundwater Modeling System) It states an error: "Virtual Machine or Server detected. Network Lock required." Security String :0 56bb669ee I am not using a virtual machine, I am using a fresh install of windows 10 on a Surface Book. Please advise, Thank you in advanced.
  3. Earlier
  4. Hello, There is a parameter in the swt_v4.f on line 200 called MXPER. It should be just a matter of changing its value to lets say 100 000 and compiling.
  5. Hello all, I realize it is been a number of years since this thread was last active, but I am running into a similar issue in SEAWAT V4. I need ~35,000 stress periods and it appears the max number of stress periods in SEAWAT is 10,000. I'm receiving the error below. Does anyone know where I can increase the number of allowable stress periods in the SEAWAT source code so that it can be recompiled to accept a larger number of stress periods? I'm modeling tides, so many stress periods are needed to resolve the tidal signal over a year. **** STRESS PERIOD(S) IN SIMULATION THE MAXIMUM
  6. If your river stage is below the river bottom, then you definitely want to switch to one of the stream packages. The stream packages allow the river/stream to go up and down based on the surrounding groundwater elevation and flows in the stream.
  7. If you have a river stage below bed level, you will get a warning but the model may still run. Unfortunately, the result will be garbage, sometimes spectacularly so. This is because the package includes the calculation stage elevation - bed elevation to calculate gradient, so then the value becomes negative. It could be solved by inserting a line of code that sets flow to zero if stage is at or below bed level, but for some reason that has never been implemented by USGS (perhaps I'm missing some consequence of doing so). I once got someone to modify an earlier version of the MODFLOW source cod
  8. Hi everyone, I am working on my multi layer model in MODFLOW-USG. In the middle of the model I have a big river. For that river I have defined river bed and head stage as TINs. I am trying to Map it in MODFLOW-USG as polygon but there are too many errors (although conceptual model looks fine). Most common errors are "Stage elevation is below river bed" and "River stage is below cell bottom elevation". A few time I succeed to start MODFLOW but the heads were too high and low (-2e-17 to 2e+12). Also there are many dry cells close to the river. What is
  9. Hi, I have the same problem, I tried to save the project with another name, and tried to change the initial values of the pilot points, but the model detected OK, but finished with error ( without converging). Do you think if it is the problem with the transient data, or if there is any settings with pilot points, or the problem with the pilot points locations?
  10. Hi I have the same problem, and the model stoped with error. However, when I check the simulation, there is no error detected. Is there anyway that I can solve this? Thank you
  11. 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
  12. Okay - so the way your first post was worded, it sounded like you were getting different head results in the NWT than the USG runs. Your latest post suggests that what you are comparing are "observation" results (which is probably why the topic is titled as it is). Can you confirm that? Can you also confirm that by manually checking cells in the NWT and USG simulations that the heads are similar? I know that I had issues with observations in my USG simulations (and seem to recall asking about it as well - there might even be a post on this board about it), so I managed it in other ways (se
  13. 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.
  14. I think the difference may be in the MODFLOW build itself. While working with MODFLOW-USG a couple of years ago (which, if I understand correctly, would use similar code to MODFLOW-NWT), an updated version came out which changed how calculations were performed for "dry" cells (due to users who didn't agree with how the solver handled those cells). It changed my model results and would have negated the work I had done for half a year. Working with the GMS developers, we solved it by using the older MODFLOW executable during my model runs. It is easy to do this by directing GMS to run the ol
  15. 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.
  16. Hi Michael, Thank you for the prompt response and clarification. I tried the screen levels instead of the layer range and it works. Best regards, Lalith
  17. Hi Lalith, this is because you used layer range. If you use Screen Top/Bot GMS will use different algorithm and the amount specified will be total for entire well. Or you could just leave it as Layer range and set the Q value as 1/3 of the total rate (if the well is set in 3 layers). I belive this is intentional GMS feature.
  18. Hi there How easy is it to integrate or interface GMS generated MODFLOW models with MIKE FLOOD? Any thoughts on how to do this directly or indirectly will be greatly appreciated. Cheers Hisham
  19. Hi, I have a MODFLOW/SEAWAT with 12 layers. There are pumping wells in the model that runs through multiple layers (the screens go through multiple layers). Please see how I included the well information in the conceptual model. These wells are supposed to be screen through layer 6 through 8 and each pump is supposed to extract 757 m3/day as you can see. I saved the model in the native text format also in the model set up so that I can also run the model in the command prompt. When I look through the .wel file I noticed the pumping rates are assigned in the following way in the
  20. Hi, I get the same error message (also new to the modell). I have tried both the full plane and half plane of the modell, but the modell produce the same error message everytime I try to introduce the bottom friction. Did any of you find a solution to this problem? - Mari
  21. Have you tried the LMG-solver instead? The PCGN-solver did not convince me mostly..
  22. I tried the PCGN solver and it was awesome to see it use 90% of my 24 cores. But, strangely the PCGN took 17 hours to run using all 24 cores, where the PCG solver only took 30 minutes to run basically using one core.
  23. Hi thanks for responding. I have the 64bit option and parallel option checked. I am using the PCG package. Has the PCG package not been parallized?
  24. The slow link in the model execution is most probably that you are not using a parallel version of MODFLOW (Check option in MODFLOW Global/Basic Package) or a not parallelised solver (LMG or PCGN). 2 x 12 processors = 24 processors - makes a max. of 4% usage per core if not parallelised...
  25. I don't know if this should be under the MODFLOW directory, but I have been trying to see if I can speed up my GMS runs. I have a GMS MODFLOW model that is taking about an hour to run and I would like to shorten that run time. I see that I am using about 2.5% of my CPU utilization and I am running about 300 kB/s in disk access time, well below the capacity of the CPU or disk. I have a dual processore Xeon system with 12 cores for each processor running at 3.2GHz. My disk drive is 4-2TB M.2 NVME SSD's running in a Raid 0 array in a PCIe slot. The system has 256GB of RAM. This configu
  26. This is a little late for adding to this topic, but your path name is really long. Try shortening up your directory path name and see if that helps.
  1. Load more activity
×
×
  • Create New...