AGS update: bug fixes, relaxation, split leaf branches, read vegetation constants from the input - #312
AGS update: bug fixes, relaxation, split leaf branches, read vegetation constants from the input#312adoyenne wants to merge 1 commit into
Conversation
…on constants from input
| count = (/imax, jmax/) ) | ||
| if (lags) then | ||
| !gm25 | ||
| call check( nf90_inq_varid( ncid, 'gm25_'//trim(tile(ilu)%lushort), varid) ) |
There was a problem hiding this comment.
Would it be possible to use the new read_nc_field interface? You could specify a fill value, so we can maybe use the default parameters that existed before? Depending on which lutype it is (the previou ('fbd', 'fce', 'sem', 'urb', 'brn', 'crp', 'ara') switch case) I'd love to try the ags scheme out some time, but I have no real knowledge about which parameters are right, so if we can keep some sensible default values I would be very happy.
There was a problem hiding this comment.
Would it be possible to use the new read_nc_field interface? You could specify a fill value, so we can maybe use the default parameters that existed before? Depending on which lutype it is (the previou ('fbd', 'fce', 'sem', 'urb', 'brn', 'crp', 'ara') switch case) I'd love to try the ags scheme out some time, but I have no real knowledge about which parameters are right, so if we can keep some sensible default values I would be very happy.
I actually have a lookup table with these coefficients implemented as a Python script in my DALES input generator (for the surface data part). You could add it to your workflow as well, I can send it to you.
I was thinking that adding the entire lookup table directly to the surface data code might be a bit bulky. Another option would be to define default values there, for example using the grass (grs) coefficients. Then, if the coefficients are missing from the LSM input, the program would automatically fall back to the grass values for any missing coefficients.
What do you think? Or would you prefer to have the full lookup table implemented in the surface data code?
There was a problem hiding this comment.
Thinking about it a bit more, in the rest of modLSM, we're already asking people to give values for things like LAI, a_r and b_r, without having fill values.
The danger with leaving grass values in would be that people run the AGS scheme without really knowing what they're doing.
I think it would be fine to leave it like this, but I think it's nice to have somewhere in the code some link to a repo showing how these values can be generated/filled. If you can put that in I think it looks nice!
There was a problem hiding this comment.
Thinking about it a bit more, in the rest of modLSM, we're already asking people to give values for things like LAI, a_r and b_r, without having fill values. The danger with leaving grass values in would be that people run the AGS scheme without really knowing what they're doing. I think it would be fine to leave it like this, but I think it's nice to have somewhere in the code some link to a repo showing how these values can be generated/filled. If you can put that in I think it looks nice!
I agree. By the way, I have added my input generator workflow to repo: https://github.com/adoyenne/DALES_input_generator/tree/main
There is a python script in land_surface that has all needed input coefficients for Ags: https://github.com/adoyenne/DALES_input_generator/blob/main/dales_openBC_setup/scripts/land_surface/ags_parameters.py
In principle, we can add this somewhere as link that everyone can find this, to not extend too much the surfdata part.
There was a problem hiding this comment.
It's good you added the workflow to your repo, I think if you add it as link to the code, just so people can find appropriate parameters would be nice!
2 participants
Summary
This PR updates the ags scheme implementation in modlsm with several bug fixes and improvements.
Changes