Jump to content
GMS, SMS, and WMS User Forum

Michal

Members
  • Posts

    81
  • Joined

  • Last visited

Everything posted by Michal

  1. 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.
  2. 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.
  3. 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.
  4. Just run from command line: pest case with case being the name of the modified PEST control file.
  5. 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.
  6. Jonas, I have noticed, you were not running PEST in Regularization mode. That is probably the source for your error.
  7. 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.
  8. 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:
  9. 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.
  10. 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.
  11. 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).
  12. 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.
  13. 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.
  14. 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.
  15. 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.
  16. 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.
  17. 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.
  18. 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.
  19. Hi Jonas, this is interesting. What interpolation method have you used for the pilot points in the first place? Did GMS just read the pre-generated values from the RANDPAR utility and than continued itself with the PNULPAR, etc. ?
  20. You are welcome. I am happy I could help you.
  21. I think the behaviour you are describing relates to the Upstream Weighting scheme of MF-NWT, that is implemented in MF-USG as Upstream Convertible. See this report, chapter treatment of dry cells.
  22. Hi there, I am also interested in solving this issue. I have found out so far, that the ugrid has to be a "stacked" ugrid in order for the GMS spec. flow BC to map from the conceptual model. This means, that layer discretisation must not change from layer to layer. This sucks, because GMS Specified flow boundary condition utilizes WEL package and you can easily do the assignment manualy on the grid level even on a grid, that is not strictly "stacked". All you have to do is to ensure, that the cells in the column, where WEL is assigned have the same horizontal dimmensions through the vertical column of cells. Here is a short demonstration. It is a simple test three layer model computed with MF-USG using quadtree geometry. It utilizes CHD for south BC and GHB for a river runnnig through the domain. This GHB river is in the top layer and it is densely discretized (see the first picture). There is also Recharge in the top layer. There are three pumping wells (WEL package), that withdraw water from the third bottom most layer. These are densely discretized in all three layers. The specified flow BC is in the third (bottom) layer as inflow 100 l/s. It was assigned to the north model boundary using grid aproach by dividing the flow equaly between cells. The cells with this spec. flow BC have all equal vertical column sizes. The point is, that the river running through the domain is discretized only in the top and second layer, not in the third one (see the picture below). This approach can save a lot of computation time as it reduces the number of cells significantly. The solution is the same as when everything is assigned on the stacked grid and the river is densely discretized through all layers. The question is if there realy is necessary such a strict limitation on the grid geometry when mapping Spec. flow BC from the conceptual model? By my opinion only the vertical column sizes must have the same dimmensions and the grid doesnt need to be "stacked". The same thing as with specifying wells in GMS should apply to the Spec. flow BC.
  23. Hi Jonas, If you try to generate random parameter values with this utility you have to decide how to describe the variability in the generated values. If you choose, that random values should obey (log)normal distribution you must specify its properties for each ajustable parameter (e.g. uncertainty of that parameter). This is done by specifing uncertainty file (see section 2.5 in PEST manual part II). Within this file uncertainties can be supplied on a parameter-by-parameter basis; alternatively one or a number of parameter covariance matrices can be supplied. If you want to avoid all this, try selecting (log)uniform distribution for the random values. Then you should be able to generate the uniformly distributed values without any problems. Hope it makes sense
  24. Hi Bruce, you may try to make one parameter adjustable (parent) and the rest in the basin tied to the parent. Relevant part from PEST manual: Or, alternatively, you could include the ratio between the pertinent parameters as prior information and adjust its weight accordingly. This way it would still be treated individualy, but the solution would tend to respect the parameter ratios. It is also also possible, that the contribution to total phi for drain observation group is too low, so it is invisible for the inversion proces. You may try to look at it in the case.rec file. It could be resolved by adjusting the weights for the observation groups. There is a nice utility form the PEST suit, that can help to balance this, its called PWTADJ1.
  25. If it is the case, that there is a bug in gms, so that it does not perform the final model run with the best parameter values stored in the case.bpa you would probably have to move the entire analysis out of GMS. I would suggest you to look at http://www.pesthomepage.org/. There you will find some guidelines on how to formulate the problem for the NSMC analysis to get the desired results. The usage of parrep utility is prety simple, it is command line utility, so since it is in your environment PATH variable you can run it from CMD: parrep parfile.bpa case_orig.pst case_new.pst The common framework for any NSMC analysis would be to manualy generate random parameter sets with the randpar utility then to project these sets into the solution space using pnulpar. Then runing PEST for each projected parameter set with 1 or 2 optimisation iteration to account for model nonlinearities and colect the best parameter values (.bpa files). Finaly you may run the model with these parameter sets to collect the predictions of interest.
×
×
  • Create New...