Update NEON surface data PFT mixture to match NEON observations

[adrifoster]

It would be great if we could use the NEON observational data (e.g. inventory data) to determine the percentage of each PFT in the surface data files we use to drive NEON cases. This is especially important for FATES work in some of the reduced complexity modes (e.g. fixed biogeography).

NEON has data from ~20 inventory plots surrounding each tower so my idea would be to use this data to determine the mixture of PFTs at the sites. We can add this functionality to modify_singlept_site_neon.

Similarly, we should also think about creating inventory initialization files for FATES-NEON runs, using similar methods.

[wwieder]

Agreed, this would be excellent to develop.

It seems like you have some of these tools fairly well developed, at least for BONA. Is is something that @TeaganKing could help expand to additional sites? Also wanting to loop in @danicalombardozzi too.

[adrifoster]

Because of the way NEON stores it’s data the scripts I have now are generalizable to any NEON site. But I agree it would be good to get everyone’s input on best methods (from a science/ecology perspective) for going from inventory data (or AOP data, etc.) to a surface data update.

[adrifoster]

And also my scripts are in R right now so maybe @TeaganKing can help translate to python and incorporate into the current infrastructure?

[TeaganKing]

I'd certainly be happy to help generalize/translate this once we decide which direction we want to go!

[wwieder]

I'm so excited about this, @adrifoster Thanks!

I'm not sure it's worth reinventing the wheel if you have this working in R. These seem like preprocessing data that don't necessarily belong in the CTSM repo? It could live on the NEON side, which already includes scripts that pre-processes NEON meteorological and flux tower data for use in CLM. Could the output from your scripts generate (or modify) this (.csv file), which is already being used by this wrapper?

[adrifoster]

I'm not sure it's worth reinventing the wheel if you have this working in R. These seem like preprocessing data that don't necessarily belong in the CTSM repo? It could live on the NEON side, which already includes scripts that pre-processes NEON meteorological and flux tower data for use in CLM. Could the output from your scripts generate (or modify) this (.csv file), which is already being used by this wrapper?

Sure I think either way is fine.

[ekluzek]

Just to reinforce the idea of NOT converting from R to python -- let me throw in a little bit. In general we are supporting python for scripting, but it can sometimes make sense to use a different language. We do use some bash for example. And we still have a few things in NCL. It is important for availability to use a few language -- but R is also free. From what I remember @adrifoster you said you were using a module that was written in R for NEON work. This is a strong reason to use R, we shouldn't be rewriting NEON work in another language. If we could convince NEON to convert that would be one thing, but I don't think there's a strong enough reason to convince them to change either.

Since, it's reliant on NEON packages that's another strong reason that it could live on the NEON side. So I agree with Will on this that you should put this on the NEON side.

[adrifoster]

From what I remember @adrifoster you said you were using a module that was written in R for NEON work.

If we just use inventory data the only NEON API R function I'm using is to download the data so it probably isn't that crucial, but if we end up using the AOP data that changes things...

[adrifoster]

The REALLY ANNOYING THING we need to do first is to determine the PFTs for all the species at supported NEON sites (e.g. Quercus alba is a deciduous broadleaf tree, etc.) I'm not sure there is a way to do this in an automated/reproducible fashion, so if anyone has ideas please let me know.

[adrifoster]

Tagging @ckoven and @mpaiao as they are also interested in this work.