-
Notifications
You must be signed in to change notification settings - Fork 92
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
FATES-HOST parameter API #156
Comments
This looks great @bandre-ucar, thanks for kicking this off. Some initial thoughts:
Following up on question 2. When the parameter ultimately gets interpreted in our physics routines, I think it is important that the user does not see the extra dimensions for the variable, its confusing. Using the vcmax parameter as an example again: However it is handled, lets avoid the user from seeing something like vcmax25(ft,1,1). I think there are various ways to achieve this. Regarding centralization and de-centralization of transferring the object list to fates internal memory. If I am interpreting this correctly, it seems like the question is whether to have separate object lists for different groupings of parameters, right? My opinion is that we are fine storing these parameters in one list for now.
I'm not sure I'm clear on this one. Which array is being looped over multiple times, the fates_parameter_type structure, or something else? |
|
Regarding #1). I would very much appreciate having the capability to output
3D variables; would be useful for the plant hydraulics. One example (though
there are more), is h2osoi_liqvol_shell (soil volumetric water content),
which has (c,j,k) dimensionality, where c is column, j is soil layer, and k
is rhizosphere shell.
…On Tue, Dec 6, 2016 at 4:09 PM, Ryan Knox ***@***.***> wrote:
This looks great @bandre-ucar <https://github.com/bandre-ucar>, thanks
for kicking this off. Some initial thoughts:
1.
I am trying to imagine a 3D parameter, I suppose it is possible, but
it seems unlikely no? I can't even really think of many 2D parameters. I
don't have strong feelings about this honestly, I suppose allocating for up
to 3 dimensions does some future proofing.
2.
What are your thoughts about associating the data arrays in each
object to unique variable name, or way to look it up in Fates internal
routines? For instance, in history and restarts, we assign a unique index
identifier to each variable (such as the long list of "ih_" and "ir_"
integers at the top of those modules). Maybe for parameters we can create a
global alias mapping. ie: vcmax25 => fates_params(ip_vcmax25)%real_
data(:,:,:)?
Following up on question 2. When the parameter ultimately gets interpreted
in our physics routines, I think it is important that the user does not see
the extra dimensions for the variable, its confusing. Using the vcmax
parameter as an example again: *However it is handled*, lets avoid the
user from seeing something like vcmax25(ft,1,1). I think there are various
ways to achieve this.
Regarding centralization and de-centralization of transferring the object
list to fates internal memory. If I am interpreting this correctly, it
seems like the question is whether to have separate object lists for
different groupings of parameters, right? My opinion is that we are fine
storing these parameters in one list for now.
Need to think more about whether to have a single central loop over
parameters, or loop over array multiple times in different modules….
I'm not sure I'm clear on this one. Which array is being looped over
multiple times, the fates_parameter_type structure, or something else?
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
<#156 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/AOV4ZhuIjYZ6IkGaPHvLw8iLmV_CnQBRks5rFestgaJpZM4LF49s>
.
|
brad, I think the question here is the dimensionality of the input parameters, not the history outputs. though i completely agree that we ought to try to get support for 3d output -- which requires some lower level ncio changes -- too. |
Just to be sure, you're talking about 3D parameters (as opposed to output),
right? One can imagine potentially wanting a kind of spatially gridded
parameter (a'la Peter Reich's efforts) in some sort of alternative future?
On 7 December 2016 at 05:50, Brad Christoffersen <[email protected]>
wrote:
… Regarding #1). I would very much appreciate having the capability to output
3D variables; would be useful for the plant hydraulics. One example (though
there are more), is h2osoi_liqvol_shell (soil volumetric water content),
which has (c,j,k) dimensionality, where c is column, j is soil layer, and k
is rhizosphere shell.
On Tue, Dec 6, 2016 at 4:09 PM, Ryan Knox ***@***.***>
wrote:
> This looks great @bandre-ucar <https://github.com/bandre-ucar>, thanks
> for kicking this off. Some initial thoughts:
>
> 1.
>
> I am trying to imagine a 3D parameter, I suppose it is possible, but
> it seems unlikely no? I can't even really think of many 2D parameters. I
> don't have strong feelings about this honestly, I suppose allocating for
up
> to 3 dimensions does some future proofing.
> 2.
>
> What are your thoughts about associating the data arrays in each
> object to unique variable name, or way to look it up in Fates internal
> routines? For instance, in history and restarts, we assign a unique index
> identifier to each variable (such as the long list of "ih_" and "ir_"
> integers at the top of those modules). Maybe for parameters we can
create a
> global alias mapping. ie: vcmax25 => fates_params(ip_vcmax25)%real_
> data(:,:,:)?
>
> Following up on question 2. When the parameter ultimately gets
interpreted
> in our physics routines, I think it is important that the user does not
see
> the extra dimensions for the variable, its confusing. Using the vcmax
> parameter as an example again: *However it is handled*, lets avoid the
> user from seeing something like vcmax25(ft,1,1). I think there are
various
> ways to achieve this.
>
> Regarding centralization and de-centralization of transferring the object
> list to fates internal memory. If I am interpreting this correctly, it
> seems like the question is whether to have separate object lists for
> different groupings of parameters, right? My opinion is that we are fine
> storing these parameters in one list for now.
>
> Need to think more about whether to have a single central loop over
> parameters, or loop over array multiple times in different modules….
>
> I'm not sure I'm clear on this one. Which array is being looped over
> multiple times, the fates_parameter_type structure, or something else?
>
> —
> You are receiving this because you are subscribed to this thread.
> Reply to this email directly, view it on GitHub
> <#156 (comment)>, or
mute
> the thread
> <https://github.com/notifications/unsubscribe-auth/
AOV4ZhuIjYZ6IkGaPHvLw8iLmV_CnQBRks5rFestgaJpZM4LF49s>
> .
>
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
<#156 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/AMWsQ454jxSv3RmzUKye7VOR5lqZ1WZbks5rFquZgaJpZM4LF49s>
.
--
------------------------------------------------------------------------
Dr Rosie A. Fisher
Staff Scientist
Terrestrial Sciences Section
Climate and Global Dynamics
National Center for Atmospheric Research
1850 Table Mesa Drive
Boulder, Colorado, 80305
USA.
+1 303-497-1706
http://www.cgd.ucar.edu/staff/rfisher/
|
Sorry folks, I didn't pay enough attention here to the subject of the
thread (parameter input, not history output).
More apropos would be to highlight that there are some hydraulics
parameters which are indexed by PFT and plant tissue type (leaf, stem,
root). With the addition of some spatially explicit dimension, this would
give a 3D parameters. So, yes, I can conceive of the need for 3D input
parameters in the not-to-distant future!
…On Wed, Dec 7, 2016 at 8:40 AM, rosiealice ***@***.***> wrote:
Just to be sure, you're talking about 3D parameters (as opposed to output),
right? One can imagine potentially wanting a kind of spatially gridded
parameter (a'la Peter Reich's efforts) in some sort of alternative future?
On 7 December 2016 at 05:50, Brad Christoffersen ***@***.***
>
wrote:
> Regarding #1). I would very much appreciate having the capability to
output
> 3D variables; would be useful for the plant hydraulics. One example
(though
> there are more), is h2osoi_liqvol_shell (soil volumetric water content),
> which has (c,j,k) dimensionality, where c is column, j is soil layer,
and k
> is rhizosphere shell.
>
> On Tue, Dec 6, 2016 at 4:09 PM, Ryan Knox ***@***.***>
> wrote:
>
> > This looks great @bandre-ucar <https://github.com/bandre-ucar>, thanks
> > for kicking this off. Some initial thoughts:
> >
> > 1.
> >
> > I am trying to imagine a 3D parameter, I suppose it is possible, but
> > it seems unlikely no? I can't even really think of many 2D parameters.
I
> > don't have strong feelings about this honestly, I suppose allocating
for
> up
> > to 3 dimensions does some future proofing.
> > 2.
> >
> > What are your thoughts about associating the data arrays in each
> > object to unique variable name, or way to look it up in Fates internal
> > routines? For instance, in history and restarts, we assign a unique
index
> > identifier to each variable (such as the long list of "ih_" and "ir_"
> > integers at the top of those modules). Maybe for parameters we can
> create a
> > global alias mapping. ie: vcmax25 => fates_params(ip_vcmax25)%real_
> > data(:,:,:)?
> >
> > Following up on question 2. When the parameter ultimately gets
> interpreted
> > in our physics routines, I think it is important that the user does not
> see
> > the extra dimensions for the variable, its confusing. Using the vcmax
> > parameter as an example again: *However it is handled*, lets avoid the
> > user from seeing something like vcmax25(ft,1,1). I think there are
> various
> > ways to achieve this.
> >
> > Regarding centralization and de-centralization of transferring the
object
> > list to fates internal memory. If I am interpreting this correctly, it
> > seems like the question is whether to have separate object lists for
> > different groupings of parameters, right? My opinion is that we are
fine
> > storing these parameters in one list for now.
> >
> > Need to think more about whether to have a single central loop over
> > parameters, or loop over array multiple times in different modules….
> >
> > I'm not sure I'm clear on this one. Which array is being looped over
> > multiple times, the fates_parameter_type structure, or something else?
> >
> > —
> > You are receiving this because you are subscribed to this thread.
> > Reply to this email directly, view it on GitHub
> > <#156 (comment)>,
or
> mute
> > the thread
> > <https://github.com/notifications/unsubscribe-auth/
> AOV4ZhuIjYZ6IkGaPHvLw8iLmV_CnQBRks5rFestgaJpZM4LF49s>
> > .
>
> >
>
> —
> You are receiving this because you are subscribed to this thread.
> Reply to this email directly, view it on GitHub
> <#156 (comment)>, or
mute
> the thread
> <https://github.com/notifications/unsubscribe-auth/
AMWsQ454jxSv3RmzUKye7VOR5lqZ1WZbks5rFquZgaJpZM4LF49s>
> .
>
--
------------------------------------------------------------------------
Dr Rosie A. Fisher
Staff Scientist
Terrestrial Sciences Section
Climate and Global Dynamics
National Center for Atmospheric Research
1850 Table Mesa Drive
Boulder, Colorado, 80305
USA.
+1 303-497-1706 <(303)%20497-1706>
http://www.cgd.ucar.edu/staff/rfisher/
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#156 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/AOV4Zu3orYJ6GTsypMXKZoMKBohlbg_rks5rFtN9gaJpZM4LF49s>
.
|
Re the question of spatially explicit veg parameters, it seems like the main near-term one that we'd want is the initial cold-start number density (so that we could, e.g., have separate biogeographic provinces in a single run). Is that most eaaily accomplished via the PFT parameter file or a surface parameter dataset? |
I'd advocate for keeping initial conditions out of the parameter file |
My understanding is that CLM classifies input data roughly as:
A multi-dimensional parameter would be something like a 2D look-up table where a parameter varies with state in a non-analytical way. We have negotiated with CLM to modify how the parameters are handled. We haven't had any discussions with CLM about changing handling for surface data sets and initial conditions. Those are different infrastructure and a completely different scope of work. If people want to make those changes, we need to start the discussion with CLM sooner rather than later. |
To be clear, I am specifically referring to the PFT parameter "initd". This is configured as a pft-vector parameter, but in fact is actually a cold-start initial condition. This is the only thing I can imagine wanting to be geographically dependent any time soon. The reason we'd want this to vary geographically is to allow certain PFTs to exist in one place but not another. |
thinking about this some more, I think we should just proceed with supporting only the currently-required parameter data shapes for now. we can come back to the initd issue at some later date via some sort of surface-dataset override of the PFT parameter. We'd only need that capability when/if we get to the point of having separate biogeographic provinces running in a pantropical model, and the complexity of having to support different geographic resolutions in a pft file seems like something to avoid at all costs. |
Good point... It should probably be a surface dataset if we decide to go
that route anyway, but it's some way down the road.
…On 7 December 2016 at 17:52, Charlie Koven ***@***.***> wrote:
thinking about this some more, I think we should just proceed with
supporting only the currently-required parameter data shapes for now. we
can come back to the initd issue at some later date via some sort of
surface-dataset override of the PFT parameter. We'd only need that
capability when/if we get to the point of having separate biogeographic
provinces running in a pantropical model, and the complexity of having to
support different geographic resolutions in a pft file seems like something
to avoid at all costs.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#156 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/AMWsQxMJjKOAxL43yZlGalVRYWYfuNgMks5rF1TOgaJpZM4LF49s>
.
--
------------------------------------------------------------------------
Dr Rosie A. Fisher
Staff Scientist
Terrestrial Sciences Section
Climate and Global Dynamics
National Center for Atmospheric Research
1850 Table Mesa Drive
Boulder, Colorado, 80305
USA.
+1 303-497-1706
http://www.cgd.ucar.edu/staff/rfisher/
|
Merge remote-tracking branch 'pr/andre-ed-params' Introduce an interface to pass parameter information from the host to fates. Fates registers a set of parameters that it needs read in, and indicates if they are fates only parameters, or need to be synced with values from the host. The host reads the parameters and returns them to fates. This refactor attempted to be as minimally invasive as possible to the fates science code. All existing storage and conventions for fates parameters were left in place. The only exception was the consolidation of all pft dimensioned parameters into the EDpftvarcon type. Fates no longer uses variables from the host pftcon type. This introduces dynamic allocation of pft level parameter in preparation for setting the number of pfts at run time, but still requires a hard coded number of pfts until the host code can be modified. Note that the default clm and old clm-ed parameter files have diverged before this work began. To do this development in a bit for bit way, the clm-ed parameter file was updated to agree with the clm default parameter file. This is answer changing compared to the fates master branch, but code was refactored in a bit for bit way. No netcdf variables were added or removed in this PR. Fixes: #155, #156 User interface changes?: Yes. 1. Users will need to update custom parameter files. This introduces a new namelist variable, fates_paramfile. The fates parameters are **always** read from the netcdf file pointed to by fates_paramfile. All host parameters are **always** read from the netcdf file pointed to by paramfile. The host paramfile and fates paramfile **may** point to the same netcdf file. 2. All fates parameters and dimensions are now name spaced by 'fates_'. The variable names have remained the same, but the dimension 'param' is now 'fates_scalar'. A new default parameter file with the required changes is available. See fates_params.c170308.nc in the input data repo. Code review: self. Discussion with clm-cmt, code walk through with ckoven, rgknox, rosie Testing: andre: 2017-03-14 Test suite: ed - yellowstone gnu, intel, pgi hobart nag Test baseline: 0ea3fed Test namelist changes: addition of fates_paramfile Test answer changes: bit for bit Test status: all tests pass Test suite: clm_short - yellowstone gnu, intel, pgi Test baseline: clm4_5_12_r195 Test namelist changes: none Test answer changes: bit for bit Test status: all tests pass
I think we can close this right? @bandre-ucar gave us a smashing API on this front. |
Summary of Issue:
Define and implement a fortran API for fates to exchange parameter information with the host model.
Requirements and design considerations:
Summary of API v0.1
fates_register_parameters_for_hlm(fates_params)
HLM loops over the array of fates parameters, extracts data from netcdf file using host infrastructure.
fates_receive_parameters_from_hlm(fates_params)
Depends on:
#155
The text was updated successfully, but these errors were encountered: