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

Allow n-band radiative transfer #1014

Draft
wants to merge 41 commits into
base: main
Choose a base branch
from
Draft

Allow n-band radiative transfer #1014

wants to merge 41 commits into from

Conversation

Espeer5
Copy link
Collaborator

@Espeer5 Espeer5 commented Feb 5, 2025

Purpose

This PR extends our radiative transfer functionality from 2 bands (PAR and NIR) to an n-band scheme. This will allow pairing with ClimaAtmos which provides 16 bands. Represents step one towards #876.

This PR must be a large number of lines due to updating of all of the experiments and tests.

To-do

  • Update fundamental radiation structs
  • Update radiative transfer computations in models
  • Repair all experiments and tests to work with new scheme
  • Add a test for using up to 16 bands of radiation
  • Check benchmarks and long runs to ensure no significant regressions
  • Verify GPU compatibility is not broken
  • Restore windows-latest to tests when working

Content

  • Adds a tuple-based type for the discretization of the λ spectrum
  • All leaf & soil optics types are converted to tuple-valued fields
  • Uses solar irradiance curve to allocate incoming shortwave to radiation bands
    • Also to compute PAR quantities from spectral absorption for photosynthesis
  • Updates all tests and experiments to work with new structs / types

  • I have read and checked the items on the review checklist.

@Espeer5 Espeer5 added enhancement New feature or request breaking change labels Feb 5, 2025
@Espeer5 Espeer5 self-assigned this Feb 5, 2025
@Espeer5 Espeer5 force-pushed the es/n_bands branch 3 times, most recently from ef3d4c1 to fba4d2a Compare February 12, 2025 11:46
@Espeer5 Espeer5 force-pushed the es/n_bands branch 9 times, most recently from b6d5976 to c4c1e23 Compare February 18, 2025 06:32
@Espeer5 Espeer5 force-pushed the es/n_bands branch 2 times, most recently from 115102c to 9c371e2 Compare February 19, 2025 05:51
@Espeer5
Copy link
Collaborator Author

Espeer5 commented Feb 19, 2025

Can anyone help me out with the GPU compatibility issue here?

It's a bit odd to me because the same broadcast structure is used over ntuple in canopy_sw_rt_beer_lambert as in the canopy_sw_rt_two_stream, but only one of them seems to cause the issue. I'm a little stumped by it.

@Sbozzolo
Copy link
Member

I can help with the GPU compat, but I have a couple of other things that I need to finish first.

@juliasloan25
Copy link
Member

juliasloan25 commented Feb 19, 2025

Can anyone help me out with the GPU compatibility issue here?

It's a bit odd to me because the same broadcast structure is used over ntuple in canopy_sw_rt_beer_lambert as in the canopy_sw_rt_two_stream, but only one of them seems to cause the issue. I'm a little stumped by it.

I expect that somewhere in canopy_sw_rt_two_stream you're broadcasting over floats, which will error if it's inside a GPU kernel (which this function will be since it's called with @.). E.g. see this thread. It's hard to tell what inside that function is a Tuple vs a float though, so I can't tell exactly where the issue is. Since this function is a lot more complex than canopy_sw_rt_beer_lambert there's more space to make an error in the broadcasting.

@juliasloan25
Copy link
Member

Is it possible to apply canopy_sw_rt_two_stream for each element of \alpha_soil, \rho_leaf, \tau_leaf (just broadcasting normally) instead of wrapping them in tuples to get around the broadcasting?

@Espeer5
Copy link
Collaborator Author

Espeer5 commented Feb 19, 2025

Is it possible to apply canopy_sw_rt_two_stream for each element of \alpha_soil, \rho_leaf, \tau_leaf (just broadcasting normally) instead of wrapping them in tuples to get around the broadcasting?

Possibly. I was originally doing this but had some issues handling it correctly when α/ρ/τ were tuple-valued-fields vs. plain tuples. But you're right this must be the issue. Thanks

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
breaking change enhancement New feature or request
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants