Open alee opened 6 years ago
@mcflugen what do you think about this approach for landlab? We would be taking landlab output and generating dssat input data structures e.g., something like:
input = DssatInput(field_id="AMES1001", rainfall=rainfall_list, soil_id="AMES000910")
output = dssat_model.run(input)
DSSAT component: a distant suggestion (this assumes that changing DSSAT so that it can called directly without constructing files is too much work)
soil_specification = ...
DSSAT_DEFAULT_CONFIG = ...
class DSSAT(HomogeneousSDF):
"""A DSSAT model component using the synchronous data flow formalism.
Homogeneity means that when it has received data from all its ports the
`run` method will be called to produce data on the out ports"""
def __init__(self, config=None):
if config is None:
self.config = DSSAT_DEFAULT_CONFIG
# Open ports are created where config param is external
# This should make it possible for models to provide multiple pieces
# of data if necessary (such as a table with rain and solar radiation
# columns
for param, value in self.config.params:
if getattr(param, value).external:
setattr(self, param, models.InPort(value.data_type))
def build_files(self):
"""Given incoming data (possibly rain, wind, temperature, dew point, solar radiation)
construct the files DSSAT needs to run (a XZM file and a WTH file where the XZM file
references the WTH file)
"""
...
return xzm_file_path, wth_file_path
def run(self):
xzm_file_path, wth_file_path = self.build_files()
data = dssat(xzm_file_path)
self.crop_characteristics.data = data
Have you checked in with the DSSAT folks recently. There was someone working on making it more compatible with docker.
Gerald C. Nelson Professor Emeritus, UIUC +1 217-390-7888 (cell) +1 970-639-2079 (land line) http://bit.ly/1arho7d
From: cpritcha notifications@github.com Reply-To: comses/ming reply@reply.github.com Date: Thursday, June 14, 2018 at 12:47 PM To: comses/ming ming@noreply.github.com Cc: Subscribed subscribed@noreply.github.com Subject: Re: [comses/ming] establish initial set of dssat input / output variables (#11)
DSSAT component: a distant suggestion (this assumes that changing DSSAT so that it can called directly without constructing files is too much work)
soil_specification = ...
DSSAT_DEFAULT_CONFIG = ...
class DSSAT(HomogeneousSDF):
"""A DSSAT model component using the synchronous data flow formalism.
Homogeneity means that when it has received data from all its ports the
`run` method will be called to produce data on the out ports"""
def __init__(self, config=None):
if config is None:
self.config = DSSAT_DEFAULT_CONFIG
# Open ports are created where config param is external
# This should make it possible for models to provide multiple pieces
# of data if necessary (such as a table with rain and solar radiation
# columns
for param, value in self.config.params:
if getattr(param, value).external:
setattr(self, param, models.InPort(value.data_type))
def build_files(self):
"""Given incoming data (possibly rain, wind, temperature, dew point, solar radiation)
construct the files DSSAT needs to run (a XZM file and a WTH file where the XZM file
references the WTH file)
"""
...
return xzm_file_path, wth_file_path
def run(self):
xzm_file_path, wth_file_path = self.build_files()
data = dssat(xzm_file_path)
self.crop_characteristics.data = data
— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHubhttps://github.com/comses/ming/issues/11#issuecomment-397399869, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AH1Eso2mDZ3R36nrQMT8OBvQIKyohbgnks5t8q_CgaJpZM4UnGf3.
One of Willingthon Pavan's students generated a DSSAT Docker container for linking with other models. I'm not sure how they handled the I/O. There are several ways to handle I/O. As you mentioned, a template approach may be the easiest. We can also translate data from AgMIP json format for use by DSSAT. Or you can create new DSSAT input files on the fly.
@chporter for the AgMIP json format you are talking about this project - agmip/translator-dssat?
Ideally we would be able to expose a schema of the DSSAT configuration so that if another component (such as a LandLab output adapter) wants to feed rainfall data to DSSAT the coupled model system can report whether or not output type of the other component are compatible with the input type of DSSAT.
If you are supplying weather data only, then presumably the other DSSAT data files already exist or are being prepared by another application. So you only need to worry about preparing DSSAT weather files. We do have some translation tools that might help, but actually weather files are pretty easy to deal with.
To support more generalizable / reusable software components Calvin and I have been discussing building some common data structures and adapters to/from those data structures.
So in order for a model to become a reusable component it would have to:
When a different application wants to work with dssat it interfaces with the declared I/O data structures built in step 1.
Coupling models together involves programmatically constructing and manipulating these declared I/O data structures, then calling "run" on the model.