choice-metrics.com

A design that is optimised for efficiency will ensure that all your parameters can be estimated with high reliability. It is therefore not necessary to have each attribute level appear equally, but I do often like to see some attribute level balance. Some people do not care about attribute level balance at all. Minimising the D-error in an efficient design ensures that all attribute levels appear a sufficient number of times to estimate the parameters, so do you not need to worry about that.

Note that you only included main effects in your utility function, therefore there is no optimisation for the estimation of interaction effects and it cannot be guaranteed that you can estimate all interaction effects. You can increase the number of rows to increase the variation in the data, which allows estimating more interaction effects, or you can include interaction effects direclty in the utility fuction, eg beta * distance * price, or beta * distance * chargingspeed.dummy[1], which will guarantee that you can estimate these interaction effects.

Michiel

Dear Professor,
One thing that is still persisting the a problem into my design.

I have conditional prohibitions in my attribute level such as (For example: considering Charging speed and price attribute- Charging speed so called 'Rapid', 'Fast', 'Moderate' and the price levels are 55€,75€,95€). I have a limitation saying that the 55€ cannot appear with Fast & Moderate charging speeds and 95€ cannot appear with Rapid charging speeds.

Since, i have these attribute level constraints, i assume it is not possible to maintain the attribute level balance in a symmetrical design experiment (since it is an unlabeled experiment with generic attribute levels).

What possible thing needs to be done under this circumstances?

Here is my code:

design
;alts = Tariff1*, Tariff2*, Tariff3*
;rows = 16
;eff= (mnl,d)
;alg = mfederov
;block= 2
;model:
U(Tariff1) = bloc[-0.000001] * Distance[500,1000,1500](4-6,4-6,4-6)
+brt [0.000001] * RWT[0,10,15](4-6,4-6,4-6)
+ bchargingspeed.dummy[0.0001|0.0001] * Chargingspeed[1,2,3] ? 1 = Moderate, 2 = fast, 3 = Rapid
+ bcost[-0.000001] * Price[55,75,95](4-6,4-6,4-6)
/
U(Tariff2) = bloc*Distance+brt*RWT+bchargingspeed*Chargingspeed+bcost*Price /
U(Tariff3) = bloc*Distance+brt*RWT+bchargingspeed*Chargingspeed+bcost*Price

$

You can add restrictions, for example:

;reject:
Tariff1.Chargingspeed = 1 and Tarrif1.Price = 55,
Tariff1.Chargingspeed = 2 and Tarrif1.Price = 55,
Tariff2.Chargingspeed = 1 and Tarrif2.Price = 55,
Tariff2.Chargingspeed = 2 and Tarrif2.Price = 55,
Tariff3.Chargingspeed = 1 and Tarrif3.Price = 55,
Tariff3.Chargingspeed = 2 and Tarrif3.Price = 55

You can find more about the reject command in the Ngene manual.

Adding these restrictions will make it more difficult to satisfy the attribute level balance constraints, so if Ngene cannot find a feasible design you need to somewhat relax the attribute level balance constraints.

Michiel