Problem of runing a fixed prior design

This forum is for posts that specifically focus on Ngene.

Moderators: Andrew Collins, Michiel Bliemer, johnr

Problem of runing a fixed prior design

Postby wxy008 » Thu Mar 05, 2020 7:29 am

Hi there,
There's a problem when I run my design. Ngene showed the massage:
A valid initial random design could not be generated after approximately 10 seconds. In this time, of the 189399 attempts made, there were 0 row repetitions, 11920 alternative repetitions, and 177479 cases of dominance. There are a number of possible causes for this, including the specification of too many constraints, not having enough attributes or attribute levels for the number of rows required, and the use of too many scenario attributes. A design may yet be found, and the search will continue for 10 minutes. Alternatively, you can stop the run and alter the syntax.

Below is my codes:
Code: Select all
Design;
;alts = alt1*,alt2*,nobuy
;rows = 32
;eff = (mnl,d)
;block = 4
;model:
U(alt1) =  b1[-0.81] * price[4.45, 8.45, 12.45, 16.45] +
                 b2.dummy[0.94]   * Or[0,1] +
                 b3.dummy[0.55]   * Ft[0,1] +
                 b4.dummy[0.22]   * Ct[0,1]
                         /

U(alt2) = b1     * price +
                 b2         * Or +
                 b3        * Ft +
                 b4         * Ct
  /
U(nobuy) = b0[-8.68]
        $


Are there somethings wrong in my codes? How should I solve this problem?

Thanks for your helps.
wxy008
 
Posts: 9
Joined: Wed Mar 04, 2020 3:22 am

Re: Problem of runing a fixed prior design

Postby Michiel Bliemer » Thu Mar 05, 2020 8:55 am

In total there exist (4*2*2*2)^2 = 1,024 choice tasks, of which 516 choice tasks do not contain a dominant alternative or repetition.
The default swapping algorithm, randomly generates designs that satisfy attribute level balance, however it is difficult for Ngene to randomly generate a design with 32 rows in which there do not exist any dominant alternatives.

In this case, it is best to switch to the modified Federov algorithm, which can handle constraints such as dominance checks much better. The modified Federov algorithm by default does not impose attribute level balance, so additional constraints need to be added to guarantee (some level of) attribute level balance if desired.

The syntax below works well for your case:

Code: Select all
Design;
;alts = alt1*,alt2*,nobuy
;rows = 32
;eff = (mnl,d)
;alg = mfederov
;block = 4
;model:
U(alt1) =  b1[-0.81] * price[4.45, 8.45, 12.45, 16.45](8,8,8,8) +
                 b2.dummy[0.94]   * Or[0,1] +
                 b3.dummy[0.55]   * Ft[0,1] +
                 b4.dummy[0.22]   * Ct[0,1]
                         /

U(alt2) = b1     * price +
                 b2         * Or +
                 b3        * Ft +
                 b4         * Ct
  /
U(nobuy) = b0[-8.68]
$


I have added ;alg = mfederov and I have also added (8,8,8,8) as attribute level constraints for your price attribute, which adds constraints that each level should appear exactly 8 times in the 32 rows (i.e. attribute level balance). Dummy coded variables generally do not need an attribute level constraint since these levels will automatically be fairly balanced, but if desired you could try adding (16,16) for complete attribute level balance, or if that does not work, relax it to something like (14-18,14-18), which states that each level needs to appear between 14 and 18 times.

Michiel
Michiel Bliemer
 
Posts: 898
Joined: Tue Mar 31, 2009 4:13 pm

Re: Problem of runing a fixed prior design

Postby wxy008 » Fri Mar 06, 2020 3:06 am

Dear Michiel,

Thanks so much your help. I run the codes you provided, and I got 16.15 of B estimate which is far from 70%-90%. Do you think it is ok? what does cause the low utility balance, price levels or prior value? Do you have any suggestion to improve the utility balance?

Thanks for your help. I really appreciate it.

Wei
wxy008
 
Posts: 9
Joined: Wed Mar 04, 2020 3:22 am

Re: Problem of runing a fixed prior design

Postby Michiel Bliemer » Fri Mar 06, 2020 8:45 am

The imbalance is caused by your priors, which are extremely large. b1 being -0.81 and multiplied with a large attribute level means that this attribute completely dominates choices and therefore it is difficult to get good trade-offs. Please make sure that your priors come from a pilot study, it is difficult to imagine that these priors come from a pilot study (unless the pilot study had many dominant alternatives in the choice tasks).

Michiel
Michiel Bliemer
 
Posts: 898
Joined: Tue Mar 31, 2009 4:13 pm

Re: Problem of runing a fixed prior design

Postby wxy008 » Fri Mar 06, 2020 10:19 am

Michiel,

Thank you ever so much for your help. I truly appreciate all your suggestions.

Wei
wxy008
 
Posts: 9
Joined: Wed Mar 04, 2020 3:22 am


Return to Ngene

Who is online

Users browsing this forum: Google [Bot] and 8 guests

cron