2024 was a relatively low-flowering year in the common gardens, but that doesn’t mean we didn’t bring plenty of Echinacea heads back to the lab for our volunteers! Here are our stats:
TOTAL: 689heads
exPt01: 82 heads (11.9%)
exPt02: 375 heads (54.4%)
exPt07: 87 heads (12.6%)
exPt08: 23 heads (3.3%)
exPt09: 110 heads (16.0%)
tplot: 12 heads (1.7%)
(rounding errors in %s abound)
Our first harvest was at p2, p7, and p9 on August 19th. Our last harvest was all the way on October 3rd at p7 and p9! Those hybrid plants really held on for awhile. Unfortunately, our first harvest was not in time to harvest some heads before they begin dispersing, and there are always a couple that lose achenes throughout the harvest season before we catch them. This year wasn’t toooo egregious, but our worst head lost an estimated 85% of its achenes before we encountered it. Yikes! Keep an eye out for seedlings around (7, 2) in p2…
A few achenes shy of a full head…
One major victory from this year is that, besides a couple holes and piles of dirt, the ground squirrels were relatively well behaved in p2 this year. Typically, they enjoy ripping heads off echinacea plants and leaving stems, heads, and achenes everywhere. Based on harvest notes, in 2024 we only found two heads on the ground and only one was missing entirely. Compare this to 2022, when the team only harvested 41% of the heads they planned on harvesting due to ground squirrel activity. (Though, I suspect this may have been a blessing—they still harvested 480 heads. If they’d harvested all of them, it would have been around 1,170 heads. That’s a lot of harvesting!)
Another fun fact: The 99 south garden in p1 produced 25 heads this year, but its 99 north counterpart didn’t have a single flowering plant.
Additionally, we did visit p5 this year and found several flowering (and some basal) plants, but were instructed not to harvest them, so we didn’t.
cg heads in the seed dryer prior to going through the ace process in the lab. It isn’t every year when almost all of your gBags fit in the seed dryer at once! I bet I could’ve made em all fit if I really squeezed them, but what’s the rush?
We still have a couple of gBags from 2023 to clean, plus 10 from this year. We like keeping our volunteers stocked! We’ll send exPt01 2024 through first, just after the remnant heads. And so the cycle continues!
The team has dwindled, and so has our progress on p1 this last month… With other priorities such as demo/surv and e-traps wrapping up in the next couple weeks, hopefully we can get back to it!
Members of Team Echinacea do a good job while measuring. Members of Team Echinacea are also humans (mostly, I think). We make mistakes! Maybe we searched for a plant that is there, but we couldn’t find it. Or maybe we had missteps while recording data. That’s why an essential part of our work each summer is identifying errors and inconsistencies in our database and then revisiting these in the field to check our work, as well as searching again for any plants we marked as can’t finds.
Thanks to the ghost of interns past, there is quite a bit of framework and functions that already exist to handle this work. It’s also a bit of a hodgepodge to keep track of, especially when you don’t have last year’s cg intern to show you around (we miss you Lindsey!) Here, I am documenting my personal journey in figuring out the who what when where why and hows of this process. I’ll continue updating this as I learn more.
Step 1: preRaw -> raw
The first step in the process is to take the data from the visors, which we call “preRaw” and turn it into a “raw” state that we can more easily work with. This is mostly a quality control step that a) formats the data how we like it and b) identifies and eliminates any carriage return issues that would be a source of head scratching down the line.
We do this step in a single script, but in separate steps for exPt08, exPt10, and then the rest of the plots as one. The same goes for the head data. Ideally, we would put in the work to combine all plots into one. Unfortunately there is a labor shortage, shall we say.
Next, we put the data through some more formatting tweaks. We also create a column called “recQ” (record quality) and tentatively mark every record we have as “good”. Any record with this field marked as “good” will be included in measureGood/plantAll_2024.txt and measureGood/headAll_2024.txt. Even prior to fixing errors, these can be useful in other processes, like setting up harvest.
That’s just the trick, isn’t it? There are a number of ways we go about getting good records. For some records, the mistake is obvious and easy to fix in R. When this is the case, you make the change in the offending column(s) directly in “pp” or “hh”, the plant and head measure data frames, respectively. If it’s as simple as updating plant status to basal, only the plant status field needs to be update and the recQ field remains set to good. If the entire record is bad, you can modify recQ to be something other than “good” to keep the record from being included in plantAll or headAll (e.g., “dup record”).
Other times, we have to revisit the location in the field. When this is the case, we identify the issue and change recQ from “good” to a descriptive note about the issue. For example, any issue that I feel is worthy of a revisit in the field, I make sure to change the recQ to “revisit; xxx” with “xxx” being a brief note about the issue. The hh df is special in that it also has an “auditNote” column, where you can add additional notes about any issues. I’m not sure why this is exclusive to the head data.
Some ways we identify issues:
compare2vectors()
Ol’ reliable. I use this first thing to compare the cgPlaIds that are in the plot (use getPlaIds(), but don’t forget to add Amy’s annex in p1. side note, add Amy’s annex to getPlaIds()) to cgPlaIds we have measure records for (in pp)
This alerts me of any records missing and any dups
compareStatusToPrior()
Location: ~/functions.R
specific to plantMeasure
This function, when assigned to a variable, spits out a list of many things and is very useful in identifying errors. It compares the status of the plant this year to the previous year’s and points out when there are issues. As far as I can tell, it only pulls records from pp that have a “good” recQ, so once you make updates you no longer see them pop up as errors here
Some of the list items I’ve used (or seen others use):
$summary.df
summarizes all the varying combinations of prior and current statuses (referred to as “conditions”) and labels them as either an error (TRUE), not an error (FALSE) or NA (probably an error? Look into this if you encounter it).
$plaIdsByCondition
Lists which plaIds have which condition. I found it useful for finding plaIds with conditions that were labeled NA in summary.df
$search0.err
Contains a list of cgPlaIds whose records certainly have errors (were labeled as TRUE in summary.df)
This can be used to easily fix or otherwise modify records that need it
There are a bunch of other list items that I have not encountered in use yet
Where we go about the process of comparing plant data to the corresponding head data, or lack thereof.
Sets up plant and head data to be put through function compareMeasureAndHeadRecords()
Function source: ~/cgData/summer2022/makeFunctionCompareMeasureAndHeadRecord.R
Maybe we could move this into functions.R
Some issues identified with this function require returning to pp in makeGood to fix issues.
Others require fieldwork. The script produces 2 csvs (called datasheets in the script) to assist with this fieldwork. Notes taken on these datasheets in the field can be used to update pp or hh in makeGood. Datasheet examples:
Checks to see if any leaves are suspiciously long or if counts are suspiciously high
The end goal of this process is also a csv datasheet to return to the plot to record the correct info and then fix it directly in pp. When I did p2, there was no infrastructure to make this datasheet and it looked like Lindsey may have just run the code here and then run the code over in makeLfErrorChecker.R (next bullet) without clearing the environment. Maybe not up to code but this is what I did too. That makes just one datasheet for the two scripts, which is more convenient in the field. Seems like these two could be wrapped into one script.
How we check any issues that could be associated with leaf data, primarily checks for any missing or illogical data (e.g., cauline leaf is not recorded for a flowering plant or cauline leaf is recorded for a basal plant)
This script also produces a csv datasheet that is put into dropbox. We can use this datasheet to collect the correct data in the field and then make the updates directly to pp. Example:
The team takes its first steps into measuring experimental plot 1
Friday, 26 July, 2024, was the first day we started measuring p1 this year! Coincidentally, this was the same day we started last year. This monumental task involves visiting 10992 positions in the plot and assessing the status of the plants there (or not, in the case of plants we have not been able to find in >3 years. RIP. Presumably.) After measuring again this morning, I booted up the old progress tracker (in the cgData repo, if you ever need it) to see how we’re doing. After making some adjustments (for the colorblind out there), here’s our progress over the last two days:
A map of every position in p1. Every position we have visited so far is colored in purple. On Friday, we were 8.1% done with measuring the plot. After today, we jumped up to 23.8% done. Rounding up, that’s about a quarter of the plot done already! Yahoo!
Today was also RET Brittany’s last day with the field team. Brittany, you will be sorely missed, and we hope you bring a bit of the prairie to share with your students!
Brittany evaluates Heterostipa spartea reproduction in p1
