Math meeting notes from 5/16/2019

We kicked off our monthly Math meetings again! They are on the 3rd Thursday of the month at 10 am Eastern time on Google Meet. It is open to anyone interested in the Math library’s development. Feel free to copy this calendar event or dm me for an invite to the calendar event.


Attendees

@syclik, @increasechief, @roualdes, @rok_cesnovar, @Stevo15025, @drezap, @seantalts

Discussion

We didn’t have a focused agenda this meeting. It was a chance to discuss status, what sorts of problems have popped up, and how to address them. Here are some of the things that were discussed:

  • @Stevo15025: in working with the PR for exponential quadratic covariance function, the header includes was causing problems. Question about how the headers work. We discussed a little.

  • Related to that, @rok_cesnovar asked for status of the flattening refactor. @drezap is planning on putting together a PR for the first step next week. @roulades is also involved in the process. We discussed some of the technical details of why it’s complicated on the call. This flattening would help with @Stevo15025’s PR by simplifying the logic.

  • Discussion of parallelization. @rok_cesnovar and @syclik are looking at @wds15’s design document on parallelization. We discussed a bit about some of the technical details, but mostly agreed that it’s taking a while to review due to the nature of it.

  • Related to that, there was a question of how Torsten’s MPI backend works.

  • @Stevo15025: there’s a GPU course at Columbia. It’d be good to put together a list of masters-thesis level projects. @rok_cesnovar will put one together of things that would be great to have in the Math library and we’re just out of time.

  • If there are any problems with Jenkins and this is coming from a PR, tag @serban-nicusor-toptal and/or @seantalts on GitHub.

  • We discussed performance regression tests. We now have them downstream for CmdStan and Stan. @syclik suggested we create some for the Math library that’s independent of the downstream tests. If anyone else wants to help spec out what this looks like, we can discuss.

  • For the flattening refactor, to test all existing Stan models to see if they instantiate properly, run (from Stan) make test/integration/compile_models_test

For anyone at the meeting, please feel free to update this. If we have additional technical things to discuss, please feel free to start new threads.

3 Likes

@increasechief wrote out a sketch of a proposal for something like this here: https://github.com/stan-dev/design-docs/pull/4

Cool! I missed that. @increasechief, I’ll take a look this week.

1 Like

sorry that I wasn’t able to attend. What was the question on MPI backend?

@yizhang, no problem. Hopefully you can make the next one! It was just a question on the design taken for MPI in Torsten (as opposed to the map_rect design in Math).

Quoting the other post, the design is motivated by

Another, albeit more philosophical, motivation, is avoid appearing as a universal solution but actually limited to a single pattern (master/worker), despite MPI is much more flexible and versatile. The approach is rather simple, as we simply distribute the task of a population of ODEs among the cluster, regardless of its size, and we don’t lock worker nodes to waiting/working cycle(without this kind of limitation of map_rect, along with issues like 939 and 1165, Torsten’s MPI scheme could be compatible with Stan’s).

I’d be happy to talk about it in next meeting if anyone still interested.

1 Like

I forgot this on the meeting yesterday, but could someone review this PR in the Stan repo: https://github.com/stan-dev/stan/pull/2754 which is blocking this PR by @andrjohns in Math.

3 Likes

@rok_cesnovar: thanks. I just reviewed it.

1 Like

Thanks!