mxLog failed with errno=-1

22 posts / 0 new
Offline
Joined: 01/16/2013 - 10:41
mxLog failed with errno=-1
AttachmentSize
12.16 KB

Hi,
I' getting the following errors when trying to run a submodel (i.e. putting on constraints). I have tried changing starting values, putting on bounds, but nothing seems to help. I'm running this in Windows.

Error in runHelper(model, frontendStart, intervals, silent, suppressWarnings, :
mxLog failed with errno=-1
or
Error: The job for model 'HomAceIP' exited abnormally with the error message: MxComputeGradientDescent: fitfunction HomAceIP.fitfunction evaluated to 1.#INF00 ()
or
Error: The job for model 'HomAceIP' exited abnormally with the error message: MxComputeGradientDescent: fitfunction HomAceIP.fitfunction evaluated to 1.#QNAN0 ()

I have attached the script. It is model 2 that produces the different errors.

Thanks,
Karoline

Offline
Joined: 04/19/2011 - 21:00
This might be a dumb

This might be a dumb question, but could you refer me to where functions like labFull() and makeModel() are defined? I'm not familiar with them.

Offline
Joined: 01/16/2013 - 10:41
Not at all. Sorry, I should

Not at all. Sorry, I should have sent this in the script (it's just to assign labels):
labFull <- function(lab,nr,nc) { paste(lab,1:nr,rep(1:nc,each=nr),sep="_") }

The function makeModel is defined in the script: makeModel <- function(name) {

Hope that helped to clarify.

Offline
Joined: 04/19/2011 - 21:00
Move stuff from the top-level model to the submodels

I think what you need to do is move stuff from the top-level model into the submodels. Try re-defining makeModel() to something like this:

makeModel  <- function(name) {
mats      <- list( matUnv, matI, meanG, inc)
parsf     <- list( pathAcf, pathCcf, pathEcf, pathAsf, pathCsf, pathEsf, covAf, covCf, covEf, covPf, invSDf,
threGf, threTf, pathBf)
parsm     <- list( pathAcm, pathCcm, pathEcm, pathAsm, pathCsm, pathEsm, covAm, covCm, covEm, covPm, invSDm,
threGm, threTm, pathBm)
parsfm    <- list( covAmf, covCmf, covAfm, covCfm, threTo )
defsf     <- list( defAge, devAgef, meanTf )
defsm     <- list( defAge, devAgem, meanTm )
defso     <- list( defAge, devAgef, devAgem, meanTo )
modelMZf  <- mxModel( mats, parsf, defsf, covMZf, dataMZf, expFunctionMZf,var1f, fitfunction, name="MZf" )
modelDZf  <- mxModel( mats, parsf, defsf, covDZf, dataDZf, expFunctionDZf,var1f, fitfunction, name="DZf" )
modelMZm  <- mxModel( mats, parsm, defsm, covMZm, dataMZm, expFunctionMZm,var1m, fitfunction, name="MZm" )
modelDZm  <- mxModel( mats, parsm, defsm, covDZm, dataDZm, expFunctionDZm,var1m, fitfunction, name="DZm" )
modelDZo  <- mxModel( mats, parsf, parsm, parsfm, defso, covDZo, dataDZo, expFunctionDZo, fitfunction, var1m, var1f,name="DZo" )
mgalg <- mxAlgebra(MZf.fitfunction + DZf.fitfunction + MZm.fitfunction + DZm.fitfunction + DZo.fitfunction, name="mgalg")
mgfitfunction <- mxFitFunctionAlgebra("mgalg")

name  <- mxModel( name,
modelMZf, modelDZf, modelMZm, modelDZm, modelDZo, mgalg, mgfitfunction )
}
Offline
Joined: 01/16/2013 - 10:41
Thank you. I tried this, and

Thank you. I tried this, and still get the following error:

Error in runHelper(model, frontendStart, intervals, silent, suppressWarnings, :
mxLog failed with errno=-1

Offline
Joined: 12/12/2012 - 12:15
try this

Can you apply the attached patch and try again?

Offline
Joined: 01/16/2013 - 10:41

Could you please provide information on how to apply it?

Thank you.

Offline
Joined: 04/19/2011 - 21:00
Karoline, do you know how to

Karoline, do you know how to build OpenMx from source?

In any event, I notice that you don't use mxFactor() on your data anywhere in the script you posted. That might not matter, but would you mind running the following R command,
Edit: Never mind. A problem with the dataset wouldn't explain why the first model runs but the second one doesn't.

Offline
Joined: 12/12/2012 - 12:15
Rgui

Karoline, this is a known problem with Rgui. Can you run your script in RStudio or at the batch terminal prompt instead?

Offline
Joined: 07/31/2009 - 14:25
what is Rgui? CRAN R (R.app on mac?) what's the known problem?

Hi,
Not sure what what "Rgui" is. Does that mean the R app that most people run, downlaoded from CRAN? (i.e. R.app on OS X?)

What is the known problem?
I'm not experiencing any (R 3.1.2)

Offline
Joined: 04/19/2011 - 21:00
This is (I believe) a Windows-specific issue

Rgui.exe is the filename of the Windows executable that constitutes the "out-of-the-box" graphical user interface for R. The known problem is documented in the R Project's Windows FAQ:

8.6 The output from my C code disappears. Why?

The Rgui.exe console is a Windows application: writing to stdout or stderr will not produce output in the console. (This will work with Rterm.exe.) Use Rprintf or REprintf instead. These are declared in header file R_ext/PrtUtil.h.

Note that output from the console is delayed (see The output to the console seems to be delayed), so that you will not normally see any output before returning to the R prompt.

Offline
Joined: 01/16/2013 - 10:41
I ran it in RStudio and got

I ran it in RStudio and got this for the second model:
[0] The linearized problem has no feasible solution. The problem may not be feasible.

I guess there could be a problem of enough power in the data, but I think it is a bit strange, since the second model is simpler than the first. And I get homogeneity in a correlated factors model, so setting the parameters to be equal across sexes in Model 2 shouldn't be that far off.

When trying to run only the second model in a new RStudio session, I got this (same as in Rgui):
Error: The job for model 'IndAce' exited abnormally with the error message: MxComputeGradientDescent: fitfunction IndAce.fitfunction evaluated to 1.#INF00 ()

Offline
Joined: 04/19/2011 - 21:00
You no longer see error

You no longer see error message "mxLog failed with errno=-1", correct? That was the error message that really had me and Joshua stumped.

If you no longer see that error message, then I hate to say it, but I think your start values are the problem. For the second model, you mention both a warning, "The linearized problem has no feasible solution. The problem may not be feasible.", and an error, "Error: The job for model 'IndAce' exited abnormally with the error message: MxComputeGradientDescent: fitfunction IndAce.fitfunction evaluated to 1.#INF00 ()". The warning message is telling you that, given the imposed constraints, the optimizer cannot both minimize the fitfunction and satisfy the constraints. The error message is telling you that the fitfunction returned an infinite value. If the infinite value was enough to prematurely terminate optimization, then it very likely happened on the first iteration...implying bad start values.

In particular, note that you've used an MxConstraint to fix the diagonals of the expected covariance matrices to 1. It would help if your start values satisfied that constraint (or came close to doing so). I'm looking at the expected covariance matrix of one of the submodels in your second model, at the start values, with mxEval(expCovMZf,ACEmvhomIPModel$MZf,T). It might help if you tweaked the start values so that the diagonals were closer to 1. Also, the ratio of its largest eigenvalue to its smallest is 155, so you might want to reduce the off-diagonals as well. Are you using the third beta? If so, consider mxTryHard(). It will repeatedly run your model a given number of times until an acceptable solution is reached, and randomly jitters start values in between attempts. It prints to console the start values it used on its last attempt, so if you get an acceptable fit, you can copy-paste those start values into your script. See the function's help page for details. One last thing--are you using NPSOL or CSOLNP as default optimizer? You can tell with mxVersion(). Offline Joined: 01/16/2013 - 10:41 Thank you very much for the Thank you very much for the help and guidance to what may be the problem. I have not seen the "mxLog failed with errno=-1" in the last attempts. It came up occasionally when trying out different starting values at the beginning, before I posted it on the forum. Yes, I'm using the third beta. I'll try mxTryHard(). Thanks. I'm using CSOLNP as the default optimizer, but I also tried NPSOL with no luck. Offline Joined: 01/16/2013 - 10:41 Unfortunately, I am still Unfortunately, I am still seeing the error "mxLog failed with errno=-1" despite having tweaked the starting values for the diagonals to be closer to 1 and reduced the off-diagonals as well. E.g. > mxEval(expCovMZf,ACEmvhomIPModel$MZf,T)
[,1] [,2] [,3] [,4] [,5] [,6]
[1,] 1.01 0.82 0.83 0.93 0.78 0.77
[2,] 0.82 0.88 0.78 0.78 0.80 0.72
[3,] 0.83 0.78 0.95 0.77 0.72 0.82
[4,] 0.93 0.78 0.77 1.01 0.82 0.83
[5,] 0.78 0.80 0.72 0.82 0.88 0.78
[6,] 0.77 0.72 0.82 0.83 0.78 0.95

Continuing to tweak the starting values resulted in both RStudio and R crashing.

I tried mxTryHard() in RStudio, but this does not seem to work. After 18 attempts it kept returning the warning "The linearized problem has no feasible solution".

I have previously posted a question because every time I install the beta I get this warning: dependencies ‘RcppEigen’ is not available. However, this package shows in the library. I don't know if this may have anything to do with the current issue though. http://openmx.psyc.virginia.edu/thread/3911

Is there any possibility that there could be a bug that hinders the optimization? Although it seems strange that the first model will run.

Thanks for the help.

Offline
Joined: 04/19/2011 - 21:00
Karoline, I first want to

Karoline, I first want to thank you for being so patient through all this. We really appreciate it, because you're definitely helping us with debugging and beta-testing OpenMx!

If the problems you're encountering are due to a bug, we need to know whether or not it has been repaired since the third beta was released. I'd like you to install the most recent revision of OpenMx from the repository. I'll build you a binary of the package (for 32-bit Windows, correct?) and contact you via email to arrange how to get it to you.

Once you've installed the most recent revision, try your script again, but with a few changes. First, set the default optimizer to NPSOL with mxOption(NULL,"Default optimizer","NPSOL"). I suspect the crashes you experience were due to ongoing problems with CSOLNP. Also, before you run your second model, change some of its options as follows:

ACEmvhomIPModel <- mxOption(ACEmvhomIPModel,"Always Checkpoint","yes")
ACEmvhomIPModel <- mxOption(ACEmvhomIPModel,"Checkpoint Directory",getwd())
ACEmvhomIPModel <- mxOption(ACEmvhomIPModel,"Checkpoint Units","evaluations")
ACEmvhomIPModel <- mxOption(ACEmvhomIPModel,"Checkpoint Count",1)

These four changed options will write a checkpoint log file of the parameters, fitfunction value, etc. as optimization proceeds. The file will be written to whatever is R's current working directory, so if you want to write it to a different directory, replace getwd() above with the path (in quotes) for the directory you want. The file will be called something like HomAceIP.omx.

Then, when you run your second model, pass argument checkpoint=TRUE to mxRun() or mxTryHard(), as the case may be.

If your second model runs with the new revision and NPSOL, then great! If not, the checkpoint log--and especially, its last few lines--will give us an idea of what's going on.

If your second model still doesn't run, then I have a few more ideas up my sleeve. One would be to remove the boundary constraints (lbound and ubound) on the paths. Another would be to identify the model without using any MxConstraints, by fixing the unshared-environmental variance to some constant (say, 1).

Offline
Joined: 01/16/2013 - 10:41
Thank you, Rob. The second

Thank you, Rob. The second model runs with the new revision and NPSOL!

I'm getting a warning RED (Optimizer returned a non-zero status code 6) for both model 1 and 2 though, but I guess that's more to do with the starting values or sth of that sort.
I've attached the .omx file just in case. I deleted some of the middle lines because of the maximum upload size limit.

Thanks,
Karoline

Offline
Joined: 04/19/2011 - 21:00
Good news

Karoline, that's very good to hear! You should try to clear the code RED if possible (mxTryHard() may help in this regard). Unfortunately, code REDs are sometimes virtually unavoidable in ordinal-threshold models (it has to do with the limited precision of the approximation to the multivariate-normal integral).

It would seem that the problems you were encountering initially were due to a bug that has been corrected since the release of the third beta. Naturally, we're curious if the bug (or a similar one) still exists with CSOLNP, so if you're feeling adventurous, please give your script a try with CSOLNP and let us know how it goes.

Offline
Joined: 01/16/2013 - 10:41

I ran the models with CSOLNP. The first model ran fine (no errors or warnings), and also indicated better fit than when using NPSOL. The second model returned this: Running HomAceIP
Error in runHelper(model, frontendStart, intervals, silent, suppressWarnings, :
mxLog([0] The linearized problem has no feasible solution. The problem may not be feasible.
) failed with errno=-1

Offline
Joined: 04/19/2011 - 21:00
CSOLNP still problematic

Thanks for trying again with CSOLNP. It seems that the same problem (or a similar one) persists when using that optimizer. Is running the analysis with NPSOL and the revision I built for you adequate for your purposes?

Offline
Joined: 01/16/2013 - 10:41
Yes, I'm getting the output

Yes, I'm getting the output that I need. Thank you!

Offline
Joined: 01/16/2013 - 10:41
I haven't tried to build

I haven't tried to build OpenMx from source. Found the page on "how to", so if you think that may be a solution to the problem, then I could try. Not sure what it means though.

I cleaned the script a little before I posted it and mxFactor() got left out. But thanks for noticing.