Skip to content
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

BiomeE forcing homogenization #251

Merged
merged 52 commits into from
Nov 13, 2024
Merged

BiomeE forcing homogenization #251

merged 52 commits into from
Nov 13, 2024

Conversation

marcadella
Copy link
Collaborator

  • Add steps_per_day parameter to specify the resolution of the time series.
  • Use same forcing as p-model (RH and soil_temp are now computed from other forcing).
  • Simplify implementation of soiltemp() to use a constant with rolling window, and fix a bug.
  • Add missing initializations affect totSeed and totNewC.
  • Factorize zero_diagnostic() to the start of the loop.
  • Split script generating drivers and computing sample output in two.
  • Regenerate both drivers and sample outputs.
  • Add integration test for BiomeE

marcadella added 30 commits October 24, 2024 08:16
…ng ('climate_type').

- Replace the automagic time resolution discovery by a simpler user-defined 'steps_per_day' parameter in 'params_siml'.
- Fix documentation issue 'recycle' is in years, not in days.
- Other minor cleaning
…ndow

- Use same year padding for both yearly mean temp and soil moisture (the latter was using an unpadded mean) in 'soiltemp'
- Fixed a bug in `soiltemp` where return was called instead of cycle.
- Add forcing description and units to `run_biomee_f_bysite`'s doc
- Minor changes in doc
…first year and can therefore not be used as left padding after all.
@marcadella marcadella requested a review from stineb November 12, 2024 13:41
@fabern
Copy link
Member

fabern commented Nov 12, 2024

🎉 Yay: "All checks have passed"

Copy link
Collaborator

@stineb stineb left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@marcadella thanks for this milestone PR! I left a couple of questions.

