Intro
This page is devoted to the telecon on Feb 5th, 2016 at 10am PT.
Call-in info:
The purpose of this telecon is to generate the questions to put into a survey. The survey will then be sent out to all participants.
Topics
Access and Location
In Phase 1A, we had a single axis called Access. Several people felt this conflated with a distinct axis (Location). As a result, we split Access into two axes in Phase 1B (Access and Location). In Phase 1B, there was some discussion to merge them back. Amit Chourasia recommends having a single "Data" axis with sub-axes for these points.
I suspect this will ultimately be a survey question point, but I believe this should be discussed in the call to help thoughts mature before going out for a vote.
Other discussion points not related to location/access conflation or types of locations:
- Matthieu Dorier suggests direct access is better phrased as shared.
- Daniel Weiskopf recommends we better use terminology from parallel computing.
- Ken Moreland points out that access can take the form of read-only vs read/write (i.e., steering). This is not reflected in the current form. Janine Bennett expands on this point and brings in the concept of hazards (RAW/WAR). (Hank agrees that hazards are an important concept that have not been represented in the discussion so far.)
Regarding location, other comments include:
- Berk Geveci notes "If the simulation keeps part of the data in an on-package fast memory (or GPU memory) and we have to move it to main memory, is this direct access? I prefer to think in terms of the distance of the in situ code to the simulation data. You can extend this analogy to the Location section in theory - over the network is just extra distance to the simulation data." Sean Ziegeler also comments on this point. He asks the question "does the viz _take_ resources away from the simulation?" as a possible differentiator.
- Bernd Hentschel notes that HW is changing quickly, and we should future proof our discussion.
- Ken Moreland introduces the notion of proximity. His off-the-top-of-his-head categorization:
- Different facilities spread across the world.
- Different systems in the same facility (separate computation and vis clusters).
- Different nodes in the same system.
- Different subsystems in the same node (CPU and GPU).
- Dedicated processors in different socket on the same node.
- Dedicated cores in the same processor.
- Time sharing or dynamic allocation on the same cores.
- Janine Bennett believes the discussion is more confusing than it needs to be because the initial terms are wrong. She believes "Execution Spaces" and "Memory Spaces" are a cleaner fit.
Synchronous vs Asynchronous
Folks seem to be in agreement that this is a needed axis, but the current description seems to be too limited for people to rally behind. As Ken Moreland says, this axes is really about "when things are running". The group should discuss the best way to characterize this. Timo suggest that "Synchronous just means the next time step has to wait for the last of these to finish", which folks mostly agreed with. I again note Tom Peterka's Time Division / Space Division.
Output Type
Lots of good discussion here, but it seems like it will need to go to vote. The group needs to help finalize the description.
Operation Controls
Surprisingly, this section seems to be converging. There was much discussion of steering. Steering was also mentioned in access. Group should discuss where it goes
Interface
- Paul Navratil notes that Interface is a poor term, since "(1) the interface to the vis capability and (2) the interface to the simulation data." This axis is dealing with the former. How to improve?
- Ken Moreland makes a distinction about general purpose code that can be used by many sim codes vs custom code for one sim code. Hank doesn't view this as part of this axis, but it does seem like something to distinguish. (Although it may not change our notion of the underlying system.) Andy Bauer also asks if "framework" should be an option here.
- Steffen Frey believes this axis is non-orthogonal with Access. This should be discussed. [(SF) I felt that the positioning on the Access axis possibly has some direct impact on the Interface axis. After todays discussion about Access/Proximity and seeing where this is heading, I don't see any issues any more in that regard.]
- Joseph Cottam mentions a non-represented option where the integration is automated. I believe his intent is analogous to how Mesa spooks the GL interface ... you think you are doing GL, but you actually get Mesa. Tom Fogal's in situ work would be an example of this approach.
- (WB) a couple of comments. The high-level concept here seems to be about the mechanism for control interface and data movement between sim code and in situ methods/infrastructure. Whatever term is chosen, it needs to be carefully defined so that people don't misinterpret the meaning within this context. E.g., we could mean "API" when we say "interface," but someone else might interpret "interface" to mean something different, like what is the mechanism for moving data (data bytes or a pointer to data bytes) between components.
Concurrent vs In Situ
- Should this be a survey question? (Many folks contribute older related work that support the notion that in situ may not be the correct name.)
Other
- Rob Sisneros praises these points "adaptivity of data structures, as in zero-copy (like SCIRun's templates) vs making a copy and putting it in your own layout" and "adaptivity across simulation codes, as in custom code to solve one stakeholder's problem vs code that scales to many simulation codes" and encourages us to find homes for them in the main axes.
Comments
- (CDH) Maybe this is part of the plan, but I didn't see it explicitly mentioned: As we move to Phase 2, will there be an exercise to look at a (small?) set of existing papers from the community and try to map their concepts onto our agreed axes. One of the goals of this effort is to resolve confusing cases, it seems this exercise is necessary to check the clarity and expressiveness of our solution. Are there other ideas that can help? (Where are the unit tests for our new nomenclature :-) )
- (MW) I just want to amplify the "unit test" comment/request. For example, I'm having a hard time reconciling some "new" language features (tasklets, coroutines, etc.) with the definitions above. I don't think the google Go runtime should count as being in situ, but I don't see how it's clearly distinguished at the platform (ie access/location) level. Some examples of "in/out/other" would help greatly.
Log
Want to communicate you looked this over? Add your name to the list below:
- (CDH) -- Cyrus Harrison
- (MW) -- Matthew Wolf
- (HT) -- Bernd Hentschel
- (AB) -- Andy Bauer
- (WB) -- Wes Bethel
- (LL) -- Laura Lediaev
- (MD) -- Matthieu Dorier
- (SF) -- Steffen Frey
- (TP) -- Tom Peterka
- (SZ) -- Sean Ziegeler
- (RS) -- Rob Sisneros
- (FS) -- Franz Sauer
