Currently, I’m writing this from my new apartment in Chicago! Classes start next week for me, and I’m moving on to the data management portion of my summer project. This summer, I looked at pollen and nectar quantity in Coreopsis palmata (prairie coreopsis) in burned vs. unburned sites. But why does this matter? Pollinators depend on pollen and nectar from flowers to supply the nutrients they need to survive. However, there has yet to be a strong comparison between common Asteraceae plants identifying the quantity and quality of plants that can be shared with land managers to help create more viable resources for pollinators in their prairie restoration efforts. Therefore, I wanted to conduct a study looking at pollen and nectar quantity in common non-Echinacea prairie plants to examine how prescribed fire affects plant resources for pollinators.
The sites I collected data from included Torgeson North and South, Tower and Nice Island, and Yellow Orchid Hill West. Pollen data was collected by selecting three immature florets from three flower heads in a “patch,” defined as five or more stems in one central location. These immature florets will then go through a lab process where they are sliced open and placed into an agar solution, allowing the pollen to float to the top, where it can be counted. Nectar collection was done using microcapillary tubes, where we measured the amount of nectar in each tube in millimeters. The volume of nectar can then be calculated based on the size of the microcapillary tube in relation to the measurement in millimeters obtained from the tube. In total, I had around 75 pollen and nectar measurements. I also collected transect density data for each “patch” that we sampled and mapped them in Avenza for future reference. This allows me to identify and see how dense the populations are within a certain site, and to determine if there is a difference between burned vs. unburned areas.
I was not able to study more than one species this summer, but we shall see what the next summer holds!
NOTE: Funding for this project was provided by the Minnesota Environment and Natural Resources Trust Fund as recommended by the Legislative-Citizen Commission on Minnesota Resources (LCCMR).
Team Echinacea finished Total Demo today! That was a big undertaking. We visited 2640 locations to search for Echinacea plants in our remnant sites. But we’re not done with our remnants yet. Today we started de-mopup or demopup. In the likely event that we missed a few flowering Echinacea, we revisit each site to do a thorough search. I am not sure if we are as thorough as this AI puppy mopping the floor, but we strive to find the Echinacea Plants that no one else will find.
Hailey hand pollinated flowers on six silver-leaf scurf pea plants (Pediomelum argophyllum). We are harvesting the plants as the pods ripen. Wyatt harvested two plants on 30 Aug, I harvested two today (9 Sept). Two remain–each is attached to a pin flag so it doesn’t tumble way. But don’t seem like that will happen soon.
Yesterday I squeezed every pod from the plant that Wyatt harvested S of 23518-L. They all felt the same (empty), including the treatment pods that have yellow & blue twist-ties. Many of the pods had fallen off the stem, but not the bagged one. This time I gently put the entire plant into a large paper grocery bag to keep the pods on the stems. I regret i didn’t take any photos of the plants.
Stay tuned to learn about effects of hand pollination on seed set in the silver leaf scurf pea!
Let’s consult our total demometer to see how much progress we’ve made. The team has tackled some large sites in the past few weeks. We’ve made lots of progress! We’re about 45% done with all locs.
Throughout this summer Stuart, Jared, and I have been discussing the possibility of a new addition to the production plots at the Hjelm. The main goal was to create a production plot for the Prairie Violet. It is a notoriously difficult species to collect seed for in the wild due to its relatively early seed set period and its tendency for seed pods to burst open and scatter seeds the moment they are ripe. Our first obstacle was determining exactly how we wanted to get local viola plants. Would we need to be exhaustive in harvesting local seeds and sprouting them; could we attempt to propagate from cuttings; or were transplants our best course of action? After some discussion and reaching out to the Chicago Botanical Garden we found that cuttings weren’t a good option and attempt to harvest and sprout seed was going to be too difficult and possibly provide low yields. Next, we worked on sourcing a growing vessel that will prevent weeds while providing well-draining soil, perfect for the violets. An old cattle trough from a local farmer was the perfect solution.
Holes were drilled and a piece of drain tile was placed inside of the bottom the planter to allow drainage. and then the clay-rich soil that was dug up to level the bed was used to fill the first 1/3 of the planter. Weed free garden soil and washed sand was then mixed approximately 1:1 to fill the rest of the bed with high quality soil that will drain enough for the violets. On Aug 7th Starting at around 6:45 am Stuart and I both went out to collect violets from 5 different sites we had determined to be good host sites. Five plants were taken with each being at least 5 meter away from each other per site. We then recorded the gps postion of the collection point and gave each violet a number to identify it.
Once all the violets were collected a random position was chosen for each plant to ensure fair representation per site. And then finally we could plant each violet after washing its roots to ensure no weeds become established.
Now have a finished production Plot full of V. pedatifida that seem to be doing well only a few weeks on and some are already producing new leaves a good sign they are enjoying their new home.
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:
