Modified canopy wind calculation to be continuous. #57
Conversation
|
@angehung5 You also may want to test this change with the canopy wind evaluation, as it may have some slight impacts on the results, particularly since RSL_OPT = 0 is the only option now to make the profile continuous in output. This should have no effect on WAF calculation. |
|
@zmoon and @angehung5 Converted to draft, as this needs more thought...I am also unsure on how much the continuous profile is needed here in canopy-app, considering its application to gridded ATM/LSM models that already have computed the log MOST/RSL profile above the canopy... Up for more discussion on approaches for sure. |
|
Figure shows the wind profile at Chestnut Ridge site. Updated code creates continuous profile. But I am somehow uncomfortable with removing RSL_opt =1, since it actually provides better results than RSL_opt=0 when reference height larger than 0. |
|
@angehung5 Thank you for your testing, and we could certainly find a way to work back in RSL =1, but keep profile continuous when HREF > 0. We can also tune the LAMBDARS in RSL=0 though. |
|
And here shows the wind profiles using updated code with RSL_opt=0, old code with RSL_opt=0 and old code with RSL_opt=1. Seems like updated code tends to create higher wind speed at canopy top. @drnimbusrain How do you get the log profile above canopy? Based on Massman? |
|
There long profile is based on the Noah-MP calc (with RSL LAMBDARS factor),
but get very similar results when using the Massman log wind profile. You
could try another test with updated RSL_OPT =0 code and lambdars = 1.0.
LAMBDARS is essentially a RSL tuning factor (with no representation of
atmospheric stability). I will try to bring back the RSL_opt = 1 soon.
…On Fri, Apr 14, 2023, 4:21 PM Wei-Ting Hung ***@***.***> wrote:
[image: Screen Shot 2023-04-14 at 3 54 04 PM]
<https://user-images.githubusercontent.com/107704243/232146072-d6eeff6e-ff2f-4f1c-934a-f92a643d8979.png>
Just found a bug in my script. Here is the updated plot of wind profiles
at Chestnut using updated code. A relative sharp change at canopy top like
Patrick shown above.
And here shows the wind profiles using updated code with RSL_opt=0, old
code with RSL_opt=0 and old code with RSL_opt=1. Seems like updated code
tends to create higher wind speed at canopy top. @drnimbusrain
<https://github.com/drnimbusrain> How do you get the log profile above
canopy? Based on Massman?
[image: Screen Shot 2023-04-14 at 4 13 09 PM]
<https://user-images.githubusercontent.com/107704243/232147213-5cbde635-7ec7-4a5b-9c1d-33dfc8fe5eb2.png>
—
Reply to this email directly, view it on GitHub
<#57 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AGLFYNXVW26VKUHLHNGUUNTXBGWTJANCNFSM6AAAAAAW4P6RQQ>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
|
Great, thanks! I test lambdars = 1.0 with updated RSP_opt=0 code. It looks better now but the wind speed at canopy top is still higher than the old results. |
|
@angehung5 I have made some substantial changes (may still need a bit more work on an updated re-calculation of zero plane displacement height for RSL) to bring back an improved method for the unified RSL_OPT=1. Can you please test it again with the above case for new RSL_OPT=0 and =1? Thank you! |
|
@angehung5 I just tested these mods for continuous RSL_OPT=1, and it fails for regional domains in some locations. I think you could still test it at Chestnut Ridge, but, we should discuss more about this maybe in person at the AMS meeting this week. It is not trivial to bring back RSL_OPT=1 in a full unified approach with continuous profile, energy balance, and iterative updates to the MOL for a canopy. This is also complicated with coupling this approach (from Bonan's work) above the canopy to Massman within the canopy. |
|
@angehung5 @zmoon OK, I have made the canopy_wind module to have only the Massman/MOST subroutine (RSL_OPT=0), controlled through the canopy_calcs now. The profile should be continuous below and above the canopy, with Massman below, and general MOST theory above. Remember in Massman, RSL_Opt=0 approach, the RSL effects are simply the LAMBDARS variable than just provides a constant factor to tune the RSL effects. I think this is sitll a valuable approach. So, as noted in the README, the RSL_OPT=0 is the only option right now. Once we can can take Bonan's codes from Zach, we can create another unified RSL approach (somehow) as a new subroutine in the canopy_wind module. This can then form a better continuous, and unified RSL_OPT=1 approach, which will differ from the pure Massman/MOST approach. What do you think? Maybe if Wei-Ting can re-evaluate this new continuous Massman/MOST (RSL_OPT=0), I can clean up the code and we can merge, and then make a new issue/PR for integrating a more robust RSL_OPT=1 for unified RSL from Bonan? |
|
Yes, I think it is a good idea to re-evaluate the new profile with observation. Not all sites have above-canopy wind measurements though. What do you mean merge? Merge to the develop branch? |
|
@angehung5 Yes, merge the continuous Massman/MOST profile (RSL_OPT=0 only) to develop branch so we can at least have the wind profile continuous using MOST for now, and then open a new issue/PR for the Bonan RSL approach. |
|
@angehung5 Please let me know when you have re-evaluated the new RSL_OPT=0 option here in 'canwind' branch, and if it looks OK through canopy. @zmoon Then we can finalize review of this branch, merge with develop branch, and then I can start to work on a new branch PR for RSL_OPT=1 branch with Bonan unified RSL approach ( issue #62 ) . |
|
@zmoon Thanks to Wei-Ting, I think the results of the new RSL_OPT=0 (Massman/MOST approach with lambdars) approach is working very well: https://docs.google.com/presentation/d/1yRbnbYQQxkAnK79ud-n9MOw3V5YEcy55/edit#slide=id.p4 Therefore, can we move forward with review, and/or merge to develop? |
|
Thanks Patrick @drnimbusrain , for posting the results. Should it be RSL_OPT=0? Going to approve. |
|
@zmoon What do you think about merge? I have just cleaned up the RSL_OPT=0 code to remove old fragmented RSL_OPT=1 codes. |
|
Thank you Zach, can you fix it up?? ;)
…On Thu, May 11, 2023, 5:59 PM Zachary Moon ***@***.***> wrote:
***@***.**** commented on this pull request.
Noticed a little something in the readme
------------------------------
In README.md
<#57 (comment)>
:
> @@ -183,9 +183,10 @@ https://nacc-in-the-cloud.s3.amazonaws.com/inputs/geo-files/canopy.2022MM01.test
| `ifcanphot` | logical canopy photolysis option (default: `.FALSE.`) |
| `ifcanbio` | logical canopy biogenic emissions option (default: `.FALSE.`) |
| `href_opt` | integer for using href_set in namelist (= `0`, default) or array from file (= `1`) |
-| `href_set` | user-set real value of reference height above canopy associated with input wind speed (m) (only used if `href_opt=0`) |
+| `href_set` | user-set real value of reference height above canopy associated with input wind speed (m) (only used if `href_opt=0`) ***\*\*** |
It looks like only two are bolding, I think you want to use **\*\*\***
instead
------------------------------
In README.md
<#57 (comment)>
:
> | `bio_cce` | user-set real value of MEGAN biogenic emissions "canopy environment coefficient" used to tune emissions to model inputs/calculations (default: `0.21`, based on Silva et al. 2020) |
| `lai_thresh` | user-set real value of LAI threshold for contiguous canopy (m2/m2) |
| `frt_thresh` | user-set real value of forest fraction threshold for contiguous canopy |
| `fch_thresh` | user-set real value of canopy height threshold for contiguous canopy (m) |
**\*\*** If `modres` >> `flameh` then some error in WAF calculation will be incurred. Suggestion is to use relative fine `modres` (at least <= 0.5 m) compared to average flame heights (e.g., ~ 1.0 m) if WAF is required.
+***\*\*** If `href_set` becomes small and approaches z0 (or as `href_set` --> 0), only the sub-canopy wind profile is calculated, recommend `href_set` = 10 m.
here too
—
Reply to this email directly, view it on GitHub
<#57 (review)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AGLFYNUTISCDHG23VDRXSLTXFVOLXANCNFSM6AAAAAAW4P6RQQ>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
|
Thank you @zmoon ! |
This addresses issue #56 , and instead of setting winds to reference height at z > hc, this uses the log wind profile above canopy top. This also removes the fragmented RSL_OPT (=1) effects option that created even more discontinuity across the canopy top from the different approaches. Thus, RSL_OPT = 0 is the only option for now, and uses the LAMBDARS scaling parameter to represent RSL effects above the canopy top for now.
After the change the wind speed profile is more continuous, with still a relatively sharp change at the canopy top from logarithmic to exponential in type.
