11:55 <simbergm> jbjnr_: hkaiser: is the talk still on today (joost is wondering)?

11:55 <jbjnr_> going ahead as planned

12:01 <hkaiser> simbergm: yes, I'm planning to give the talk as planned

12:02 <simbergm> very good, thanks

13:17 <nikunj> diehlpk_work, yt?

13:21 <hkaiser> nikunj: so I assume you did arrive safely

13:21 <nikunj> hkaiser, yes :)

13:21 <nikunj> I registered for the semester today

13:21 <hkaiser> good

13:21 <nikunj> settled down in my dorm here

13:22 <hkaiser> just don't go on strike with the rest of your lot ;-)

13:22 <nikunj> haha, point noted ;)

13:22 <zao> nikunj: Welcome to wherever you are now! :)

13:23 <nikunj> zao, xD

13:23 <nikunj> I'm back in India after my internship at LSU

13:25 <zao> So what's coming up now, doctoral studies or something else? I don't think I ever knew what level you were at.

13:26 <nikunj> zao, I'm still in my undergrad

13:26 <nikunj> I'm a junior at IIT Roorkee studying computer science and eng

13:36 <heller> staying with HPX then?

13:36 <nikunj> heller, absolutely!

13:36 <heller> cool

13:44 <hkaiser> heller: I'd liek to talk to you about the execution_agent stuff at some point

13:44 <hkaiser> I think it's not quite right, but I might not understand all of the details

13:44 <heller> hkaiser: ok

13:44 <heller> hkaiser: tonight might be good for me

13:45 <hkaiser> ok, I should have some time this afternoon - should we play it by ear?

13:45 <heller> sure

13:46 <hkaiser> would 2pm/21:00 sound like a viable target time for you?

13:46 <heller> yup!

13:46 <hkaiser> ok

13:46 <hkaiser> thanks

13:47 <heller> hkaiser: I am on and off trying to integrate p0443r11 properly into the execution agent stuff ... not using C++17 features is making it incredibly hard :/

13:48 <hkaiser> heller: sure, I know

13:48 <hkaiser> you will have to suffer

13:48 <heller> *a lot*

13:49 <hkaiser> poor guy ;-)

13:50 <hkaiser> heller: all of spirit was written using c++98, so this should be possible as well using c++14

13:50 <heller> hkaiser: I feel like we are missing out on a few opportunities by not going bleeding edge

13:51 <heller> it seems like the really start to shine once combining them with coroutines, for example

13:52 <hkaiser> absolutely - but I'd suggest to do that only in step two

13:52 <hkaiser> anyways, gtg

15:53 <diehlpk_work> simbergm, Should I start a Fedora build before we release HPX 1.4?

15:54 <simbergm> diehlpk_work: yes please

15:55 <diehlpk_work> Ok, which branch?

15:55 <simbergm> release

15:55 <diehlpk_work> Ok, I will start it today, so we have the results by tomorrow morning

15:59 <simbergm> Thanks

16:22 <hkaiser> simbergm: hey yt?

19:04 <heller> hkaiser: I am ready from now on

19:05 <hkaiser> heller: we can do it now

19:05 <hkaiser> appear.in?

19:05 <heller> sure

19:06 <hkaiser> how is it called nowadays?

19:06 <heller> hkaiser: https://whereby.com/stellar-group

19:34 <weilewei> For the hpx module recently available on Summit, in its .../include/hpx/, it does not have collectives.hpp, which is required by hpx 1d stencil 8 here: https://github.com/STEllAR-GROUP/hpx/blob/3c8cada91cd6532c2c07fdc3dd72600c38f8ef4d/examples/1d_stencil/1d_stencil_8.cpp#L14. This example cannot be built.

19:35 <weilewei> For this hpx module, it passes -DHPX_WITH_EXAMPLES=OFF, so no examples folder is generated. But I am trying to build stencil 8 on my own to test newly existing hpx module on Summit.

19:35 <weilewei> What should I do?

19:36 <weilewei> or more specifically, why collectives.hpp is not generated with hpx module on Summit?

19:45 <hkaiser> because it's not part of V1.3

19:47 <weilewei> ah, I see... then I need to find the stencil 8 code that is V1.3

19:47 <hkaiser> right

19:52 <simbergm> hkaiser: here now, kind of

19:53 <hkaiser> simbergm: sec

19:54 <hkaiser> simbergm: we ran into the problem of how to test the hpx module on summit

19:54 <hkaiser> is there a way to build the tests against an installed version of hpx?

19:57 <simbergm> hkaiser: uh, no, don't think so... :/

19:57 <simbergm> to do it cleanly would maybe require having the tests separate from the the rest

