R2MLwiN: possible bug :

Welcome to the forum for R2MLwiN users. Feel free to post your question about R2MLwiN here. The Centre for Multilevel Modelling take no responsibility for the accuracy of these posts, we are unable to monitor them closely. Do go ahead and post your question and thank you in advance if you find the time to post any answers!

Go to R2MLwiN: Running MLwiN from within R >> http://www.bris.ac.uk/cmm/software/r2mlwin/
Post Reply
AaipoesNL
Posts: 4
Joined: Tue Jul 14, 2015 7:31 pm

R2MLwiN: possible bug :

Post by AaipoesNL »

Hi, I think I might have found a possible bug. I kept on getting this really annoying error:

Code: Select all

Error in `[.data.frame`(indata, , outvars) : undefined columns selected
This is my R2MLwiN call (shortened the formula)

Code: Select all

estoptions  <- list(xc = TRUE, sort.force = FALSE, EstM=1, x64=TRUE, optimat = TRUE, debugmode=FALSE, resi.store = FALSE, clean.files = FALSE);

fullmodel <-  runMLwiN(Formula = logit(var, cons) ~ ...,
                       D="Binomial", indata = f, estoptions = estoptions, MLwiNPath=mlwin, workdir=wdrlmwin);
The solution appears to be to put in estoptions the following extra command:

Code: Select all

drop.data = FALSE
My guess is that the error is somewhere in R2MLwiN.R near line 2299, reading currently:

Code: Select all

  if (drop.data) {
    outvars <- c(resp)

    # Multiple membership IDs if applicable
    if (!is.null(mm)) {
      for (i in 1:length(mm)) {
        if (!any(is.na(mm[[i]]))) {
          varnames <- unlist(mm[[i]]$mmvar)
          weightnames <- unlist(mm[[i]]$weights)
          outvars <- union(outvars, varnames)
          outvars <- union(outvars, weightnames)
        }
      }
    }
Maybe any developer wants to look into this. Examples can be provided if wanted. Thanks!
AaipoesNL
Posts: 4
Joined: Tue Jul 14, 2015 7:31 pm

Re: R2MLwiN: possible bug :

Post by AaipoesNL »

...and another even more serious issue, I think.

What I did is akin this (tried d:e and d*e, doesn't matter):

Code: Select all

fullmodel <-  runMLwiN(Formula = logit(dv, cons) ~ 1 + a + b + c + d + e + f + d:e + d:e:f + (1+a+b+c|group)
                       , D="Binomial"
                       , indata = f
                       , estoptions = estoptions
                       , MLwiNPath=mlwin
                       , workdir=wdrlmwin);
                       
And this makes a MLWIN command file with (just an excerpt):

Code: Select all

ADDT    'd:e'
ADDT    'd:e:f'
rather than this, what it should be:

Code: Select all

ADDT    'd' 'e'
ADDT    'd' 'e' 'f'
ChrisCharlton
Posts: 1351
Joined: Mon Oct 19, 2009 10:34 am

Re: R2MLwiN: possible bug :

Post by ChrisCharlton »

Thank you for the reports. If you do have an example to hand for the first problem that you ran into that would be useful.

As far as the second problems goes, the reason for what you are seeing is due to R2MLwiN creating any interactions or transformations within R before sending the data to MLwiN. This means that it can fully support the R formula syntax as well as match the parameter names with those that would be generated by native R functions. You should therefore find that the 'd:e' and 'd:e:f' variables that were sent to MLwiN contain the result of the interaction calculation and that the parameter values match those you would get if you set up the models with the second syntax you referred to. Are you getting results that contradict this?
AaipoesNL
Posts: 4
Joined: Tue Jul 14, 2015 7:31 pm

Re: R2MLwiN: possible bug :

Post by AaipoesNL »

Hi Chris,

With regard to your first point: I will send you a private message here with my emailaddress, so I can send you some data and scripts.

The second point is somewhat more problematic for me. I'm not sure if I'm getting conflicting results within those variables - the thing is that I'm not sure if I can still do with it what I want to do. So basically, I'm letting R2MLwiN generate a nice macro file based on a fairly complex regression formula and data set, so I don't have to think about it. Then, when it is executed within R, I cancel it and edit the generated macro manually to add some specific stuff like saving the .wsz file so I can open it later to do simulations within the MLwiN GUI. Then my question would be: can I just run predictions there if the interactions are actually calculated in R and then passsed on as separate variables?

My solution for now is to change the generated macro from

Code: Select all

ADDT    'd:e:f'
to

Code: Select all

ADDT    'd' 'e 'f''
This seems to work (since the original variables (d,e,f) are also added separately in the regression formula. It also works and the results are as expected, so unless you say that it doesn't work like this, then I keep on working with it like this.
ChrisCharlton
Posts: 1351
Joined: Mon Oct 19, 2009 10:34 am

Re: R2MLwiN: possible bug :

Post by ChrisCharlton »

When you add an interaction within MLwiN it essentially creates and adds equivalent variables to those created in R while also remembering the interaction specification. As far as I remember this additional information is only used when modifying a term (so it can fill in the dialogue box with the previous choices), when using the customized predictions window (so that it can identify and use the main effects) and in the Realcom-Impuation interface (so that it can rebuild the model after loading each imputed data file). Everything else uses the generated variables directly and so should operate in the same way if the interactions were created by R or MLwiN. Having said that, if you prefer to edit the macros files then what you have done should be fine too. Finally, previous versions of R2MLwiN did create the interactions within MLwiN, but supported a much less flexible formula syntax. This syntax is still available for backwards compatibility purposes, but is not being developed further (see Formula.translate.compat).

It would be fairly simply for us to add an option in future versions of the command for saving the final worksheet to a location specified by the user. If the other modifications that you are making are similarly generic we could look into adding these as options too.
Post Reply