This is the most up to date FAQ (superseding the community posting). If you can’t find the answer to your question here, please ask the IPC Team by emailing the In-Kind Helpdesk at JIKH at lsst dot org.
Q: What is the status of the data rights agreements?
Q: Can PI-ship be reassigned within a team that asks for more than 1 PI?
Q: Did I see 2 different meanings for 'IPC'? One for 'In-kind', and one for 'International'?
Q: With which agency or managing organization will IDAC DRAs be signed?
Q: Will it be possible to extend a data rights agreement after it has been signed?
Q: How often do you expect amendments to the data rights agreements?
Q: What happens if two proposal teams want to make the same in-kind contribution?
Q: Can someone that is already a PI contribute a fraction of their time in the proposed program?
Q: Are there any outreach contributions that could be considered in-kind?
Q: Can I add a new contribution or expand my current program?
Q: When would AEON integration have to be complete?
Q: Will the acquired data have proprietary time and will they be made public?
Q: How can we make sure the SCs have more input in time allocation?
Q: What are the rules about PIs collaborating with external collaborators?
Q: What is the exchange rate between (software developer) FTE vs. PI?
Q: When should we be able to start a directable software contribution (general pool)?
Q: Do you anticipate that any of the general pool will go to Rubin DM rather than SCs?
Q: When should IDACs expect to begin operations?
Q: How can IDACs support allocation to analysis tasks for groups/collaborations?
Q: Which data products will be available from IDACs?
Q: Which computing resources will IDACs provide?
Q: Will Scientific Processing Centers (SPCs) get data from IDACs?
Q: Do IDACs have to be ready by Commissioning?
Q: How should IDACs organize user support?
Q: Are there plans to help users move between IDACs?
Q: If the start of survey operations is delayed, should my in-kind contributions also be delayed?
Q: What is needed for the initial work plan?
Q:How detailed does the work plan (and its quarterly updates) need to be?
Q: How is it managed when the recipients are more than one single SC?
Q: Are the recipient groups expected to review the quarterly updates as well as the annual reports?
Q: What is the status of the data rights agreements?
A: Legal teams from SLAC, AURA and DOE are working together to produce a (as much as possible) mutually consistent set of terms and conditions for their respective agreement templates. When these are complete, Rubin will support the production of the agreement documents. Rubin Observatory now has a template for the AURA agreements, and advanced drafts of the SLAC and DOE templates, all designed to be mutually consistent. Draft agreement documents should be available for analysis and iteration by the program teams during November and December of 2022, but please understand much of the timing is out of Rubin's control. Each data rights agreement will include, as an appendix, a high level "statement of work" that captures the basic deliverables of the contribution and the number of PI slots awarded in exchange. These statements of work are being extracted from the reviewed proposal documents (or in some cases, the previous MOAs). DOE will sign the French and UK agreements (which include contributions that significantly offset Rubin operations costs), and AURA and SLAC will sign the others, with the types of contribution involved determining who signs which. (For example, telescope time to be managed by NOIRLab would be in an AURA agreement, while software development effort contributed to the LSST DESC would be in a SLAC agreement.) A few large programs that contain a variety of contributions (in terms of their category and recipient) may ended up having two data rights agreements.
Q: Can PI-ship be reassigned within a team that asks for more than 1 PI?
A: Yes. The program that makes the in-kind contributions is awarded data rights, and it's up to that team to distribute those PI ("Principal Investigator") and JA ("Junior Associate") slots. The Program Manager then provides their list to Rubin, and then Rubin uses it to maintain a database of who has user accounts for data access,.
Q: What is the process for defining data rights holders, and how do we know how many PI slots we have?
A: PI quotas are based on the accepted contributions that you submitted in your proposals (and will appear in the Data Rights Agreements). Each year, Heather Shaughnessy will send your program's Program Manager an update request form (spreadsheet) to be filled out with the names of the people who will occupy the allotted PI and JA slots in the coming academic / US fiscal year. This form includes a statement of the current PI and JA quotas. These spreadsheets are then used to populate the list of In-kind Data Rights Holders, which is checked during the data preview delegate award and Rubin Science Platform account creation processes.
Q: Does 1 PI's worth of data access rights via in-kind contributions also come with 4 associated JAs, as in the previous MoAs with LSSTC?
A: Yes.
Q: Am I correct in thinking that our PIs, and their JAs, automatically get the same access to data processing facilities as US/Chilean astronomers?
A: Yes, the PIs and JAs have the same access to data as US/Chilean astronomers: all will be able to request an account on the Rubin Science Platform.
Q: On page 25 of the Handbook it says: 'Due to the diverse conditions of proposing groups and funding sources we do not distinguish between permanent staff or temporary staff in the exchange rate'; Does this imply that temporary staff who lead contributions will be considered as PIs if data rights are approved?
A: It is important to separate the two roles. A PI is someone who has LSST data rights, and it is up to the proposal team to decide who gets those data rights. We look to the Program Managers to give us the list of PIs and JAs who have data rights and should be granted LSST user accounts. Permanent staff cannot take up JA slots, but temporary staff can, if needed, use PI slots. Separately, the Contribution Leads are the people actually responsible for delivering the contributions. Contribution Leads may or may not be PIs. Contribution Leads could be temporary staff in some cases, but it is a position of some responsibility (they would be reporting on status and progress of the contribution).
Q: Could a JA be at any institution as long as the associated mentor is at an institution with data rights?
A: Yes, as long as that institution is in the same program: Mentors should still be local in that sense. From the Rubin Data Policy: "Programs are expected to provide each JA with a "mentor" who is a PI within the same program (but who need not be at the same institution), such that the junior scientist is supported in their work on LSST."
Q: Did I see 2 different meanings for 'IPC', one for 'In-kind', and one for 'International'?
A: Official terminology is 'In-kind Program Coordinator'. You might also see contribution and program IPC being referred to. The Contribution IPC (C-IPC) is the IPC who has been assigned to a given contribution and will typically liaise with the contribution lead and the recipients of that contribution. Each program also has a program IPC (P-IPC) defined, who will deal with more programmatic issues and will typically liaise with the Program Manager and Program Leads.
Q: Once everything is sorted, with whom will our data rights agreement actually be, Rubin Observatory, SLAC, NOIRLab or ...?
A: Most data rights agreements will be with either AURA or SLAC. France IN2P3 and LSST:UK will hold agreements with DOE.
Q: If a country has 5 different in-kind contributions to different SCs, will they have 5 different data rights agreements (DRAs) to sign?
A: No, there will be at most two DRAs to sign (one SLAC, one AURA), and only if your program has a mixture of contribution types and recipients.
Q: With which agency or managing organization will IDAC DRAs be signed?
A: The agencies, AURA and SLAC will decide which DRAs they will each sign, but we are expecting IDACs to be covered by SLAC agreements (because of the connections to the US Data Facility).
Q: Will it be possible to extend a data rights agreement after it has been signed?
A: Yes. There will definitely be opportunities to expand your data rights as we go, if there are more PIs within your institute or other institutes in your country. You will be able to amend your agreements to make more or larger in-kind contributions, and hence cover more PIs.
Q: How often do you expect amendments to the data rights agreements?
A: We are hoping that amendments to the DRAs will not be frequently required, but they will be a part of the annual reporting cycle.
Q: How often can the International Data Rights Holders list be updated by an in-kind agreement holder?
A: Program Managers (PMs) make changes once per year and will be contacted in early summer for the update for the upcoming Rubin year that starts in October of the same year. It is envisaged that the new hires for that new academic year will be known by this time and therefore can be added to the DRH list. PMs: if your program needs to make a small amendment outside the annual update, please email JIKH at lsst dot org with your request.
Q: In the future, will there be another call for Letters of Intent and Proposals like the 2019 one, for international groups that did not/could not submit LOI's that time?
A: We are not planning another LOI call at this time, but do not want to rule it out. We do want to be inclusive, but our current focus is getting the initial in-kind program up and running.
Q: How do I describe the beneficiaries of our in-kind contribution? Is it the US astronomy community, or the US community plus the Chilean community, or some other group?
A: You can quote the US agencies' May 2019 talking points, and say something like the following (from the Manual). In-kind contributions from teams outside the US and Chile should, in return for LSST data rights, "expand the resources available to the U.S. astrophysical and high energy physics communities."
Q: What happens if two proposal teams want to make the same in-kind contribution?
A: We are taking a collaborative approach, and encouraging coordination between the teams and the recipients so that the teams make contributions that are complementary to each other. There are also cases where duplication is warranted and desired by the recipient groups. For example: the photo-z coordination group will bring together a number of teams to discuss the work they want to do. See the Manual for more on how duplicative contributions are managed, and the Handbook for how duplicative proposals are reviewed.
Q: Will it be possible to include in the proposal contributions that were not originally included in the LOIs, and so were not assigned an LOI code?
A: Yes, absolutely: we're open to hearing new ideas. Feel free to include those new ideas, just please follow the Handbook in preparing them, and if you need help in identifying an appropriate recipient group just get in touch and we can help with that. The "LOI code" for such proposed contributions is "N/A".
Q: Are the categories of contributions mutually exclusive? e.g. Are there any circumstances in which a contribution counts as both a "dataset" and as a "software development" contribution?
A: Yes, generally speaking, the contribution categories are designed to be mutually exclusive, but please do discuss carefully with the IPCs as there are a handful of real edge cases.
Q: Regarding efforts already made within the Science Collaborations: will "service" work that has already been done (such as leading working groups and chairing task forces, to writing documents and participating in meetings) be evaluated in the in-kind process?
A: The short answer is no, science collaboration service work does not qualify as an in-kind contribution. This is explicitly addressed in the Handbook (see the section on "Past software development effort"). We make a distinction between past contributions to software development (that would meet the criteria for an in-kind contribution in the Handbook if proposed now) and service work in collaborations, which would not. There is an alternative route to permanent data rights for people who have made valuable contributions to building the LSST science community, separate from the in-kind process: see the Rubin Data Policy section on Builders for detail.
Q: If for one team, each PI makes a totally independent contribution, how do we structure our proposal?
A: The required proposal structure is already well suited for such an eventuality: each PI can be a Contribution Lead, and then write their section of the proposal and be responsible for the delivery of the contribution. However, please note that in general there is a logical distinction between a PI with data rights, and the lead of a contribution. Many contributions will be worth several PIs, and Contribution Leads do not have to be PIs (although in most cases they will need to be). The data rights agreement (and the delivery of the contributions) establishes a certain number of PIs for each team, and it's then up to the team which individuals get those data rights (PI slots). Proposals should be sectioned into logically distinct contributions, with a requested number of PIs for each block.
Q: Can someone that is already a PI contribute a fraction of their time in the proposed program?
A: Yes! Such a case can help a team to succeed.
Q: Are there any outreach contributions that could be considered in-kind?
A: It would need to benefit the US community, complement the existing US EPO efforts, and be approved by the Head of Rubin EPO. It's good to discuss ideas with Phil (listed as Point of Contact for EPO ideas in the Handbook directory).
Q: If participation is being proposed by researchers from different institutions, who would sign the DRA(s) in case of approval? The lead proposal institution?
A: Yes: the easiest thing for Rubin is to set up an agreement with a single lead institution, and that institution manages the interactions among the institutions in the consortium.
Q: Could the Contribution Lead change during the time of the project, regardless to which institution they belong?
A: Yes: this would be an amendment to the data rights agreement statement of work, but one that is straightforward to make. We would expect the program team to provide a replacement Contribution Lead, or work with us to define an alternative contribution.
Q: Are the PI rights linked to the institution/proposal, or the individual? And are they transferable?
A: The data rights go to the institution or consortium that signs the agreement, and we look to the program team to assign those data rights (and tell us who to grant Rubin Science Platform LSST user accounts to). We do recognize that some individuals will end up making significant contributions on their own time, and those individuals can earn permanent data rights on the basis of the contributions they make, separate from the institutional data rights agreement. Specifically, such in-kind contribution team members can be nominated for either LSST Science Community Builder status, or LSST Builder status, depending on whether their contribution's recipient is a Science Collaboration or Rubin. See the Rubin Data Policy at https://ls.st/RDO-013 for details.
Q: Understandably there is some discretion in the process on your side, weighting factors etc. This might eventually reduce the value of the final agreed value of the contribution, hence the number of PIs. Would you recommend proposing more than what the proposal team is aiming for?
A: The first thing to do is try to make good estimates of the weighting factors yourself. That's something that the IPCs can help you with if needed. If you have that estimate, there is some strategy on your part to guard against contributions being weighted less highly in the end. We're quite keen to help you make good estimates because we hope to minimize the amount of back-and-forth in the negotiation.
Q: Are formal endorsements of our proposed in-kind contributions from their intended recipients needed in all cases?
A: Only in the case of non-directable software development effort do we ask you to reach out to your recipient groups and get explicit endorsements for your contributions. However, collaboration between the Contribution Leads and recipient groups is particularly important, for any kind of contribution. Such collaboration is also essential in the process of preparing the work plans.
Q: Will it be acceptable for proposal teams to reach out to other Science Collaborations, not specifically identified in the feedback to their LOIs, when they develop their full proposals?
A: Yes, absolutely. Feel free to include new ideas for contributions, just please follow the Handbook in preparing them, and if you need help in identifying an appropriate recipient group just get in touch and we can help with that.
Q: If one item in the list of in-kind contributions is potentially useful to more than one recipient group, should we include them in the same section, or create different sections containing specific information regarding each recipient group?
A: You should make a single proposal section for each contribution, but there could be cases where a contribution has more than one recipient group: in such cases, write one section but list and reach out to multiple recipients.
Q: What kind of commitment are you looking for in the proposal: a firm, fully funded commitment for 13 years or an intended, but so far non-funded, intention? Or something in between?
A: The more secure the funding the better, but funding for a proposed contribution does not have to have been secured (and we recognize that in some cases you may need the data rights agreement to secure funding successfully). We do ask that your proposed contributions represent good faith commitments on your part to deliver those contributions. For any proposed contribution that is accepted and included in your data rights agreement, we will hold the Contribution Leads accountable for delivery of that contribution, and would like to minimize the number of contributions that have to be amended because the funding has not panned out. As a rough rule of thumb, don't propose anything that your funding agency has not provided some initial commitment to.
Q: Can I add a new contribution or expand my current program?
A: There is currently no open opportunity to expand accepted programs or accept new ones as we are focussing on getting the initial set of 160+ in-kind contributions up and running with corresponding DRAs. Any future opportunity will be announced at the discretion of the Director of Operations. We do not expect an announcement of opportunity before spring 2023, if not later.
Q: Does a 4m-class telescope like the AAT have to be integrated into AEON, despite being 3.89m in diameter?
A: We specified D<4-m as the cutoff, but of course some smaller telescopes could bring a lot of value without being integrated into AEON while other, larger, telescopes could be included in AEON to very good effect. We believe that it would benefit AAT to be integrated to AEON, but it's good to remember that this is a negotiation: we are open to discussion.
Q: When would AEON integration have to be complete?
A: AEON integration would expect to be complete for Y1 of the survey, although in some instances earlier integration would be beneficial. Please note that in order for AEON to be available in Y1, substantial effort may be needed 1+ years in advance, to allow for implementation and testing. This should be accounted for in work plans and quarterly reports. Keep in mind that if you add AEON integration you can gain PI credit for that.
Q: Does NOIRLab need to be in control of the allocation process - or can time be protected for the US, but through the telescope TAC itself?
A: Our objective is to use the NOIRLab TAC. For special cases, especially for high value facilities, we are open to discussion about working through the in-place international TAC. Any such case is going to have its unique issues and we will work with you to try for a mutually satisfactory scheduling process.
Q: Some proposals may want to contribute follow-up to specific science collaborations like TVS or DESC for training sets for transient classification (for example). How would a proposal like this interact with the NOIRLab TAC?
A: In this case, what is really being offered is a bespoke dataset, rather than telescope time. We highlight some aspects of contributed datasets in the Handbook: valuation is similar to telescope time, but with some additional criteria. For dataset contributions, the NOIRLab TAC is not involved.
Q: Is telescope time, or actual telescope operating cost, considered most significant in the valuation?
A: The issue here is how many PIs is telescope time worth, and the underlying logic is to look at how much it would cost the US science community to buy the same amount of time (and how much of a discount it would seek). This led us to the current model, which is for you to estimate the total operational cost of the time you are offering, divide that by $300k per PI, and discount by a weighting factor that captures how well suited the facility and instrumentation is to LSST follow up.
Q: Can the future observations of LSST targets which will be done by us (non-US PI) on our telescope be considered an in-kind contribution as a value-added catalog if the data will be made public to LSST scientists or the US community within a certain period? Probably we (non-US PIs) will have more access to our telescope than we can provide as in-kind contribution.
A: If the targets are chosen by a Rubin PI, and that PI then has proprietary access for an appropriate time, then it may be possible to process such a proposal as a telescope access proposal. If the targets are chosen by the in-kind contributor(s), then the in-kind proposal should probably be formulated as a dataset contribution. In any case the data you take would need to be shared promptly with the US community (rather than first made public and then shared).
Q: Suppose we are speaking about photo-z. The best photo-z are obtained by combining Rubin data with other ancillary data. Are these data made available by Rubin? Or is it the proposer that has to take care of the merging?
A: For this case, you could propose either to provide (and support!) an ancillary dataset that could be combined with the LSST data, or you could propose to provide (and support!) a "value added catalog" where you had already combined the dataset with the LSST data. Either way, the ancillary data would need to be hosted at a Rubin IDAC such that the LSST community could use it (or you'd need a convincing plan to enable access to the LSST science community otherwise). If you were going to do the merging anyway, you should propose the combined catalog and the underlying ancillary dataset as the same contribution: that's what would have most likely the highest scientific impact.
Q: Regarding telescope time; is it necessary to also submit this form that is mentioned in the Handbook, or is it just for reference?
A: Yes, the form is required.
Q: How will the 'weighting' be justified? Since we still have to pay for 100% of the telescope time, e.g. a 0.25 weighting means a PI is 4x as expensive.
A: The telescope operation cost is the main factor in valuation. The weighting is based on common sense (e.g. reflecting the fraction of LSST sky coverage accessible from your site and resources, or the availability of AEON support). In most cases the weighting is sufficiently mild that it does not prove to be a concern for applicants.
Q: We would like to release our spectra for LSST alerts directly through TNS within 48 hours, for LSST alert triggers from the LSST community. Is that not better than providing them to a single US PI?
A: The general concept of in-kind telescope access is to add facilities to the list of telescope resources allocated by the NOIRlab TAC. Immediate publication of data would thus be unusual, unless initiated by the PI of the science program. However, publication to TNS would be advantageous to a wider community. You are welcome to propose this for negotiation with Rubin.
Q: Our institution is part of a telescope consortium, where we own the telescope time but not the infrastructure. As such, since it is not our telescope, we cannot guarantee full AEON implementation, but can arrange to receive triggers from an AEON interface that we then execute. The triggers could come from all LSST:ers, or from selected groups as TAC:ed, or graded by a TAC. We would need to do the scheduling based on magnitude, RA, and observing conditions. Is that acceptable?
A: We were aware that some of you have constraints on what you can do with telescope time, and we may have to treat that on a case by case basis. We'd really like to see telescope time coming through AEON, but there may be ways to help you contribute telescope time through other means and that's something we can work with you on.
Q: For the active follow-up: would it be OK to impose a restriction on the type of targets — e.g. extragalactic transients, or supernova classifications – but not open up to all science (CV, AGN, GRB..) to not get in conflict with local TAC? Should we ask an LSST SC to endorse such a scheme?
A: That is a constraint that is not desirable, but may be acceptable if the opportunity that is offered is valued highly. Since the potential recipients review the proposal as written, any endorsement of the proposal will reflect the impact of such constraints. You are welcome to propose the program that you can support. If the constraints are deemed excessive, a change may be requested, and terms will be subject to negotiation.
Q: Is that dollar value the same regardless of the dollar values in the original MOAs? And, how is the tying to exchange rates being considered?
A: For telescope facility operations cost, please use current exchange rates. Negotiated agreements will reflect deliverables and we do not expect revision with changing exchange rates. For valuation of data rights, in the current process, we are leaving previous MOAs behind. We are trying to maintain some approximate logical link with previous MOAs, but with a fresh look. Rough guidance of $300K per PI is the link to the past, but weighting factors are new. Valuation is approximate, subject to change through negotiation.
Q: This is about providing spectroscopic followup of LSST transients (instead of handing over time to US PIs through AEON). This could be attractive to other groups and perhaps shouldn't be treated on a case by case basis. In other words, roughly what weight do you have in mind for such an arrangement?
A: The concept of in-kind telescope access is for the NOIRLab TAC to process proposals, and for the in-kind team to ensure that the proposals are accepted and executed by the in-kind facility. If you are proposing to provide service observing followup for targets approved by the NOIRLab TAC (and perhaps scheduled via AEON) this appears to be a good match for the in-kind program objectives.
Q: How does the NOIRLab time allocation work? What happens if the LSST is delayed after one of the allocated time contributions has started?
A: It will follow NOIRLab policies. Some time may be allocated via contributor procedures. The procedure for allocating any time will be described in advance through NOIRLab websites and other channels.
Q: Will the acquired data have proprietary time and will they be made public?
A: The expectation is that in most cases telescope access will be allocated by the NOIRLab TAC, and the standard NOIRLab proprietary periods will apply. Generally standard proprietary time is 18 months, but for some cases, shorter proprietary periods (or instant public) have happened. As the distribution and archiving of the data are responsibilities of the contributing facility, the long term status of the data is unclear.
Q: Where should communication between facilities and AEON/NOIRlab take place?
A: For general questions and clarifications, the Community forum is preferred so that other teams can also take advantage. For questions specific to your contribution, please contact your IPC (see the contact page).
Q: How can we make sure the SCs have more input in time allocation?
A: Both in-kind and Rubin data are part of NOIRLab’s program but we will work to make sure DOE science is supported. We emphasize science benefits and will not disadvantage large programs.
Q: What are the rules about PIs collaborating with external collaborators?
A: PIs of contributed time proposals may collaborate with any qualified scientist/student as they choose on the telescope proposal. However, they must abide by the Rubin Data Policy with regards to sharing Rubin proprietary data as or if it is used to support the telescope time proposal/collaboration.
Q: When will the time available via the in-kind program, and the facilities and instrumentation available, be announced to the community for planning purposes?
A: The exact time available and details of the facilities will be made available as part of the regular call for proposals for a given semester. We hope to be able to provide a provisional long-term view of the facilities and time available in early 2023 to allow sufficient long-term planning.
Q: With regards to value-added data sets: is there any kind of embargo against publishing science papers based on these prior to handing it in to the Rubin data facility?
A: Our view is that the datasets ought to be provided to the LSST community promptly. You can certainly argue that previously published data have less value. The counter-argument is that publishing it provides full documentation. We may have to take this offline and consult the CEC about it, but it may come down to what is meant by publishing and how it impacts scientific opportunity. More generally, we stress that we won't accept unsupported datasets. We definitely require appropriate documentation. If you need to partner via an IDAC, the proposal will need a letter of endorsement.
Q: In the value-added catalog section of the Handbook, you mention that the labor to make the catalog is not credited towards the contribution. While it is true that a given survey would have done the catalog anyway, the work of cross-correlating it with LSST catalog in a sensible and clean way will likely not be trivial. In the case of value-added catalogs that are accounted as software contributions, they also need computing power: can we include this with the standard conversion factors?
A: Value-added catalogs are a benefit to both the recipients of the contribution, but also to the contributors themselves (through the knowledge and expertise they develop through their labor, which primarily benefits the proposing team). In the case of value-added catalogs contributed as datasets, we focus on the value of the telescope time needed to generate the data, counting the effort put in by the catalog makers as investment that will bring its own return. Likewise, in the case of non-directable software development effort contributed in making a value-added catalog, we take the input data's telescope time value and the computing resources needed to make the catalogs as investments that will pay off for the contribution team. In both cases, the final PI value of the contribution will also depend on the scientific opportunities afforded by the catalog.
Q: Regarding fully directable software development: if this kind of contribution was not explicitly mentioned in the LOI, can it still be part of the proposal?
A: Yes, never too late. And in general, this applies to all aspects of LOIs.
Q: To ensure that the hired personnel for this task have the appropriate skill levels, it'd be good if somebody from Rubin Observatory could be involved in the selection process. Perhaps drafting the job ad, or simply having a look at a shortlist of candidates before a job offer is made. Is something like this envisioned?
A: Yes, we would be happy to collaborate on the selection process. Consulting with the recipient group might be valuable to include in the process.
Q: If we want to contribute the software development effort of one or more specially hired people, should we start advertising these positions before knowing the outcome of our proposal?
A: The timescale of the contribution should really be set by the needs of the recipients: you may find that your contribution is better made over a shorter or longer period than you had envisioned, for example. If your funding allows it, you can begin your contributions before your DRA is signed: if the contribution is approved and included in the DRA, then effort contributed prior to its signing will be credited towards your program's data rights.
Q: For directed effort, will there be a scope / area of expertise within which the directed effort is restricted? For instance, the proposal could state that we will contribute development effort to certain sub-systems or such (via mutual agreement)?
A: This sounds reasonable. Providing directable effort is an attitude: it's about making someone available to do the work directed by the recipient group. Such a statement shows that the person is willing to work on the needs of the group.
Q: For directable software development, how do we fill up the activities and deliverables sections of the proposal, as they will be quite non-specific? When will the particular tasks of projects be determined?
A: This should take place when the Contribution Lead makes a work plan with the recipient group. Your proposal doesn't need to say what the specific tasks will be (although it could). The detailed plan can be updated to include the work plan when it is made; the statement of work will probably always just say "X FTE of directable effort" as the deliverable. Specifically, we think that identifying an area of contribution is necessary, but describing the details is not absolutely required.
Q: If we hire a software professional, does this person eat up one of the junior positions under a PI? Or is that going to be counted separately? The software professional, for example, may not be an astronomer.
A: A full-time software developer who is not an astronomer shouldn't use up a PI position, but they may need a JA slot in order to have the data access they need to work on their contribution.
Q: For "directable" SW development, and even more for the General pool, there is a general problem of providing specifications and supervising the work. In scientific coding these processes are difficult to formalize, so that expert human supervision is needed. How would you arrange it for resources that are external to your teams?
A: By definition, we expect in-kind developers who are providing directable effort to receive their technical direction from their recipient group, while local supervision is only administrative. As the Handbook says, though, "smaller contributions of time (less than 0.5 FTE) in support of a larger one may also be impactful, and will be considered as in-kind contributions wherever those smaller contributions are similarly dedicated to the development work." Small fractions of highly skilled senior developers and faculty can go a long way: if their effort is as directable as the primary component of the contribution, that effort would be eligible for data rights credit.
Q: A question related to the "General pool of directed effort": how should the international contributors define activities and deliverables in the proposal if they don't know in advance where the effort will be directed?
A: For the In-Kind contribution itself, what we're really looking for is dedicated time. I think it is possible to add small fractions of management of leadership time provided it really is dedicated to that contribution. We do recognize that developers and postdocs need local supervision as well as remote. For directable and general pool effort, we're expecting the work plan for the developer to be made in collaboration with the recipient group - that's why we are focussed on the recipient as an important component in the In-Kind program. So we expect the developer to work with the leads and the members of that recipient team to prepare a plan and work to it. We would expect them to present reports of progress to meetings of that recipient team. So this is a particular aspect of the large collaboration model. We think it will work naturally in all recipient teams we have identified.
Q: Who is the recipient group/point of contact for the General Directable Pool of software development effort?
A: The In-Kind Program Coordinators will be working on this aspect of it. We'll take advice from CEC as we go but we will start by just collecting all of you who are interested in this kind of contribution and helping you through the guidelines. The process of matching the general pool software contributions to the potential recipients was outlined in the call for proposals, sent to potential recipient groups early in calendar 2022.
Q: What is the exchange rate between (software developer) FTE vs. PI?
A: From the Handbook: "1 FTE-yr of software development effort that is provided in compliance with the CEC software guidelines should earn data rights for 1 PI for the duration of the survey – unless that effort is provided to the General Pool of fully directable effort, for which the exchange is 0.75 FTE-yr per PI."
Q: Do you think it would be appropriate to have the proposers write the areas of expertise of the person they propose, such that the person is not saddled with doing something completely outside the realm of their expertise?
A: Absolutely, yes. That would be ideal material for the background section of the contribution. This is particularly relevant for the General Pool contributions, and it will be the task of the IPC team to assure the best possible match.
Q: When should we be able to start a directable software contribution (general pool)?
A: Some GP contributions start in FY22 so we will be working on allocating them at the start of that year, but we hope that the overall profile of the General Pool extends well into the survey.
Q: How far in advance will the recipient of the general pool contribution be made known? (e.g. to help plan the hiring of people who will provide the general pool contributions.)
A: The problem will be more one of matching existing skills and experience. There will be an opportunity for the recipient to work with the contribution team to make sure the job ad makes sense. The IPC team already has sent a call requesting proposals from potential recipients of the General Pool software contributions, and the IPCs anticipate to carry out the matching process in the Spring of 2022. These proposals will provide a list of the needs in the community.
Q: Do you anticipate that any of the general pool will go to Rubin DM rather than SCs?
A: Yes - some GP contributions may go to DM or project needs, as they are also one of the recipients of in-kinds.
Q: Sometimes a suitable person with the right skillset to meet requirements for a specific directable software contribution may not be available in a hiring cycle. How will such situations be handled?
A: This depends on the skill set of the contributor. The resolution is probably best handled via discussions between the contributing team and the recipients to find a suitable role for the contributing person.
Q: Will the software deliverables being developed through the in-kind contributions be served through the RSP?
A: While there is no expectation that user-generated software contributions will be automatically served via the RSP, it is possible that some of the deliverables might be valuable enough to be included in the RSP. And we expect individual RSP users such as the SC recipients to install and use the tools they need for their science, including any built by in-kind contribution teams.
Q: We plan to operate a Lite IDAC, and would like to use the Rubin Science Platform as an interface. Can we do this?
A: Lite IDACs should not count on the Rubin Science Platform being available as an interface to their hardware resources. The resources provided by IDACs must have a service layer in order for them to be useful to users. It is expected that Lite IDACs will use existing service layers, or develop them themselves, to support usage of their hardware. In contrast, Full IDACs are required to adopt the Rubin Science Platform.
Q: Are the values for number of cores and storage listed in the templates suggestions or requirements? Do they need to be up and running by 2024, according to the new time table?
A: Please consult the tech note RTN-003 (https://rtn-003.lsst.io) referenced in the Handbook; there are some numbers in the Handbook provided as examples.
Q: The value of IDAC CPU resources is based on CPU hours. But what is the reference CPU type/clock speed/memory per core?
A: The current fiducial CPU used for sizing at the US Data Facility is an AMD Rome processor with 128 cores and 512 GB total RAM. As specified in the Handbook, IDAC proposers should report both CPU hours and FLOPS provided, so that a fair assessment of the computational resources can be made.
Q: Can requirements for Object Lite DAC be negotiable if it is a science specific Object Lite DAC (e.g. star catalogs) and how will such a science specific Object Lite DAC be valued?
A: The storage and computational resources for an Object Lite DAC could be allowed to differ somewhat from the requirements listed in RTN-003, depending on the volume of catalog data hosted. The requirements on Rubin-compatible Authentication and Authorization, the agreement to make the data broadly available to Data Rights Holders, the need for sufficient connectivity to support users, the need for TAP, MyDB, and CAOM, and the requirement for support may not be negotiated. A science-specific Object Lite DAC should consult with the appropriate Science Collaborations for an endorsement of their value.
Q: For an IDAC or IDAC Lite proposal: what kind of relation to the SCs is expected? A direct relation/embedding in one SC? More SCs? Or independent of SCs? Must an IDAC (Lite) have a well-defined scientific scope/profile?
A: IDAC proposals do not need to have a direct relationship to the Science Collaborations. Indeed, IDACs that provide significant data, storage, and computational resources, supported by a service layer, to the general LSST community will be among the most valuable In-Kind contributions. If an IDAC aims to have a specific scientific purpose, however, it should seek an endorsement from the appropriate Science Collaborations. Please contact the In-Kind Helpdesk (jikh@lists.lsst.org) for guidance on how to proceed.
Q: One promising option for running an IDAC is to use a GPU-based supercomputer. I know that it is technically feasible to run a database on GPUs and this works even faster than on CPUs. However, can you see any potential caveats, any cons?
A: There are no plans on the part of Rubin to use GPUs in the science pipelines. However, GPUs could be beneficial for certain computationally bound use cases, such as crossmatching large tables or all-sky visualizations. Operating a database on GPU-based hardware could offer speed benefits if data access is not I/O-bound, but would need development work on the part of the proposers to demonstrate the utility. Note that the Rubin Science Platform should not be assumed to be available for deployment for an IDAC; please contact the In-Kind Helpdesk (jikh@lists.lsst.org) for questions about it.
Q: What sets the minimum connection speed of 20 Gb/s for a Full IDAC? What sort of connection requirement is there for Lite IDACs?
A: The requirement of sustained speed of 20 Gb/s for a Full IDAC is not negotiable, and is needed in order to support the transfer of pixel data in a timely way. For Lite IDACs, which typically will serve slimmed-down catalog data such as Object Lite, the requirement on connection speed is only that it be sufficient to support users of the Lite IDAC in a performant way. Lite IDAC proposals could use past user experience over their existing connection to justify that this requirement is met.
Q: What are the requirements for the authentication and authorization procedure? Do you plan to have one central authorization server and then distribute users among the IDACs, or will users directly access each IDAC individually?
A: Work on authentication and authorization will be performed during summer 2022, so exact details are subject to change. However, the expectation is that IDACs will authenticate against a service.
Q: When should IDACs expect to begin operations?
A: It is expected that, in general, IDAC operations will start with the first data release of the LSST catalog. The date for this release is still uncertain given delays in construction as a result of the pandemic, but is likely to be sometime in 2025.
Q: How can IDACs support allocation to analysis tasks for groups/collaborations?
A: This is under discussion but the US DAC plan is to enable groups of users to pool their resources, we will probably expect IDACs to enable that too.
Q: Which data products will be available from IDACs?
A: As described in RTN-003, Lite IDACs are sized to host a limited amount of data, such as a version of the Object Catalog with a reduced number of columns; however, the specific subset of LSST data hosted by a Lite IDAC will vary from center to center. The UK Data Facility, which classifies as a Full IDAC, will host a complete copy of the data, including the Prompt Data Products. The Data Previews are currently only supported through the US Data Facility.
Q: Which computing resources will IDACs provide?
A: Lite IDACs will provide a diverse range of storage and computing resources, including GPUs in several cases. Collectively, IDACs augment the computing and storage resources freely available to the Rubin community by a factor of several. See our page for details of planned IDACs.
Q: Will Scientific Processing Centers (SPCs) get data from IDACs?
A: As described in RTN-003, data transfer will require planning on the part of IDACs and on Rubin. Having IDACs share data between themselves and SPCs is an idea worth exploring, as it takes some burden away from the Rubin Observatory bandwidth..
Q: Do IDACs have to be ready by Commissioning?
A: IDACs are expected to start operations at the time of the release of LSST DR1. However, preparatory activity will likely need to happen much earlier in order for the IDACs to be ready by this date. This activity should be developed as part of the IDAC work planning effort.
Q: How should IDACs organize user support?
A: The official support route for Rubin is through the Community Forum, and IDACs are encouraged to use it as well; contact Melissa Graham and the Community Engagement Team to get set up for this. Note that there is already a topic in the Forum, which is useful for engaging the IDACs Coordination Group.
Q: Are there plans to help users move between IDACs?
A: The software services that will be offered at IDACs are still under discussion. However, the use of Containerization is encouraged to enable portable software and workflows. The US Data Facility will be supporting VOSpace as an interface for file storage; IDACs with VOSpace clients should be able to connect to the USDF for shared file access.
Q: Concerning in-kind contributions from international teams to commissioning: is it expected that they will start roughly with the same timeline as the Chile/US Announcement of Opportunity, or will they be treated on a case-by-case basis?
A: These will likely need to start at the same time, as the SIT-Com leadership will need to develop the commissioning program with all contributors (US/Chilean+In Kinds). CLs for commissioning contributions will be put in touch with the SIT-Com team for planning and scheduling the contribution according to their overall schedule."
Q: Can the Program Manager be scientific staff or does one need to hire someone specifically for the role?
A: Yes, the person can be a member of the scientific staff.
Q: If the start of survey operations is delayed, should my in-kind contributions also be delayed?
A: Each CL and their Recipients will need to figure this out on a case by case basis. Dependent on the contribution, some can be safely delayed, e.g. timed well to the start of the survey. Some might benefit by starting as planned, to allow early development e.g. for SCs. IPCs will help facilitate these conversations as needed.
Q: What happens where the T0 minus 3-4 months has already passed? There are ongoing contribution discussions which may not be exactly able to follow all the timelines as listed.
A: The task for CLs, Recipients and IPCs is to get each contribution to merge into the timeline laid out in the Manual. The big milestone is the first annual evaluation, in fall 2022 - so there is time to get the work planning and quarterly updates going in advance of that. Then, there will be more contributions that get started during FY23 and which have their first annual evaluation in fall 2023, and so on.
Q: Could you clarify the role of the point of contact, when it is not the same as the Contribution Lead?
A: This is to allow CLs to designate primary contacts for technical direction to e.g. the main contributor or another team member that would be most beneficial to receive the technical direction. The CL remains responsible for reporting progress. Designation of a point of contact for a contribution is at the CL's discretion.
Q: For IDACs, I worry about purchasing equipment ahead of time. I presume that in 2021 we should present the work plan?
A: Yes, agreed — but given the DR1 start for IDAC contributions, there shouldn't be too much of a lag before survey start. But we could work out a ramp in the work plans to accommodate this.
Q: What is needed for the initial work plan?
A: The initial work plan need only include high-level goals for the overall contribution, along with the plan for first 3 months of work. The work plan will then be further developed via the quarterly updates, and after the 1st year the recipients will review progress against this plan.
Q:How detailed does the work plan (and its quarterly updates) need to be?
A: The work plan should be sufficiently detailed so it is possible to track the progress, but not to the point of being excessively prescriptive. It needs to allow for flexibility to allow for modifications as the needs arise.
Q: How is it managed when the recipients are more than one single SC?
A: As explained in the Manual, the primary recipient is responsible for the technical direction of the contribution, while the secondary recipient groups should be included in the discussion and will have access to the work plans.
Q:How can a quarterly report due (say) first week of Dec address work completed in Oct, Nov, and Dec?
A: Only include the weeks of Dec up to the point of reporting. The actions/successes/issues in the missing weeks of Dec can then also be reported in the next quarter. These are guidelines to allow the work to be reported in the first week of the designated month and the work for the next quarter to be agreed on with the recipient before the quarter starts. The months stated for reporting are only indicative, the reporting doesn’t need to follow a precise date but the work up to the date of submission. Much of the reason for doing the report is to lay out the plan for upcoming work and allow time for review.
Q: Are the recipient groups expected to review the quarterly updates as well as the annual reports?
A: Yes, but the review can be quite lightweight, just a check that the work outlined is as expected. Feedback on the quarterly updates (and the annual report) can be given in the recipient viewer.
