FSURDAT and DGVM

[ckcastillo@purdue_edu]

Hi, I just wanted to clarify something about defining FSURDAT when running CLM3.5-DGVM. The manual says that FSURDAT "specifies a surface dataset containing time-invariant land properties such as plant functional types and soil textures..."

However, if the DGVM is activated (with arbitrary initialization), then the pft's and PCT_PFT change over time as the model spins up. How is this achieved if the pft's are "invariant" in the surface dataset? Is CLM3.5-DGVM disregarding the PCT_PFT prescribed in the surface dataset when it spins up from bare ground?

Thanks!

 

[slevis]

Yes, the model ignores the pft and lai data from fsurdat when DGVM is active.

Sam

 

[ckcastillo@purdue_edu]

Thanks for that clarification!

Does this mean, then, that if I wanted to create a branch run where, say trees are converted to grass, I need only edit the pft types, fpcgrid, albedo, canopy top & bottom etc. in the initial dataset (assuming I already have a spun-up initial dataset) and just ignore what's specified in the surface dataset for these relevant fields?

If so, how can one access only certain lat/lons to change fields like ITYPVEG and FPCGRID that are dimensioned by "pft" only, as opposed by the PCT_PFT in the surface dataset that has lat, lon dimensions?

Thanks again.

 

[slevis]

I guess so, but changing an initial/restart dataset is not easy because variables are stored as vectors (1D) rather than gridded (2D). Initial/restart datasets include mapping indices that tell you the lat and lon for each p-index.

I'm curious why you would want to change the initial dataset. Are you exploring differences in the dgvm simulation in response to differences in the initial conditions?

Sam

 

[ckcastillo@purdue_edu]

So pfts1d_lon/lat, for example, are the indices that correspond one-to-one with the entries in itypveg and fpcgrid?

I'd like for force some amount of deforestation annually - say, convert 2% of trees at the start of every year to grasses for 50 years, and then experiment with others runs where I stop the deforestation earlier or slow down the rate, etc. and see what happens. Experimenting with just CLM-DGVM is the first step. I plan to move on to CCSM later. If you have any suggestions, they're most welcome.

Thanks!

 

[slevis]

pfts1d_lon and lat sounds like the correct variable. Still, if you find working with the initial/restart files cumbersome, then you may wish to try something else, eg, making your pft changes directly in the code somehow, eg, in subroutine establishment.

Sam

 

[ckcastillo@purdue_edu]

Is it possible, within the subroutine for establishment, to apply pft changes only to selected latitudes and longitudes? I've been going over the code and it's still not clear to me how to determine the lat/lon of a gridcell since there doesn't seem to be a variable within that module with this information. Would you have any suggestions for how to go about this? Thank you!

 

[slevis]

Clm has the variables latdeg and londeg defined in clmtype.F90. You would need to point to them in the subroutine that you're interested in. If this makes no sense, then you probably need some background in programming before delving into this...

 

[ckcastillo@purdue_edu]

Thanks! I was able to figure out as much.
If I may also ask, how are the upper and lower bounds determined for the dimensions 'pft' and 'gridcell' which are being looped over in the code? I suspect that maybe these are based on just the number of land cells rather than the entire span of lats/lons, but I'm not sure.

 

[slevis]

Yes, the p and g indices are looping over land points only. In subr. Establishment they may even be looping over a filter of soil points only (I don't remember for sure). You could put a write statement in the code and see what values you get for p, g, latdeg, londeg, and even ivt (= the pft number, in case you find it helpful).

The upper and lower bound variables in the code (e.g., ubg, etc) are not exactly what you think. These facilitate the distribution of the clm over multiple processors when running on a multi-processor machine. You don't need to worry about that. You can still place a write statement in a loop and write out values of variables.

Given what you're trying to do, you will find it useful (maybe you've started doing this already) to use existing code as a template for the things that you wish to do. E.g., if you don't know how to use a write statement in subr. Establishment, then you could look for examples of write statements elsewhere in the code. Of course this is not a substitute for understanding how fortran works, and I hope I did not offend you when I mentioned the option of picking up some programming skills before becoming overwhelmed by the clm code.

Sam

 

[ckcastillo@purdue_edu]

Thanks a lot, your replies have been really helpful. No, I didn't take offense - I really don't have any fortran programming background though I have had some basic C and Pascal. I'm essentially using what I learned from that while, as you suggested, looking through the fortran code for examples of specific syntax. So it just takes me a little longer to figure out as much as more seasoned programmers might get easily, and in certain cases, I need to ask in the forum to verify if I understood right.

I'll try what you suggested, and I hope you don't mind if I keep on asking things as I go along.

 

[ckcastillo@purdue_edu]

Good day, Dr. Levis!

I was able to loop over the indices, force deforestation by preventing establishment of saplings and reducing nind in selected latitudes, write out statements to check and confirm, then just allow the Establishment subroutine to update the fpc's accordingly.

