Scheduled Downtime
On Friday 21 April 2023 @ 5pm MT, this website will be down for maintenance and expected to return online the morning of 24 April 2023 at the latest

(RESOLVED) Issue writing daily carbon fluxes (GPP & NPP) in Noah-MP

This post was from a previous version of the WRF&MPAS-A Support Forum. New replies have been disabled and if you have follow up questions related to this post, then please start a new thread from the forum home page.

W

wrf_alessandro

Member
Hi All,

I am facing an issues with Noah-MP: when I set the history frequency to 1 day, the variables GPP and NPP are always 0, while when the history frequency is 3h or 6h they are correctly saved and displayed in wrfout. Any suggestion on how to fix this bug keeping the history frequency at 1 day?

Best,
Alessandro
 
Hi,
Can you let me know which version of WRF you are using, and will you attach your namelist.input file? Thanks!
 
Hi,
I am not seeing this problem. With your namelist settings (including setting history_interval = 1440), I see values for GPP and NPP in the history files, not for the initial time, but after 24 hours. When I set history_interval = 180, for GPP, I don't see values until 15 hours into the integration, but I do see values starting with 3 hours into integration. Was your code modified in any way?
 
Hi,
thanks for cross checking. I did not modify the code.
I have attached the GPP for the first 5 days of my simulation setting history_interval = 1440. As I said, with history_interval = 180 it works fine.
Any suggestion to understand what is going wrong?
 

Attachments

  • GPP.nc
    2.3 MB · Views: 39
That certainly is odd. Can you try to run again (only 1 day is necessary) with dveg=2. Re-run real and wrf, and see if that makes a difference. If not, can you send me the following files so that I can try to run this with your exact input?
  • met_em.d01* files for the first 24 hours
  • your wrfout* files for the first 24 hours

These files are likely going to be too large to attach. If you don't have another method to send a link to them, see the home page of this forum for instructions on attaching large files. Thanks!
 
Hi, I ran the model again from scratch using a coarser domain and a different forcing data (ERA-Interim) and I confirm I still have the same issue (both when using dveg=5 and dveg=2). In both cases, the model works perfectly if I do not set history_interval to 1 day.
For a further check, I have packed and uploaded namelists, met_* and wrfout to nextcloud server (Test_Cfluxes_NOAH-MP.tar.gz).
Thanks,
Alessandro
 
Hi,
I have reviewed this and run a few tests, myself. With your files, I am able to see what you are seeing. And unfortunately this physics scheme was provided to us from an outside group, so I do not understand everything that is happening in the code. However, according to the definition of GPP in the phys/module_sf_noahmplsm.F file, it is "net instantaneous assimilation." Of what...I'm not sure, but the fact that it says it's instantaneous makes me think whatever its value is at the time of the output, that is what you see in the output. I also notice that when I output it every 3 hours, I'm seeing that the values are 0, and then they increase, but seem to increase with the same pattern as the sun would be setting, back to 0 again by hour 24 (take a look at the screen shots I'm attaching). If I follow the code deep enough, there is a call to a radiation subroutine, and since there is no incoming SW radiation once the sun sets (nor at 0 UTC for the area in your domain), it seems correct that this value is zero. So I think it's doing what it is supposed to do, and this is actually not a bug.
 

Attachments

  • hr12.png
    hr12.png
    108.3 KB · Views: 1,059
  • hr15.png
    hr15.png
    85.2 KB · Views: 1,058
Hi kwerner,
thanks again for running these tests.
Actually, GPP represents the flux of carbon stored by vegetation through photosynthesis, hence it strictly depends on light availability: during night it is correct that GPP is 0, while during daytime GPP has non null values.
Having said that, if GPP is saved as an instantaneous value, when I use a history frequency of 1d the model writes data at 00:00, so it would be correct to find only 0s. However, in one of your mail you wrote "with your namelist settings (including setting history_interval = 1440), I see values for GPP and NPP in the history files". If I understood it well, you were able to have see GPP in output even when using history_interval_d=1; is that correct? If so, I assume GPP is not an instantaneous flux, but an averaged daily value. Otherwise, in case GPP really represents an instantaneous flux I have to increase history_interval from daily to 3 or 6 hours. Besides, would be possible to modify in some way the code to change GPP from instantaneous to accumulated or averaged flux between writing time steps?
Thanks,
Alessandro
 
Alessandro,
When I originally tested this (before having access to your files), I used a domain over the western U.S., so at 0 UTC, there still would have been daylight.

It may be possible to modify the code for your purpose, but this will be something you will have to tackle, as we don't have the resources in our group to do so. You may also be able to contact the group who develops/supports Noah-MP to get their thoughts on it. Here is a web page with some information about the scheme: https://ral.ucar.edu/solutions/products/noah-multiparameterization-land-surface-model-noah-mp-lsm
 
Hi, thanks for getting back to me. That makes sense.
Gonna try to see if I can modify the code for my purposes or increase the output frequency.
Thanks again for support,
Best,
Alessandro
 
You must log in or register to reply here.
Top