Cannot run models after updating brms and rstan

Do you have anything in the ~/.R/Makevars or ~/.R/Makevars.win files?

C:\Users\blokeman\Documents.R\Makevars.win contains:

CXX14FLAGS=-O3 -march=native
CXX14 = g++ -m$(WIN) -std=c++1y
CXX11FLAGS=-O3 -march=native

OK. Eliminate the -march=native from both the first and last lines, but there might be something else wrong.

Thanks. That seems to have fixed it. There’s still a warning message that reads

In system(paste(CXX, ARGS), ignore.stdout = TRUE, ignore.stderr = TRUE) :
  'C:/rtools40/usr/mingw_/bin/g++' not found

But at least models are now being fit.

I’m having the same problem since updating to R 4.0. When I run

remotes::install_github(“bgoodri/inline”)
example(stan_model, package = “rstan”, run.dontrun = TRUE)

I get

Error in withr::set_makevars(new, path, state, assignment = assignment) :
Multiple results for CXX14FLAGS found, something is wrong.FALSE
In addition: Warning message:
In system(paste(CXX, ARGS), ignore.stdout = TRUE, ignore.stderr = TRUE) :
‘C:/rtools40/usr/mingw_/bin/g++’ not found

Any help would be much appreciated

I also checked Makevars.win for reference and it has this

CXX14FLAGS=-O3 -march=native -mtune=native
CXX11FLAGS=-O3 -march=corei7 -mtune=corei7

CXX14FLAGS=-O3 -march=corei7 -mtune=corei7
CXX14 = $(BINPREF)g++ -m$(WIN) -std=c++1y
CXX11FLAGS=-O3 -march=corei7 -mtune=corei7

CXX14FLAGS=-O3 -mtune=native -mmmx -msse -msse2 -msse3 -mssse3 -msse4.1 -msse4.2

CXX14FLAGS=-O3 -mtune=native -mmmx -msse -msse2 -msse3 -mssse3 -msse4.1 -msse4.2

CXX14FLAGS=-O3 -mtune=native -mmmx -msse -msse2 -msse3 -mssse3 -msse4.1 -msse4.2

CXX14FLAGS=-O3 -march=corei7 -mtune=corei7
CXX14 = $(BINPREF)g++ -m$(WIN) -std=c++1y
CXX11FLAGS=-O3 -march=corei7 -mtune=corei7

UPDATE

I modified makevars.win to

CXX14FLAGS=-O3 -march=corei7 -mtune=corei7
CXX14 = $(BINPREF)g++ -m$(WIN) -std=c++1y
CXX11FLAGS=-O3 -march=corei7 -mtune=corei7

And that seems to maybe have fixed it? The test program now ran successfully (with the same warning blokeman had) and I’m trying the model I was working on now.

Hi Mark,

Great to hear that you resolved it! The error:

Multiple results for CXX14FLAGS found, something is wrong

Means that you had specified CXX14FLAGS = more than once in your Makevars.win, and so it didn’t know which to take.

Also, if you’re using RTools4, you don’t need to set the compiler explicitly, like you have in this line:

CXX14 = $(BINPREF)g++ -m$(WIN) -std=c++1y

And it can cause issues if the location of the compiler changes. Additionally, the -march=corei7 -mtune=corei7 optimisation flags have been seen to cause instability and crashes with rtools4, so it would be safest to turn those off.

To reset your Makevars.win to ‘safe’ but optimised settings, run:

cat("CXX14FLAGS += -O3 -mmmx -msse -msse2 -msse3 -mssse3 -msse4.1 -msse4.2",file = "~/.R/Makevars.win", sep = "\n", append = FALSE)

Thanks for the tips. I sort of figured that was what was going on with the repeated lines in makevars, but I’m nothing close to a developer so good to hear I didn’t inadvertently break something!

I have gotten my model to run, though still having some crash/instability issues and it’s extremely slow. A couple times I’ve gotten crashes that seem to happen after sampling finishes and things are wrapping up (R aborts so I can’t post the errors/warnings if there are any)

This could totally be user error related to my model and I may seek more specific support on it elsewhere, or try my hand at writing a stan program from scratch again (I took a course with @bgoodri last semester so hopefully I can make him proud!)

Just out of curiosity, if this is answerable to a relative layman, what does the g++ warning mean? Any chance that’s related to the problem?

Either way I appreciate the help!

A couple things to check for the crashes/slowness, what’s the current state of your Makevars:

readLines("~/.R/Makevars.win")

Also, we’re finding that R will sometimes crash if you keep assigning new models to the same output. So try assigning the results of new models to different outputs (if that’s not what you’re already doing). In other words, rather than:

out = stan("model1.stan",data)
out = stan("model2.stan",data)

Try using:

out1 = stan("model1.stan",data)
out2 = stan("model2.stan",data)

As for the g++ error:

In addition: Warning message:
In system(paste(CXX, ARGS), ignore.stdout = TRUE, ignore.stderr = TRUE) :
‘C:/rtools40/usr/mingw_/bin/g++’ not found

This is just a misconfiguration in the RStan setup when preparing to run a model, it doesn’t affect the sampling or choice of compiler and will probably be fixed in the next release

Thanks. Here is what makevars.win looks like

"CXX14FLAGS += -O3 -mmmx -msse -msse2 -msse3 -mssse3 -msse4.1 -msse4.2"

The advice about not ovewriting objects is helpful. My guess is that explains the the crashing (I can’t remember for sure but it sounds like something I might have done).

The slowness may be that its just a complicated hierarchical model with tons of crossed person and item level parameters and lots of sparsity in between them. It’s like 500 people, 200 items, and most people answered ~20-50 items, but answered several multiple times at different time points, and there’s a covariate for time. So truthfully, while I didn’t think it would take quite as long as its been taking to run, I’m not really surprised and it may just be the nature of the beast.

Now I’ve lost brms again. RStan is working fine, it works when I run test models and works when I run models I wrote in .stan files, but brms ends immediately without error again (it just says “compiling stan program…” then returns to the console).

I did get a popup error (not an R console error) the first time I ran it that said something like “file not found”.

I only noticed because we’re going to be teaching some basic rstanarm and brms in a stats lab that I’m TAing and I was starting to prep some materials.

As always any help would be much appreciated

Nevermind, running it in make_stancode I think I found the error in how I was composing the bf() for a nonlineard model. Different type of problem! I’ll try to work through it and post elsewhere

It’s the classic case of figuring out the problem as soon you post it online, been there more than once!

The make_stancode approach is good for debugging, I’d also recommend running the models with the verbose=TRUE flag enabled to see if you can get more information that way

1 Like