src/forcing_siterun_biomee.mod.f90 Show resolved Hide resolved
src/vegetation_biomee.mod.f90 Show resolved Hide resolved
@@ -70,62 +64,69 @@ subroutine biosphere_annual( &
! Initialize vegetation tile and plant cohorts
allocate( vegn )
call initialize_vegn_tile( vegn )

! Sort and relayer cohorts
call relayer_cohorts( vegn )
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why did you remove this here @marcadella ?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

relayer_cohorts is called in initialize_vegn_tile already.

simu_steps = 0
doy = 0
call Zero_diagnostics( vegn )
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

safe to remove? @marcadella

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I am 'factorizing' the diagnostics reset at the start of the loop as it is cleaner than calling the zero_diagnostics function from multiple places. I checked that this is equivalent to the previous implementation.

@stineb stineb merged commit 69fcbe2 into master Nov 13, 2024
7 checks passed
@marcadella marcadella deleted the 228-forcing-homogenization branch November 13, 2024 13:24
@fabern
Copy link
Member

fabern commented Nov 13, 2024

My thirteen comments from 2 days ago (scroll up in this thread) have not yet been addressed before merging.
@marcadella could you please go through them and consider their inclusion?
@stineb, 2 out of 13 were addressed at you: (one on renaming QMD => QMD12, and another one on storing the full example output instead of only the annual tile in rsofun::biomee_p_model_output). Could you please comment on those?

(EDIT: Okay, sorry my bad. I was unaware that the review had not been submitted.)

R/run_biomee_f_bysite.R Show resolved Hide resolved
init_soil = list(tibble(init_soil)),
forcing =list(tibble(forcing))
)
rad_to_ppfd <- function(rad) {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can you please add in comments the units of the input and output for both functions (rh_to_vpd() and rad_to_ppfd())?

src/biosphere_biomee.mod.f90 Show resolved Hide resolved
data-raw/generate_biomee_output.R Show resolved Hide resolved
if (vegn%nindivs12>0.0) then
vegn%QMD = sqrt(vegn%DBH12pow2 / vegn%nindivs12)
else
vegn%QMD = 0.0
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@stineb Why are we not using DBH but DBH12 for QMD? Would it make sense to clarify this by renaming QMD12 ?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In practice, there is a limit to which tree size in monitored, and therefore real life QMD reflect the QMD of all the trees larger than a minimum size. Here, 12cm is assumed, but @lauramarques said that the this limit should ideally be configurable. So the limit size should not be present in the variable name.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I suggest to have it in the variable name until it is configurable. (And then change the output definition, when we include the cutoff as an input parameter.)

@stineb what is your take on this?

implicit none

private
public paramstype_siml, getsteering, outtype_steering
public paramstype_siml

!----------------------------------------------------------------
! Derived type for simulation parameters
!----------------------------------------------------------------
type paramstype_siml
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is it correct that we have two different types of the same name (paramstype_siml) for BiomeE and P-Model? Could we either harmonize their contents (difficult...) or then distinguish them by name?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, that's right. I have already factorized steering_parameters, but I agree that I would be with to rename both derived types. In addition, there are plenty of parameters that are actually not used and could be removed (ex: outputhourly, outputdaily, dist_frequency, ...)

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, please rename the two types paramstype_siml with their current definitions. Could you then open an issue to discuss removal of unneeded fields in these types?

end if

end function running

subroutine downscale(out, in, rate)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In climate science downscaling is a common term which refers to increasing the spatial (or temporal) resolution (which is the opposite to 'image downscaling'). (see https://en.wikipedia.org/wiki/Downscaling or https://climate.copernicus.eu/sites/default/files/2021-01/infosheet8.pdf)

For the sake of clarity, I suggest to rename downscale() to aggregate(). Also clarify the units of rate (it is in rows of the input array, right?). Furhter, maybe call it rather resolution instead of rate?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ok.

src/soiltemp_sitch.mod.f90 Show resolved Hide resolved
@@ -1335,29 +1333,8 @@ subroutine relayer_cohorts( vegn )
! THIS CREATES WEIRD BUG: SOMETIMES ZERO SOLUTION
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is the 'WEIRD BUG' still present? Or are the modification now doing what was suggested in the removed commments?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

As far as I know the implementation is working. I believe the comment was copied by mistake from below. I'll remove it.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ok

# # test for correctly returned values
# expect_equal(tolerance, 0.6768124, tolerance = 0.03)
# })
test_that("biomeE quantitative check (gs leuning)", {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Where do we want to do these regression checks of the numeric results? In phydro-branch I added those to test-model-runs.R instead of test-quantitative-validation.R.
I did so because the latter was earmarked to be for 'quantitative check versus observations'.
I suggest thus to:

  • move this to test-model-runs.R

I further suggest to structure this similarly to the tests in pydro-branch. This involves the following steps instead of using just the single example combination of driver and (reduced) output:

  • hardcode (a subset of) the output as reference values, since this allows to better keep track of the evolution of reference values in git (see how it is done in pydro-branch)
  • test a number of different flag combinations (check what would make sense for BiomeE) that activate different parts of the BiomeE code (e.g. the p-model/Leuning flag)
  • test not only out_annual_tile, but also the other ouputs of 'runread_biomee_f' which are not all stored in the *.rda-file.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I can move it to test-model-runs, but improving the test coverage is outside the scope of the CRAN release.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ok

@fabern
Copy link
Member

fabern commented Nov 13, 2024

Since my previous review has been added here to this closed PR, I will now also add here the feedback on documentation you requested. Based on the published documentation, I suggest the following changes:

@fabern
Copy link
Member

fabern commented Nov 13, 2024

  • 7. be more explicit on https://geco-bern.github.io/rsofun/articles/data_format.html, e.g.

    BiomeE follows the same structure of input data as P-model overall, but with some differences regarding both parameters and forcing.
    Details about parameters can be obtained in the documentation: ?run_biomee_f_bysite.
    The required structure of forcing data are provided by the two example data sets below. Note that 'hod' hour of day is only used when running the gs_leuning photosynthesis and not when running pmodel.
    rsofun::biomee_p_model_drivers$forcing
    rsofun::biomee_gs_leuning_drivers$forcing

  • 8. is there a check on input data depending on code_method_photosynth ?
  • 9. explain the effect of output_hourly_tile and the parameter outputhourly when running p-model in the doc of run_biomee_f_bysite, i.e. when code_method_photosynth=="pmodel" as opposed to when code_method_photosynth=="gs_leuning".

@marcadella
Copy link
Collaborator Author

  1. init_dates_dataframe() is tested in test_ancillary_functions.R so I think it is meant as a utility function for the users.
  2. Out of scope for the CRAN release.
  3. Ok
  4. Out of scope for the CRAN release.
  5. Ok
  6. Looks like they are sorted alphabetically. I don't think it is wise to hard code the order in this file (if at all possible?) as when we will add new vignettes, we will of course forget to update this file too... But I could be possible to add a number in front of the name?
  7. More explicit about what?
  8. Yes, the model will complain if the wrong resolution is used with the wrong photosynthesis method. Other than that, both models use the same input data.
  9. outputhourly is not used at all...

@fabern
Copy link
Member

fabern commented Nov 14, 2024

Ok, sounds good. Some clarifications to four of the points.

'1. @stineb could you confirm that init_dates_dataframe() should be a function that is exposed to the package user? I would suggest to make it internal only since I do not see when a user would need this.
'4. I think homogenizing the documentation should be done before CRAN release.
'6. yes I think prepending a number to the title is a good, robust workaround.
'7. explicit about the different ways the drivers can be formatted for Biomee. Basically just what I had suggested in the quoted part.

@marcadella
Copy link
Collaborator Author

@fabern Do you have anything special in mind regarding pt4?

@marcadella
Copy link
Collaborator Author

Created a new issue: #253

@fabern
Copy link
Member

fabern commented Nov 14, 2024

@fabern Do you have anything special in mind regarding pt4?

That the two sites (https://geco-bern.github.io/rsofun/reference/p_model_drivers_vcmax25.html and https://geco-bern.github.io/rsofun/reference/p_model_drivers.html) show e.g. the forcing arguments in the same order and have the same description.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Homogenize forcing between run_biomee_f_bysite() and run_pmodel_f_bysite()
3 participants