Attribute level realistic only for SQ alternative

[atien]

Dear all,

I am facing the following problem. The level of 430 for attribute seal is not very realistic in alt1 and alt2, only in SQ. However, if I add require alt1.seal > 430, alt2.seal > 430 to the syntax, I will have problems with ASCs. I actually did include this constraint in our pilot design and Ngene found a design but, understandably, there were problems with modelling when we tried to add ASCs.

So my question is, is there a way to work around this and make a design where seal=430 attribute level only appears in sq alternative and ASCs can be estimated? Or alternatively, is there a way to make seal=430 appear only in few choice sets? Even though seal=430 is really unrealistic for alt1 and alt2, it might be plausible if it appears only in few choice sets, clearly more seldom than levels 600,800 and 1000.

I add syntax for both final and pilot study below.

Thank you in advance!
Best, Annika



Final study (draft)

Design
;alts = alt1*, alt2*, sq*
;rows = 108
;block = 18
;eff = (mnl, d) + 0.5 * (imbalance)
;alg = mfederov(candidates = 25000)
;require:
sq.seal = 430,
sq.motor = 100,
sq.const = 7200,
sq.fish = 1,
sq.cost = 0,
alt1.cost>0,
alt2.cost>0

;model:
U(alt1) = seal.dummy [0.08|0.15|0.20] * SEAL[600, 800, 1000, 430]
+ motor.dummy [(n,0.05,0.1)|(n,0.09,0.1)] * MOTOR[200, 400, 100]
+ const.dummy [(n,0.15,0.1)|(n,0.15,0.1)] * CONST[5400, 3600, 7200]
+ fish.dummy [-0.03|-0.21|-0.22] * FISH[2, 3, 4, 1]
+ cost [-0.0047] * COST[0, 5, 10, 20, 50, 100, 150, 300]
/
U(alt2) = seal.dummy * SEAL
+ motor.dummy * MOTOR
+ const.dummy * CONST
+ fish.dummy * FISH
+ cost * COST
/
U(sq) = seal.dummy * SEAL
+ motor.dummy * MOTOR
+ const.dummy * CONST
+ fish.dummy * FISH
+ cost * COST $



Pilot study

Design
;alts = alt1*, alt2*, sq*
;rows = 30
;block = 5

;eff = (mnl, d) + 0.5 * (imbalance)
;alg = mfederov(candidates = 25000)
;require:
sq.seal = 430,
sq.motor = 100,
sq.const = 7200,
sq.fishing = 1,
sq.cost = 0,
alt1.cost>0,
alt2.cost>0,
alt1.seal > 430,
alt2.seal > 430

;model:
U(alt1) = seal.dummy [0.0001|0.0002|0.0003] * SEAL[600, 800, 1000, 430]
+ motor.dummy [-0.00001|-0.00002] * MOTOR[200, 400, 100]
+ const.dummy [-0.00001|-0.00002] * CONST[5400, 3600, 7200]
+ fish.dummy [-0.00001|-0.00002|-0.00003] * FISH[2, 3, 4, 1]
+ cost [-0.00001] * COST[0, 10, 20, 50, 100, 200, 500]
/
U(alt2) = seal.dummy * SEAL
+ motor.dummy * MOTOR
+ const.dummy * CONST
+ fish.dummy * FISH
+ cost * COST
/
U(sq) = seal.dummy * SEAL
+ motor.dummy * MOTOR
+ const.dummy * CONST
+ fish.dummy * FISH
+ cost * COST $

[Michiel Bliemer]

To make sure that you can estimate all constants in your model it is best to add these constants also in the utility functions in Ngene. If Ngene produces an infinite (or very large) D-error then it is not possible to estimate the model and you immediately know that there is an issue in parameter identifiability.

Below are three approaches that I can think of.

Approach 1: Consider Seal as a numerical variable (not dummy coded) just like cost. This will allow estimating all constants. If a nonlinear relationship is desired, you can put log(seal) or another transformation in your utility function. This approach would not work if Seal cannot reasonably be considered a numerical variable.

Approach 2: Per your suggestion, let Seal = 430 only appear rarely for alt1 and alt2 in the design. In the syntax below, I require that Seal only appears a maximum 10 times in alt1 and in alt2. Note that I reduced the number of candidates and used smarter Bayesian draws to reduce the computation time. You will still need to run this syntax for quite a long time.

Code: Select all

Design
;alts = alt1*, alt2*, sq*
;rows = 108
;block = 18
;eff = (mnl, d) + 0.5 * (imbalance)
;alg = mfederov(candidates = 2500)
;bdraws = gauss(3)
;require:
sq.sealsq = 430,
sq.motor = 100,
sq.const = 7200,
sq.fish = 1,
sq.cost = 0,
alt1.cost>0,
alt2.cost>0

;model:
U(alt1) = con1
+ seal.dummy [0.08|0.15|0.20] * SEAL[600, 800, 1000, 430](1-108,1-108,1-108,1-10)
+ motor.dummy [(n,0.05,0.1)|(n,0.09,0.1)] * MOTOR[200, 400, 100]
+ const.dummy [(n,0.15,0.1)|(n,0.15,0.1)] * CONST[5400, 3600, 7200]
+ fish.dummy [-0.03|-0.21|-0.22] * FISH[2, 3, 4, 1]
+ cost [-0.0047] * COST[0, 5, 10, 20, 50, 100, 150, 300]
/
U(alt2) = con2
+ seal.dummy * SEAL
+ motor.dummy * MOTOR
+ const.dummy * CONST
+ fish.dummy * FISH
+ cost * COST
/
U(sq) = seal.dummy * SEALSQ[600, 800, 1000, 430]
+ motor.dummy * MOTOR
+ const.dummy * CONST
+ fish.dummy * FISH
+ cost * COST $

Approach 3: Cooper et al. (2012) proposed a hybrid coding approach in model estimation to resolve this issue. I have no experience with this hybrid coding approach.

Cooper, B., Rose, J.M. and Crase, L. (2012) Does anybody like water restrictions? Some observations in Australian urban communities, Australian Journal of Agricultural and Resource Economics, 56(1), 61-51.

I hope this helps.

Michiel

[atien]

Thank you so much Michiel! I think we are going to proceed with the second approach.
Hybrid coding sounds interesting, but would probably require some time to get familiar to.

Best regards
Annika