[SciPy-User] [SciPy-user] code structure advise for a model

[mdekauwe]

OK given the above perhaps my latest implementation is wrong then?

So to recap I have a model, lets say it predicts the photosynthesis by a
plant. There are some parameters which are read in from a file, for example
size of leaf, efficiency at converting sunlight etc. So my current
implementation is to group all the functions of the model in one class and
pass the parameters to this class.

(1). 

Based on previous suggestions I used ConfigParser to read a file containing
various model parameters into a set of different dictionaries which I then
passed around the code (for example control parameters: e.g. out_fname,
log_fname, model_number and initial model parameters: eg. leaf size)

However I was finding using the dictionary syntax made the code a little
hard to read, so now I have packaged these dictionaries into classes

e.g.

class Dict2Class:
	def __init__(self, d):
		self.__dict__ = d

so now instead of control_param['logfile']

I can just do control_param.logfile.

Does that sound OK? I think it makes the code easier to read personally, but
perhaps this is not great?

(2).

In line with the example the model has a set of "pools" (values) that get
updated during every loop iterations (for example over all the days in the
year). These "pools", for example the total amount of leaves on a tree are
required throughout different model functions. I had toyed with inheriting
these, but then I think it is hard to follow exactly where they are being
adjusted. So I wondered if I could take a similar approach to (1) and
declare and empty class and update this when I read the initial conditions
file and then pass the pools object around between the model methods.

e.g.

class ModelPools:
    pass

cpools = ModelPools()
cpools.total_leaves = ini_cond['total_leaves']

so a general code structure now looks like this

def read_confile(confname, section, data_type):
    """ 
    read the config file with various model parameters
    into different dictionary, broken down by section
    """
    return dict


class Dict2Class:
	def __init__(self, d):
		self.__dict__ = d

class ModelPools:
    """ fill when initial conditions file is read    
    pass


class Model:
    
    def __init__(self, config_fname, initialcond_fname):
        
        self.config_fname = config_fname
        self.initialcond_fname = initialcond_fname
        
  
    def main(self):
       
        # read the driving data in
        met_data = met_data = np.loadtxt(self.met_fname, comments='#')
        
        # read the configuration file, keep params grouped in dictionaries
        ini_cond = Dict2Class(rc.read_confile(self.initialcond_fname, 'ini',
'float'))
        photo_params = Dict2Class(rc.read_confile(self.config_fname,
'prodn', 'float'))
        control_params = Dict2Class(rc.read_confile(self.config_fname,
'control', 'float'))
        

        # setup pools structure
        cpools = ModelPools()
        cpools.total_leaves = ini_cond['total_leaves']
        
        self.call_some_func(cpools, control_params, photo_params)

thanks again.


Christopher Barker wrote:
> 
> On 2/3/11 8:42 PM, David wrote:
>> As for how to use inheritance: inheritance is tricky. One rule which
>> works almost all the time to decide where B should derive from A is
>> whether an instance of B can be used whenever an instance of A needs to
>> be used (this is called the Liskov substitution principle if you want to
>> shine in discussions).
> 
> There is also the classic way of thinking about OO:
> 
> use inheritance for a "is a" relationship:
> 
> a cat "is a" mammal.
> 
>> In that aspect, from what information you gave us, I don't see why Model
>> should inherit from Params.
> 
> let's see: A Model "is a" set of parameters -- nope!
> 
> Another common relationship is the "has a" relationship:
> 
> A Model "has a" set of parameters -- yup!
> 
> So that means that your model would have a Params instance as an
> attribute.
> 
>> def create_params(some_param=0.0):
>>       data = {"some_param": some_param, "other_param": ...}
>>       return data
> 
> yup -- a simple dict may be all you need.
> 
> -Chris
> 
> -- 
> Christopher Barker, Ph.D.
> Oceanographer
> 
> Emergency Response Division
> NOAA/NOS/OR&R            (206) 526-6959   voice
> 7600 Sand Point Way NE   (206) 526-6329   fax
> Seattle, WA  98115       (206) 526-6317   main reception
> 
> Chris.Barker at noaa.gov
> _______________________________________________
> SciPy-User mailing list
> SciPy-User at scipy.org
> http://mail.scipy.org/mailman/listinfo/scipy-user
> 
> 

-- 
View this message in context: http://old.nabble.com/code-structure-advise-for-a-model-tp30841514p30860854.html
Sent from the Scipy-User mailing list archive at Nabble.com.