Go to the U of M home page
School of Physics & Astronomy
Probe Mission Study Wiki

User Tools


playground:playground

This is an old revision of the document!


Attendance: Al, Shaul, Lloyd, Amy, Dave,

Notes by: Karl

May Workshop

  • minor changes from 3 wks ago. All slots now filled – except final decadal process panel.
  • SH: Small time allocation to foregrounds currently. But not clear that more discussion time is what is most needed.
  • final decadal process discussion: John Carlstrom tentative, Steve Ritz checking his schedule

SPIE and future Papers

  • Sutin Abstract
    • Format: Few paragraph science. 5 pages instrument (optical design refer to Young paper). 2-3 pages mission design.
    • AT: due to ITAR, it will be difficult to include full groups comments. The time frame will be short.
      • non-JPL co-authors won't have much time to read and comment.
      • AT: so we need an internal JPL deadline to pass ITAR then release to co-authors, then submit to co-authors, then to SPIE. Tight timeframe.
      • SH: suppose draft goes to Co-Is, give them 1 week to read/approve. What if changes made? Does it go through ITAR again?
        • AT: 2nd ITAR would still be 1 week (delta review). Means JPL draft circulated in ~ 1.5 weeks.
          • SH: That seems required to give co-Is time.
          • AT: but 1.5 weeks isn't enough time for writing a reasonable paper given manpower. Really only time for 1 ITAR round (so paper in ~3 weeks). So JPL and onboarded co-authors help write. Non-JPL have few days to read and opt in or out. But not time for large changes or iterations.
            • SH: Really need time for people to read/comment make changes. Full PICO community has contributed to many systems so they need to be included.
            • AK: Can we skip ITAR? AT: Nope. Not for technical paper.
            • Deadline May 16th. AK: often can get 2 more weeks out of them. Up to conference date.
              • SH: means release to ITAR by April 18th. Doable?
              • AT/SH: Will take offline. No agreement yet.
  • Young Abstract
  • Author list changes due April 9th.
    • Policy for authorship?
      • AK: If open invite we should have some sort of policy requirement.
        • SH: Could have couple EC members review names, or bring up issues and have full EC decide.
        • LK: Don't see downside to erring on side of inclusion. Bringing each case to EC on case-by-case basis makes most sense. Should be very few.
        • AT: More inclusion is fine.
        • Will say policy is just review by EC. Shaul will flag cases for discussion if needed.
  • How do these papers fit in overall picture of outcomes for the study?
    • Not flagship PICO papers, rather technical papers.
      • AT: Need to be clear these aren't final design or go-to papers for full PICO study.

TeamX Sessions

  • TeamX-I, -M
    • No large changes to instrument
    • Mission, got full end-to-end cost. Still in cost window, probably. Final number in ~ week.
  • Review of TeamX slides
    • input to SOMA. We will work to release (ITAR) slides to EC review. EC note issues and TeamX will clean up slides in summer. Give 'sanitized' input to SOMA.

Setting 'Requirements' (vs. Best Case)

  • Forecasts are currently 'best case'. Need requirements.
    • example: current assumption = 100% yield. is requirement 80%? 90%?
    • What is the right process to set requirements?
      • AK: should set for performance of full array. what is the sensitivity where you no longer have a useful r value? So science drives the margin. Work back to band/detector NET.
        • SH: makes sense. Threshold value?
          • AK: r ~ 10^-3 at 3-5 sigma seems critical. So sig® 2-3 * 10^-4.
          • SH: Ok, for comparison, think (will check after telecon) that S4 proposes 5 sigma on 4*10^-3. On 3-5% of sky.
          • AK: Also really a question for theoretical community. Is there a threshold r value? Where null result is compelling.
            • Shaul will communicate with Raphael, Lloyd, others to see if we can set a requirement.
      • SH: Other option is to take 1-2 sigma variations in inputs. Calc noise for all worst cases and get a worst case version. No strong preference for this, just pointing it out.

<note warning>warning</note>

<note important>important</note>

<note tip>tip</note>

<note>note</note>

playground/playground.1522875467.txt.gz · Last modified: 2018/04/04 15:57 by kyoung