Jump to content
GMS, SMS, and WMS User Forum


  • Content count

  • Joined

  • Last visited

Community Reputation

0 Neutral

About Michal

  • Rank
    Senior Member

Profile Information

  • Location
    Czech Republic

Recent Profile Visitors

733 profile views
  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. 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.
  11. Fixed pilot points in PEST NSMC

    Just run from command line: pest case with case being the name of the modified PEST control file.
  12. 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.
  13. 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.
  14. 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.
  15. 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: