RFP Questions/Answers

Q: For this we would like some clarification on invoicing, we'd like to avoid forming an LLC, but rather both track our hours internally and then splitting the invoice(s) based on the ratio, but would like to know how IRIS views a joint contractor proposal.

A: IRIS would consider a proposal that includes the partnering of two or more individuals bidding on the Project Elements. The proposal should articulate the division of labor and define the expected invoicing by individual upon completion of the project. Any awardee(s) must adhere to a Master Work Agreement (RFP Appendix A) and have a DUNS number to track payment.

Q: We also would like to discuss in a little more detail the deliverables for Element 2; We identified four key high level deliverables and would like to get your feedback before we formalize the proposal:

  • The ability to read/write the "FC" files that Gary's code uses as inputs. Many people use these codes and the interface to the FC-File I/O is dated and much more difficult to use than it needs to be.
  • A: The legacy FC file formats do not need to be retained as readable/writeable i/o.
  • A python wrapper for Gary's executable transfer function estimation routines. This serves two purposes; first it enables end-to-end processing early on using the standard methods/functions that the community knows and trusts, and second, it will give a baseline ‘answer’ that we can use for the python version to ensure that the processing is implemented correctly.
  • A: Recent issues compiling EMTF in gfortran for Mac lead us to question the long-term viability of the fortran version. We do not desire this as a deliverable, although a developer may choose to use a wrapper for internal validation purposes.
  • The python version of EMTF (with possible additional features)
  • A: The rewrite of EMTF in python is the key deliverable of Element 2. The matlab conceptual implementation of EMTF (see matlabPrototype_10-13-20.tar / matlabPrototypeTest_10-13-20.tar [contains test MT dataset] in the RFP Appendix B) should be seriously considered by the developer as the starting point for this work.
  • A framework and documentation that a user can use to ‘plug in’ another TF estimation method. (including video tutorial)
  • A: We consider adequate documentation to enable ease of use as a critical part of the rewritten EMTF and especially the TF module.

Q: Regarding Element 3, I had intended to apply for that independently of the joint proposal between myself and [redacted] and would like to know if this is the best way to propose (in separate submissions) or if we could just bundle as one with the division of labour agreed upon between us.

A: See previous answer related to this. Bundling with a defined division of labor is acceptable.

Q: How are these codes tested/delivered? i.e. Is there going to be a cloud server or login of some sort that we will have access to in order to do testing/proveout? If so, does IRIS foresee any issues giving the contractors access to their network for running codes/testing?

A: We propose using github (or similar) for hosting the development of the code. There are multiple internal/external options that can be discussed during the kick-off process.

Q: It is not clear how the testing on multiple OSes will be performed? Will IRIS be providing users from each camp (Windows/Linux/Mac), or is it sufficient to demonstrate them on the contractor's machine(s)?

A: Demonstrations should be conducted from the developer’s machine(s), with additional final validation and testing performed locally by IRIS facility staff and/or members of the IRIS Project Team.

Q: Will there be anyone at IRIS project team who can act as a tester/give feedback? What level person may this be? Staff member? Intern?

A: Yes, one or more members of the IRIS Project Team will be responsible for conducting testing and providing feedback. These roles can be fully defined during the project kick-off.

Q: How are the datasets for tests of the codes selected? How many test datasets will there be? Size, number of stations?

A: We envision two datasets, tentatively 1) a predefined set of long-period MT stations downloaded from IRIS that were collected as part of the EarthScope USArray MT-TA dataset, 2) wideband MT stations collected as part of a USGS experiment. The IRIS Project Team will work with the developer in identifying and furnishing these datasets.

Q: Eventually there will be web interfaces for these tools. This normally involves passing processing/configuration parameter objects. I see no reference to processing configuration interfaces. Has IRIS selected a format for this? JSON? YAML? Or are these interfaces selected during the proposal execution in discussion with the project team? There is some yaml in the github site, but it would be good to define these metadata frameworks (or at least rank them in order of preference).

A: To clarify, we do not intend for these tools to require web interfaces in their function, as the MTH5 format will not be hosted or produced directly by IRIS. Element 1 should exist as simple command line executables and/or executables that call a GUI and to operate, with released versions kept in an open public repository. Element 2 will be a bundle of codes residing in an open public repository. Options for this can be discussed in the proposal and further refined with the Project Team.

Q: What sort of time availability can the contractor(s) expect from the IRIS project team? i.e. Will there be regular tag-up meetings? With what approximate frequency? Who will be the POC for questions/issues as they come up?

A: The IRIS Project Team will be available for regular consultation. We will work with the contractor(s) to structure the interactions as appropriate. In general, we envision a combination of email dialog, project calls, scheduled milestone design reviews, and periodic ad hoc conversations as needed. Andy Frassetto will serve as the initial POC, and we are open to suggestions from the developer(s) on the best mechanism to facilitate the development (setting up a trac page, github, etc.).

Q: Flexibility on delivery dates?

A: We are somewhat flexible. March 31st is desired but not required and any competitive proposal should be well underway during the first quarter of 2021. Completion within FY21 (ending September 30, 2021) is required.

Q: Are there priority levels to these individual tasks?  Some attributes are listed as 'desired'.  It would be good to label/tag high, medium, low for project/timeline planning.

A: Attributes described as desired are prioritized accordingly:

  • Element 1 - Allow for parallel utilization of MTH5 (low)
  • Element 2 - Graphical display of site occupations (high)
  • Element 2 - Time series plotting module (high)
  • Element 2 - HPC (low)

Q: I noticed there is explicit reference to working with Jared Peacock's codes in Element 1. Is there any budget for trips up to USGS in Mountain View to work with Jared from time to time (say 3 days, 3x over the four months? pandemic permitting)

A: Given the current public health challenges and travel restrictions presented by COVID, we prefer this development to be conducted remotely and supplemented as needed with remote meeting/collaboration technology (e.g. Zoom). Should the situation change and in-person collaboration be possible, this expense would be incurred by the awardee.

---------------------------------------

Q: For the MT consultant, is that someone that the developer should write into their proposal or is that something that the IRIS project team will provide?

A: The MT consultant may be written into a developer’s proposal, should the bidder have in-house expertise or have identified an appropriate partner in advance. If a proposal for Elements 1 and 2 does not address Element 3, we will consider appropriate pairings with any proposals that only address the MT consultant component. The IRIS Project Team will evaluate whether proposals that include or omit the consultant are appropriately framed. Bidders proceeding this way should consider the risk that no “solo” Element 3 Project Proposals are received.

Q: What is the timeline? How soon would the code need to be developed? How long will the funding last?

A: See previous answer, the desired completion is by March 31, 2021. Funding for this main round of development is available through U.S. federal fiscal year 2021. Maintenance funds for upkeep or expansion of the software may be available in FY22 and FY23.

Q: Is it ok for a Canadian developer to put in a proposal?

A: Yes. There are no inherent exclusions. Any awardee is required to adhere to a Master Work Agreement (RFP Appendix A) and have a DUNS number to track payment.

Q: Is there any expected development for writing out the EMTF XML?

A: Yes. Transfer functions produced using EMTF should be exportable in XML format such that they can be archived in the IRIS TF repository

---------------------------------------

Q: I currently live [outside the U.S.] and work full time. Am I still eligible to apply for the project or are there any requirements that preclude me from keeping my full time employment?

A: See previous answer, you are eligible to apply. Any awardee is required to adhere to a Master Work Agreement (RFP Appendix A) and have a DUNS number to track payment.