February 2017 - mpiwg-tools - mailman3.cels.anl.gov

Re: [mpiwg-tools] Tools topics meeting reminder: Jan 19, 2017
by Marc-Andre Hermanns 02 Feb '17

02 Feb '17

Hi Jeff, > Keep in mind that I proposed a *tuple*, not a single value. You may be assuming we can split up the uint64_t into a tuple -- but I just wanted to make sure we'r talking about the same thing. I did not want to mandate a specific length. The way I understand it is that the ID is an integer of some length, where parts can be masked and queried for information. If I look at UUIDs, they are currently 128-bit, so they feel like a 2-tuple of 64-bit integers. What we need to discuss is how many bits we need to encode the information we want to be encoded in such an ID. > The tuple was (vendor ID, part ID, event ID). I think you're mainly asking about the vendor ID part. In my last mail, yes, but I do acknowledge that additional fields are necessary. I just asked about the vendor ID, as that is the one mostly regulated, right? The vendors are free to use the remaining bits as they see fit, right? If we could have some additional bit ranges in the ID with additional meaningful semantics, that would be great, and we should discuss what we might need. > In libibverbs, such vendor IDs are typically the Organization Unique Identifier (https://en.wikipedia.org/wiki/Organizationally_unique_identifier and http://standards-oui.ieee.org/oui/oui.txt) > > I.e., we could just leverage this existing IEEE standard -- no need to print all this stuff in the MPI standard itself. Yes, I read about the OUI. As far as I know, these are _bought_ from and controlled by IEEE. How would an MPI vendor obtain one of those to use for software events from inside the MPI? Cheers, Marc-Andre > >> On Feb 1, 2017, at 3:24 AM, Marc-Andre Hermanns <hermanns(a)jara.rwth-aachen.de> wrote: >> >> Hi Martin, Hi Jeff, >> >> my apologies for taking so long to reply. >> >> As far as I understand and remember we discussed these universal IDs >> in both contexts: (1) source ids and (2) event types. >> >> Such an ID would allow a tool to cast a pointer to an info struct to a >> specific known struct revealing additional information. >> >> In context of Martin's comment on easy integration with the existing >> API, I could imagine a call like >> >> int >> MPI_T_event_get_uid(int index, uint64_t* uid); >> >> 'uid' being the short form of "universal id". It would be easy to >> provide such a call for the other parts (performance/control >> variables) of MPI_T as well. >> >> There are some questions arising from this vendor prefixed ID: >> 1) Which entity issues the prefixes to ensure we don't have duplicates? >> 2) How would a vendor apply for/request a prefix? >> 3) Where would the issued prefixes be listed? In the standard? >> 4) Would the rest of the ID be free for the vendor to use, or would we >> need to reserve some bits? >> >> We should use this weeks call to discuss this further. >> >> Cheers, >> Marc-Andre >> >> >> On 22.01.2017 10:55, Schulz, Martin wrote: >>> Hi Jeff, >>> >>> Don’t get me wrong - I wasn’t proposing to push this onto the long bench and do it after MPI-4. There is no reason to not bring this up in time for MPI 4 or even develop it together. I was just suggesting to decouple this from the actual events ticket for two reason: >>> - I think the events part is fairly far along and probably easily accepted and I was suggesting to not push it out because of this >>> - We need a clean retrofit solution anyway to make it work for variables - we can the use it for events as well. >>> >>> At the end, this is up to Marc-Andre since he is doing the work :) >>> >>> Martin >>> >>> >>> >>>> On Jan 20, 2017, at 6:41 PM, Jeff Squyres (jsquyres) <jsquyres(a)cisco.com> wrote: >>>> >>>> My $0.02: we know that there are limitations with the way we've been approaching this stuff for years (over specifying, e.g. PERUSE, which got shot down/shunned, and under specifying leads to tools without any semantic information and implementations that are not incentivized to do anything because the Forum doesn't like "creative" uses of the API, even if they give semantic information to the tools [who are asking exactly for this semantic information] -- e.g., usNIC BTL use of MPI_T variables on a per-interface basis). >>>> >>>> Why not learn from these limitations and propose something better? >>>> >>>> My point: if we're going to do this, do it right. Let's not have more buyer's remorse after MPI-4 because the new API (still) doesn't give tools any rich and/or semantic information. >>>> >>>> ---- >>>> >>>> Keep in mind that I proposed two different ideas: >>>> >>>> 1. The idea of identifying event sources by a (vendor ID, part ID, source ID) tuple >>>> 2. The idea of a sanctioned extension mechanism >>>> >>>> Note that neither of these are new ideas; they're borrowed from best practices that just happen to be (just barely) outside of the realm of MPI. >>>> >>>> They're still best practices, though. >>>> >>>> >>>>> On Jan 20, 2017, at 12:03 AM, Martin Schulz <schulzm(a)llnl.gov> wrote: >>>>> >>>>> Hi all, >>>>> >>>>> I was thinking about today’s discussion on the tools call and since I won’t be able to join in two weeks, I thought I’d send a follow-up to start a discussion: >>>>> >>>>> I like Jeff’s ideas to provide cross-platform events that are keyed using a vendor ID (or sets of IDs). As Jeff mentioned, it would be cool to see common events in different MPIs if they are built on the same underlying layer. >>>>> >>>>> Listing to the discussion today, though, I think this would face quite some controversy in the forum and makes the overall problem quite a bit bigger. Also, this functionality seems useful for control and performance variables, for the same reason, and hence it would be good to look for a solution that can also be retrofitted to these variables. A second set of get info calls that translate an MPI specific event/variable ID to a vendor ID could be one option (but just shooting off the hip right now). >>>>> >>>>> I’d therefore suggest to separate the two issues - one ticket to add events in the style that we have already (which seems to be quite acceptable to the forum, at least there weren’t many negative comments) - and then a second ticket on adding vendor IDs to all three MPI_T concepts (again in the same style). This could help MPI_T events in its discussion in the forum and potentially get it passed sooner and it would give us consistency between the three MPI_T concepts. >>>>> >>>>> What do you all think about this? >>>>> >>>>> Thanks! >>>>> >>>>> Martin >>>>> >>>>> >>>>>> On Jan 19, 2017, at 1:15 AM, Marc-Andre Hermanns <hermanns(a)jara.rwth-aachen.de> wrote: >>>>>> >>>>>> Dear all, >>>>>> >>>>>> This is the gentle reminder for this week's call with a session on >>>>>> *Performance Tools*: >>>>>> >>>>>> Thursday Jan 19, 2017 11 a.m. Eastern Time (*today*) >>>>>> >>>>>> Here is the webex link: >>>>>> >>>>>> https://cisco.webex.com/ciscosales/j.php?MTID=m0fb3e4a68162bff5874849e4700b… >>>>>> >>>>>> Agenda: >>>>>> - MPI_T events >>>>>> >>>>>> Cheers, >>>>>> Marc-Andre >>>>>> -- >>>>>> Marc-Andre Hermanns >>>>>> Jülich Aachen Research Alliance, >>>>>> High Performance Computing (JARA-HPC) >>>>>> Jülich Supercomputing Centre (JSC) >>>>>> >>>>>> Wilhelm-Johnen-Str. >>>>>> 52425 Jülich >>>>>> Germany >>>>>> >>>>>> Phone: +49 2461 61 2509 | +49 241 80 24381 >>>>>> Fax: +49 2461 80 6 99753 >>>>>> www.jara.org/jara-hpc >>>>>> email: hermanns(a)jara.rwth-aachen.de >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> mpiwg-tools mailing list >>>>>> mpiwg-tools(a)lists.mpi-forum.org >>>>>> https://lists.mpi-forum.org/mailman/listinfo/mpiwg-tools >>>>> >>>>> ________________________________________________________________________ >>>>> Martin Schulz, schulzm(a)llnl.gov, http://scalability.llnl.gov/ >>>>> CASC @ Lawrence Livermore National Laboratory, Livermore, USA >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> mpiwg-tools mailing list >>>>> mpiwg-tools(a)lists.mpi-forum.org >>>>> https://lists.mpi-forum.org/mailman/listinfo/mpiwg-tools >>>> >>>> >>>> -- >>>> Jeff Squyres >>>> jsquyres(a)cisco.com >>>> >>>> _______________________________________________ >>>> mpiwg-tools mailing list >>>> mpiwg-tools(a)lists.mpi-forum.org >>>> https://lists.mpi-forum.org/mailman/listinfo/mpiwg-tools >>> >>> >>> >>> _______________________________________________ >>> mpiwg-tools mailing list >>> mpiwg-tools(a)lists.mpi-forum.org >>> https://lists.mpi-forum.org/mailman/listinfo/mpiwg-tools >>> >> >> -- >> Marc-Andre Hermanns >> Jülich Aachen Research Alliance, >> High Performance Computing (JARA-HPC) >> Jülich Supercomputing Centre (JSC) >> >> Wilhelm-Johnen-Str. >> 52425 Jülich >> Germany >> >> Phone: +49 2461 61 2509 | +49 241 80 24381 >> Fax: +49 2461 80 6 99753 >> www.jara.org/jara-hpc >> email: hermanns(a)jara.rwth-aachen.de >> >> >> _______________________________________________ >> mpiwg-tools mailing list >> mpiwg-tools(a)lists.mpi-forum.org >> https://lists.mpi-forum.org/mailman/listinfo/mpiwg-tools > > -- Marc-Andre Hermanns Jülich Aachen Research Alliance, High Performance Computing (JARA-HPC) Jülich Supercomputing Centre (JSC) Wilhelm-Johnen-Str. 52425 Jülich Germany Phone: +49 2461 61 2509 | +49 241 80 24381 Fax: +49 2461 80 6 99753 www.jara.org/jara-hpc email: hermanns(a)jara.rwth-aachen.de

1 0

Re: [mpiwg-tools] Tools topics meeting reminder: Jan 19, 2017
by Jeff Squyres (jsquyres) 02 Feb '17

02 Feb '17

Keep in mind that I proposed a *tuple*, not a single value. You may be assuming we can split up the uint64_t into a tuple -- but I just wanted to make sure we'r talking about the same thing. The tuple was (vendor ID, part ID, event ID). I think you're mainly asking about the vendor ID part. In libibverbs, such vendor IDs are typically the Organization Unique Identifier (https://en.wikipedia.org/wiki/Organizationally_unique_identifier and http://standards-oui.ieee.org/oui/oui.txt) I.e., we could just leverage this existing IEEE standard -- no need to print all this stuff in the MPI standard itself. > On Feb 1, 2017, at 3:24 AM, Marc-Andre Hermanns <hermanns(a)jara.rwth-aachen.de> wrote: > > Hi Martin, Hi Jeff, > > my apologies for taking so long to reply. > > As far as I understand and remember we discussed these universal IDs > in both contexts: (1) source ids and (2) event types. > > Such an ID would allow a tool to cast a pointer to an info struct to a > specific known struct revealing additional information. > > In context of Martin's comment on easy integration with the existing > API, I could imagine a call like > > int > MPI_T_event_get_uid(int index, uint64_t* uid); > > 'uid' being the short form of "universal id". It would be easy to > provide such a call for the other parts (performance/control > variables) of MPI_T as well. > > There are some questions arising from this vendor prefixed ID: > 1) Which entity issues the prefixes to ensure we don't have duplicates? > 2) How would a vendor apply for/request a prefix? > 3) Where would the issued prefixes be listed? In the standard? > 4) Would the rest of the ID be free for the vendor to use, or would we > need to reserve some bits? > > We should use this weeks call to discuss this further. > > Cheers, > Marc-Andre > > > On 22.01.2017 10:55, Schulz, Martin wrote: >> Hi Jeff, >> >> Don’t get me wrong - I wasn’t proposing to push this onto the long bench and do it after MPI-4. There is no reason to not bring this up in time for MPI 4 or even develop it together. I was just suggesting to decouple this from the actual events ticket for two reason: >> - I think the events part is fairly far along and probably easily accepted and I was suggesting to not push it out because of this >> - We need a clean retrofit solution anyway to make it work for variables - we can the use it for events as well. >> >> At the end, this is up to Marc-Andre since he is doing the work :) >> >> Martin >> >> >> >>> On Jan 20, 2017, at 6:41 PM, Jeff Squyres (jsquyres) <jsquyres(a)cisco.com> wrote: >>> >>> My $0.02: we know that there are limitations with the way we've been approaching this stuff for years (over specifying, e.g. PERUSE, which got shot down/shunned, and under specifying leads to tools without any semantic information and implementations that are not incentivized to do anything because the Forum doesn't like "creative" uses of the API, even if they give semantic information to the tools [who are asking exactly for this semantic information] -- e.g., usNIC BTL use of MPI_T variables on a per-interface basis). >>> >>> Why not learn from these limitations and propose something better? >>> >>> My point: if we're going to do this, do it right. Let's not have more buyer's remorse after MPI-4 because the new API (still) doesn't give tools any rich and/or semantic information. >>> >>> ---- >>> >>> Keep in mind that I proposed two different ideas: >>> >>> 1. The idea of identifying event sources by a (vendor ID, part ID, source ID) tuple >>> 2. The idea of a sanctioned extension mechanism >>> >>> Note that neither of these are new ideas; they're borrowed from best practices that just happen to be (just barely) outside of the realm of MPI. >>> >>> They're still best practices, though. >>> >>> >>>> On Jan 20, 2017, at 12:03 AM, Martin Schulz <schulzm(a)llnl.gov> wrote: >>>> >>>> Hi all, >>>> >>>> I was thinking about today’s discussion on the tools call and since I won’t be able to join in two weeks, I thought I’d send a follow-up to start a discussion: >>>> >>>> I like Jeff’s ideas to provide cross-platform events that are keyed using a vendor ID (or sets of IDs). As Jeff mentioned, it would be cool to see common events in different MPIs if they are built on the same underlying layer. >>>> >>>> Listing to the discussion today, though, I think this would face quite some controversy in the forum and makes the overall problem quite a bit bigger. Also, this functionality seems useful for control and performance variables, for the same reason, and hence it would be good to look for a solution that can also be retrofitted to these variables. A second set of get info calls that translate an MPI specific event/variable ID to a vendor ID could be one option (but just shooting off the hip right now). >>>> >>>> I’d therefore suggest to separate the two issues - one ticket to add events in the style that we have already (which seems to be quite acceptable to the forum, at least there weren’t many negative comments) - and then a second ticket on adding vendor IDs to all three MPI_T concepts (again in the same style). This could help MPI_T events in its discussion in the forum and potentially get it passed sooner and it would give us consistency between the three MPI_T concepts. >>>> >>>> What do you all think about this? >>>> >>>> Thanks! >>>> >>>> Martin >>>> >>>> >>>>> On Jan 19, 2017, at 1:15 AM, Marc-Andre Hermanns <hermanns(a)jara.rwth-aachen.de> wrote: >>>>> >>>>> Dear all, >>>>> >>>>> This is the gentle reminder for this week's call with a session on >>>>> *Performance Tools*: >>>>> >>>>> Thursday Jan 19, 2017 11 a.m. Eastern Time (*today*) >>>>> >>>>> Here is the webex link: >>>>> >>>>> https://cisco.webex.com/ciscosales/j.php?MTID=m0fb3e4a68162bff5874849e4700b… >>>>> >>>>> Agenda: >>>>> - MPI_T events >>>>> >>>>> Cheers, >>>>> Marc-Andre >>>>> -- >>>>> Marc-Andre Hermanns >>>>> Jülich Aachen Research Alliance, >>>>> High Performance Computing (JARA-HPC) >>>>> Jülich Supercomputing Centre (JSC) >>>>> >>>>> Wilhelm-Johnen-Str. >>>>> 52425 Jülich >>>>> Germany >>>>> >>>>> Phone: +49 2461 61 2509 | +49 241 80 24381 >>>>> Fax: +49 2461 80 6 99753 >>>>> www.jara.org/jara-hpc >>>>> email: hermanns(a)jara.rwth-aachen.de >>>>> >>>>> >>>>> _______________________________________________ >>>>> mpiwg-tools mailing list >>>>> mpiwg-tools(a)lists.mpi-forum.org >>>>> https://lists.mpi-forum.org/mailman/listinfo/mpiwg-tools >>>> >>>> ________________________________________________________________________ >>>> Martin Schulz, schulzm(a)llnl.gov, http://scalability.llnl.gov/ >>>> CASC @ Lawrence Livermore National Laboratory, Livermore, USA >>>> >>>> >>>> >>>> _______________________________________________ >>>> mpiwg-tools mailing list >>>> mpiwg-tools(a)lists.mpi-forum.org >>>> https://lists.mpi-forum.org/mailman/listinfo/mpiwg-tools >>> >>> >>> -- >>> Jeff Squyres >>> jsquyres(a)cisco.com >>> >>> _______________________________________________ >>> mpiwg-tools mailing list >>> mpiwg-tools(a)lists.mpi-forum.org >>> https://lists.mpi-forum.org/mailman/listinfo/mpiwg-tools >> >> >> >> _______________________________________________ >> mpiwg-tools mailing list >> mpiwg-tools(a)lists.mpi-forum.org >> https://lists.mpi-forum.org/mailman/listinfo/mpiwg-tools >> > > -- > Marc-Andre Hermanns > Jülich Aachen Research Alliance, > High Performance Computing (JARA-HPC) > Jülich Supercomputing Centre (JSC) > > Wilhelm-Johnen-Str. > 52425 Jülich > Germany > > Phone: +49 2461 61 2509 | +49 241 80 24381 > Fax: +49 2461 80 6 99753 > www.jara.org/jara-hpc > email: hermanns(a)jara.rwth-aachen.de > > > _______________________________________________ > mpiwg-tools mailing list > mpiwg-tools(a)lists.mpi-forum.org > https://lists.mpi-forum.org/mailman/listinfo/mpiwg-tools -- Jeff Squyres jsquyres(a)cisco.com

1 0

Re: [mpiwg-tools] Performance tools topic meeting reminder: Feb 2, 2017 (<- Date fixed)
by Marc-Andre Hermanns 02 Feb '17

02 Feb '17

Dear all sorry for not reading my calendar correctly. Of course the meeting is *today* on February *2*, 2017. Cheers, Marc-Andre On 01.02.2017 23:06, Marc-Andre Hermanns wrote: > Dear all, > > This is the gentle reminder for this week's call with a session on > *Performance Tools*: > > Thursday Feb 3, 2017 11 a.m. Eastern Time > > Agenda: > - MPI_T events: UIDs for events & sources contd. > > Due to the increasing number of bots connecting to the call, Jeff set > up a new WebEx call for us. > > You can find the information for the new link at: > https://apps.fz-juelich.de/scalasca/mpiwg-tools-webex/ > > (The info is now protected by a recaptcha). > > Cheers, > Marc-Andre > > > > _______________________________________________ > mpiwg-tools mailing list > mpiwg-tools(a)lists.mpi-forum.org > https://lists.mpi-forum.org/mailman/listinfo/mpiwg-tools > -- Marc-Andre Hermanns Jülich Aachen Research Alliance, High Performance Computing (JARA-HPC) Jülich Supercomputing Centre (JSC) Wilhelm-Johnen-Str. 52425 Jülich Germany Phone: +49 2461 61 2509 | +49 241 80 24381 Fax: +49 2461 80 6 99753 www.jara.org/jara-hpc email: hermanns(a)jara.rwth-aachen.de

1 0

Performance tools topic meeting reminder: Feb 3, 2017
by Marc-Andre Hermanns 01 Feb '17

01 Feb '17

Dear all, This is the gentle reminder for this week's call with a session on *Performance Tools*: Thursday Feb 3, 2017 11 a.m. Eastern Time Agenda: - MPI_T events: UIDs for events & sources contd. Due to the increasing number of bots connecting to the call, Jeff set up a new WebEx call for us. You can find the information for the new link at: https://apps.fz-juelich.de/scalasca/mpiwg-tools-webex/ (The info is now protected by a recaptcha). Cheers, Marc-Andre -- Marc-Andre Hermanns Jülich Aachen Research Alliance, High Performance Computing (JARA-HPC) Jülich Supercomputing Centre (JSC) Wilhelm-Johnen-Str. 52425 Jülich Germany Phone: +49 2461 61 2509 | +49 241 80 24381 Fax: +49 2461 80 6 99753 www.jara.org/jara-hpc email: hermanns(a)jara.rwth-aachen.de

1 0

Re: [mpiwg-tools] Tools topics meeting reminder: Jan 19, 2017
by Marc-Andre Hermanns 01 Feb '17

01 Feb '17

Hi Martin, Hi Jeff, my apologies for taking so long to reply. As far as I understand and remember we discussed these universal IDs in both contexts: (1) source ids and (2) event types. Such an ID would allow a tool to cast a pointer to an info struct to a specific known struct revealing additional information. In context of Martin's comment on easy integration with the existing API, I could imagine a call like int MPI_T_event_get_uid(int index, uint64_t* uid); 'uid' being the short form of "universal id". It would be easy to provide such a call for the other parts (performance/control variables) of MPI_T as well. There are some questions arising from this vendor prefixed ID: 1) Which entity issues the prefixes to ensure we don't have duplicates? 2) How would a vendor apply for/request a prefix? 3) Where would the issued prefixes be listed? In the standard? 4) Would the rest of the ID be free for the vendor to use, or would we need to reserve some bits? We should use this weeks call to discuss this further. Cheers, Marc-Andre On 22.01.2017 10:55, Schulz, Martin wrote: > Hi Jeff, > > Don’t get me wrong - I wasn’t proposing to push this onto the long bench and do it after MPI-4. There is no reason to not bring this up in time for MPI 4 or even develop it together. I was just suggesting to decouple this from the actual events ticket for two reason: > - I think the events part is fairly far along and probably easily accepted and I was suggesting to not push it out because of this > - We need a clean retrofit solution anyway to make it work for variables - we can the use it for events as well. > > At the end, this is up to Marc-Andre since he is doing the work :) > > Martin > > > >> On Jan 20, 2017, at 6:41 PM, Jeff Squyres (jsquyres) <jsquyres(a)cisco.com> wrote: >> >> My $0.02: we know that there are limitations with the way we've been approaching this stuff for years (over specifying, e.g. PERUSE, which got shot down/shunned, and under specifying leads to tools without any semantic information and implementations that are not incentivized to do anything because the Forum doesn't like "creative" uses of the API, even if they give semantic information to the tools [who are asking exactly for this semantic information] -- e.g., usNIC BTL use of MPI_T variables on a per-interface basis). >> >> Why not learn from these limitations and propose something better? >> >> My point: if we're going to do this, do it right. Let's not have more buyer's remorse after MPI-4 because the new API (still) doesn't give tools any rich and/or semantic information. >> >> ---- >> >> Keep in mind that I proposed two different ideas: >> >> 1. The idea of identifying event sources by a (vendor ID, part ID, source ID) tuple >> 2. The idea of a sanctioned extension mechanism >> >> Note that neither of these are new ideas; they're borrowed from best practices that just happen to be (just barely) outside of the realm of MPI. >> >> They're still best practices, though. >> >> >>> On Jan 20, 2017, at 12:03 AM, Martin Schulz <schulzm(a)llnl.gov> wrote: >>> >>> Hi all, >>> >>> I was thinking about today’s discussion on the tools call and since I won’t be able to join in two weeks, I thought I’d send a follow-up to start a discussion: >>> >>> I like Jeff’s ideas to provide cross-platform events that are keyed using a vendor ID (or sets of IDs). As Jeff mentioned, it would be cool to see common events in different MPIs if they are built on the same underlying layer. >>> >>> Listing to the discussion today, though, I think this would face quite some controversy in the forum and makes the overall problem quite a bit bigger. Also, this functionality seems useful for control and performance variables, for the same reason, and hence it would be good to look for a solution that can also be retrofitted to these variables. A second set of get info calls that translate an MPI specific event/variable ID to a vendor ID could be one option (but just shooting off the hip right now). >>> >>> I’d therefore suggest to separate the two issues - one ticket to add events in the style that we have already (which seems to be quite acceptable to the forum, at least there weren’t many negative comments) - and then a second ticket on adding vendor IDs to all three MPI_T concepts (again in the same style). This could help MPI_T events in its discussion in the forum and potentially get it passed sooner and it would give us consistency between the three MPI_T concepts. >>> >>> What do you all think about this? >>> >>> Thanks! >>> >>> Martin >>> >>> >>>> On Jan 19, 2017, at 1:15 AM, Marc-Andre Hermanns <hermanns(a)jara.rwth-aachen.de> wrote: >>>> >>>> Dear all, >>>> >>>> This is the gentle reminder for this week's call with a session on >>>> *Performance Tools*: >>>> >>>> Thursday Jan 19, 2017 11 a.m. Eastern Time (*today*) >>>> >>>> Here is the webex link: >>>> >>>> https://cisco.webex.com/ciscosales/j.php?MTID=m0fb3e4a68162bff5874849e4700b… >>>> >>>> Agenda: >>>> - MPI_T events >>>> >>>> Cheers, >>>> Marc-Andre >>>> -- >>>> Marc-Andre Hermanns >>>> Jülich Aachen Research Alliance, >>>> High Performance Computing (JARA-HPC) >>>> Jülich Supercomputing Centre (JSC) >>>> >>>> Wilhelm-Johnen-Str. >>>> 52425 Jülich >>>> Germany >>>> >>>> Phone: +49 2461 61 2509 | +49 241 80 24381 >>>> Fax: +49 2461 80 6 99753 >>>> www.jara.org/jara-hpc >>>> email: hermanns(a)jara.rwth-aachen.de >>>> >>>> >>>> _______________________________________________ >>>> mpiwg-tools mailing list >>>> mpiwg-tools(a)lists.mpi-forum.org >>>> https://lists.mpi-forum.org/mailman/listinfo/mpiwg-tools >>> >>> ________________________________________________________________________ >>> Martin Schulz, schulzm(a)llnl.gov, http://scalability.llnl.gov/ >>> CASC @ Lawrence Livermore National Laboratory, Livermore, USA >>> >>> >>> >>> _______________________________________________ >>> mpiwg-tools mailing list >>> mpiwg-tools(a)lists.mpi-forum.org >>> https://lists.mpi-forum.org/mailman/listinfo/mpiwg-tools >> >> >> -- >> Jeff Squyres >> jsquyres(a)cisco.com >> >> _______________________________________________ >> mpiwg-tools mailing list >> mpiwg-tools(a)lists.mpi-forum.org >> https://lists.mpi-forum.org/mailman/listinfo/mpiwg-tools > > > > _______________________________________________ > mpiwg-tools mailing list > mpiwg-tools(a)lists.mpi-forum.org > https://lists.mpi-forum.org/mailman/listinfo/mpiwg-tools > -- Marc-Andre Hermanns Jülich Aachen Research Alliance, High Performance Computing (JARA-HPC) Jülich Supercomputing Centre (JSC) Wilhelm-Johnen-Str. 52425 Jülich Germany Phone: +49 2461 61 2509 | +49 241 80 24381 Fax: +49 2461 80 6 99753 www.jara.org/jara-hpc email: hermanns(a)jara.rwth-aachen.de

1 0