-
Notifications
You must be signed in to change notification settings - Fork 6
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
Add option to input functional groups and size classes parameters #912
base: main
Are you sure you want to change the base?
Conversation
If no file provided, default parameters will be loaded
Add helper function for creating default coral_spec
…` to default parameter set Fix units in calculating colony areas Formatting Fix bugs causing test errors
YAML is what we use else where and it supports in-file comments, but I'll take a look first |
Sure, happy to change to that. I'll sort out the failing formatting test now. If you're happy with the setup I'll also add a test for loading the coral_spec from a file, at the moment the tests only test the default loading. |
Sorry, could you say a few words on what the intended use case being supported is? Changing the spec won't affect the data or any of the modelling done via ADRIA, so just trying to understand the purpose better |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Still waiting on the above but for now I'll say I wish you discussed these changes with someone beforehand.
The principle concerns I have are:
- Relies on a separate (and currently undocumented?) JSON file that the user provides when loading a domain.
- I suspect this will create mismatches all over ADRIA as some code rely on the "default" coral specification, and others don't
- Adds a
coral_params
field to theDomain
type that is not consistently used. It also duplicates the function of themodel_spec
. - Requires even more changes to the
metrics
module than what is currently included in this PR.
Specific to just changing the number of functional groups and size classes, a cleaner approach would be to add methods to allow the model_spec
and coral_spec
to be changed/updated with new coral-relevant factors.
See relevant code, which you would have seen when working on this PR:
ADRIA.jl/src/ecosystem/corals/Corals.jl
Line 465 in 50c3aa0
function _update_coral_factors(spec::DataFrame, coral_params::DataFrame)::DataFrame |
ADRIA.jl/src/ecosystem/corals/Corals.jl
Lines 370 to 371 in 50c3aa0
function create_coral_struct(bounds::Tuple{Float64,Float64}=(0.9, 1.1))::Nothing | |
_, base_coral_params, p_vals = coral_spec() |
ADRIA.jl/src/ecosystem/corals/Corals.jl
Line 412 in 50c3aa0
function to_coral_spec(m::Coral)::DataFrame |
function load_domain(path::String; coral_spec_path::String="")::Domain | ||
return load_domain(path, ""; coral_spec_path=coral_spec_path) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sorry, I don't see how this works.
The Domain datasets themselves hold data relevant to initial coral cover, susceptibility to cyclones and other info.
" | ||
The number of functional groups and size classes specified in the coral parameters file | ||
does not match the size of the initial coral cover matrix. | ||
" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Multi-line strings are triple quoted:
"""
like so
"""
# The following splits into "small, mid and large" indices based on number of size classes and functional groups | ||
indices_array = zeros(Int64, (n_groups, n_sizes)) | ||
for n_g in 0:(n_groups - 1) | ||
indices_array[n_g + 1, :] .= collect((n_g * n_sizes + 1):(n_g * n_sizes + n_sizes)) | ||
end | ||
|
||
mid_ind = collect(indices_array[:, 2:(end - 1)])[:] | ||
size_mid = prod(size(indices_array[:, 2:(end - 1)])) | ||
|
||
small::SVector{n_groups} = indices_array[:, 1] | ||
mid::SVector{size_mid} = mid_ind | ||
large::SVector{n_groups} = indices_array[:, end] | ||
p = @NamedTuple{ | ||
small::StaticArrays.SVector{5,Int64}, # indices for small size classes | ||
mid::StaticArrays.SVector{25,Int64}, # indices for mid-size corals | ||
large::StaticArrays.SVector{5,Int64}, # indices for large corals | ||
rec::Matrix{Float64}, # recruitment values, where `s` relates to available space (not max carrying capacity) | ||
sXr::Array{Float64,3}, # s * X * r | ||
X_mb::Array{Float64,3}, # X * mb | ||
r::Matrix{Float64}, # growth rate | ||
mb::Matrix{Float64} # background mortality | ||
small::StaticArrays.SVector{n_groups,Int64}, # indices for small size classes | ||
mid::StaticArrays.SVector{size_mid,Int64}, # indices for mid-size corals | ||
large::StaticArrays.SVector{n_groups,Int64}, # indices for large corals | ||
rec::Matrix{Float64}, # recruitment values, where `s` relates to available space (not max carrying capacity) | ||
sXr::Array{Float64}, # s * X * r | ||
X_mb::Array{Float64}, # X * mb | ||
r::Matrix{Float64}, # growth rate | ||
mb::Matrix{Float64} # background mortality | ||
}(( # cache matrix to hold X (current coral cover) | ||
# Cached indices | ||
# cached indices | ||
small, mid, large, | ||
|
||
# Cache matrices | ||
zeros(n_groups, n_locs), # rec | ||
zeros(n_groups, n_sizes, n_locs), # sXr | ||
# cache matrices | ||
zeros(n_groups, n_locs), # rec | ||
zeros(n_groups, n_sizes, n_locs), # sXr | ||
zeros(n_groups, n_sizes, n_locs), # X_mb | ||
zeros(n_groups, n_sizes), # r | ||
zeros(n_groups, n_sizes) # mb | ||
zeros(n_groups, n_sizes), # r | ||
zeros(n_groups, n_sizes) # mb |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This entire bit needs to be revisited as many of these cache are not used any more (they were for the older ODE method).
function bin_widths(bin_edges) | ||
return bin_edges[:, 2:end] .- bin_edges[:, 1:(end - 1)] | ||
end |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This will break any code that used the older implementation?
function colony_areas() | ||
# The coral colony diameter bin edges (cm) are: 0, 2, 5, 10, 20, 40, 80 | ||
edges = bin_edges(; unit=:cm) | ||
function colony_areas(edges) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Same comment here. This will break any code that relies on the previous method.
To be clear, anyone who had written ADRIA.colony_areas()
will see their code break.
return ZeroDataCube(; | ||
timesteps=1:length(timeframe), | ||
locations=sort(loc_data.reef_siteid), | ||
species=ADRIA.coral_spec().taxa_names, | ||
species=ADRIA.default_coral_spec().taxa_names, | ||
scenarios=[1] | ||
) | ||
end |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm unsure of the thinking here as this will only work for the default coral specification and nothing else.
Adds the option to input the number of functional groups and size classes and associated parameters as an input file when loading the domain. If no file is input, the domain loads the default parameters as normal.
CoralGrowth
so number of functional groups and size classes is not hard codedcoral_spec()
requires an input dictionary with the base parameters required to build the spec, but the default can be loaded without inputs usingADRIA.load_default_coral_spec()
@ConnectedSystems, I'm not sure what you think of storing alternative coral parameters in a json. This was used due to being able to load directly into a dict, but open to other formats.