APS DPF Computing and Software Coordinating Panel - Plenary Session -
02-08-2024
Captioned By: White Coat Captioning
>> JOEL BUTLER: I kind of knew who my successor would be. It's too
short a term. Hi, Tulika, you made it.
>> TULIKA BOSE: Yes, I did.
>> JOEL BUTLER: We were concerned that people at this CMS week would
be justifiably exhausted by the end of the day and go for dinner and some
nice wine.
>> TULIKA BOSE: Well, I've been in meetings all weekend.
>> JOEL BUTLER: Me too, actually. I missed one only because the first
one ran into the second one. Who else is on? We have lots of people on.
>> IAN FISK: Not so many people from -- I was going to give people
another minute. That's an interesting perspective. Ruth, you have an
enormous cat.
>> RUTH V.: This is Otis. Otis likes to join meetings when I work
from home. He's big.
>> JOEL BUTLER: As part of our experience with the pandemic, we don't
have a meeting where a cat doesn't walk across the screen, it's just not
real. Or a child comes in and disconnects your laptop or something.
>> IAN FISK: I guess there are -- there were some people who told me
they were going to have constraints, so they weren't going to make it.
Let's assume this is the people we have. I know Giordan has a hard cutoff
in half an hour, looks like he's already on his way.
And so why don't we get started. I put all of the slides under the
first heading, introduction and news, those are actually the slides for the
whole meeting. So I will share my -- I will post them and share my screen.
>> MATTHEW FEICKERT: Does Fermilab do the conversion of the PDF?
>> IAN FISK: Do you want me to quickly post it at PDF?
>> MATTHEW FEICKERT: If you don't mind, that would be grand, but you
can also do it after the meeting.
>> IAN FISK: If I don't have to do it right this second, I'll do it
after the meeting. Liz just joined, excellent.
>> LIZ SEXTON-KENNEDY: You know, Ian, the link in your email was
different than the link on the [indiscernible].
>> IAN FISK: The link to what?
>> LIZ SEXTON-KENNEDY: The Zoom meeting.
>> JOEL BUTLER: Oh, that could be a problem, and that would be my
fault, probably. But I thought I did them the same.
>> LIZ SEXTON-KENNEDY: Is there anyone in the other session?
>> LIZ SEXTON-KENNEDY: No, I was the only one there when I connected.
>> IAN FISK: Okay. So if I connect over to it to check, I will lose
the host privileges.
>> JOEL BUTLER: I'll check, if I can, okay?
>> IAN FISK: Sure, that would be great. Why don't we get started.
Can everyone see my screen?
>> STEVE GOTTLIEB: No.
>> IAN FISK: How about now?
>> STEVE GOTTLIEB: Yes.
>> IAN FISK: Excellent. A quick couple of notes introduction from
last week. So last week, followup, we heard from Petra Merkel about CPAD
and discussed the committee makeup and the selection process. I believe
with committee makeup and selection, that we preferred not to be too
prescriptive about the makeup. It seems from Petra's presentation, CPAD,
she proposes a slate of candidates for approval of the EB. I suggest that
we not do this. The community we're interacting with is very diverse and
there are a lot of constraints. If you look at the things we wanted to
balance against, it's large and it's a lot to ask a single person to try to
do that.
So I would propose that we, in the writeup of the committee selection
and followup, that we suggest that there be a nominating process and that
the executive board will choose, with a set of confined criteria that the
original founders thought were important for balancing things out, without,
again -- I think there were some texts and comments that need to be
expanded and cleaned up, also in this section. And I will work on doing
that.
There was -- I think in some ways we became more prescriptive, how
many theorists, which I think we should simply say we would like to have a
balance of theory and experiment. And again, a balance across other
attributes. And I'll put those in. That's one thing.
And then today I wanted to have a high level discussion on the two
next categories which are communication and partnerships, technical working
groups, with the hope of inspiring, having some discussions, there will be
some things that we are then inspired to include in the report as a way of
sort of jump starting this process.
In terms of a schedule, sticking with our normal schedule, we meet
again in two weeks, on February 22nd. And I would propose at that time
discussing career development and DEI activities, again, at a fairly high
level. And I'm asking would Amy or Mike Kirby or Gavin or Varena or Tulika
like to lead that part, you can all be contributors to it, if anyone wants
to sign up right now, they can, otherwise they can tell me later.
And DEI activities, the only people who signed up, signed up to
audited, not to lead. But if anyone would like to volunteer, that would be
great. And everyone is encouraged to contribute text to the document.
That's it from the sort of introductory section. Now we'll discuss
the two parts. What I've done is -- Maria?
>> MARIA ELENA: Yes. I'm not really clear what you want us to do for
text while we're still having the high level conversations.
>> IAN FISK: I think that -- I think what I would like is that as we
have the high level conversations on things like the committee makeup,
people can contribute to the text, and after today's high level discussion,
people contribute to the text of those two sections. I agree that until we
have had the high level discussions, probably it's hard to [indiscernible].
>> MARIA ELENA: Thank you, that helps.
>> IAN FISK: Anything else before we move on?
>> CHARLES LEGGETT: I think it would be good to have some talking
points, though, if you have some ideas, to add those to the text before we
discuss.
>> IAN FISK: Right, if people have talking points, that's great. I've
prepared some talking points for the next two sections because there wasn't
anything there. But if people have ideas, they should put them in.
Giordan? Let's see.
>> GIORDAN STARK: I guess my one question is, do we know, of the
future meetings that we have, which of those particular meetings will focus
on which section, just so that we can plan accordingly to make sure that
the sections we audited or are writing, that we're definitely there for
that meeting?
>> IAN FISK: Right. So on this slide I was planning for the next
meeting to cover career development and DEI. And then that actually brings
us -- that ends the -- that's the end of the big sections. I think that
we -- in some sense I think the meeting after that should make sure that
there aren't any holes, that there's not some great, large topic that we
think we can't address in sections of the report.
And then we should get into sort of more detail in writing after that.
All right. Anyone else? This is something that I don't know how much time
we'll spend on it. I'm trying to remember that about a third of the people
are in Europe and it's getting late. And so I intended to make sure this
is about 45 minutes. But we'll see.
So communications and partnerships. There were -- in terms of the
overall initial charge, there were a variety of questions -- Charles?
>> CHARLES LEGGETT: Go ahead.
>> IAN FISK: All right. For partnerships, communications and
partnerships, there were three main questions, like how should the panel
partner and with whom. And so promoting domain expertise and partnerships
between HEP institutions, including laboratories, labs, universities, to
address significant challenges, the role of the CPSC in encouraging and
facilitating strategic links to computing research institutions, industry,
and other scientific communities, and the role the CPSC should play in
facilitating communication between different programs within and across
funding agencies.
The purpose of these slides is basically people should jump in. The
funding agency interactions, judging from the interactions we had last time
with Petra, the relationship with the agency seems to have evolved and
we're driven by individual relationships with the agency representatives.
So in some sense I think we as a committee need to find ways for the
CPSC to make itself valuable to the agency. I would imagine workshops,
working groups, reports, community consensus building and feedback would be
valuable to the agencies and they would see the value of this committee.
CPAD also participated in an SBIR review, in a relatively formal way.
Peter?
>> PETER BOYLE: I don't know if I'm being a bit premature, but there
are in the industry -- so some of us have been using HPC for decades and
have industry contacts and some experience of how the industry is
interacting with domain science, both talent and video have various forms
of ecosystem development, they call it, where they have funds for workshops
that they call Hackathons for reporting, computing center activities where
they fund software developers in science domains to develop software and
all get together at meetings, road maps and things like that and exchange
best practice.
I think there's a role for CPSC in trying to both put people in touch
with industry programs for ecosystem development and in trying to make sure
that any knowledge of best practice that exists in any part of the
community has a forum for being shared, because I don't think we're all
talking together enough.
>> IAN FISK: I agree. As you will see, you're slightly ahead of your
time. We're going to address industry interactions in just a second.
>> PETER BOYLE: All of the asks are activities that happened, I think
that the HEP experiment has maybe not quite tapped into the ASCAR, people
in the ASCAR funds as much as they could, that should also be encouraged.
>> IAN FISK: That's an interesting thing that we associated with the
agencies themselves. So, yeah, I will include that, that's a good point
we'll include in the notes. The last item I had on this particular thing
was that CPAD had one or two post-docs that they basically were allowed to
allocate on behalf of the agencies. Basically I would like some feedback
from the committee, it wasn't entirely obvious to me whether the
cost-reward of this was positive for us, given that we have a lot of other
ways that we fund these groups, and this seemed like it might have been
like complicated. Tulika?
>> TULIKA BOSE: Yes, hi, Ian. I wanted to clarify these are actually
graduate students.
>> IAN FISK: Oh, okay.
>> TULIKA BOSE: The juror award, maybe what I can do is somewhere in
the chat here I'll put the link so that everybody can see what it is
actually about. And it funds a graduate student or maybe two using DOE
funds, and I think the interesting thing is that the student has to work in
collaboration with a lab person even if they're coming from a university.
>> IAN FISK: Okay.
>> TULIKA BOSE: So this is new in the sense that -- let's say there
are a couple of different kinds of awards, right? There are the DOE
traineeships in instrumentation, and then the JURA, I don't know how they
work together. The DOE has also started traineeships in computational,
which kind of have the same sort of relationship that you need to have a
lab partner to work with even if you are a university BI who has such a
traineeship award. There is no similar JURA award.
>> IAN FISK: Thanks, and I'll fix the slides. Maria.
>> MARIA ELENA: Yeah, I think this is very valuable, to be honest, for
the visibility of people doing their presentation mostly on computing
things. I had -- what's the word? My grad student who is mostly on
computing staff with defended this summer and he was seen as a bit of like
an incomplete student because his hardware was not a match, he did a lot of
analysis, I think raising the profile of students in competition will be
really helpful.
>> IAN FISK: Okay, I'm happy to actually even explicitly as a target,
I'm happy to put it in. Giordan, you had your hand up? Okay.
>> GIORDAN STARK: I think it was covered by Maria's point.
>> IAN FISK: Okay. So unless people object, I will make sure that we
put, if we can arrange for explicit graduate student support, we should do
that at the level. Very good. And then interaction with the universities,
national labs, I think somehow this was the least clear, which was what
will be our formal interaction. I would think workshops and reports helps
establish consensus. I also was imagining that one could if they wanted to
make a standing advisory group that we brought in upon request to either
universities or national labs.
Most of the national labs have computing committees of various kinds,
whether they're resource or advisory committees. And having the same set
of expertise, be able to sort of do comparisons against more than one place
might be a tremendous amount of work, it also might be very valuable.
Again, this is something that was sort of brought up as a suggestion.
Ruth?
>> RUTH V.: One thing that occurs to me that is, you know, something
where we could interact with the universities and national labs is, trying
to somehow encourage the creation of more bridge positions.
>> IAN FISK: Okay.
>> RUTH V.: Because certainly at least in LATIS, we have been very
successful, more so in nuclear physics than in particle physics, in getting
people in the door at universities and labs by leveraging, you know, funds
in various ways. And I think that that seems like, since universities
don't just hire computational people, when they're competing in an open
search with somebody who seems like a more experimental or theoretical
theorist, that sweetening the pot like this is a really big deal.
>> IAN FISK: Okay. I think we would have to have a discussion on
how -- like how we sort of guide the agencies who have the money to do
those sort of things, because of course --
>> MARIA ELENA: We have no money, I understand.
>> IAN FISK: Giordan.
>> GIORDAN STARK: I don't know if you can hear me, my connection goes
in and out.
>> IAN FISK: We can hear you right now.
>> GIORDAN STARK: So I was thinking kind of similar to what Ruth was
mentioning, that at the university level, it would be good to encourage
funding agencies to treat research --
>> JOEL BUTLER: I'm afraid now he's out.
>> GIORDAN STARK: Okay, back again. To treat research software
engineers like what we treat hardware engineers as right now. You know,
DOE tends to have funding for us to hire technicians separately from
engineers and post-doc students. It would be nice if software engineers
were seen the same way, rather than trying to train a cross student to be
an expert or not, to have them complementary with the research software, an
engineer who is an expert in that and help the graduate student develop
being more physics side of it rather than just learning all about a
specific tool per se.
>> IAN FISK: Agreed, I think to me, there's an interesting discussion
two weeks from now about career development which some of these things, at
least for me, fit in there in terms of elevating the value of the software
computing engineers in the eyes of the agency. Maria.
>> MARIA ELENA: Very quickly, I would also call out, in addition to
universities and national labs, national computing centers. And it is the
way we capture the NSF side of the computing centers, because DOE are going
to accept that at the international level already.
>> IAN FISK: Yeah, that's a good point, I will ask national computing
facilities as well. Ruth?
>> RUTH V.: So I just -- Giordan, I completely agree with what you say
about more direct funding for software engineers. I do want to add,
though, that we need to make sure that we're not saying that these are in
lieu of the physicists who need to also be very involved in writing the
code. I mean, certainly -- I mean, I wish Stefan was on this committee,
because he and I talk a lot about this and he can certainly give examples
where, you know, software engineers at CERN have made very little progress
on speeding up things that people down the hallway can help in an afternoon
by knowing the physics and knowing where to go.
>> IAN FISK: Charles?
>> CHARLES LEGGETT: I think I want to reinforce what Giordan is
saying. I think first of all, there is a significant difference between
how software is seen in national labs and how it is seen at universities,
in the sense that it is much easier to get a career in a national lab in
physics than there is in a university. Maybe we should defer this
conversation until we get to the data we talk about, career progress.
But I think one of our primary missions should really be to support
the progress of people who are doing software in the university
environments and really contribute to their professional development there
and make sure they have the support they need.
>> IAN FISK: That sounds like we're getting a consensus around that's
one of our primary issues of interaction with the universities. Peter.
>> PETER BOYLE: So it's not necessarily software or physics, quite
often you need a physicist who knows the physics to make the software. It
can be a fallacy that you can -- labeling them as distinct from physicists,
we probably need a lot of people who know their physics very well, to
conduct the research and develop the software that leads to the research,
quite often.
>> IAN FISK: I agree, I think we need to figure out -- in substance I
think they've been successful at this on the detector side, people don't
talk about them as engineers, they're talked about as detectors. We have
to figure out how they succeeded at doing that so people aren't classified
as software engineers.
>> It can become an stigmata that is held against you.
>> IAN FISK: Matthew.
>> MATTHEW FEICKERT: I think it's important to remember also that
research software engineers are not necessarily ones that are just coming
from, you know, some CS background and that many RSEs do come from hard
science and they aren't just coming into a vacuum. And I can speak from my
professional experience for the last five years that working very closely
with the RSEs have, who most of them, to be fair, are former particle
physicists, but not all of them, has been truly exceptional at moving
things forward at a rate that they wouldn't be able to do if there were
people like me and Giordan trying to do this work by ourselves.
I do think RSEs are fantastic and they shouldn't be viewed as just
software engineers but emphasize the research part of the RSE. Although I
do want to echo Ruth's point that while RSEs are amazing, I don't think
that we need to make it clear that RSEs are not the only career paths
forward, that we need to make sure that people who have strong research
questions also care about the software and computing are still represented.
>> IAN FISK: Thanks. Before we go to Verena, maybe we need to have a
dedicated discussion on this, because I guess sometimes we should establish
what the goal is with the interaction with the universities, because one of
the challenges of research software engineer is it's a job which is very
valuable to us, it's very valuable to science. It will not turn you into a
faculty member, typically.
The question is would we like the universities to value this set of
skills in addition to domain science with the idea that people have the
same opportunities to be domain science professors or whether we want to
emphasize the fact that there's a lot of other places you can go and be
gainfully employed.
I think we may want to have more than one of these approaches. But I
think one of the things we need to encapsulate is sort of what our goals
are a little bit, but maybe not -- we may not get consensus today. Verena?
>> VERENA: Thanks. Just one quick thing I wanted to say, I wonder if
there might be a role for this panel, helping sort of collect data on
education and employment in these areas, and also, you know, it might be
possible to conduct surveys and things like that, to sort of gather some of
the information about what R&D people are doing, what are kind of the
picture out there, that sort of thing, could also be useful information for
future folks and recruitment and that sort of stuff.
>> IAN FISK: Great. Tulika?
>> TULIKA BOSE: Yeah, I just wanted to say, Matthew nicely summarized
somewhat I wanted to say. I see RSEs as an additional career pathway, not
so say -- they're just separate from faculty and scientists at labs, we
absolutely need them, and we need to emphasize that. But RSEs are a
different path. And in particular, RSEs at universities, because that's
where the graduate students are, the undergrads are.
And having them close to the universities where they can work with
this is what I consider important for training in the future.
>> IAN FISK: Agreed. Maria?
>> MARIA ELENA: I want to advertise that this is also crucial to the
"I" conversation in the sense that I know a lot of people who have
effectively a background in hard science and software engineering for
reasons such as, for me personally, I was the first generation high school
graduate, and so I always thought, I still do, that I need to be able to
get a real job outside of academia if things go bad.
A lot of people with dual backgrounds are from similar immigrant
background, first generation background, low income, minorities, et cetera.
So that social justice conversation.
>> IAN FISK: Giordan?
>> GIORDAN STARK: So I was just going to mention for an example what
I've seen that seems to be working. University of Arizona has something I
haven't seen anywhere else in the world, they have two different tracks for
faculty there, one that they call tenure track which is your typical one,
and the other one called career track. And in the career track, they have
either research faculty, hardware faculty, or software faculty.
And that's kind of an interesting model, that I haven't actually seen
anywhere else. It basically gives you all the benefits and privileges of,
you know, being a faculty or professor at the university, but with just
limited other things like maybe you don't teach or maybe you can't have
student [indiscernible].
>> IAN FISK: Yeah, that's an interesting model to call out. I think,
going back to the interactions with the funding agencies, historically,
looking back decades, occasionally the agencies become hostile toward
whatever sort of soft money research faculty positions, which can be
devastating for these kinds of jobs.
In some sense, having a commitment from the agencies that this is
valuable to the field and needs to be maintained over generations of
experiments might be a message that may not be received but it maybe should
be sent.
Peter.
>> PETER BOYLE: I've had experience supervising RSEs in the UK for
quite a while. Some examples of career tracks, one ended up in Google, one
ended up at Intel, and the other, the successful one went on to post-doc
using the skills, onto a faculty position. I dispute the idea that RSE is
necessarily a bifurcation away from an academic path.
>> IAN FISK: Agreed. Any other points on this? Okay. Let's go to
the next slide, which is interactions with industry. So I was trying to go
through this. From my perspective there's a couple of successful
interactions with industry collaborations. The one that I know most is
CERN openlab, which is project-driven and focused, intended for the
partners and CERN with technical solutions.
It tends to be pretty short to medium term. It's not really blue sky,
because it has to be project driven and there has to be things that are
accomplishable for the partners and the community. In this committee we
might want to engage more on sort of future technology directions rather
than industry collaborations. So an industry technology forum, as Peter
was mentioning earlier, this might be an opportunity for things like
industry engagement in terms of Hackathons or in terms of training.
But I wasn't -- like I'm sort of opening the floor for discussion as
to how people will see this part working, because I think this is an
opportunity, but if I look at the places that have succeeded with this
before, CERN openlab has been doing this for 20 years, there's a tremendous
amount of legal umbrella in terms of how industries work with each other
and how they work with the science community, when you get into the area of
projects and resources being used, which is some of those things have
become more relaxed if you're talking more about strategy and more about
training and more about sort of the future.
So I open the floor for discussion. Peter.
>> PETER BOYLE: I've in the past collaborated with IEBA, one of their
super computers, I've worked with Intel, legal constraints in DOE labs tend
to make future technology difficult to deal with. The only way I've seen
working in the DOE labs, through the path forward program where DOE domain
scientists could get on Intel's hardware before it was built, in simulation
and so on.
It may be that engaging with the HPC development program for the labs
is probably the best way to do this from within the lab sector, within the
university sector, direct collaboration with industry is more possible but
it's kind of hard within the DOE lab system to legally get things set up
because of all the IP concerns.
>> RUTH V.: I guess I would also add, as a scientist, it can be hard
depending on what the arrangements are regarding NDAs and open science and
whatnot. Certainly I see that in regards to the super conducting quantum
materials signed whatever center at Fermilab, once you join those meetings,
you're now forced to be silent about lots of stuff that actually be really
good for science knowledge and whatnot. Which is why I don't go.
>> IAN FISK: Yeah, I think there is -- in technology forum,
[indiscernible] technology forum is worthwhile if people can't talk about
things that are commercially protected. Charles.
>> CHARLES LEGGETT: So I apologize [indiscernible], I kind of lost
reception here for a while. I've been involved in a number of different
industry partnerships. Some of them through LBL with the NISAP program
which have been incredibly productive. We had a recent one Nvidia which
have lasted for a couple of years, and it's been really useful for us and
Nvidia.
I've also worked with Intel through their ECP at ANL and in many ways
that one has been very restrictive because of the NDAs. [Indiscernible] of
getting into the NDAs took nine months. And it was a very arduous task
dealing with lawyers at different labs and different companies.
So, you know, there are a lot of both positives and negatives of
dealing with industries. If you can avoid some of especially the NDA
restrictions, it can actually be very, very beneficial.
>> IAN FISK: Is there anything else on this particular area? In terms
of trying to figure out what I'm going to write in, the points to bring
out, I think there will be open questions in this particular section about
how we expect this panel to interact with industry and at what level,
because I can imagine a couple of different -- okay.
Last slide in this section, which is interactions with other
crosscutting organizations, so in terms of organizations, there are things
like HSF, there's HEPiX, agency funded long running projects and institutes
like A3D3 and Iris HEP. It occurred to me that one thing is that a survey
and report about where there are gaps in IND activity might be of value.
But I wanted to hear what other people had to say about how they might
sort of view the interactions and also what organizations I'm simply
forgetting. Charles, you have your hand up from before? He can't hear.
Liz.
>> LIZ SEXTON-KENNEDY: Yeah, in terms of people you don't have listed,
I won't say that you forgot them because they haven't yet formed yet.
There is the ICFA panel, the ICFA subpanel on software and computing and
data life cycles. Do you know what I'm talking about?
>> IAN FISK: I do not, but I can look it up.
>> LIZ SEXTON-KENNEDY: Okay, yeah. You do know, probably, that there
was an ICFA panel on data preservation, right? So at the last ICFA in
Daisy, they agreed with a proposal to expand the scope and be a panel for
data from, you know, cradle to grave, but, you know, a lot of it has to do
with the software and computing and the support thereof.
So it's kind of like an international reflection of this panel, of
this group, for Snowmass.
>> IAN FISK: Okay. Giordan.
>> GIORDAN STARK: So I wanted to bring up here, I think there are a
couple of differing ways that this interaction can be seen. One way is to
support these organizations in the future. But the other way is also that
some of these organizations, for example HEP software foundation here,
organize things such as boot camps and tutorials.
This is something CMS and Atlas also do, you can imagine having some
consolidated version, at least in the U.S., both Atlas and CMS can come
together, Fermilab, for a week for some sort of tutorial hosted by the
foundation. They can have breakout sessions dedicated to software specific
to the experiments themselves, but there are still pieces of some of these
tutorials that we're doing that are kind of reinventing themselves.
So I think it will help if we -- on this particular slide, if we
understand what sort of topics we're talking about here. We need to talk
about organizations that are primarily focused on workshops and boot camp
and other organizations which are primarily focused on developing software
for particle physics.
Some organizations kind of do a mix of both. But they also have
different rules and responsibilities for what CPSC should be supporting.
>> IAN FISK: Right. I guess the question, when you say "supporting,"
how do you -- like what -- like publicizing or in terms of trying to
raise -- like, we have no -- we have no financial support. So I guess,
what do you mean by "supporting"?
>> GIORDAN STARK: That's kind of what I mean on some level. What
frustrates me is sometimes these organizations only exist for a certain
time and then it becomes some new organization after the fact. There's
kind of maybe a loss of continuity, maybe not necessarily true, but it
seems like that to me.
>> IAN FISK: Say, so I think in some sense one of the things this
group could do in terms of support would be to document that the field
would be better off if we had sort of longer term rather than project
driven support for some of these activities, because there are -- like even
though things that we think of as institutes, they tend to be of limited
life. Peter.
>> The common thing between the organizations that you have there, the
HSF, HEPiX, I was half, maybe more, AD3D, there's some sense of trying to
use them to engage with the larger community for one or more software
computing topics. And that of course I think, you know, has value.
And so in the sense of whatever the charge of the panel wind up being,
again, it won't have direct funds or likely won't have, you know, those
things should be seen as means of gathering and propagating to the U.S.
funding agencies, notions about what the community needs.
That's certainly what HSF has done, HEPiX, what was the mandate of
Iris HEP.
>> IAN FISK: From my expect, the question we are to ask is how this
panel can benefit these organizations who are clearly doing good things in
the field of software for computing. If one of those is to sort of
document what's needed and how these things are being met by those groups,
that probably is a valuable service, that's something that would be within
the scope of this committee.
>> G.J. PETER ELMER: Document and also leverage, document that it's
leveraging those rather than trying to do things redundantly.
>> LIZ SEXTON-KENNEDY: Maybe one thing could be some crossover between
membership. You know, that, you know, this panel sent one person to HSF
meetings and vice-versa, something like that. Just so you know what each
other are thinking and can communicate that.
>> IAN FISK: That would be a formalizing interaction. Other things
for this before we move on to technical working groups? So technical
working groups was the next section. And if you look, again, the high
level questions we're asked in the charge, the first was, what are the
methods by which the CPSC can help the community coordinate its approach to
software and computing issues, what mechanisms should the panel use to
communicate meetings, town halls, workshops, studies, tutorials, training?
With what entities should the panel communicate?
It occurred to me that technical working groups is an area where some
of those are applied. They're an opportunity to facilitate communications
across labs and university groups, to provide training and help input on
the needs for R&D. I imagine they would be formed by the CPSC but would
have membership from outside because we say the committee has 12 or 15
people, there are a lot of technical topics that people want addressed so
they would be organized to be larger.
I think that's consistent with what they do in CPAD. Forming,
operating and closing groups, again, this is a proposal, people should feel
free to say this is a stupid proposal or propose an alternative. The
topics would be chosen by the CPSC itself, the technical areas are likely
to change over the course of time.
I can imagine they would be either focused meaning limited duration or
standing meaning open duration groups. They should be of general interest
to the community. And I would recommend, in the recommendations section of
the charge, that they don't have more than five operating simultaneously
simply because. And Peter.
>> G.J. PETER ELMER: Maybe I'm just allergic to meetings. But
technical working groups always kind of seems to sort of open-ended to me
in the sense that -- okay, I mean, the thing -- one of the things that we
sort of adopted, again, in six, seven years, is this notion of a task
force, a set of blueprint meetings where things are formed with sort of
specific topics to explore and finalize things with a document, right?
And they're sort of much more focused and goal-oriented, right?
>> IAN FISK: Okay, so that would be a vote in the left hand column for
focus. So focus groups might operate for a year, and generate a report as
a conclusion, narrower topics, it's an opportunity to influence R&D
direction and strategy and more topics can be covered because they're
short.
>> G.J. PETER ELMER: And they can have crisper outcomes too.
>> IAN FISK: Yes, I think a task force almost by definition is
designed to be of limited duration. They tend to be a fixed task. Maria.
>> MARIA ELENA: I was going to make the exact same comment. I don't
think in my understanding of this new committee, it's not the committee
that does actual work. I don't want to spin off like a real research
activity here that keeps going and then, you know, it's already a
committee, then if we have technical working groups that are standing,
basically the committee has subcommittees, and then it becomes hard to
track who is doing what and what their conversations are and what the point
is.
So I think that, you know, doing task forces, especially if DPF asks
us to do them, that will be very valuable. I would not set up standing
committees. That makes me a little nervous both in terms of diluting the
visibility of this lab work and in terms of dispersion of the work we do.
>> IAN FISK: Okay, thanks. I guess I open it to like, is there anyone
who feels strongly that we should have standing committees? If not, we
will then suggest that in the report, that we will be writing for task
forces, focused.
>> PETER BOYLE: What about an advisory panel, the idea that there's
some -- this is very HEP facing and they have advisers from within the
computing expert community in the U.S., and specifically ask NSF, people
like the director of TAC computing center, there are various other people
who are experts in high performance computing software, might be useful to
have as members of an advisory panel or something like that.
>> IAN FISK: Yeah, to me that's a little -- when we were talking
before about the interactions with the labs and the universities, I could
imagine that having a standing advisory panel might be a very valuable
thing. In some sense that would be a little more open-ended and somehow it
might be separate from the concept of the technical working task force.
>> PETER BOYLE: Exactly, these are people who might have expertise
that's really useful to draw on.
>> IAN FISK: Yes, it's a good thought. Peter. Other Peter. Peter
Elmer.
>> G.J. PETER ELMER: So the problem is, again, the sort of breadth of
the scope. Software computing is different things. If there's a high
level advisory panel that sort of informs the eventual panel here, it
probably should be about which task forces and which objectives to give --
to start, rather than -- I mean, what could they advise on if not, you
know, the strategic task forces to start?
>> IAN FISK: Yeah, and that's sort of -- I would also imagine that
they might be able to give advice on sort of where the field was not making
the right investments in research as a report to the agencies but maybe
it's a similar set of decisions. Tulika, you had your hand up but you put
it down.
>> TULIKA BOSE: I did, I guess I realized it was maybe not relevant
now. I was going to talk about inclusion, but that might not be a
technical committee, that's why I put my hand down.
>> IAN FISK: Yes, that's a committee that needs to be persistent. But
the technical ones -- it would not be technical.
>> TULIKA BOSE: Right, yeah. We can talk about it next time.
>> IAN FISK: Yeah. Peter.
>> PETER BOYLE: Maybe to have an industry representative on the panel.
That could be helpful.
>> IAN FISK: I guess I would like to raise one question, how do people
think there is a distinction between an advisory panel for protective items
as well as a panel of people who are fairly expert?
>> PETER BOYLE: I was thinking of people who aren't in HEP.
>> IAN FISK: So an external advisory committee.
>> PETER BOYLE: Yeah.
>> IAN FISK: Okay. The other Peter, what's your view?
>> G.J. PETER ELMER: That's how I interpreted his comments. Indeed
that's why I think there can be interesting -- that we're sort of missing
something and have been, and color our thinking about which task force,
blueprint, you know, things that get started.
>> IAN FISK: That might answer one of others questions we have which
is how we interact with other fields of science, that would be a concrete
way of doing that, so perhaps that solves another problem.
>> G.J. PETER ELMER: You probably catch a little flavor in what I was
saying, that things should be -- you know, we always need two things, we
need the things where we're sort of informing each other about what's going
on, but my take on the flavor of what this thing could be could have a bit
more sort of Action Jackson in terms of, you know, being able to take the
lead on trying to make something happen, again, potentially in partnership
with other entities.
>> IAN FISK: The next slide is simply, I was trying to figure out some
potential topics in both categories, and I believe that it probably -- this
maybe just drives home the idea that having focused task forces is probably
better because things like standing, things like software, processing
technology, evolution, theory calculation and simulation, which are very
broad topics and last a long time, could be more focused. I found it much
easier to define focused technical ones rather than standing. So to me
that sort of further drives home the point that we should probably be
thinking about focused. Giordan.
>> GIORDAN STARK: One quick thing that I think is going to somewhat
important as a collaboration, is thinking about the technologies on which
we run software on. So the fact that now we have this development of M1,
M2, M3 chips from Apple, for example, and that we need perhaps some sort of
probably a standing committee at this point, that's always going to be
keeping on top of the industry development for new processors and integrate
that on some level.
I don't know if it makes sense to have that as a focused, one-year
thing, because there's always going to be some sort of new development
there, probably.
>> IAN FISK: Yeah. I guess for me, maybe other people should comment,
I think it would be interesting to focus that sort of technology evolution
into the advisory panel with connections with industry, if we could, the
idea being each of those might turn into specific task force, like for
instance you mentioned M1, M2, M3, to me there's a larger item, which is
how one integrates CPUs and GPUs together in the same features which is
sort of what Apple has already done, AMD and Nvidia are all doing the same
thing.
It's interesting, it has a lot of impact on how we're going to program
these resources and how we think about them but it would probably
eventually turn into a task force to figure out where we're missing
research. Peter Elmer.
>> G.J. PETER ELMER: Yeah, I mean, the last bit what have you said is
I think the critical part, is that this eventual panel can do anything
itself, right? So it really has to be constructed in a way that it's a
task force and documents that come out of that, that it basically enables
the funding agencies to fund the right things to make something happen, or,
you know, fund a workshop that brings in the right people to make a
discussion happen.
But the panel itself isn't --
>> IAN FISK: Agreed. Charles.
>> CHARLES LEGGETT: So it seems like there's a lot of overlap between
this and the HEPiX tech watch group. We should at least make sure we're
not duplicating effort or leverage the work of others.
>> IAN FISK: That's an interesting point, maybe having it as part of
the advisory infrastructure, that we weren't duplicating effort
[indiscernible] other people are doing. Peter Boyle.
>> PETER BOYLE: I think the technology discussion, we could add a
bullet point along the length of languages, paradigms, and platforms.
>> IAN FISK: Yes. I will add that. Charles's hand is still up. Are
you wanting to speak, or left over ?
>> CHARLES LEGGETT: Sorry, that's left off.
>> IAN FISK: It's 10:00 at CERN. That's the last slide I had for the
day. Is there other business before we adjourn? Maria.
>> MARIA ELENA: Yes, so I was going to offer that I can prepare for
the DEI conversation in two weeks.
>> IAN FISK: Thank you.
>> MARIA ELENA: Whatever we discuss today, because that came up three
times already, I think we have enough to get going. So you can call up
those notes in the document or we can confer offline.
>> IAN FISK: Excellent, thank you, that's great. And I will ping some
of the people who agreed to participate in career development about whether
they can also help lead the discussion on that next time too. Next time is
two weeks from now.
I will spend some of that time trying to compose the thoughts that we
had today into text and bullets, into the document. And people should feel
free to expand on those or correct my -- anything I got wrong. Other than
that, I'll see you in two weeks.