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

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 using WRF4.2 and I have attached the namelist I am using.
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?

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.

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