gsem with random effects and mi estimate, cmdok - not working

[Matthew Burnell]

Dear Statalist

I've been trying to fit a multinomial random effects model to MI data. The only options are -gsem- and -gllamm- , but of course neither is officially supported with mi estimate. So when fitting the model with -gsem- I have used the cmdok option (whether it really is OK is another matter I guess), but after estimating the model on all the imputation sets it refuses to combine the results, issuing the following message in red (error r(3598)):

name conflict
stata(): 3598 Stata returned error
_e_repost(): - function returned error
<istmt>: - function returned error

Is it something to do variables named differently across imputations, or perhaps it doesn't like the contrained latent variable=1, with no standard error? Fitting a standard multinomial logit model with -gsem- and -mi estimate, cmdok- is fine, as is the also non-supported -melogit- , but random effects logit via gsem also gets the same error message as above.

Is there any way to 'coerce' MI estimate to go through with the combination of imputation results? Actually, using -gllamm- will work with -mi estimate, cmdok- but I would rather not as the full model I mean to fit will take around 6-7 hours for each imputation (and _mi_m=20). I am prepared to combine the results 'manually' if need be, but was hoping specifically to use -mi test- to test the equality of corresponding coefficients across the two non-reference categories.

Any ideas and thoughts greatly appreciated, many thanks
Matthew

[Tim Morris]

Hi Matthew

Sounds like it might be easiest to just do the mi estimation 'by hand'. Rubin's rule is very simple to program (the formulas are given pdf documentation for mi estimate). If you program it yourself and it still fails at least you'll be able to see why.

Tim

[Richard Williams]

I would be tempted to report the problem to Stata Tech Support. When you see weird error messages like this, it is often because Stata doesn't know how to report a more meaningful error (or there might be a bug in Stata itself.)

[Matthew Burnell]

Hi Tim

yes I think I will have to do it 'by hand'. As you sayit should be simple enough, but I did want to be able to use the -mi test- feature as looking at the manual and formulae, it seems quite complex to get the correct inference. I wonder how 'inappropriate' it would be to just do a 'lincom' after estimation on each imputation set, and then just combine with Rubin's Rules using the estimate and se?

I have also now looked into the user written -mim- , using the cat(fit) option. Initially it didn't work either as it required me to -mi fvset- the data, but after doing that it a) worked on a random effects mlogit with just one shared random intercept but b) didn't work on the specific model set-up I would like that has a separate random intercept for each (non-reference category) equation because that requires me to specify the separate equations:

-gsem (1.ycat<- xvars... M1) (2.ycat<- xvars... M2), mlogit-

rather than just a single (ycat<-xvars.. M1) and so I still get the

no; data are mi set
Use mi fvset to set or query these data; mi fvset has the same syntax as fvset.

objection, which I'm not quite sure why and not sure if can be overcome. My experiments also suggest that using -mim- for the post-estimation stuff on even the single mlogit random intercept model will be problematic.

Matthew

[Matthew Burnell]

Hi Richard
thanks for the advice - I'm always reluctant to contact Stata directly as I always assume I'm doing something (stupidly) wrong! But perhaps I'll mention it if you think it is worth passing on.
regards
Matthew

[Matthew Burnell]

Just to let Statalist users know, if anyone comes across this with a similar issue, I have partially gotten to the bottom of the problem:

It is indeed a naming problem and specifically mi estimate doesn't seem to like the col/row names of the latent variables - the names attached to the lines in the output constrained to be equal to one (not the names relating to the variance component estimates themselves). What it doesn't like specifically is, I am guessing, the square brackets containing the name of the cluster variable.
My rough solution was to write a program that did the estimation command you wanted, took the e(b) and e(V) matrices, renamed them getting rid of those square brackets and then posted them back as estimation results. When then doing the mi estimate command, instead of using gsem, use myprogram.
Not sure yet how well this will deal with any mi postestimation commands...

[Tim Morris]

Interesting Matthew Burnell, and glad you got somewhere with it. Have you reported this to StataCorp? Sounds like it shouldn't be happening.
Tim

[Matthew Burnell]

Hi Tim
no I've not reported it yet. gsem is not an mi supported command, so maybe Stata have their reasons for it not working with -mi estimate-? That said, if my square bracket hypothesis is correct then this issue will relate to any multilevel model fitted with gsem, including those replicating models that are even supported by -mi estimate- such as -mixed- and -xtlogit- etc. (Regarding my 'solution', I guess if you also have a random coefficient term, then that will have a square bracket in the name that needs to be changed too in e(b) and e(V))

[Patrick Dickson]

I've just encountered the same error message using a -mi estimate, cmdok: gsem- command estimating a seemingly unrelated regression model with one mixed effect.

Matthew, could I ask you for more details about your solution that involved renaming matrices please?

[Matthew Burnell]

Hi Patrick, sorry the email notification was sent to a spam folder, and I don't check statalist itself very often at the moment.

As I said a workable solution (it seems) is to relabel the variables names attached to the estimation matrices. Basically anything with the square bracket seems to be a problem. Below is an example of the program I used. The fiddly part will be renaming the matrices, especially if you have a lot of variables, making sure you supply enough names and they are in an appropriate order. In fact I recall the matrix order is somewhat different from the output order (?) so you might need some trial and error to find out where the new names for variance/covariance terms go. Obviously Stata giving lots of these parameters the name '_cons' is confusing, and are only differentiated by the 'equation name' .
I wasn't able to use MI predict after this though - I hadn't posted everything required correctly I think, though MI test was OK.

cap program drop MLgsem
program MLgsem, eclass
version 14.2


local rownb /* now list all the variable (parameter) names, keeping most the same, but definitely changing the variance component with square brackets. May need to slightly reorder compared to model output. You can extract and display the current names to edit using the extended local macro function> local mname: rownames (and rowequation etc) */


local eqnb /* do the same for the equation names - you'll have a few I guess with SUR. for some reason doing it all together i.e extended fn: rowfullnames didn't work out for me, so tried this way with names and equation names separately */

gsem /* model syntax here */



/* then save estimates and its variance in temporary matrices*/
tempname b V N
mat `b' = e(b)
mat `V' = e(V)
local `N' = e(N)


/* Step 3: make column names and row names consistent*/
mat colnames `b' = `rownb'
mat colnames `V' = `rownb'
mat rownames `V' = `rownb'
mat coleq `b' = `eqnb'
mat coleq `V' = `eqnb'
mat roweq `V' = `eqnb'

/*Step 4: post results to e(). there are other things you need to post for the full MI estimate to display everything, like sample size, esample , number of aux parameters and df but I couldn't seem to get everything it needed successfully. */
ereturn post `b' `V'
ereturn local cmd "gsem"
ereturn local title "gsem SUR"
end

[Yulia Marchenko (StataCorp)]

The error that mi estimate, cmdok produced when used with unsupported command gsem in the presence of random effects has been fixed in Stata 15 and in Stata 14 as of update 13jul2017.

[Patrick Dickson]

Thanks very much Matt and Yulia for replies on this - thanks to Stata technical support for a rapid response and the fix that Yulia reports.