During my first try at 2% reduction in nind, the run failed as fpc_total_new and the sum of pft weights in gridcell exceeded by 0.05+. But, at a 10% reduction, the one-year initial run was completed successfully. The problem came in the next year's run - I got this message:

'Error: Forcing height is below canopy height for pft index '

I'm looking through the corresponding module, CanopyFluxesMod.90, and it's not clear to me how the changes I made in DGVMEstablishment would cause this error as the program moves on to the next year. Would you have any suggestions?

Thank you!

 

[slevis]

By reducing the nind by 2% or 10%, you have effectively thinned the forest, right? I guess I cannot think off the top of my head why this error would come up, but somehow you have caused the height of your pft to exceed a threshold which triggers this error. In other words, lowering the nind changes the pft's fpcgrid, lai, height, (anything else that I'm forgetting?), but the height for some reason has exceeded an allowed threshold. Maybe, when you change the nind, you also need to change something else for consistency, but I don't know off the top of my head what.

Have you read through the dgvm equations in the dgvm user's guide? I wonder if that would give you the bigger picture of what is going on and possibly give you some clues.

Sam

 

[ckcastillo@purdue_edu]

I see how the fpc and lai are affected by I'm a little confused about the height. Going through the documentation, I see that the error was triggered when observational wind height (forc_hgt_u(g)) - displacement height (displa(p)) becomes

 

[ckcastillo@purdue_edu]

Thanks! What you said about thresholds got me to thinking that maybe I should have checked already if the new thinned population density was still above the minimum nind instead of waiting until the next year's call to the Establishment module for that to update. The code seems to be working now.

 

[ckcastillo@purdue_edu]

I seem to have been mistaken - during on of my runs the the error

'Error: Forcing height is below canopy height for pft index

came back in year 52 of the run. I was wondering if it's possible that some point is reached when the vegetation has just been thinned out too much, but then the model works fine during spin-up runs from bare ground so that can't be the problem, right?

 

[slevis]

...so I'm looking in subroutine Establishment. Canopy height is calculated in this section of the code:
stemdiam=(4.0_r8*(sm_ind_temp+hm_ind(p))/wooddens(ivt(p))/SHR_CONST_PI/allom2(ivt(p)))**(1.0_r8/(2.0_r8+allom3(ivt(p))))
htop(p) = allom2(ivt(p)) * stemdiam**allom3(ivt(p))

From your error (canopy height too high) I get suspicious that you remove individuals from nind before the code adds new saplings to the current population. As a result sm_ind_temp and hm_ind become bigger, stemdiam becomes bigger, and htop becomes bigger. If instead you removed the individuals after that, you would only affect fpcgrid and litter, I think. Doesn't that seem preferable?

But maybe you're doing things as I suggest, and the error shows up in the following year? In that case, the only suggestion I've come up with is to put an upper limit on htop, so that you will not trigger the error...

Sam

 

[ckcastillo@purdue_edu]

Yes, the error came back at year 52 so it seems I did not really solve is the first time.

Yes, I thin out nind before new saplings are added and yes, the error shows up in the following year. But I do not allow for new saplings in the coordinates which I am controlling - i.e. I skip Case 2 if tree(ivt(p)), proceed to thin out nind, and then skip the section that adds new tree saplings and recomputes individual masses, new canopy height, etc. Thus, htop shouldn't get bigger than what was previously computed for in the Allocation module, right?

I do update the litter pools right after I update nind, with the assumption that leaf and mass go to litter while the sapwood and heatwood are logged for timber and are thus taken away. I've just added a line updating fpcgrid after updating nind too, instead of waiting for that to get updated at the end of the module. Not sure if this resolves anything though - the model is still running.

 

[ckcastillo@purdue_edu]

I just noticed something about fpc_total_new which confuses me (and which could be one of the sources of my error):

After it is initialized at 0, fpc_total_new is not updated until within the "add saplings block". The conditions to go through this block are that present(p) and tree(ivt(p)) and grid_estab(g,ivt(p)) are true.

So, what about those for which there are trees present and grid_survive=true but grid_estab=false? How do the fpc_grid's from these get added to fpc_total_new before the part that adjusts if fpc_total_new>0.95?

Since I modified the code to skip the "add new saplings" block in areas where I am forcing deforestation and restricting regrowth, the fpc_grid's of these cells are not being added to the fpc_total_new as well also before the 95% check.

This may not related to the canopy height error and might already be resolved by the part that "recaulculates fration of veg landunit for each pft" but I just want to make sure I understand what's going on.

Thanks!

 

[slevis]

I wrote this code many years ago, so I don't remember it much. To try to explain how it works or to fully understand your thought process would require that I refamiliarize myself with it. Instead of doing that, I recommend that you read the code line by line and at the same time follow the dgvm technical note. Should take less than an hour to decipher exactly what is going on in this subroutine. If you like to see numbers as examples, add write statements in the code. You could do the same to figure out exactly why your changes are making the code stop. It's the old fashioned method of debugging, but I haven't found a better one, yet...

Sam