Code Monkey home page Code Monkey logo

usgs / pestpp Goto Github PK

View Code? Open in Web Editor NEW
125.0 22.0 68.0 1.11 GB

tools for scalable and non-intrusive parameter estimation, uncertainty analysis and sensitivity analysis

Makefile 0.04% CMake 0.95% C++ 56.74% C 0.88% Shell 0.06% Fortran 4.67% JavaScript 0.02% CSS 0.02% Python 0.46% TeX 0.49% Smarty 1.09% Batchfile 0.01% Jupyter Notebook 12.60% HTML 21.25% Cuda 0.36% Visual Basic 6.0 0.35% FreeBasic 0.01%
uncertainty-quantification parameter-estimation ensembles optimization-tools optimization sensitivity-analysis global-sensitivity-analysis parallel-computing non-intrusive ensemble-methods

pestpp's Introduction

pestpplogo image

PEST++

a Software Suite for Parameter Estimation, Uncertainty Analysis, Management Optimization and Sensitivity Analysis

PEST++ is a software suite aimed at supporting complex numerical models in the decision-support context. Much focus has been devoted to supporting environmental models (groundwater, surface water, etc) but these tools are readily applicable to any computer model.


Master branch: master branch

Develop branch: develop


Documentation

The latest official report documenting PEST++ is available from the USGS:

https://pubs.er.usgs.gov/publication/tm7C26

Suggested Citation:

White, J.T., Hunt, R.J., Fienen, M.N., and Doherty, J.E., 2020, Approaches to Highly Parameterized Inversion: PEST++ Version 5, a Software Suite for Parameter Estimation, Uncertainty Analysis, Management Optimization and Sensitivity Analysis: U.S. Geological Survey Techniques and Methods 7C26, 52 p., https://doi.org/10.3133/tm7C26.


User's Manual

The lastest PEST++ users manual is available here or as a word document.


Links to latest binaries

As of version 4.3.11, PEST++ pre-compiled binaries for windows and linux are available as a github release:

https://github.com/usgs/pestpp/releases


Compiling

The develop branch includes a Visual Studio solution, as well as CMake files for building on all operating systems using g++, MSVC, and/or intel C++.

See details here to compile using CMake.


Overview

The PEST++ software suite includes several stand-alone tools for model-independent (non-intrusive) computer model parameter estimation and uncertainty analysis. Codes include:

  • pestpp-glm: deterministic GLM parameter estimation using "on-the-fly" subspace reparameterization, effectively reproducing the SVD-Assist methodology of PEST without any user intervention and FOSM-based parameter and (optional) forecast uncertainty estimation with support for generating Bayes-linear posterior parameter realizations.

  • pestpp-sen: Global sensitivity analysis using either Morris or Sobol

  • pestpp-swp: a generic parallel run utility driven by a CSV file of parameter values

  • pestpp-opt: chance-constrained linear programming

  • pestpp-ies: iterative ensemble smoother implementation of GLM (based on the work Chen and Oliver 2013) with support for generic localization (local analysis and/or covariance localization)

  • pestpp-mou: multi-objective optimization under uncertainty using evolutionary algorithms (single objective also!)

  • pestpp-da: model-independent ensemble-based sequential and batch iterative data assimilation with options to use standard Kalman update, multiple data assimilation (MDA), or the GLM algorithm of Chen and Oliver (2013).

All members of the software suite can be compiled for PC, MAC, or Linux and have several run managers to support parallelization. Windows users with older OS versions should use the iwin binaries (starting "i", compiled with intel C++) to avoid the dreaded MSVC missing runtime DLL issue.


Funding

