search

ddalthorp / GenEst

R package development for a generalized mortality estimator
Other
6 stars 6 forks source link

per turbine / per MW / per unit area estimates #515

Closed prabie closed 6 years ago

prabie commented 6 years ago

Need to translate our estimate of fatality into a per turbine / per MW or per unit area rate, with confidence bounds.

ddalthorp commented 6 years ago

This assumes that units are inherently compatible and comparable, e.g., individual turbines. But other kinds of units may not be (e.g., even at a wind farm 'unit' doesn't have to be a turbine, and at a solar facility 'units' may not be similar). Should we leave it up to users to translate results into per unit or per turbine if they desire?

prabie commented 6 years ago

I think it's a mistake to close this. To be clear, WEST will continue to make the translation and where appropriate, provide the necessary caveats. But I've already had clients ask me why GenEst is not producing per-MW estimates.

I'd rather see us give users a check-box option to produce the per-unit estimate and then provide the necessary caveats. If we don't we have an estimator that produces estimates that are fundamentally different from what most people are used to looking at for standard PCM studies.

For those jurisdictions that do have AM thresholds for all bats (eg Ontario & a couple of the other CA provinces), they are in terms of per turbine or per MW fatality rates.

Estimating only bulk M also hinders comparability. Project X killed 1k birds and project y killed 500 birds. From a population impact perspective, the difference is meaningful. From a cost-benefit analysis, it also matters that project X was 1200 MW and project Y was 500 MW. Or maybe they have the same # MW but one is a power tower and one is PV. Per unit fatality, even averaged over units that are inherently different, provides important information to assess policy goals.

Stantec produces per turbine, per MW and per facility estimates (https://www.fws.gov/midwest/endangered/permits/hcp/wildcat/pdf/2017PCMMReport_WildcatWindFarm.pdf)

Tetra Tech produces per turbine and per MW estimates (http://wintuaudubon.org/Documents/HatchetRidgeYear2FinalReport3-13.pdf)

HT Harvey produces per turbine and per facility estimates (https://admin.solanocounty.com:4433/civicax/filebank/blobdload.aspx?blobid=17153)

NRSI produces per turbine and per MW estimates (http://ontario-wind-resistance.org/wp-content/uploads/2011/09/nrsi_0953c_harrow-2010-post-construction-report_2011_08_04.pdf)

And at the end of the day, I've never heard a discussion of all-bat or all-bird fatality rates at wind facilities that relied on per-facility estimates. For solar, yes, sometimes, on a per-facility basis.

ddalthorp commented 6 years ago

I'm sorry, Paul. I didn't mean to close this on you. I was trying to raise a question for discussion, and then auto-piloted to the "close and comment" button since that was the rhythm I was in...

I don't have much of an issue with per MW in general. It's a rational stab at standardization, which makes sense. The problem I have is that GenEst doesn't know what MW or a turbine is. For example, suppose one analysis splits mortality by sector (NW, SE, central, remote, etc.) at a site. Or a split by season. Or, or or...How to properly allocate the MW among the subgroups? I don't think we can anticipate the kinds of summaries someone will want. Also, what IS a MW? Nameplate? Actual power production?

mintzj commented 6 years ago

Hi folks, I've been out of the loop recently but here's one idea on how you could address it:

Suppose we add an additional file, similar to the Search Schedule, which contains the power associated with each unit during that period of monitoring.

This would complement the way we currently handle data, and allow us to do various splits on it. I also think this sort of formatting of power data is fairly common (I'm thinking of the per unit summaries of SCADA files I received from power companies in the past).

mintzj commented 6 years ago

For example, here's an excerpt from our search schedule for power towers:

image

Imagine that same file, but with 1/0 replaced by kw over that day. That'd allow us to put 0 if if a unit were offline, or doesn't produce power (such as a transmission line).

Also, if we are only interested in the power produced by the units we surveyed, on the days they were surveyed, we'd be able to match it with the survey schedule from the SS file.

mhuso commented 6 years ago

Paul, I think this is a topic we discussed pretty extensively during one of our calls - exactly how to output mortality estimates. My notes say it was May 16, but we might have discussed since then as well. I believe we all agreed that our job was to estimate the number of fatalities that occurred at a site during the monitoring period. To standardize for the size of the site (in terms of MW capacity, physical area (solar) or any other measure) or fraction of year monitored, the adjustments would best be left to the user. I understand that many people have now begun to use fatalities/nameplate capacity as a standardizing metric. But we all know that two facilities with the same MW capacity can produce radically different amount of energy - a difference captured in their capacity factor. The idea behind standardizing by capacity is to put these estimates into a societally-relevant context, which I think is appropriate. But MW capacity won't do it for us. The societally relevant metric is deaths/power produced, not deaths per hypothetical capacity to produce power. If users feel that it is an appropriate thing for them, then it should be easy for them to take our reported totals and divide by a relevant number. It doesn't seem necessary to add a button for them to click so that we do it for them. The actual implementation of this becomes a bit sticky. We allow users to split on any number of factors, e.g., species. If 3 eagles were found at 3 2.5 MW turbines at a site with 50 2.5MW and 50 1.5 MW would we need to divide our M-hat for eagles by 125 or by 200? This is just a silly example of the kinds of decisions we can't make for the user. These are best left to them to decide, not us. Our estimator applies to much more than wind and even solar. It can (and should) be used for estimating fatality from oil spills, or from electrocution or from power line collisions, none of which would be standardized by MW capacity.

prabie commented 6 years ago

Manuela, I agree that actual production would be a much better metric than nameplate. But actual production is usually top-secret (I was really amazed when the Genesis manager gave that info up without blinking when you asked, a couple years ago).

Your points about the potential for nonsensical estimates and the potential for GenEst to inform more than renewable energy are also well taken, but I think we need to give a nod to established precedent in the wind PCM community because they are (for now) our biggest audience.

As a compromise, could we put some language in the documentation (and maybe even near the estimates in the GUI) that says that if you want to scale the estimates & confidence bounds to a per-unit basis, and if it is appropriate to make the assumption that your units are identical in their lethality, then you can scale the estimates and confidence bounds in a linear way?

ddalthorp commented 6 years ago

A note in the User Guide is a great idea. Can you insert a draft, Paul?

mhuso commented 6 years ago

I agree. I think it is important that we address it directly in the User Guide. In the same section we should also address extrapolating to a full year. For some species and environments and monitoring periods an assumption of 0 outside the monitored period is defensible. For others it is not. Yet the standardization to a specific time period is as necessary as standardization to some measure of power production.

ddalthorp commented 6 years ago

I like the analogy.

prabie commented 6 years ago

Group, see what you think of this. I suggest it become section 3.4.1.2, right after the splitting Mortality Estimates section.

3.4.1.2 Scaling Mortality Estimates

        GenEst provides mortality estimates for the whole facility over

the period during which sampling occurred. Users may desire to scale the mortality estimates to represent mortality on a per megawatt, per turbine, per PV-array, per-unit-area or other basis, or users may desire to scale mortality estimates to represent a more expansive period of time than was covered by the sampling period. In either case, both the point estimate and the confidence bounds of mortality can be scaled directly to represent a convenient unit for a mortality rate. For example, suppose sampling occurred at a 200 MW facility during three summer months, and that there are data to suggest that 80% of all bat mortality occurs during the three-month sampling period. Suppose that the total mortality estimate is 1789 bats with a 95% confidence interval of (1587, 2001) bats. Then the summertime per MW estimate is 1789 / 200 = 8.95 bats per MW with a 95% confidence interval of (1587 / 200, 2001 / 200) = (7.94, 10.00) bats per MW. And considering that summer time represents 80% of the total bat mortality, scaling to represent the entire year is accomplished by dividing the estimate and confidence bounds through by 0.8: 8.95 / 0.8 = 11.2 bats per MW per year with a 95% confidence interval of (7.94 / 0.8, 10.00 / 0.8) = (9.9, 12.5) bats per MW per year.

        Users who choose to scale their estimates should take care to

ensure that the assumptions inherent to scaling are valid. For example, a three-month sampling interval for bats may represent 80% of the bat mortality but may represent 25% of the mortality for a resident, winter-active species of bird. Similarly, it may be convenient to scale a wind-facility’s mortality to an overall per-MW basis for comparison to other wind facilities, but that same overall per-MW metric might not be well-suited for making adaptive management decisions if there is variability among turbines within the facility based on habitat context or turbine type.

Western EcoSystems Technology, Inc. Environmental & Statistical Consultants 200 S. Second Street Laramie, WY 82070 307-755-9447 www.west-inc.com

Follow WEST: Facebook http://www.facebook.com/pages/Western%E2%80%90EcoSystems%E2%80%90Technology%E2%80%90WESTInc/125604770807646 , Twitter http://twitter.com/WestEcoSystems, Linked In http://www.linkedin.com/company/1458419, Join our Mailing list http://visitor.r20.constantcontact.com/manage/optin/ea?v=001qrD4A3S5xJ5KgMyelH9jyw%3D%3D

CONFIDENTIALITY NOTICE: This message and any accompanying communications are covered by the Electronic Communications Privacy Act, 18 U.S.C. §§ 2510-2521, and contain information that is privileged, confidential or otherwise protected from disclosure. If you are not the intended recipient or an agent responsible for delivering the communication to the intended recipient, you are hereby notified that you have received this communication in error. Dissemination, distribution or copying of this e-mail or the information herein by anyone other than the intended recipient, or an employee or agent responsible for delivering the message to the intended recipient, is prohibited. If you have received this communication in error, please notify us immediately by e-mail and delete the original message. Thank you.

P Please consider the environment before printing.

On Fri, Sep 21, 2018 at 1:48 PM Manuela Huso notifications@github.com wrote:

I agree. I think it is important that we address it directly in the User Guide. In the same section we should also address extrapolating to a full year. For some species and environments and monitoring periods an assumption of 0 outside the monitored period is defensible. For others it is not. Yet the standardization to a specific time period is as necessary as standardization to some measure of power production.

— You are receiving this because you modified the open/close state. Reply to this email directly, view it on GitHub https://github.com/ddalthorp/GenEst/issues/515#issuecomment-423651759, or mute the thread https://github.com/notifications/unsubscribe-auth/Acw22rRLHsTimsSK3Rl0-woQ4DybEs2Wks5udUKWgaJpZM4WjvQE .

mhuso commented 6 years ago

Clear and concise. I like it. Just a few minor edits in red below

Thank you, Paul!

Manuela

< :: >< :: >< :: >< :: >< :: >< :: >< :: >< :: >< :: >< :: >< :: >< :: >< :: >< :: ><

< :: >< :: >< :: >< :: >< :: >< :: >< :: >< :: >< :: >< :: >< :: >< :: >< :: >< :: ><

Manuela Huso Research Statistician USGS Forest and Rangeland Ecosystem Science Center Forest Sciences Lab, Rm 156 3200 SW Jefferson Way Corvallis, OR 97331 ph: 541-750-0948 cell: 541-760-8520 mhuso@usgs.gov

http://usgs.gov/fresc

From: Paul A. Rabie notifications@github.com Sent: Tuesday, September 25, 2018 8:30 AM To: ddalthorp/GenEst GenEst@noreply.github.com Cc: Manuela Huso mhuso@usgs.gov; Comment comment@noreply.github.com Subject: [EXTERNAL] Re: [ddalthorp/GenEst] per turbine / per MW / per unit area estimates (#515)

Group, see what you think of this. I suggest it become section 3.4.1.2, right after the splitting Mortality Estimates section.

3.4.1.2 Scaling Mortality Estimates

GenEst provides mortality estimates for the whole facility over the period during which sampling occurred. Users may desire to scale the mortality estimates to represent mortality on a per megawatt, per turbine, per PV-array, per-unit-area or other basis, or users may desire to scale mortality estimates to represent a more expansive period of time than was covered by the sampling period. In either case, both the point estimate and the confidence bounds of mortality can be scaled directly to represent a convenient unit for a mortality rate. For example, suppose sampling occurred at a 200 MW facility during three summer months, and that there are data to suggest that 80% of all bat mortality at this site occurs during the three-month sampling period. Suppose that the total mortality estimate is 1789 bats with a 95% confidence interval of (1587, 2001) bats. Then the summertime per MW estimate is 1789 / 200 = 8.95 bats per MW with a 95% confidence interval of (1587 / 200, 2001 / 200) = (7.94, 10.00) bats per MW. And considering that at this site summer time represents 80% of the total bat mortality, scaling to represent the entire year is accomplished by dividing the estimate and confidence bounds through by 0.8: 8.95 / 0.8 = 11.2 bats per MW per year with a 95% confidence interval of (7.94 / 0.8, 10.00 / 0.8) = (9.9, 12.5) bats per MW per year.

Users who choose to scale their estimates should take care to ensure that the assumptions inherent to scaling are valid. For example, a three-month sampling interval for bats may represent 80% of the bat mortality but may represent 25% of the mortality for a resident, winter-active species of bird. Similarly, it may be convenient to scale a wind-facility’s mortality to an overall per-MW basis for comparison to other wind facilities, but that same overall per-MW metric might not be well-suited for making adaptive management decisions if there is variability among turbines within the facility based on habitat context or turbine type.

Western EcoSystems Technology, Inc. Environmental & Statistical Consultants 200 S. Second Street Laramie, WY 82070 307-755-9447 www.west-inc.com

Follow WEST: Facebook < http://www.facebook.com/pages/Western%E2%80%90EcoSystems%E2%80%90Technology%E2%80%90WESTInc/125604770807646

, Twitter http://twitter.com/WestEcoSystems, Linked In http://www.linkedin.com/company/1458419, Join our Mailing list < http://visitor.r20.constantcontact.com/manage/optin/ea?v=001qrD4A3S5xJ5KgMyelH9jyw%3D%3D

CONFIDENTIALITY NOTICE: This message and any accompanying communications are covered by the Electronic Communications Privacy Act, 18 U.S.C. §§ 2510-2521, and contain information that is privileged, confidential or otherwise protected from disclosure. If you are not the intended recipient or an agent responsible for delivering the communication to the intended recipient, you are hereby notified that you have received this communication in error. Dissemination, distribution or copying of this e-mail or the information herein by anyone other than the intended recipient, or an employee or agent responsible for delivering the message to the intended recipient, is prohibited. If you have received this communication in error, please notify us immediately by e-mail and delete the original message. Thank you.

P Please consider the environment before printing.

On Fri, Sep 21, 2018 at 1:48 PM Manuela Huso notifications@github.com wrote:

I agree. I think it is important that we address it directly in the User Guide. In the same section we should also address extrapolating to a full year. For some species and environments and monitoring periods an assumption of 0 outside the monitored period is defensible. For others it is not. Yet the standardization to a specific time period is as necessary as standardization to some measure of power production.

— You are receiving this because you modified the open/close state. Reply to this email directly, view it on GitHub https://github.com/ddalthorp/GenEst/issues/515#issuecomment-423651759, or mute the thread < https://github.com/notifications/unsubscribe-auth/Acw22rRLHsTimsSK3Rl0-woQ4DybEs2Wks5udUKWgaJpZM4WjvQE

.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/ddalthorp/GenEst/issues/515#issuecomment-424388026, or mute the thread https://github.com/notifications/unsubscribe-auth/AcwzA-aCTlSMUrOSG73axMJf1SuuO8hBks5uekvagaJpZM4WjvQE .[image: Image removed by sender.]

ddalthorp commented 6 years ago

Thanks, Paul! This is great.

A concern I have is that although MW scaling is somewhat like converting from feet to meters to make comparisons meaningful (as long as you don't take the scaling too seriously), a temporal extrapolation is a different bear.

ddalthorp commented 6 years ago

How about something like this?

3.4.1.2 Scaling Mortality Estimates GenEst provides raw mortality estimates for the whole facility or for user-specified splits of the facility (for example by sector, turbine type, visibility class, habitat type, or other factor) for the period of time spanned by the monitoring. Users may scale the mortality estimates to represent mortality on a per megawatt, per turbine, per PV-array, per-unit-area or other basis, by multiplying the point estimate and confidence bounds of mortality by the appropriate scaling factor to represent a convenient unit for reporting a mortality rate. For example, if mortality was estimated to be 67 with a CI of [41, 93] at a 50 MW site, the scaled mortality would be 1.34 with a CI of [0.82, 1.86]. It must be cautioned that such a scaled estimate is a convenience for comparison to other wind facilities, but that same overall per-MW metric might not be well-suited for making adaptive management decisions if there is variability among turbines within the facility based on habitat context or turbine type. In addition, smaller sites will tend to have larger scaled variances than larger sites with comparable mortality rates per MW.

Extrapolation beyond the monitored period can be done via adjusting the "Sampling Fraction" parameter. For example, if it is assumed that at this site summer time represents 80% of the total bat mortality, scaling to represent the entire year is accomplished by entering 0.8 as the sampling fraction and re-running the analysis (or entering, for example, 0.4 = 0.8 * 0.5 if the sampling fraction was 0.5 in the original analysis). This extrapolation should be interpreted with caution because it is based on the assumption that the fraction of mortality occurring outside the monitored period is known with certainty. There are some additional complications as well. For example, a three-month sampling interval may represent 80% of the bat mortality but only 25% of the mortality for a resident, winter-active species of bird.

prabie commented 6 years ago

I can live with that. I would exclude the sentence below because although it is a statistical reality and will come in to play for scaled estimates, it's probably just distracting to a user trying to figure out what is and is not appropriate to do with their estimates:

In addition, smaller sites will tend to have larger scaled variances than larger sites with comparable mortality rates per MW.

Western EcoSystems Technology, Inc. Environmental & Statistical Consultants 200 S. Second Street Laramie, WY 82070 307-755-9447 www.west-inc.com

Follow WEST: Facebook http://www.facebook.com/pages/Western%E2%80%90EcoSystems%E2%80%90Technology%E2%80%90WESTInc/125604770807646 , Twitter http://twitter.com/WestEcoSystems, Linked In http://www.linkedin.com/company/1458419, Join our Mailing list http://visitor.r20.constantcontact.com/manage/optin/ea?v=001qrD4A3S5xJ5KgMyelH9jyw%3D%3D

CONFIDENTIALITY NOTICE: This message and any accompanying communications are covered by the Electronic Communications Privacy Act, 18 U.S.C. §§ 2510-2521, and contain information that is privileged, confidential or otherwise protected from disclosure. If you are not the intended recipient or an agent responsible for delivering the communication to the intended recipient, you are hereby notified that you have received this communication in error. Dissemination, distribution or copying of this e-mail or the information herein by anyone other than the intended recipient, or an employee or agent responsible for delivering the message to the intended recipient, is prohibited. If you have received this communication in error, please notify us immediately by e-mail and delete the original message. Thank you.

P Please consider the environment before printing.

On Tue, Sep 25, 2018 at 10:43 AM ddalthorp notifications@github.com wrote:

How about something like this?

3.4.1.2 Scaling Mortality Estimates GenEst provides raw mortality estimates for the whole facility or for user-specified splits of the facility (for example by sector, turbine type, visibility class, habitat type, or other factor) for the period of time spanned by the monitoring. Users may scale the mortality estimates to represent mortality on a per megawatt, per turbine, per PV-array, per-unit-area or other basis, by multiplying the point estimate and confidence bounds of mortality by the appropriate scaling factor to represent a convenient unit for reporting a mortality rate. For example, if mortality was estimated to be 67 with a CI of [41, 93] at a 50 MW site, the scaled mortality would be 1.34 with a CI of [0.82, 1.86]. It must be cautioned that such a scaled estimate is a convenience for comparison to other wind facilities, but that same overall per-MW metric might not be well-suited for making adaptive management decisions if there is variability among turbines within the facility based on habitat context or turbine type. In addition, smaller sites will tend to have larger scaled variances than larger sites with comparable mortality rates per MW.

Extrapolation beyond the monitored period can be done via adjusting the "Sampling Fraction" parameter. For example, if it is assumed that at this site summer time represents 80% of the total bat mortality, scaling to represent the entire year is accomplished by entering 0.8 as the sampling fraction and re-running the analysis (or entering, for example, 0.4 = 0.8 * 0.5 if the sampling fraction was 0.5 in the original analysis). This extrapolation should be interpreted with caution because it is based on the assumption that the fraction of mortality occurring outside the monitored period is known with certainty. There are some additional complications as well. For example, a three-month sampling interval may represent 80% of the bat mortality but only 25% of the mortality for a resident, winter-active species of bird.

— You are receiving this because you modified the open/close state. Reply to this email directly, view it on GitHub https://github.com/ddalthorp/GenEst/issues/515#issuecomment-424414255, or mute the thread https://github.com/notifications/unsubscribe-auth/Acw22uvedVMVkUsrBxtMdKeSogYP8mAxks5uel0qgaJpZM4WjvQE .

prabie commented 6 years ago

I guess if we suggest using the sampling fraction to adjust the estimate we should also mention it in the sampling fraction section.

Western EcoSystems Technology, Inc. Environmental & Statistical Consultants 200 S. Second Street Laramie, WY 82070 307-755-9447 www.west-inc.com

Follow WEST: Facebook http://www.facebook.com/pages/Western%E2%80%90EcoSystems%E2%80%90Technology%E2%80%90WESTInc/125604770807646 , Twitter http://twitter.com/WestEcoSystems, Linked In http://www.linkedin.com/company/1458419, Join our Mailing list http://visitor.r20.constantcontact.com/manage/optin/ea?v=001qrD4A3S5xJ5KgMyelH9jyw%3D%3D

CONFIDENTIALITY NOTICE: This message and any accompanying communications are covered by the Electronic Communications Privacy Act, 18 U.S.C. §§ 2510-2521, and contain information that is privileged, confidential or otherwise protected from disclosure. If you are not the intended recipient or an agent responsible for delivering the communication to the intended recipient, you are hereby notified that you have received this communication in error. Dissemination, distribution or copying of this e-mail or the information herein by anyone other than the intended recipient, or an employee or agent responsible for delivering the message to the intended recipient, is prohibited. If you have received this communication in error, please notify us immediately by e-mail and delete the original message. Thank you.

P Please consider the environment before printing.

On Tue, Sep 25, 2018 at 10:43 AM ddalthorp notifications@github.com wrote:

How about something like this?

3.4.1.2 Scaling Mortality Estimates GenEst provides raw mortality estimates for the whole facility or for user-specified splits of the facility (for example by sector, turbine type, visibility class, habitat type, or other factor) for the period of time spanned by the monitoring. Users may scale the mortality estimates to represent mortality on a per megawatt, per turbine, per PV-array, per-unit-area or other basis, by multiplying the point estimate and confidence bounds of mortality by the appropriate scaling factor to represent a convenient unit for reporting a mortality rate. For example, if mortality was estimated to be 67 with a CI of [41, 93] at a 50 MW site, the scaled mortality would be 1.34 with a CI of [0.82, 1.86]. It must be cautioned that such a scaled estimate is a convenience for comparison to other wind facilities, but that same overall per-MW metric might not be well-suited for making adaptive management decisions if there is variability among turbines within the facility based on habitat context or turbine type. In addition, smaller sites will tend to have larger scaled variances than larger sites with comparable mortality rates per MW.

Extrapolation beyond the monitored period can be done via adjusting the "Sampling Fraction" parameter. For example, if it is assumed that at this site summer time represents 80% of the total bat mortality, scaling to represent the entire year is accomplished by entering 0.8 as the sampling fraction and re-running the analysis (or entering, for example, 0.4 = 0.8 * 0.5 if the sampling fraction was 0.5 in the original analysis). This extrapolation should be interpreted with caution because it is based on the assumption that the fraction of mortality occurring outside the monitored period is known with certainty. There are some additional complications as well. For example, a three-month sampling interval may represent 80% of the bat mortality but only 25% of the mortality for a resident, winter-active species of bird.

— You are receiving this because you modified the open/close state. Reply to this email directly, view it on GitHub https://github.com/ddalthorp/GenEst/issues/515#issuecomment-424414255, or mute the thread https://github.com/notifications/unsubscribe-auth/Acw22uvedVMVkUsrBxtMdKeSogYP8mAxks5uel0qgaJpZM4WjvQE .

mhuso commented 6 years ago

It sounds like you couldn’t see my edits. Here in image format:

< :: >< :: >< :: >< :: >< :: >< :: >< :: >< :: >< :: >< :: >< :: >< :: >< :: >< :: ><

< :: >< :: >< :: >< :: >< :: >< :: >< :: >< :: >< :: >< :: >< :: >< :: >< :: >< :: ><

Manuela Huso Research Statistician USGS Forest and Rangeland Ecosystem Science Center Forest Sciences Lab, Rm 156 3200 SW Jefferson Way Corvallis, OR 97331 ph: 541-750-0948 cell: 541-760-8520 mhuso@usgs.gov

http://usgs.gov/fresc

From: Manuela Huso mhuso@usgs.gov Sent: Tuesday, September 25, 2018 9:02 AM To: 'ddalthorp/GenEst' < reply@reply.github.com>; 'ddalthorp/GenEst' GenEst@noreply.github.com Cc: 'Comment' comment@noreply.github.com Subject: RE: [EXTERNAL] Re: [ddalthorp/GenEst] per turbine / per MW / per unit area estimates (#515)

Clear and concise. I like it. Just a few minor edits in red below

Thank you, Paul!

Manuela

< :: >< :: >< :: >< :: >< :: >< :: >< :: >< :: >< :: >< :: >< :: >< :: >< :: >< :: ><

< :: >< :: >< :: >< :: >< :: >< :: >< :: >< :: >< :: >< :: >< :: >< :: >< :: >< :: ><

Manuela Huso Research Statistician USGS Forest and Rangeland Ecosystem Science Center Forest Sciences Lab, Rm 156 3200 SW Jefferson Way Corvallis, OR 97331 ph: 541-750-0948 cell: 541-760-8520 mhuso@usgs.gov

http://usgs.gov/fresc

From: Paul A. Rabie notifications@github.com Sent: Tuesday, September 25, 2018 8:30 AM To: ddalthorp/GenEst GenEst@noreply.github.com Cc: Manuela Huso mhuso@usgs.gov; Comment comment@noreply.github.com Subject: [EXTERNAL] Re: [ddalthorp/GenEst] per turbine / per MW / per unit area estimates (#515)

Group, see what you think of this. I suggest it become section 3.4.1.2, right after the splitting Mortality Estimates section.

3.4.1.2 Scaling Mortality Estimates

GenEst provides mortality estimates for the whole facility over the period during which sampling occurred. Users may desire to scale the mortality estimates to represent mortality on a per megawatt, per turbine, per PV-array, per-unit-area or other basis, or users may desire to scale mortality estimates to represent a more expansive period of time than was covered by the sampling period. In either case, both the point estimate and the confidence bounds of mortality can be scaled directly to represent a convenient unit for a mortality rate. For example, suppose sampling occurred at a 200 MW facility during three summer months, and that there are data to suggest that 80% of all bat mortality at this site occurs during the three-month sampling period. Suppose that the total mortality estimate is 1789 bats with a 95% confidence interval of (1587, 2001) bats. Then the summertime per MW estimate is 1789 / 200 = 8.95 bats per MW with a 95% confidence interval of (1587 / 200, 2001 / 200) = (7.94, 10.00) bats per MW. And considering that at this site summer time represents 80% of the total bat mortality, scaling to represent the entire year is accomplished by dividing the estimate and confidence bounds through by 0.8: 8.95 / 0.8 = 11.2 bats per MW per year with a 95% confidence interval of (7.94 / 0.8, 10.00 / 0.8) = (9.9, 12.5) bats per MW per year.

Users who choose to scale their estimates should take care to ensure that the assumptions inherent to scaling are valid. For example, a three-month sampling interval for bats may represent 80% of the bat mortality but may represent 25% of the mortality for a resident, winter-active species of bird. Similarly, it may be convenient to scale a wind-facility’s mortality to an overall per-MW basis for comparison to other wind facilities, but that same overall per-MW metric might not be well-suited for making adaptive management decisions if there is variability among turbines within the facility based on habitat context or turbine type.

Western EcoSystems Technology, Inc. Environmental & Statistical Consultants 200 S. Second Street Laramie, WY 82070 307-755-9447 www.west-inc.com

Follow WEST: Facebook < http://www.facebook.com/pages/Western%E2%80%90EcoSystems%E2%80%90Technology%E2%80%90WESTInc/125604770807646

, Twitter http://twitter.com/WestEcoSystems, Linked In http://www.linkedin.com/company/1458419, Join our Mailing list < http://visitor.r20.constantcontact.com/manage/optin/ea?v=001qrD4A3S5xJ5KgMyelH9jyw%3D%3D

CONFIDENTIALITY NOTICE: This message and any accompanying communications are covered by the Electronic Communications Privacy Act, 18 U.S.C. §§ 2510-2521, and contain information that is privileged, confidential or otherwise protected from disclosure. If you are not the intended recipient or an agent responsible for delivering the communication to the intended recipient, you are hereby notified that you have received this communication in error. Dissemination, distribution or copying of this e-mail or the information herein by anyone other than the intended recipient, or an employee or agent responsible for delivering the message to the intended recipient, is prohibited. If you have received this communication in error, please notify us immediately by e-mail and delete the original message. Thank you.

P Please consider the environment before printing.

On Fri, Sep 21, 2018 at 1:48 PM Manuela Huso notifications@github.com wrote:

I agree. I think it is important that we address it directly in the User Guide. In the same section we should also address extrapolating to a full year. For some species and environments and monitoring periods an assumption of 0 outside the monitored period is defensible. For others it is not. Yet the standardization to a specific time period is as necessary as standardization to some measure of power production.

— You are receiving this because you modified the open/close state. Reply to this email directly, view it on GitHub https://github.com/ddalthorp/GenEst/issues/515#issuecomment-423651759, or mute the thread < https://github.com/notifications/unsubscribe-auth/Acw22rRLHsTimsSK3Rl0-woQ4DybEs2Wks5udUKWgaJpZM4WjvQE

.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/ddalthorp/GenEst/issues/515#issuecomment-424388026, or mute the thread https://github.com/notifications/unsubscribe-auth/AcwzA-aCTlSMUrOSG73axMJf1SuuO8hBks5uekvagaJpZM4WjvQE .[image: Image removed by sender.]

ddalthorp commented 6 years ago

added to user guide