Zobitz modifications

Here is a quick rundown of what I have done:
- Added MODIS satellite fAPAR data as a co-constraint with NEE data at Niwot. I am currently investigating if this improves the parameter estimation and what effect it has on the results. Code mofidications included a change in the variables to estimate, as well as additional columns in .data and .valid files.
- Added a new tracker variable (meanDLight), which computes the running average of the fractional light multiplier (Dlight) over 8 days, which I then compare against measured fAPAR data.
- Implemented a "weighted likelihood" cost function, where each assimilated data stream is multiplied by a fraction from 0 to 1. I did this because I wanted to determine how much the parameter estimation improves by including (or not including) a particular data stream.
- Concurrent with this approach, I did a tweak on the code to show the likelihood for each particular data stream by running sipnet forward over input data.

--> Any of these changes worth merging to the main code?

The benevolent branch czar

This should beg the question (this may already be answered, so I apologize if I am out of the loop) - when we make changes to SIPNET code to suit a particular research question, by what process should we decide to merge those changes into the code repository? Should we all comment on the blog, and if we all say "yes - that would be helpful for us all", then merge appropriately? While I know we are all doing good things with SIPNET, running all these parallel threads might not match well when merged together in the repository (it has happened before), potentially losing the "SI" in SIPNET.

Can we come to a consensus on a "core" SIPNET model? I am not well-versed enough in programming to know what would the appropriate code-development scheme would be to all of our multiple research threads. I don't think having branches from the repository with our own code tweaks would be useful - it seems that we would have multiple copies of very similar code. Maybe a sort of "plug - in" scheme, where each thread has a few base files that are plugged into the model, and maybe supersedes conflicting code. That way it could be easier to distinguish between all our different changes.

Branch projects

To my knowledge the branch projects are

1) Multiple data streams with explicit consideration of data error (Dave plus Howland group)
2) Capability of assimilating remote sensing data (Zobitz plus Tris and Ankur)
3) Multiple formulations of the cost function (Dave plus Howland group)

We are also using the model spatially explicit option (put together by Bill) for the ACME project over the Rocky Mountains - there is no particular change to the code for this project - it simply requires an adjusted file arrangement

Are there any other branches that could be added to this?
Are there any new features to the code that you think should be added to the core code?

Dave