-
Notifications
You must be signed in to change notification settings - Fork 34
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
enhancement for mxStandardizeRAMpaths: ParamsCov[paramnames, paramnames] : subscript out of bounds #49
Comments
I'd be curious to see the syntax that produced
The DZ submodel's Hessian has rows and columns corresponding to nonexistent free parameters, whereas free parameter |
OK, I see that the container model, as well as both submodels, have their own compute plans. That would explain why the submodels have their own Hessians. |
The code is just paths and models. The models have different data, different path labels, different parameter estimates. Not sure how Hessian could be the same, or how a user might even attempt to do that, or to apply a single compute plan. I just build models, and created a supermodel with a group objective. No advanced edits of any kind were made. Re stale names in Hessian, It might be that the path names are updated but the model hasn't been re-run. But in that case the bug would be But we also shouldn't allow raw errors out of functions like ParamsCov (not sure what that is) |
Some more information: offer up the container model to
But ask for the DZ model, and the error emerges:
While for the MZ model, it works fine
|
Note that multigroup standardization can yield different estimates for the same parameter, if the groups' variances differ. So to some extent, it only makes sense to standardize all the groups. However, we should probably tell the user that this is the case if they pluck a lower level model from the list. Or fix the bug :-)
|
Joshua says that the backend only looks at the compute plan in the container MxModel, so the fact that the submodels have their own Hessians isn't a result of them having their own compute plans. Did you run the MZ and DZ models separately, and then put them together into a multigroup container?
Yes, here
Perhaps. Again, I'm going to need to see the syntax that gave rise to |
Ahh: yes, models each run on their own first, as the supermodel struggled if the submodels didn't already have good starting solutions. Sounds like the thing that needs doing is to cope with the fact that models might have Hessians lying around from being run independently? Something like Or maybe trap this kind of parameter mismatch error with:
I think the issue was that I didn't know umxStandardizeRAM could cope with submodels, so maybe this won't bite anyone but me trying to write helper functions. |
So, then the mismatch between free parameter labels and Hessian dimnames in the DZ submodel arose because you ran the assembled container model through In any event, running Edit: I was wrong about it not checking the |
Should be repaired with 25eab2c, though it still needs a test. |
Closing as now has a better error message Under OpenMx version 2.9.4 I get:
|
@tbates Could you add a test for that error message? The only reason I left this open was the lack of a test. |
Load up the attached RAM model (a supermodel with 2 submodels)
running
mxStandardizeRAMpaths
yields the following error:It works fine if SE is not requested:
Also works fine on the other submodel
OpenMx version: 2.8.3.71 [GIT v2.8.3-71-g0aa1fc0]
R version: R version 3.4.3 (2017-11-30)
Platform: x86_64-apple-darwin15.6.0
MacOS: 10.13.4
Default optimiser: NPSOL
eqmeans.rda.txt
The text was updated successfully, but these errors were encountered: