Skip to Content.
Sympa Menu

usatlas-hllhc-l2deputymgmt-nsf-l - Re: [Usatlas-hllhc-l2deputymgmt-nsf-l] Mark Coles -- NSF feedback to ATLAS on CMS on Directors Review

usatlas-hllhc-l2deputymgmt-nsf-l AT lists.bnl.gov

Subject: U.S. ATLAS HL-LHC Upgrade Level 2 and Deputies-NSF only Management Mailing List

List archive

Chronological Thread  
  • From: Gustaaf Brooijmans <gusbroo AT nevis.columbia.edu>
  • To: usatlas-hllhc-l2deputymgmt-nsf-l AT lists.bnl.gov
  • Subject: Re: [Usatlas-hllhc-l2deputymgmt-nsf-l] Mark Coles -- NSF feedback to ATLAS on CMS on Directors Review
  • Date: Thu, 18 Jul 2019 10:44:40 +0200


Hi John,


1. the ATLAS SVR for 6.4.3 BE is scheduled for Nov. 2020
    - I will argue that the BE is based very closely
on Phase 1, so the "v1 preproto design" which will be
complete before Apr. 2020 will allow us to meet the
"construction ready" mark.  However, given that the
HL-LHC Specs for the BE will not even be reviewed
until Nov. 2020 leaves this argument quite open to
challenge
    (I guess there are also some other subsystems
with some SVR dates after start of MREFC?)

Yes, but there is no technological risk here, eg the 25 Gbps is now proven, and the first LASP board will be made at the end of this year. I don't see a real problem here, at least not more than for any of the other ATCA boards. LAr is in fact ahead of HTT and L0MDT on the ATCA front. Another way to look at this is that the comparison standard is FEB2, not ADC.


2. a low probability but high impact risk for the ADC
in 6.4.1 is that it fails somehow and we have to fall
back to a COTS device (with much higher cost, ...)
    - I will argue the 2 rounds of preproto so far
have reduced this risk, and the v3 preproto that will
be submitted and tested still as part of preMREFC
will get us to where we can retire (or be forced to
unfortunately realize) this risk.  However, what if we
are not 100% confident to make this decision before Apr. 1,
particularly given the NSF restriction on spending
contingency unless you have an associated risk?  ie. if
we retire it, and then find a problem a month later
that anyway forces the COTS backup solution, where do
we get the ~$2M needed??  To guarantee we don't fall
off this cliff, I would of course like to keep the
risk active, albeit with a Very Low probability.  But
how do we say this does not contradict the clause to
"eliminate all technological risks" ?


Also here I don't see the problem. Of course you can still have this risk. The point is that you have a fall-back solution if your preferred option fails. So you know you will be able to build FEB2. Only if you did not have any fallback would you be in trouble.

Best,

Gustaaf





Archive powered by MHonArc 2.6.24.

Top of Page