CrossNested Estimation
Posted: 06 Apr 2021, 13:36
Hello,
My name is Saeed. Recently, I decided to estimate a CrossNested logit model for a household's location choice & dwelling choice behavior after COVID-19 based on stated preference data. I am facing the "Parameter lambda_detac does not influence the log-likelihood of your model!" error.
I went through the manual and documentation and so far tried these solutions but I had no luck.
1- Making sure that all multiple line commands are linked
2- Starting from a simple model (constant only, generic price variable, and asv telecommuting variable, all allocation parameters are set to 0.5)
3- making "workinlogs" true
Here is what I think, and a couple of questions
- The problem is causing because my starting values, but trying various combinations of starting values is not helping so far. Is there a way I can see the calculated probabilities in the middle of the run? then I can identify which utility is creating super small values and I can balance starting points based on them?
- I am also in doubt if this problem is because of my model structure. Because of my restricted availabilities, each person only has one single alternative in each nest and no one ever sees multiple choices that are in the same nest(please see my brief model description below). (On a side note, I fixed the parameter with the issue in the estimation and another error popped up indicating the same problem with the next logsum parameter. I am pretty sure all logsum parameters have the same issue).
Also, by any chance, if anyone has a suggestion to solve this issue I would appreciate it a lot.
Here is a brief intro of my model:
*******************************************************************
My model has 73 alternatives, the "NoRelocation" choice is always available, and 4 dwelling type & region joint choices out of 72 total choices (4 total dwelling types and 18 total regions). In the dataset, in each scenario, each person has encountered the 4 choices randomly. Each person responded to 9 scenarios out of a total of 18 scenarios.
Since each person answered multiple scenarios I used "internormdraws" to capture interpersonal heteroskedasticity. Besides the mixing parameter I have in my model, the reason I have chosen the generalized nested logit model is that I don't want to prioritize dwelling choice over region choice and vice versa. If I use the nested structure I would pre-impose preference of one of the attributes to another which is not realistic.
********************************************************************
On a side note, before coming to Apollo, I tried to estimate this model by using GAUSS. GAUSS debugging indicated that the formulation of the model is correct and matches my calculations by hand, but in MLE GAUSS couldn't invert the Hessian Matrix using the BFGS method.
In GAUSS, if I set the method to BFGS and forced using the approximated hessian instead of the hessian calculation the model would converge but convergence will be always super close to starting values and after checking different starting values I realized the method is not reliable and I migrated to Apollo environment which offers "numderiv" and looks like to be more stable in approximation compared to GAUSS.
My name is Saeed. Recently, I decided to estimate a CrossNested logit model for a household's location choice & dwelling choice behavior after COVID-19 based on stated preference data. I am facing the "Parameter lambda_detac does not influence the log-likelihood of your model!" error.
I went through the manual and documentation and so far tried these solutions but I had no luck.
1- Making sure that all multiple line commands are linked
2- Starting from a simple model (constant only, generic price variable, and asv telecommuting variable, all allocation parameters are set to 0.5)
3- making "workinlogs" true
Here is what I think, and a couple of questions
- The problem is causing because my starting values, but trying various combinations of starting values is not helping so far. Is there a way I can see the calculated probabilities in the middle of the run? then I can identify which utility is creating super small values and I can balance starting points based on them?
- I am also in doubt if this problem is because of my model structure. Because of my restricted availabilities, each person only has one single alternative in each nest and no one ever sees multiple choices that are in the same nest(please see my brief model description below). (On a side note, I fixed the parameter with the issue in the estimation and another error popped up indicating the same problem with the next logsum parameter. I am pretty sure all logsum parameters have the same issue).
Also, by any chance, if anyone has a suggestion to solve this issue I would appreciate it a lot.
Here is a brief intro of my model:
*******************************************************************
My model has 73 alternatives, the "NoRelocation" choice is always available, and 4 dwelling type & region joint choices out of 72 total choices (4 total dwelling types and 18 total regions). In the dataset, in each scenario, each person has encountered the 4 choices randomly. Each person responded to 9 scenarios out of a total of 18 scenarios.
Since each person answered multiple scenarios I used "internormdraws" to capture interpersonal heteroskedasticity. Besides the mixing parameter I have in my model, the reason I have chosen the generalized nested logit model is that I don't want to prioritize dwelling choice over region choice and vice versa. If I use the nested structure I would pre-impose preference of one of the attributes to another which is not realistic.
********************************************************************
On a side note, before coming to Apollo, I tried to estimate this model by using GAUSS. GAUSS debugging indicated that the formulation of the model is correct and matches my calculations by hand, but in MLE GAUSS couldn't invert the Hessian Matrix using the BFGS method.
In GAUSS, if I set the method to BFGS and forced using the approximated hessian instead of the hessian calculation the model would converge but convergence will be always super close to starting values and after checking different starting values I realized the method is not reliable and I migrated to Apollo environment which offers "numderiv" and looks like to be more stable in approximation compared to GAUSS.