Out of curiousity, how long do the Stan Math library tests take to compile?
I’ve been running ./runTests.py test/prob -j 4 for about a day now on a quad core i7 with plenty of ram and it still appears to be in the compiling stage. ./runTests.py test/unit built in less than a day on a single core for reference. Clang 3.8.0 on Ubuntu 16.04.
I’m asking just to make sure I haven’t somehow messed up the build process. I’ve thumbed through the folders and there’s still a frightening number of tests that haven’t been compiled yet.
Those tests take a really long time (as you are experiencing). I have a 12 core machine and it takes about a day. OTOH since compilation is mostly disk bound you could probably do -j 8 and make it go faster.
We typically don’t run the prob tests on local dev machines. We tend to run the unit tests and a subset of the distribution tests if we’re working on it directly.
I wanted to hook up the rest of the pieces of Stan so I could test it in a model file by building an interface (cmdStan is the one I want to try). It looks like cmdStan includes Stan as a submodule, and Stan includes Stan-Math as a submodule. As far as I can tell, I’ll need to make modifications to both Stan and Stan-Math.
My issue is with the submodules. What do you guys do here when you have local changes to Stan/Stan-Math that aren’t a part of the main develop?
Is there a non-destructive way for me to point my repo of cmdStan to my Stan/Stan-Math forks?
Or should I be trying point cmdStan to build using my non-submodule copies of Stan/Stan-Math?
Or should I just send pull requests to Stan-Math and wait on them to be absorbed into develop before moving on to the changes in Stan itself?
I work by checking out cmdstan, which brings in the cmdstan/stan and cmstan/stan/lib/stan_math submodules. You can run make stan-update from cmdstan to get the one that matches the branch and make math-update from stan for the same thing. You just have to make sure not to accidentally commit a submodule—we only update those through auto-triggered GitHub pull requests.
Then you can run informal end-to-end tests through CmdStan.
Yes to (3). You can do them at the same time, but we won’t merge into stan-dev/stan until the matching update is already into stan-dev/math. Once something goes into the math lib, it automatically triggers an upstream pull request to update the version of the math lib in Stan.
The real hairy problem is when you need to make a breaking change to math that messes up Stan. We try not to do that, but sometimes it’s inevitable.
Oh okay, cool beans. Just tested it out. The makes seem to work. I added my own remotes to the submodules manually and it looks like make math-update/... is getting me the changes so I can test things out.
@bbbales2, it looks like you were able to find one of the ways to deal with this. There’s another way, if you have different versions of Stan or Math cloned in different locations.
From Stan, you can set the make variable MATH to point to a different location (just make sure there are no spaces in the path). For example, make MATH=~/math/ foo, where foo is the make target. It has to have the trailing slash.
From CmdStan, you can set either or both STAN or MATH to different locations if you want. Once again, no spaces and end with forward slash (/).