Scheduled Downtime
On Tuesday 24 October 2023 @ 5pm MT the forums will be in read only mode in preparation for the downtime. On Wednesday 25 October 2023 @ 5am MT, this website will be down for maintenance and expected to return online later in the morning.
Normal Operations
The forums are back online with normal operations. If you notice any issues or errors related to the forums, please reach out to help@ucar.edu

GRAINC_TO_FOOD problem?

samrabin

Sam Rabin
Member
I'm working to add an annually-output variable that gives the total "grain C to food" accumulated during each growing season. This will be faster and less error-prone than the usual method, which is to sum daily GRAINC_TO_FOOD across a growing season (after multiplying by 3600*24, or 3600*24*n_days_in_month if using monthly output).

Because that's the usual way of doing things, I was surprised to see that I'm only getting one positive GRAINC_TO_FOOD value per year, even when looking at daily outputs. I looked into it, and the variable that GRAINC_TO_FOOD tracks—repr_grainc_to_food_patch—is only ever updated immediately after harvest, in CNOffsetLitterfall():
Code:
repr_grainc_to_food(p,k) = t1 * reproductivec(p,k) &
    + cpool_to_reproductivec(p,k) - repr_grainc_to_seed(p,k)
where t1 = 1.0_r8 / dt. As I said, this was surprising but perhaps not a problem. Perhaps its constituent parts are doing the accumulating? But it looks like no, that's not the case. I don't see reproductivec get a positive value anywhere; cpool_to_reproductivec is often positive but is reset after every timestep, so it's not accumulating anything; repr_grainc_to_seed is assigned a new value (not accumulated) just before the above lines.

Then I realized that the alternative method of calculating this value—taking the maximum GRAINC_TO_FOOD seen across the entire year, instead of summing, as suggested here—conflicts with the summing method. Also, it would only make sense if GRAINC_TO_FOOD were cumulative, which it appears not to be.

What am I not understanding? @dll@ucar_edu, could you clarify?

My test simulation is 1x1_smallvilleIA, which has (I think) every crop. I branched off of ctsm5.1.dev092 and have made no changes beyond adding my new output variable and a lot of print messages.
 

sacks

Bill Sacks
CSEG and Liaisons
Staff member
I'm not totally following this... I would be happy to join a call on it if it would be helpful to have me in this discussion. But I do want to comment on this:

I don't see reproductivec get a positive value anywhere

Have you looked in src/biogeochem/CNCStateUpdate1Mod.F90? I believe it's updated there (look for references to reproductivec_patch in that module).
 

samrabin

Sam Rabin
Member
D'oh! Yes, I had added print statements at the three places in that file where it's updated, but had an incorrect conditional on the third one. Now I see it does indeed accumulate positive values.

I also now see that I was wrong about the two methods of getting GRAINC_TO_FOOD—summing a positive value plus a bunch of zeros is of course the same thing as just taking the maximum (i.e., the only positive value).

Sorry for the confusion!
 

knreddy

K Narender Reddy
Member
Hello all,
What would be the right way to extract yield data from GRAINC_TO_FOOD? I am currently employing the method described in the attachment. which is similar to method one of @samrabin. But the comparison with FAOEarthStat data and CLM data is overestimating the yield.
Please correct me if I'm using the wrong method.

NOTE: The GRAINC_TO_FOOD is written daily. Therefore, I am summing the daily values over the year.

Thanks
 

Attachments

  • Improving crop dynamics of spring wheat and rice in CLM-7-8.pdf
    512.7 KB · Views: 7

samrabin

Sam Rabin
Member
Hi Narender,

As you've experienced, using the daily GRAINC_TO_FOOD output is complicated. By any chance did you also save GRAINC_TO_FOOD_ACCUM_PERHARV? That's a new variable I added to simplify the postprocessing. It might be worth comparing with your results from daily GRAINC_TO_FOOD. (Note that you don't need to multiply the _PERHARV version by 86400.) If they agree and you thus still see disagreement relative to Lombardozzi et al. (2020)—or you didn't save that variable—start a separate forum thread and tag me so we can try to figure it out.

Also, in that reply, please clarify what CLM_D and CLM_M are in the figures on the second page of that PDF.
 
Top