Funding for PEST++ has been provided by the U.S. Geologial Survey. The New Zealand Strategic Science Investment Fund as part of GNS Science’s (https://www.gns.cri.nz/) Groundwater Research Programme has also funded contributions 2018-present. Intera, Inc. also provides ongoing support for PEST++.


PEST++ References:

White, J.T., Hunt, R.J., Fienen, M.N., and Doherty, J.E., 2020, Approaches to Highly Parameterized Inversion: PEST++ Version 5, a Software Suite for Parameter Estimation, Uncertainty Analysis, Management Optimization and Sensitivity Analysis: U.S. Geological Survey Techniques and Methods 7C26, 52 p., https://doi.org/10.3133/tm7C26.

White, J. T., 2018, A model-independent iterative ensemble smoother for efficient history-matching and uncertainty quantification in very high dimensions. Environmental Modelling & Software. 109. 10.1016/j.envsoft.2018.06.009. http://dx.doi.org/10.1016/j.envsoft.2018.06.009.

White, J. T., Fienen, M. N., Barlow, P. M., and Welter, D.E., 2017, A tool for efficient, model-independent management optimization under uncertainty. Environmental Modeling and Software. http://dx.doi.org/10.1016/j.envsoft.2017.11.019.

Welter, D.E., White, J.T., Hunt, R.J., and Doherty, J.E., 2015, Approaches in highly parameterized inversion— PEST++ Version 3, a Parameter ESTimation and uncertainty analysis software suite optimized for large environmental models: U.S. Geological Survey Techniques and Methods, book 7, chap. C12, 54 p., http://dx.doi.org/10.3133/tm7C12.

Welter, D.E., Doherty, J.E., Hunt, R.J., Muffels, C.T., Tonkin, M.J., and Schreüder, W.A., 2012, Approaches in highly parameterized inversion—PEST++, a Parameter ESTimation code optimized for large environmental models: U.S. Geological Survey Techniques and Methods, book 7, section C5, 47 p., available only at http://pubs.usgs.gov/tm/tm7c5.


Related Links:


Testing

The benchmarks folder contains a simple worked example and basic testing routines that are used for basic CI testing. Many full-worked test problems of varying sizes are now located in separate repos:


Dependencies

Much work has been done to avoid additional external dependencies in PEST++. As currently designed, the project is fully self-contained.


optional ++ arguments

please see the PEST++ users manual in the documentation directory for a current and complete description of all ++ options


USGS disclaimer

This software has been approved for release by the U.S. Geological Survey (USGS). Although the software has been subjected to rigorous review, the USGS reserves the right to update the software as needed pursuant to further analysis and review. No warranty, expressed or implied, is made by the USGS or the U.S. Government as to the functionality of the software and related material nor shall the fact of release constitute any such warranty. Furthermore, the software is released on condition that neither the USGS nor the U.S. Government shall be held liable for any damages resulting from its authorized or unauthorized use

pestpp's People

Contributors

aymanalz avatar cnicol-gwlogic avatar damianmerrick avatar gmartgit avatar jtwhite79 avatar jwhite-usgs avatar mjknowling avatar mnfienen avatar mwtoews avatar rjhunt-usgs avatar siadicus avatar timcera avatar wkitlasten avatar zstanko-usgs avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

pestpp's Issues

Only active pars (nonzero wt obs) in localizer?

I am getting "the following cols were not found in the active par names..." error whenever I fix a few pars. If I recall, I get a similar error when I set some weights to 0. I can rebuild my localizer each time, no problem... but it might be more convenient (for people like me anyway!) if there was a warning about inactive pars and zero weight obs in the localizer, rather than a full stop. Or, is there a reason this might be undesirable?

sort parameter group percent change summary table?

The parameter group percent change summary table (ies) seems to list parameters in an unsorted way (or the sorting is not obvious to me). It would be cool if it were sorted alphabetically or by % at/near bounds.

Obviously this can be done externally, but it would be nice to have it on the screen!

virus?

Hi, scanning with clamav I got the following message - probably a false positive, but better to alert:

/home/vrath/Github/pestpp/src/tests/run_manager_fortran_test/test_dir/pestpp_win.exe: Win.Ransomware.Sage-6995951-1 FOUND
/home/vrath/Github/pestpp/src/tests/runpy/yamr.dll: Win.Ransomware.Sage-6995951-1 FOUND

dense matrix and ensemble binary format

The current jco/jcb binary format is really for sparse matrices and therefore requires the full matrix/ensemble at write time. I would like to have a more flexible "dense" binary format so that we could write rows (realizations) of the ensemble (or sweep runs sequentially and then also process these files in chunks of rows and/or read only specific rows - we would know the number of cols and col names when we first open the file handle. I've got some half-baked ideas about this and could hack it in, but Im wondering if there is something out there already? Im not too interested in bringing in external lib dependencies (e.g. HDF) unless there is a real advantage in speed/storage/access patterns. Really, I think we just need labelled dense matrices/ensembles in binary. Anyone have thoughts on this? Ideas?

OPT behavior with chance constraints

Hi,

I am using PESTPP-OPT and am puzzled by what it does when using chance constraints. My simulations never complete a second iteration of optimization but it gets through the first iteration fine. It builds the response matrix for the second iteration then it just stops at the "calculating FOSM-based chance constraint components" stage, sends out an error to the workers and says simulation complete. I believe it may be related to the information written to the coin-log (attached) but I'll admit to being at a loss as to its meaning. I always test feasibility on the initial response matrix to make sure I select a chance constraint that is supposed to be calculable. I then use the base_jacobian() and hotstart_resfile() options to continue the optimization after selecting a feasible chance constraint. I've attached the coin-log, recfile and control file if they are of any help.
The error that appears on the worker cmd windows is as follows:

NetPackage::recv error - message did not originate from a PEST++ application
received corrupt message from to master: DESKTOP-PQON48A.hub:4004
error receiving message from master, terminating
error closing socket: (tcp/ip error id = 0) An operation was attempted on something that is not a socket.

I don't get the error if I use risk neutral constraint and zero the weights on the calibration observations. Then the model proceeds for 15+ optimization iterations without a problem. I am running on a home cluster and have tried different machines to host the run manager. I am using version 4.2.16

opt_controlfile.txt
opt_coinlog.txt
opt_recfile.txt

PESTPP-SEN issue in the manual

Currently, the documentation indicates that control of the global sensitivity process in pestpp-sen is through the use of "++" arguments. However, the code still requires an external .gsa file at the moment.

CMake build proposal

The current build methods for PEST++ uses mixed methods based on either GNU Makefiles for Linux and macOS, or Visual Studio (I think?) for Windows. The Makefile setup that I redesigned (see dwelter/pestpp#18) is fragile and difficult to maintain (I didn't know how to use CMake two years ago).

A proposed solution is to unify building with CMake, which is a popular cross-platform tool to build software on all of the operating systems with whatever compiler (e.g., GCC or Intel). Modern CMake methods are gaining traction on a wide range of C++ and/or Fortran projects because it is versatile, easier to use and manage. There are extra modules for testing and packing too (CTest and CPack).

So this is a proposal to add a CMake build setup for PEST++, which would essentially be a collection of CMakeLists.txt files in most directories, and some documentation. (Note that Eigen already has a CMake setup in this project, but it would be ignored, since Eigen is used as a header-only module.)

If this proposal sounds good, I can provide a PR for the develop branch. But I'm sure there are questions, so discuss any here.

Incorrectly reading secondary text marker in instruction files

The instruction files don't seem to be correctly reading output files using the secondary text marker.

We're using MODFLOW 6.0.4 and utilizing the built-in observation utility. For example, MODFLOW generates streamflow results from one or more observations in the SFR package. MODFLOW 6.0.4 uses non-advancing output instead of fixed length strings, and the outputs are comma separated but do not contain spaces between observation values. Vanilla PEST 16.1 and BeoPEST 16.1 will correctly read the instruction set and parse output values using a secondary text marker, but PEST++ doesn't seem to be locating the secondary text marker in the output observation file. In the past, we've been able to use the whitespace delimiter in our instruction file because the outputs were comma separated with spaces between values. I've included examples of working and non-working output file and instruction file.

Examples:
pre-MODFLOW 6.0.4 SFR observation output file:

time,SEEPAGE_FLUX1,SEEPAGE_FLUX2,SEEPAGE_FLUX3
1.000000000000, 1962323.838381852, 1962323.838381852, 1962323.838381852
32.00000000000, 1012443.579448908, 1012443.579448908, 1012443.579448908

working instruction file:

pif $
$time,$
l1 w w !obs1_1! w !obs2_1! w !obs3_1!
l1 w w !obs1_2! w !obs2_2! w !obs3_2!

MODFLOW 6.0.4 SFR observation output file:

time,SEEPAGE_FLUX1,SEEPAGE_FLUX2,SEEPAGE_FLUX3
1.000000000000,1962323.838381852,1962323.838381852,1962323.838381852
32.00000000000,1012443.579448908,1012443.579448908,1012443.579448908

non-working instruction file:

pif $
$time,$
l1 $,$ !obs1_1! $,$ !obs2_1! $,$ !obs3_1!
l1 $,$ !obs1_2! $,$ !obs2_2! $,$ !obs3_2!

new control file format

I want to have this discussion here so everyone is aware of how things went down. So far, @doherty1234 and I have had some discussions that have led to the attached control file format. Important bits:

  • retain the "* -section-" format.
  • "control data" can now be "control data keyword" which then makes this section a keywork-value style (whitespace sep). All of the control data args will have predefined internal default values so only changes from the defaults need to be specified. This keyword section is also be the home for svd, regularization, pareto and ++ args.
  • all repeatable sections can now be in external csv files. these files must have a header and that header must have at least the variables that each calling program needs to run (e.g. parnme, parval1, parubnd, etc). it can have extra columns (x,y,z,time,etc) but those are ignored unless the calling program needs them. might need to add parsing args such as what values represent missing values, etc
  • dimensioning counters are no longer needed
  • parameter groups and observation groups are now optional (parameter group defaults will also be internal)
  • section order doesn't matter
  • tied parameters will be handled in the standard parameter data csv file (instead of listed at the end of the parameter data section)
  • if an unrecognized "* -section-" is encountered, the calling program should ignore it
  • comment lines start with '#', blank lines are fine
  • split model input/output section into two sections: model input and model output

One item that could use some discussion: should we define and use more common variable names? so "name", "upper_bound", "value" instead of "parnme"/"obsnme", "parubnd","parval1"?

This is all up for discussion!

new_pst.zip

pestpp-da "dry run"

@aymanalz - I was thinking it might be helpful to have a "dry run" option for pestpp-da where run thru the cycles, get the child pest object and make sure the pars and obs are in sync with the templates and instructions (no model calls). For me, this has been to mess and hard to detect until you are already into the run. thoughts?

Multiplier for default initial lambda

Suggestion for something like an "ies_initial_lambda_mult()" arg such that the default initial lambda can be easily scaled, without relying on "ies_lambda_mults()" (which apply for the duration) or "ies_initial_lambda()" (which requires external estimate/calculation).

losing agents on linux

building on issue #66 from @laat0003.

I am getting similar timeouts and losing agents when they are idle with the message of no ping received from master in the last 300 seconds, terminating in output on agent side.

Setting ++panther_agent_no_ping_timeout_secs(1000000) seems to stop it.

Spaces in col names for MSN output file

Small thing, but looks like there are extra spaces in the column names string for the MSN file for Morris output. This causes issues when reading the results into Pandas, for example, because 'n_samples' is ' n_samples', etc.

Confirmed this is consistent on line 426 of MorrisMethod.cpp:
fout_morris << "parameter_name, n_samples, sen_mean, sen_mean_abs, sen_std_dev" << endl;

simple fix is:
fout_morris << "parameter_name,n_samples,sen_mean,sen_mean_abs,sen_std_dev" << endl;

I'd make a PR but don't have my CPP env running ATM.

Option to write simulation results as they finish?

It would be useful for me to check results from simulations as they finish, rather than wait for the entire batch (ensemble) to finish. Unfortunately I either run a small ensemble, or wait for all the simulations to finish (usually 1 or 2 stragglers!) before I can explore the results. I assume this is a run manager issue. Not sure if it is possible or how much pain is involved in writing a temp file or appending the .csv as the results come in, or if there is already an option and I am missing it.

'Pass-through' of Ensemble Member Number to Agent PC.

Hi.

I'm a novice user of PESTPP-IES and I'm thinking through a problem I'd like to try and solve.

What I would like to do is to generate 300 realisations of a property field, stochastically, and then use Pilot Points to 'warp' each of their respective fields during calibration.

If I start with an ensemble of 300 members, I would like each member to use its own, initial property field and then, during calibration, that particular members' Pilot Points values 'calibrates' its initial own property field. i.e. Pilot Points Kh and Kz etc are used as scaling factors to the stochastically generated property field pertaining to that member.

The above is not particular different to the PEST tutorial where PESTPP-IES is deployed, except that the Pilot Points will be 'warping' the original field, rather than rendering the field directly.

Anyhow, the bit that I am stuck on is that I don't know a way to transmit the ensemble member number through the "* model command / pestgv.bat file" structure.

To explain, I intend to have the 300 realisations of property fields on all of the PEST Agent PCs. As PESTPP-IES progresses, I just need to pass through the "Ensemble Member Number" being tested on a particular Agent PC, so that I could add something like the following, prior to the PLPROC steps:

COPY /Y CurrentPropertyField.dat.%%i CurrentPropertyField.dat
where %%i is the Ensemble Member Number.

I would appreciate it if someone is aware of how this might be able to be done.

regards
Justin

opt_std_weights option

Hi,

Does the opt_std_weights option also consider the notional calibration observation weights as standard deviations of their uncertainty? It isn't clear in the manual if this is an alternative to supplying a covariance matrix of the calibrated parameter uncertainties.

Cheers,

Missing base in new 'obs+noise' ensemble?

In the interest of efficiency, I am reusing a par ensemble (i.e. same prior) and associated obs ensemble from a previous run, but generating a new 'obs+noise' ensemble based on a new set of targets. The 'obs+noise' ensemble contains 'ies_num_reals' realizations, but no base even though the 'restart_obs_ensemble' and 'parameter_ensemble' have 'base' and 'ies_add_base' is left as the default 'true'. Several reals were dropped so there are fewer reals in the 'restart_obs_ensemble' than the 'parameter_ensemble' or the new 'obs+noise' ensemble

First a question: the 'obs+noise' are the targets in the control file plus noise, and NOT necessarily tied to the simulation results in the 'restart_obs_ensemble', right?

Is there a way to 'line up' the new 'obs+noise' ensemble with the restart 'restart_obs_ensemble' and 'parameter_ensemble' to ensure they have the same number of reals and there is a 'base' real (i.e. no noise added to the new targets). My impression from what I have is that my 'base' real in the 'restart_obs_ensemble' and 'parameter_ensemble' will be associated with the nth entry in 'obs+noise', where n is the number of reals in the obs ensemble.

For now I will just not reuse the initial 'restart_obs_ensemble' and avoid this issue.

PESTPP-OPT risk neutral with base jco

Hi,

When doing a risk neutral optimization, model parameter sensitivity is excluded from the jco, which makes sense. However, if you then try to use the resultant jco via base jacobian() for another risk neutral optimization you cannot proceed unless you supply a jco that includes the adjustable model parameter sensitivities. Not exactly a deal breaker but just thought I'd flag it.

I'm using version 4.3.17

pestpp-ies error writing model input files from template files

Hi all.
I am having an issue in which I am getting the following error:

model input/output error: error writing model input files from template files internal error condition has arisen while attempting to write current value of parameter to model input file

If I run pestpp-ies with NOPTMAX = 0, I do not get this error and the model runs as expected. When I set NOPTMAX to 3 (or any other positive integer) I get this error. The error causes the model to abort and it retries.

Any guidance related to how to debug/resolve the issue is much appreciated.
Thanks so much.
Dan
pestpp-ies error writing model input files from template files.zip

issue restarting PEST-IES from parameter and observation ensembles generated by PEST-IES

Hello,
I am trying to restart a PEST-IES run using the results of a previous run. Here are my IES options:
++ ies_num_reals(48)
++ ies_lambda_mults(0.1,1.0,5.0,10.0)
++ lambda_scale_fac(0.75, 1.0, 1.1)
++ ies_subset_size(4)
++ overdue_giveup_minutes(150)
++ overdue_giveup_fac(40)
++ ies_csv_by_reals(false)
++ ies_observation_ensemble(cal1_ps.obs+noise.csv)
++ ies_parameter_ensemble(cal1_ps.0.par.csv)
++ ies_restart_observation_ensemble(cal1_ps.19.obs.csv)
++ ies_restart_parameter_ensemble(cal1_ps.19.par.csv)

All the csv files being passes are generated by PEST-IES on a previous run
When I start PEST-IES, get the following error:
Ensemble Error: Ensemble:: get_real_vector() : ireal (47)>= real.shape[0] (47)
image

pestpp-sen keywords

Hi,

I'm using pestpp-sen to do gsa with an analytical element model but can't get the control variable keywords, as they are written in the manual (ver. 4.2.4) to be recognized. I wanted to use ++ method(sobol) but this ends up as an unrecognized keyword. I managed to guess at an alternative and got it to work with ++ gsa_method(sobol) but the same gsa_ prefix didn't work for the rest of the control keywords. I got the hint for the gsa prefix via the pestpp-sen usage examples that are displayed when you run pestpp-sen with no arguments. Can you please advise what the other control variable keywords are? Thanks in advance.

I'm using ver. 4.2.16 compiled on 11 Oct 2019.

Center on base before adding base to obs+noise?

I am providing a par ensemble and associated restart obs ensemble, and letting pest generate the obs+noise ensemble. The par and obs have a "base" realization. The default behavior adds a base realization to obs+noise. However, when using ies_center_on(base) it seems pest looks for the base realization before adding it is added to obs+noise.

Default:
base

center_on(base):
no_base

Obviously I could be missing something, but it seems like the center_on call needs to come after adding the base real to obs+noise. (Another non-pressing issue...)

restart_obs_ensemble keyword not being read?

I am using the ++ies_restart_obs_ensemble() keyword to avoid re-running the initial ensemble and use the existing results. But ipestpp-ies.exe (downloaded 6/28/2019) insists on running the initial ensemble. It loads the parameter_ensemble and observation_ensemble, just not the restart_obs_ensemble

.sen only produced for GLM, not IES

No sensitivities are written to the .sen file when using IES (.sen file created, but no info). Also, no mention of .sen for IES in the manual, only for GLM. Maybe this is intentional since the jco is only approximate in IES?

Is there an easy way to look at sensitivities from IES, or is that silly? I assume ies_verbose_level(2) will save the jco, but then storage becomes an issue. Perhaps I pass an obs.csv and par.csv in pyemu to get a jco?

Thoughts on a "ies_prior_scale_fac" type variable?

I have convinced myself I'd like my reals drawn from one parcov (e.g. "tight") and my parameter upgrades scaled, but "not that much." It seems to me the variable "ies_use_prior_scaling(False)" could be seen as implicitly scaling (pi - pm) by 1. So maybe just a linear interpolation of the scaling factor between no scaling and scaling by full std?

scaling = (1-std)*sf+std

where sf is the new variable ranging from 0 to 1, resulting in full std scaling to no scaling, respectively.

Couple of seq DA queries

In addition to my PR on your fork @aymanalz

@JTWhite @aymanalz It is going to be a common case that we have many cycles (e.g., daily models), many of which will not contain any data to assimilate! I think we can just bypass the kf_update() in the case of seq DA or iterate_2_solution() in the case of IES near line 533 of pestpp-da.cpp after doing the "forecast" EnKF step (using an appropriate condition related to the number of "active" (i.e., current cycle) non-zero weighted obs). Thoughts? Want me to go ahead with this?

Also @ayman, are you able to run your da_pumping_test_enkf test through? I get termination in the initialization of the second cycle.

More to come!

Pestpp-opt bounds enforcement

Hi,

Is there an option to have stricter bounds enforcement on decision variables when using -opt. I have a lower bound of 0.0 for injection rate on wells but I'm getting a really small negative number (-2.802e-045) fed into the template file. If the number is slightly larger (-1.262e-029) coming out of the SLP iteration then it does not go to the template file. I know that a rate that small will have no impact on model fluxes but unfortunately exponents that size in an input file trigger model run failure killing the optimization.

I am using version 4.2.16 compiled October 11 2019.

lambdas() and lambda_scale_fac() not considered for super parameter iterations ?

With a highly-parameterized model presenting pretty noisy derivatives, I obtained great improvement when using numerous lambdas and scale factors with pestpp-glm 4.3.3. But when performing an SVD-assisted parameter estimation, it appears that options lambdas() and lambda_scale_fac() are not considered for super parameter iterations. However, they are appropriately considered for base parameter iterations. Is that on purpose ?
Thank you for your reply !

Tagged release proposal

As mentioned in #45 it would be a good idea to move compiled executables out of the source tree, and into tagged releases. Binary archives are now easy to create with CPack ("free" from CMake setup), then each OS archive file is simply added to a github tagged release. For example, here is one. Related repos like pyemu can benefit from these, as it can also remove some of the binaries out (i.e. pyemu/bin), as this can be fetched from the github tagged release.

A simple script to quickly download and install the latest pestpp executables from github tagged releases (using the example linked above) is straight-forward, for example see get_pestpp_bin.py, which is something that could be put in pyemu/scripts (but not yet).

control file parsing error in PESTPP-SWP on pst file that runs fine with regular PEST

Hello, I am getting the following error:

checking model IO files...control file parsing error: error in model interface file checking:model input/output error:Error: the following observations were found in the control file but not in the instruction files:
DUMMY_OBS

This is a SWP run that is just sending .ucn files back for post processing, there are no real observations, so I have a single dummy observation. The model runs fine via PEST.

This is the pif:
pif @
@dummy_obs@ !dummy_obs!

"reg_factor" seems off, or I don't understand the message

I had reg_factor(0.1). The doc says:

The value assigned to this weight factor is such that the “regularization objective function” is equal to a fraction F of the current value of the objective function which characterizes model-to-measurement misfit. F is the value assigned to the ies_reg_factor() control variable.

The .rec file output says:

...phi summary for entire ensemble using lambda,scale_fac 1.2e+08 , 1 , 
       phi type           mean            std            min            max
      composite    3.72894e+11    9.01699e+09    3.57824e+11    3.94587e+11
       measured    3.72894e+11    9.01699e+09    3.57824e+11    3.94587e+11
 regularization        8428.79        1413.34        2256.48        10491.6
         actual    3.72894e+11    9.01684e+09    3.57824e+11    3.94586e+11
     current reg_factor: 0.1
     note: regularization phi reported above does not 
           include the effects of reg_factor, 
           but composite phi does.

I interpret the doc to mean the regularization factor should be 3.72894e+10 in this case, but I don't see that in the .rec output. I see composite, measured, and actual phis are all equal.

I assume the "regularization" phi in the .rec output is the part that is "proportional to the inverse of the prior standard deviation of the respective parameter(s)" as mentioned in the doc. Which should then have another weight factor "uniformly applied to all parameter departures" to bring the "regularization objective function" up to (reg_factor) * (current objective function).

So, how do I get the 10% penalty I deserve for my departing? Or am I misunderstanding?

Precompiled binaries for PESTPP-PSO

Hi,

I'm just wondering if there is supposed to be a precompiled binary for pestpp-pso in the latest release? I can see in the makefile that it is only created if a FORTRAN compiler is available. I downloaded both the win and iwin release yesterday and it is absent from both of them.

Is the .res file still a thing?

I can't find my case.res file from my initial run in GLM. Is there another file for hotstart_resfile(), or is that a thing of the past?

Jacobian matrix not being fully generated.

Hi there!

I'm currently testing the PEST++ code on a model I'm working on but when I run it, the Jacobian matrix is not being filled, (the .jcb file is pretty much in blank!) so the calibration/inversion process of the model can not go through due to that error. The error showing up is the next message (on my Jupyter Notebook):

PANTHER master listening on socket: 0.0.0.0:4004 (IPv4)

  reading previously computed jacobian: pest_test.jcb
error restarting with existing jco an n_iter_base < 0: pest_utils::read_binary() npar, nobs and/or nnz is zero

pest_utils::read_binary() npar, nobs and/or nnz is zero
Error encountered, cannot continue

We've checked as muuuch as we can but we still don't know what is wrong yet, there are no more details about that error. I downloaded and I'm using the most recent PEST++ executable available (V 5.0.0).
(Just in case, here is the .jcb file created: https://github.com/Lau397/mf6model)

Any help, advice and/or suggestion is incredibly appreciated!

lambda_dec_fac applied when new phi>old phi

(uhg, should read "new phi == old phi")

I am using the full ensemble for lambda tests (num_reals=subset_size). Phi is not improved by any lambda tests (no partial par upgrades either), but lambda is still decreased. Shouldn't it be increased?

Pertinent .rec bits:

...best phi yet: 14738.4

--- starting solve for iteration: 4 ---
...starting lambda calcs for lambda 0.00105469

...last best mean phi * acceptable phi factor: 15475.3
...current best mean phi: 39215.5

--- only updating realizations with reduced phi ---
...current best mean phi (after updating reduced-phi reals): 14738.4

--- updating lambda to 0.000791016 ---

Runs timing out in PESTPP-SWP when no overdue settings are specfified

Hello,

I am using PESTPP-SWP for a transport model that takes a few days to run. I have not specified any overdue giveup settings. This is all I have for SWP settings:

++sweep_parameter_csv_file(eagle_2019_update_swp.6.par.csv)
++ies_csv_by_reals(True)
++sweep_output_csv_file(SWP_out_base.csv)
++sweep_chunk(500)

But I have runs that are timing out:
image

Why are runs timing out and how do I prevent it?

PESTPP-OPT initial stack

Hi,
I’m using PESTPP-OPT with stack based uncertainty and I provided an ensemble of models from IES for the opt_par_stack() option (after adding my decision variables with zero values). A replica of this ensemble file appears to be echoed as a model.0.par_stack. It isn’t clear in the manual if this stack is run initially or if it is only the .1.par_stack (where my decision variables have non-zero values as entered in the ctl file)? In my specific case, the .0.par_stack is my “do nothing” ensemble while subsequent iterations are effectively optimising “do something”. Without a .0.obs_stack output file will I have to run SWP to get the obs for my “do nothing” ensemble?
Thanks in advance for your time,
Tariq

External Parameter Input File

Not sure if this is the right way to submit a question, but hopefully it is!

Based on previous correspondence, you guys discussed having all parameters in an external file, I've tried it with the latest version 4.1.9, without success. The documentation suggest it's possible but I'm seeking for confirmation.

Best regards,

Louis-Charles Boutin

Capture2

Capture

Feature request: ins read error trap during worker batch runs

Hi Jeremy,

This is one to consider for trapping dumb moves like mine:

I have (or had) a pestpp case where a model output file being read via an instruction file fails on some worker runs. I think it is ultimately caused by an overflow in the model code (mfusg sfr2) in certain rare situations) - but, ignoring that for now: could we add a trap for ins file reads sometimes failing during batch pestpp runs? The reason I suggest this is that I found this hard to work out what was happening, even when re-running the failed worker over the same model output files.

A few other details:

  • My case was with the IES (5.0.0 git release sept 1 2020), but it is repeatable with GLM, and probably the other executables).
  • In my case pestpp was dying with an unhandled exception window popping up on some machines, and just silently dying on others (windows 10 latest - the diff probably because I have c++/VS installed on some worker PCs and not others).
  • This always happened at the part printed to the worker console as "processing instruction files with {n} threads...thread {m} processed 1 instruction files".
  • When this happened the manager would report "...receive failed from agent..." and "...closed connection to agent..." to the rmr file. So I knew where the problem was, but not what it was, which was hard to work out (for me at least).

I'd be happy to have a stab at this feature if you are interested.

Thanks,
Chris.

Feature request to work with pest_hp parameter equations.

The pest_hp suite of programs has implemented parameter equations in the pest control file. This functionality removes the need for the par2par layer which is a confusing complexity in the pest workflow, especially for new users. It would make the transition much easier from pest_hp to pest++.

Kind regards,
Tim

PARCHGLIM error with absolute(N) for a fixed value

With PEST++ version 4.2.6, a new error is raised with a PEST control file that uses PARCHGLIM with absolute(N) inputs (e.g. see Table A1.8 from PEST user manual part 1). The error from pestpp-ies is:

parameter error: ROUGHCH01 'parchglim not in ['factor','relative']: ABSOLUTE(1)

In this particular case, PARTRANS is fixed, and the PEST user manual 1 states: "Note that If a parameter is tied or fixed, its change limit is ignored."

This particular control file worked with PEST++ 4.2.4, so it's a recent change. A suggested solution is to only permit (and ignore) absolute(N) if PARTRANS is fixed, as I guess was the behavior from previous versions. Implementing absolute(N) for non-fixed parameters seems like a bit of work, and should raise a parameter error for these combinations.

Uniform upgrade vectors across lambdas when using JTQJ matrix inversion in PESTPP-GLM

Hello,

I have a question about calculation of the parameter upgrade vectors. I have used PEST++ for calibrating two models recently (using the default jtqj option) for which I found that the computed upgrade vectors were uniform across the default lambda values.

In both cases, I also tested using an older release of PEST++ that still included the ++mat_inv(Q1/2Z) option, and using this alternate formulation the upgrade vectors did vary across the different lambdas. I have two questions:

  1. Is there a reason why this behavior should differ across the two matrix inversion options?
  2. Has this issue been reported (for example outside GitHub) or has this been observed in the past?

Thank you!
-Colin

base real not added to base obs ensemble when restarting

I would like to use an existing parameter ensemble to compare the progress of pest runs with different weighting schemes. To save time/runs I would like to restart each pest run with the same obs ensemble generated from that parameter ensemble. I am using:

++ies_parameter_ensemble(run.0.par.csv)
++ies_restart_observation_ensemble(run.0.obs.csv)

As I understand it, changing weights will change run.base.obs.csv for all reals except the noise free 'base' real, so run.base.obs.csv needs to be regenerated every time I change weights. But, when a restart_observation_ensemble is provided, the noise free 'base' real is not added, resulting in an error:

image

Is this approach silly (i.e. the obs weights won't really change the ies results much, or some other reason)?

It seems "not adding 'base' realization" is intentional for the parameter_ensemble, which makes sense. But doesn't it make sense to add a 'base' realization to base.obs.csv if a 'base' realization exists in the parameter_ensemble and observation_ensemble?

I assume I can just add the noise free obs values as the 'base' realization to base.obs.csv.

termination criteria in PESTPP-IES

@jwhite-usgs There are a few types of objective functions in PESTPP. What's the difference between the measured and actual objective function? My guess is that the measured one doesn't take weight into account. If this is true, does it even consider the observations with zero weights?
I also notice that the termination criteria is based on the measured or composite objective function. What is the reason for this? Isn't the actual one more reasonable to reflect the modeller's intention?

PESTPP-SWP parsing problem -- returning error on !dum! observation

I used !dum! to denote unneeded numbers in an instruction file to help parse the line and
find the observed value. I can use the instruction file with a pest executable, but pestpp-swp is
returning an error:

checking model IO files... L1 !DUM! !SUM_MASS5! !ES_TOTAL5! !ES_GLAC5! !ES_BDRX5! !PAL_TOTAL5! !PAL_GLAC5! !PAL_BDRX5! !ES_1MI5! % !ES_05MI5! % !PAL_1MI5! % !PAL_05MI5!
control file parsing error: error in model interface file checking: InstructionFile error in file AOC_obs.ins : observation 'DUM' listed multiple times in ins file 'AOC_obs.ins'
control file parsing error: error in model interface file checking: InstructionFile error in file AOC_obs.ins : observation 'DUM' listed multiple times in ins file 'AOC_obs.ins'
Error condition prevents further execution:

I'll note that I used lower case, !dum!, in the file as used in the documentation.

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.