Teleconference 2022-02-16
Jump to navigation
Jump to search
Attendees: Ken Moreland (ORNL), Terry Turton (LANL), Silvio Rizzi (ANL), Ollie Lo (LANL), Mark Bolstad (SNL), Manish Mathai (UO), Dave Pugmire (ORNL), Hank Childs (UO), Tushar Athawale (ORNL), Sujin Philip (Kitware), Berk Geveci (Kitware)
ECP Updates
- Ken will be gone the next 2 weeks
- No meetings during that time
- ECP Annual Meeting
- Officially now virtual, week of May 2
- Call for BoF, Breakout, Panel, Tutorials: Due Feb 23
- Participating in tutorial with Alpine
- Participating in DAV BOF during Community BOF days
- Crusher test and development system for Frontier
- Kitware now has access
- ECP management is wanting bi-weekly updates on early access progress
- Will be biweekly updates on confluence
- No NDA (limited communication for Arcticus)
- Plan to summarize progress discussed in this meeting
- https://confluence.exascaleproject.org/display/1ST/2.3.4+Data+and+Visualization+Exascale+Porting+Status
- Software sustainability town halls
- Let's think about possible highlights
- App engagement
- Success with porting (e.g. run on Aurora)
- Engagement with other ST teams (e.g. using Kokkos)
- WDM
- Possible highlight slide on particle advection with WarpX (Matt)
- Some work with MFIX. Going to execute on Summit. Might wait for run on early access machine before highlight.
Porting Activities
- https://wiki.jlse.anl.gov/display/inteldga/ECP+2.3.4.13+VTK-m
- https://frontier-coe.atlassian.net/wiki/spaces/FCOE/pages/1161625609/Porting+Activities+O21
ECP task updates
Roundtable
LSSw whitepaper: a big part of Jim's response is a question of whether everything should be in VTK-m or if there is still stuff that should be otherwise. We should give some thought on what should or shouldn't be in VTK-m and have a reasonable argument for it.
R&D100?
- Thinking of submitting for 2022
- Big stumbling block: needs to be "created" between Jan 2021 to March 2022
- Plan: Release VTK-m 2.0, do a copyright assertion
Rename master branch?
- Need to wait for some changes to git before the transition (for some automated features of repo).
- Can we for a time have a master that mirrors the new default?
- Don't know, but seems possible. Will have to look into that.