PESTools / pestools

PESTools
12 stars 10 forks source link

base class and PEST control file class #3

Closed aleaf closed 9 years ago

aleaf commented 9 years ago

Guys, Here is a draft of a base class Pest() that could be inherited by other classes. Right now it contains basic information about the run, and methods to read parameter and observation data from the PEST control file. The parameter and observation data methods can be used by some of Evan's classes including Jco and ParSen. I figure we can add additional methods/attributes if needed. Right now these methods are not called on initialization of the base class, so that pest control file is only read if needed.

The Pst() class reads most everything else from the PEST control file. I'm envisioning this class as a container that can read in a control file, allow changes to be made (maybe other methods that would adjust weighting, etc.), and then have a method to write out a new control file. The nice thing about having dataframes as containers for observation and parameter data is that the sections can be easily dumped to excel using the DataFrame.to_csv() method (and then read back in using the read_csv or excel methods).

I included almost all of the information in the Pst() class that I've used in my limited experience. More attributes are needed to handle everything described in the Addendum. I tried to make the attribute references consistent with the Addendum, to help with documentation, and also avoid some of the confusion that GWV has with variable names.

I am also working on an REI class to facilitate working with sets of REI files from successive PEST iterations. I am thinking that it can use Evan's Res class to read the files.

Let me know what you think, and if you see anything that should be modified before it is committed to the main repository. We may have to iterate a few times before we get something that we feel is good enough to start building from.

echristi commented 9 years ago

Cool. I just skimmed it for now.

What if instead of having the optional run_folder argument we work in the following logic: If full path provided as basename (probably just search for '\' in basename): then strip the folder from there. else: assume current os.getcwd() is the run folder

aleaf commented 9 years ago

how about this code:

basename = os.path.split(argument)[-1].split('.')[0]
run_folder = os.path.split(argument)[0]
if len(run_folder) == 0:
    run_folder = os.getcwd()

with these arguments:

'/path/run_folder/basename.pst'
'basename.pst'
'basename'

it returns:

print basename, run_folder

basename /path/run_folder basename /Users/aleaf/Documents/GitHub/pest_tools-1/examples basename /Users/aleaf/Documents/GitHub/pest_tools-1/examples

echristi commented 9 years ago

Perfect. Exactly what I was thinking

echristi commented 9 years ago

Andy,

I made changes to pst.py. I thought I was making changes in my fork of your fork but I don't think I did that right. I suck at this GitHub stuff! You can dif to see what I did and revert back if you need to. https://github.com/aleaf/pest_tools-1/blob/master/pst_tools/pst.py

I did a number of things but in general the following: 1.) reorganize so we aren't defining PEST variables with "dummy" values prior to reading them from the .pst file. Maybe you were thinking these can be used for defaults or something? If so, I think we can have a dictionary with default variables. The problem was the default values were available to the user in some instances but that wasn't obvious. 2.) changed a number of variables to have leading _ to indicate they are internal and not part of the public API. Things like priorind and model_ioind etc. 3.) change the methods to have leading "_" to indicate they are internal and not part of the public API. For example,readinstpl or readprior. These aren't useful to the user and only used internally.

aleaf commented 9 years ago

Cool, looks good. I think with this merge the main repo should be up to date now.