Jump to content
GMS, SMS, and WMS User Forum


  • Content count

  • Joined

  • Last visited

Everything posted by Michal

  1. Transient spatially distributed recharge

    Thank you for sharing the solution. Nice one Have you used some sort of interpolation to obtain modflow compatible dataset from the raster data? Or is the grid and rasters identical in number of rows and columns?
  2. Hi, try preparing the transient dataset so, that for each polygon in GMS coverage, there is a corresponding timeserie with the polygon id assigned at each row of the dataset. It will be a large dataset, but GMS should handle it unless you run out of memory.
  3. I agree with Hisham on this. There is no such concept as multipart polygon in GMS, as far as I know.
  4. Hello, this is interesting. Maybe there are 553 multipart polygons in the shapefile and when converting to feature object GMS performs multipart -> singlepart conversion. http://desktop.arcgis.com/en/arcmap/10.3/tools/data-management-toolbox/multipart-to-singlepart.htm
  5. PEST Observation Groups

    Hi Bruce, that would be very nice GMS feature. It could be even so, that head observations for different coverages would fall into different observation groups in the PEST control file. Also parameter grouping with custom naming would make thinks a lot easier. I can imagine, you could specify PEST parameter group in the Parameter dialog for each entry.
  6. Transient spatially distributed recharge

    Hi, I think it could be possible by interpolating transient TIN data (or maybe even rasters) into Recharge package using Interpolate to Modflow layers command. But I have not done it before. Let us know how you manage to handle it.
  7. Modflow 2000-transient model result

    Helo, try using MODFLOW-NWT instead of MODFLOW-2000. Its excelent in handling problems with cell drying/rewetting. In the LPF package set all layers to convertible. If insist on using MF-2000, maybe try different timestepping scheme to avoid overshoots.
  8. Hello, I am currently in the middle of parameter estimation process of transient MODFLOW model. The model has 21 stress periods. To obtain a good differentiability of model outputs with respect to parameter change convergence criteria had to be set quite strict in the NWT solver settings. This resulted in run time ranging form 30 to 75 minutes per run depending on the actual parameter set. Each stress period consists of a single time step. I was thinking, what the effect of different time stepping would be on the model run time? Would increasing the number of time steps per stress period make the model run faster or slower? Any experiences or advice on optimum time stepping with respect to model performance are welcome.
  9. Export native modflow files with Pilot Points

    Yes, this is my a workflow too. There are useful utility programs in PEST to use with pilot points, like PPKREG1 and VERTREG. The native PEST approach to pilot points is necessary to use with these programs.
  10. Hello, I have encountered a problem with exporting native modflow files from GMS. Some of the model parameters are defined using Pilot points. Lets say that I would like to use different version of MODFLOW to calibrate the model. I have succesfully exported the MODFLOW native files and I was able to start USGS version of modflow. The input data are read correctly, first stress period is solved, however during the second period MODFLOW stops. Here is the end of the output file: PERCENT DISCREPANCY = -0.03 PERCENT DISCREPANCY = -0.03 TIME SUMMARY AT END OF TIME STEP 1 IN STRESS PERIOD 1 SECONDS MINUTES HOURS DAYS YEARS ----------------------------------------------------------- TIME STEP LENGTH 2.67840E+06 44640. 744.00 31.000 8.48734E-02 STRESS PERIOD TIME 2.67840E+06 44640. 744.00 31.000 8.48734E-02 TOTAL TIME 2.67840E+06 44640. 744.00 31.000 8.48734E-02 1 1 STRESS PERIOD NO. 2, LENGTH = 29.00000 ----------------------------------------------- NUMBER OF TIME STEPS = 1 MULTIPLIER FOR DELT = 1.000 INITIAL TIME STEP SIZE = 29.00000 PARAMETER "sc1v1 " IN PARAMETER INPUT FILE HAS NOT BEEN DEFINED -- STOP EXECUTION PARAMETER "sc1v2 " IN PARAMETER INPUT FILE HAS NOT BEEN DEFINED -- STOP EXECUTION PARAMETER "sc1v3 " IN PARAMETER INPUT FILE HAS NOT BEEN DEFINED -- STOP EXECUTION PARAMETER "sc1v4 " IN PARAMETER INPUT FILE HAS NOT BEEN DEFINED -- STOP EXECUTION .... PARAMETER "GHB_3405 " IN PARAMETER INPUT FILE HAS NOT BEEN DEFINED -- STOP EXECUTION PARAMETER "GHB_3409 " IN PARAMETER INPUT FILE HAS NOT BEEN DEFINED -- STOP EXECUTION PARAMETER "GHB_3406 " IN PARAMETER INPUT FILE HAS NOT BEEN DEFINED -- STOP EXECUTION When modflow starts no interpolation is performed for the pilot points. I assume there is some custom routine in the GMS version that handles the interpolation from PP to the MF grid array. Please advice how this is supposed to be handled or what am I doing wrong.
  11. Export native modflow files with Pilot Points

    Thank you for your answer. Unfortunately this is not a solution to the problem, because you lose model parameterization. In my opinion it would be best if, when exporting native modflow files with parameters defined using pilot points, GMS writes also PEST "pilot point file" and "structure file". It could then write model BAT file with appropriate PEST utility programs involved prior modflow run, like PPK2FAC, FAC2REAL and REPARRAY. Such approach would allow parameter estimation using PEST.
  12. Fixed pilot points in PEST NSMC

    Just run from command line: pest case with case being the name of the modified PEST control file.
  13. Fixed pilot points in PEST NSMC

    Hi, no problem, you are welcome. In GMS it should be automatic, based on whether you check either Prefered homogeneous regularization or Prefered value regularization. However according to the recent experiences I strongly recommend not to do it this way. Be aware of the bug mentioned earlier regarding the usage of natural logarithm instead of decadic in GMS. I have no idea how this impacts the inversion process, but I would avoid it. If you have no log-transformed parameters, it should not be a problem, though. You can add prefered value regularization to the control file very easily by using the command line utlity from the PEST suite called ADDREG1. See the documentation to PEST (newpestman2.pdf, p. 21). It should make all the changes to the Control file necessary to run regularized inversion.
  14. Fixed pilot points in PEST NSMC

    Jonas, I have noticed, you were not running PEST in Regularization mode. That is probably the source for your error.
  15. Fixed pilot points in PEST NSMC

    Ok, thats definately a progress, PEST does not crash anymore . This is realy a weird bug, it should not crash so violently. To your new problem. Try turning SVD-Assist and Regularization off and set NOPTMAX to 0. Lets see if it works. Also try running PESTCHEK and examine the output.
  16. Fixed pilot points in PEST NSMC

    Hi, I have encountered the same error with my model. The reason why PEST and PESTCHEK crashed has something to do with the Regularization option. With Prefered homogeneous regularization option checked several empty regularization observation groups were created in the PEST control file. I believe there is something wrong with the Prior information data section in the PEST control file. After turning Regularization off or changing to it Prefered value everything runs just fine. There are three scatter point sets in my model with many parameters for different model layers. There are Totaly 18 parameters defined with PP for multiple model layers. It looks to me like some bug in writing the Prior information with such setup. Edit1: There were no fixed PP in my formulation. Edit2: There seems to be more errors. Here are some of the parameters and corresponding PI written by GMS: sc1v1 log factor 22.321 1.00000E-08 1000.0 general 1.0000 0.0000 1 sc1v2 log factor 16.947 1.00000E-08 1000.0 general 1.0000 0.0000 1 sc1v3 log factor 4.1647 1.00000E-08 1000.0 general 1.0000 0.0000 1 sc1v4 log factor 4.4251 1.00000E-08 1000.0 general 1.0000 0.0000 1 sc1v5 log factor 33.072 1.00000E-08 1000.0 general 1.0000 0.0000 1 * prior information pi0 1.0 * log(sc1v1) = 3.1055498123169 1.0 regul_1 pi1 1.0 * log(sc1v2) = 2.830082654953 1.0 regul_1 pi2 1.0 * log(sc1v3) = 1.4266545772552 1.0 regul_1 pi3 1.0 * log(sc1v4) = 1.4872899055481 1.0 regul_1 pi4 1.0 * log(sc1v5) = 3.4986937046051 1.0 regul_1 Log10(22.321) = 1.349, not 3.106 as supplied by GMS. Its the natural logarithm. However according to the PEST manual, it must be decadic:
  17. Porosity in MODFLOW and MT3D

    Hi Khaled, you are right about this. However please note, that this has nothing to do with the MODFLOW model results. There is no porosity variable involved in the governing equation of the MODFLOW mathematical model. So the values of porosity entered via the Cell Properties are used either for dataset postprocessing to calculate true flow velocity or for writing inputs for MODPATH as mentioned earlier. Now the question here is if it is also transalted from the Cell Properties to MT3DMS BTN file or not. Speedy, if this is so then it should be considered a serious bug in GMS. You can try changing the porosity in the Cell Properties dialog, save the model and look into the MT3DMS\case.btn file. Change it into something obvious like 0.666666. You should see if the array is written to the .btn file instead of the correct values specified in the MT3DMS dialog in GMS. If not sure check MT3DMS manual chapter 6.4 (Zheng and Wang 1999) for the BTN file format specs to help you locate the porosity array A11 in your file.
  18. Porosity in MODFLOW and MT3D

    This indeed looks like some GMS bug that is probably specific to certain usage. I suggest you contact the support and make sure they can replicate your problem. When you look into the Salt Lake example from GMS tutorials, you will find out that in MODFLOW>Global>Porosity dialog is not editable and correct values of porosity are entered in MT3DMS>Basic Transport Package>Porosity. In the Coastal Aquifer example the situation is different. The material properties for this example are enter using GMS Materials option in the LPF Package. The MT3DMS>Basic Transport Package>Porosity button is not present in the dialog at all. MODFLOW>Global>Porosity dialog is not editable and GMS notifies the user that materials are used in stead of arrays. Porosity is therefore specified only in the Materials dialog from which it is written to the pertinent file (BTN in this case).
  19. Porosity in MODFLOW and MT3D

    Hey Speedy, this is a good question. From Seawat User Guide (Guo, Langenvin 2002) it seems that value specified in the MT3DMS BTN Package file is the one used by Seawat.
  20. Hello, it is often the case to treat WEL package data (e. g. well pumping/injection rate or specified flow BCs) as adjustable parameters when doing inverse modelling for parameter estimation or optimisation. I would like to see a better GMS handlig of this. One cannot use conceptual model at all when trying to define specified inflow BCs as parameters, because GMS treats the Key value as flow rate and distribute it between the cells intersected by the BC conceptual model geometry. In the case of pumping well it is possible to specify Key value in the conceptual model and map it to MODFLOW (hopefully) correctly. However there is no check whether this exact Key value does not appear in the regular pumping data. This could easily lead to an error. Especialy when the model is continuosly used and the pumping data with some key values are reasigned over and over during the model application. I would consider wise to be able to specify in GMS whether a particular value is Key value or not and to treat it accordingly in GMS. Also a model checker should check for conflicts in the WEL package for the reasons described above. This obviously extends to MNW package as well. I am wondering if anybody else experienced this problem and would like to see this implemented.
  21. MT3DMS calibration

    Hello Georgios, could you be more specific in the problem you are solving? I suppose you are modeling the process of landfill leaching. The flow model is in a steady state with assigned recharge from the landfill that has associated nitrate concentration. The problem is, when you manualy change the value of recharge you see no response in the concentration dataset. To analyze the problem you could try to use the TOB package and check the Compute mass flux at sources/sinks in the TOB package dialog. Then when you run the model and select the polygon associated with the landfill recharge you should be able to see the mass flux for a given stress period in the status bar in GMS. Alternatively you should be able to look into the .mfx file that is writen by the TOB package in the MT3DMS folder. The mass flux data for each source/sink in the conceptual model should be listed there. Once you are able to observe the mass flux associated with the landfill recharge polygon, you could change the recharge value and see if the mass flux changes. If it does, the problem is probably somewhere in the flow velocity magnitude and/or stress period time setting. If it does not change, than there is some principal problem in the model.
  22. Importing AHGW stratigraphic model

    Hm, it looks like a 3d point feature class, since it has Point Z value in the Shape* field. You should be able to export it as shapefile and drop it into GMS. The 3d points should appear.
  23. Specified flow boundary condition with Modflow-USG

    Hi Alan and Bill, thank you for looking into it. Let me post just a few remarks. That looks like exactly the correct behaviour, I think this is how the check is implemented in MODFLOW. I may be wrong on this one. What if GMS just checked, that the layer above the top most spec. flow BC has the complete spatial XY coverage of the model region you mentioned? This would allow users to cover near-surface aquifers, that does not span across entire model with apropriate top layer in the multiaquifer system and still be able to apply spec. flow BC for the deeper aquifers/layers.
  24. About 3D Grid

    I believe, it is just due to interpolation from cell center points to gridlines intersection. It should not affect the solution for MODFLOW. Its just a matter of how GMS displays the data.
  25. Fixed pilot points in PEST NSMC

    I believe the problem is, that some parameters are cited in the covariance matrix C(k), but are not included in the PEST control file as adjustable parameters. Check it with the sc1v145 parameter.