Jump to content
GMS, SMS, and WMS User Forum


  • Content count

  • Joined

  • Last visited

Everything posted by Michal

  1. 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.
  2. 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).
  3. 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.
  4. 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.
  5. 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.
  6. 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.
  7. 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.
  8. 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.
  9. 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.
  10. Fixed pilot points in PEST NSMC

    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. ?
  11. PEST, SVD and SVD-assist

    You are welcome. I am happy I could help you.
  12. MODFLOW-USG & CLN cells staying wet

    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.
  13. Specified flow boundary condition with Modflow-USG

    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.
  14. PEST, SVD and SVD-assist

    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
  15. PEST Variables - Drain Conductance

    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.
  16. PEST, SVD and SVD-assist

    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.
  17. PEST, SVD and SVD-assist

    Hello Jonas, from my humble opinion it looks like PEST is doing its job well. It decreases Phi to 63.5% and finish optimisation after one iteration since NOPTMAX is set to 1.Which is probably correct if you try to do NSMC analysis. The reason it does not load solution into GMS may be a GMS glitch. What I think is happening, when PEST is run using svd-assisted inversion it does not carry the final model run using the best parameter values. As is described in the manual to PEST, it is encouraged for the user to do it him/herself using the PARREP utility and setting NOPTMAX to 0 in the PEST control file. So I am guesing that GMS does not do this for you. It would be best if someone from the GMS devs looked into it. Kind Regards Michal
  18. MT3D-NaCl barrier tessting

    Helo, it is hard to say without seeing the model. Could you be more specific in what do you mean by "nothing happens"? Do you mean like, the tracer concentration is zero everywhere through the simulation? First look at the mt3dms list file (case.out) and make sure, that the simulation ended without any errors. Then I would suggest to look at Output control in the basic transport package and make sure it is set properly, so MT3d is writing the concentration binary arrays at correct times. Also try to look at the model cell containing the injection well via sources/sinks dialog and check, that there is associated concentration with it.
  19. Dry cells

    There should be no obstacles in inactivating inner area of a single layer model using IBOUND. See the attached image.
  20. Coordinate Significant Figures

    Is each head observation in the *.hob file maped to the unique cell (IJK) and stress period? Athought it shouldn't matter if the observation's coordinates/times are not identical due to the offset variables (TOFFSET, ROF, COF), I can imagine certain confusion if multiple observation are defined for the same cell and stress period when using PEST.
  21. Hi It would be a nice feature to be able to display piezometric water level of a specifed layer(s) in a cross sectional view (row or column view) in adition to the free water table already implemented. I guess it would be suffictient to add one additinal curve to display and an option to specify from which layer the heads should be extracted. Clipping of the contours could remain as it is - using water table if water table is switched On or the second curve if water table is Off. Thx Michal
  22. constant concentration and source/sink

    Hi speedy, it seems you need to enable the MT3DMS SSM package to enable the mixing of fluid coming from the constant conc. BCs. I would try to enable SSM and set ICBUND to -1. It should work then. Hope it helps. Michal