Difference between revisions of "Teleconference 2022-08-24"
(Created page with "Attendees: == ECP Updates == * Note from ECP: be sure to spend out FY23 ** There will be no carryover into FY24 (even if there is some funding) * Get key people on AD alloc...") |
|||
| Line 1: | Line 1: | ||
| − | Attendees: | + | Attendees: Ken Moreland (ORNL), Ollie Lo (LANL), Abhishek Yenpure (Kitware), Silvio Rizzi (ANL), Mark Bolstad (SNL), Nichole Marsaglia (LLNL), Berk Geveci (Kitware), Jay Wang (ORNL), Terry Turton (LANL), Sujin Philip (Kitware), Vicenta Bolea (Kitware), Tushar Athawale (ORNL), Hank Childs (UO) |
== ECP Updates == | == ECP Updates == | ||
| Line 32: | Line 32: | ||
Dave Pugmire is working on adding fields to PartitionedDataSet. There can be a field that is attached to the entire thing and there can be a field with an entry for each partition (for example, for storing the level of a block in an AMR dataset). We are not sure what to call these associations. We currently thinking AllPartitions and Partitions, but we are not sure that is clear. We are also not sure how to handle the WholeMesh association for DataSet. Is there a better name for that that would suggest the field is attached to a single dataset rather than over all partitions? | Dave Pugmire is working on adding fields to PartitionedDataSet. There can be a field that is attached to the entire thing and there can be a field with an entry for each partition (for example, for storing the level of a block in an AMR dataset). We are not sure what to call these associations. We currently thinking AllPartitions and Partitions, but we are not sure that is clear. We are also not sure how to handle the WholeMesh association for DataSet. Is there a better name for that that would suggest the field is attached to a single dataset rather than over all partitions? | ||
| + | |||
| + | After some discussion, we came up with the following plan. First, we will rename the WholeMesh association to WholeDataSet, which will make it (somewhat) more clear that it is specifically associated with a DataSet object. Second, we will add an association named Partitions that will be used for a field with one entry for each partition in a PartitionedDataSet. Finally, we will add an association named Global that when attached to a PartitionedDataSet has values that relate to the data as a whole (for example, a time stamp). | ||
Should we change the implementation of CoordinateSystems to actually be stored as Fields? | Should we change the implementation of CoordinateSystems to actually be stored as Fields? | ||
Latest revision as of 14:19, 24 August 2022
Attendees: Ken Moreland (ORNL), Ollie Lo (LANL), Abhishek Yenpure (Kitware), Silvio Rizzi (ANL), Mark Bolstad (SNL), Nichole Marsaglia (LLNL), Berk Geveci (Kitware), Jay Wang (ORNL), Terry Turton (LANL), Sujin Philip (Kitware), Vicenta Bolea (Kitware), Tushar Athawale (ORNL), Hank Childs (UO)
ECP Updates
- Note from ECP: be sure to spend out FY23
- There will be no carryover into FY24 (even if there is some funding)
- Get key people on AD allocations
- The following AD codes will be running early on Frontier
- LatticeQCD, ExaSMR, ExaSky (HACC), CANDLE, EQSIM, Subsurface, WDMApp, WarpX
- For WarpX: they have already run their KPP-1. Further KPP-3 will likely be in ALPINE's project (CSC340).
- If we are providing software assistance for any of these, or we are planning a KPP-3, we should have a member as part of their allocation.
- The following AD codes will be running early on Frontier
- 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
- 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://confluence.exascaleproject.org/display/STDA05/Porting+Activities+O21
ECP task updates
Roundtable
No meeting next week (DOECGF).
Dave Pugmire is working on adding fields to PartitionedDataSet. There can be a field that is attached to the entire thing and there can be a field with an entry for each partition (for example, for storing the level of a block in an AMR dataset). We are not sure what to call these associations. We currently thinking AllPartitions and Partitions, but we are not sure that is clear. We are also not sure how to handle the WholeMesh association for DataSet. Is there a better name for that that would suggest the field is attached to a single dataset rather than over all partitions?
After some discussion, we came up with the following plan. First, we will rename the WholeMesh association to WholeDataSet, which will make it (somewhat) more clear that it is specifically associated with a DataSet object. Second, we will add an association named Partitions that will be used for a field with one entry for each partition in a PartitionedDataSet. Finally, we will add an association named Global that when attached to a PartitionedDataSet has values that relate to the data as a whole (for example, a time stamp).
Should we change the implementation of CoordinateSystems to actually be stored as Fields?
Status of dashboards
- The "external" buildbot builds no longer run.
- dragnipur already moved to new system.
- What is the status of osheim? It is not run on buildbot but not in the runners either.
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.