19:58 <simbergm> but better would be if whatever module system had some sort of step to verify the build

19:58 <simbergm> sanity check

19:58 <simbergm> *whatever module system is used on summit

19:58 <hkaiser> right

19:58 <hkaiser> weilewei was running into this

19:58 <weilewei> spack is used simbergm

19:58 <simbergm> ah yes, you already mentioned this

19:59 <simbergm> maybe zao would know...? :) do any of the typically used build/module systems have some sort of way to specify a sanity check for a build?

19:59 <weilewei> spack cannot stage/stop the installation at the build stage

20:00 <simbergm> I don't know, sorry

20:01 <simbergm> one can always put something together manually with scripts but then it won't be 100% the same as the spack build

20:01 <simbergm> and we could of course hack something together in our cmake, but I'm not sure it's worth the effort or our responsibility

20:01 <weilewei> yea, no, it won't be the same

20:02 <simbergm> I get that you want to verify the build though, and if there's no better way...

20:03 <simbergm> zao is probably enjoying his evening now, but I'd try to ping him when he's around

20:03 <simbergm> he should be able to tell you for sure if something like that exists already

20:04 <weilewei> terminate called after throwing an instance of 'std::runtime_error' what(): partitioner::partioner: Currently, HPX_HAVE_MAX_CPU_COUNT is set to 64 while your system has 128 processing units. Please reconfigure HPX with -DHPX_WITH_MAX_CPU_COUNT=128 (or higher) to increase the maximal CPU count supported by HPX.Aborted (core dumped)

20:04 <weilewei> Aha, I need to tell Summit manager to set HPX_WITH_MAX_CPU_COUNT to 256 or something

20:04 <simbergm> yay, a useful error message :) unless your system doesn't actually have 128 cores

20:04 <weilewei> simbergm thanks for following it up

20:04 <simbergm> yeah, 128 should be enough

20:05 <zao> simbergm: EasyBuild has a sanity check step, which checks for a recipe-specified set of directories and files, tries loading any Python modules, and can run `make check` or whatever.

20:05 <simbergm> zao: know of anything similar in spack?

20:05 <zao> No idea how they build things.

20:05 <weilewei> zao how about spack?

20:06 <weilewei> @zao ok..

20:06 <simbergm> no worries, thanks

20:06 <zao> One thing that works more after-installation is ReFrame from CSCS (Victor and friends), which is intended to be more for perf and integration testing against clusters.

20:06 <zao> On my site we've looked at running reframe to verify that our installs actually work with proper test cases, but it's been slow.

20:07 <zao> (slow in deployment from our side, not the tool itself)

20:07 <simbergm> do you then use custom test cases, not the usual unit test suite from a library/application?

20:07 <hkaiser> weilewei: what about creating a new CMakeLists.txt that does a find_package(HPX) and a add_sub_directory(tests)

20:07 <hkaiser> perhaps also finding Pythong etc

20:08 <heller> and enabling tests and so on

20:08 <simbergm> also needs the unit tests from modules

20:09 <simbergm> it's doable, but ugly as heck

20:09 <heller> shouldn't that be handled by the depending tatrgets?

20:09 <weilewei> hkaiser yea, that's what I am doing as well. Currently, I found out HPX_WITH_MAX_CPU_COUNT is not set correctly on Summit. maybe more errors are on the way

20:09 <hkaiser> you might want to talk to Rod as he is maintaingg the HPX Spack package for FLeCSI

20:09 <simbergm> it might be enough to run a carefully selected set of examples

20:10 <weilewei> hkaiser Ok, will do

20:10 <simbergm> heller: modules unit tests? they link correctly but the modules unit test directories need to be added as well

20:10 <heller> ahh, ok

20:11 <zao> Reframe would have separate (typically user-sourced) actual datasets with known performance properties to run with.

20:12 <zao> If I had to have wishlists from an EasyBuild perspective, I'd like a in-tree test suite that runs in acceptable time when building and detects problems like "not building with MPI right", "missing CUDA env", etc.

20:12 <zao> Exhaustive test suites that test for every problem in HPX since the dawn of time is cool and all, but if the build takes an hour with the test suite - it sucks.

20:14 <zao> The kind of stuff one cares about in a release is a bit different from what you might want while developing, after all.

20:14 <heller> tests.examples?

20:20 <simbergm> Yah, then I think running a custom set of examples and checking their output is probably the best option

20:20 <simbergm> We could also install some additional unit tests for that purpose (or have an option to install all of them)

20:20 <heller> without polluting the bin directory

20:21 <heller> please ;)

20:22 <simbergm> Yeah sure, it wouldn't be a default option either