Dear Michiel,
Using the script below, I try to generate an efficient experimental design. However, I get the error message that there are problems generating a fractional factorial of choice tasks. The problem is not solved when I reduce the number of candidates.
design
;alts = (alt1, alt2, sq)
;rows = 24
;block = 4
;eff = (mnl, d)
;alg = mfedorov
;reject:
alt1.timeb = 1 and alt1.priceb > 1, ? impossible to have multiple price blocks when there is only one time block
alt2.timeb = 1 and alt2.priceb > 1,
alt1.priceb = 1 and alt1.timeb > 1, ? impossible to have multiple time blocks when there is only one price block
alt2.priceb = 1 and alt2.timeb > 1,
alt1.diff_priceb > 0 and alt1.priceb = 1, ? impossible to have a difference between price blocks when there is only one price block
alt2.diff_priceb > 0 and alt2.priceb = 1,
alt1.diff_priceb = 0 and alt1.priceb > 1, ? impossible to have zero difference between the price blocks when having more than one price block
alt2.diff_priceb = 0 and alt2.priceb > 1,
alt1.priceb = 2 and alt1.timeb = 6, ? impossible to have 2 price blocks and 6 time blocks
alt2.priceb = 2 and alt2.timeb = 6,
alt1.priceb = 3 and alt1.timeb = 3, ? impossible to have the same amount of time and price blocks (except if both are equal to one)
alt1.priceb = 4 and alt1.timeb = 4,
alt1.priceb = 5 and alt1.timeb = 5,
alt1.priceb = 6 and alt1.timeb = 6,
alt1.diff_priceb = 0 and alt1.timeb > 1, ? impossible to have no difference between the price blocks when multiple time blocks
alt2.diff_priceb = 0 and alt2.timeb > 1,
alt1.season > 0 and alt1.timeb < 5, ? impossible to have two seasons and less than 5 time blocks
alt2.season > 0 and alt2.timeb < 5,
alt1.season > 0 and alt1.priceb < 3, ? impossible to have two seasons and less than 3 price blocks
alt2.season > 0 and alt2.priceb < 3
;require:
sq.comp = 0, sq.diff_priceb = 0, sq.priceb = 1, sq.timeb = 1, sq.season = 0, sq.capacity = 1 ? fixing the status quo grid tariff
;model:
U(alt1, alt2) = b1 *comp[0,10,20,30,40,50](3-5,3-5,3-5,3-5,3-5,3-5) ? € reduction fixed component distribution cost on bill
+ b2 *diff_priceb[0,10,20,30,40,50](3-5,3-5,3-5,3-5,3-5,3-5) ? percentage point difference between the price blocks (SQ is 100%)
+ b3 *priceb[1,2,3,4](4-8,4-8,4-8,4-8) ? no. of price blocks grid tariff
+ b4.dummy *timeb[3,5,6,1] ? no. of time blocks grid tariff
+ b5.dummy *season[1,2,0] ? composition of season structure grid tariff [1 = Winter & other, 2 = Autumn-Winter & Spring-Summer, 0 = 1 season]
+ b6.dummy *capacity[1,2,3,0] ? presence capacity component and X% reduction on kW price during 13-17h time window [0 = no capacity tariff, 1/2/3 = capacity tariff with 0/25/50% reduction in kW price]
+ i1 *priceb * diff_priceb ? how do preferences for price blocks change with the percentage point difference between price blocks & how do preferences for the percentage point difference between price blocks change with the number of price blocks
+ i2 *priceb * capacity.level[1] ? how do preferences for the kW component change with an increasing complexity in the kWh component (relative to a grid tariff without a capacity component)
+ i3 *priceb * capacity.level[2]
+ i4 *priceb * capacity.level[3]
/
U(sq) = b_sq[0] ? ASC for SQ
+ b1 *comp
+ b2 *diff_priceb
+ b3 *priceb
+ b4 *timeb
+ b5 *season
+ b6 *capacity
$
Therefore, I now first create a candidate set without a status quo; manually add the status quo to the Excel and then supply this candidate set to the mdfedorov algorithm.
design ? generate candidate set without status quo
;alts = (alt1, alt2)
;rows = 2000
;rand
;reject:
alt1.timeb = 1 and alt1.priceb > 1, ? impossible to have multiple price blocks when there is only one time block
alt2.timeb = 1 and alt2.priceb > 1,
alt1.priceb = 1 and alt1.timeb > 1, ? impossible to have multiple time blocks when there is only one price block
alt2.priceb = 1 and alt2.timeb > 1,
alt1.diff_priceb > 0 and alt1.priceb = 1, ? impossible to have a difference between price blocks when there is only one price block
alt2.diff_priceb > 0 and alt2.priceb = 1,
alt1.diff_priceb = 0 and alt1.priceb > 1, ? impossible to have zero difference between the price blocks when having more than one price block
alt2.diff_priceb = 0 and alt2.priceb > 1,
alt1.priceb = 2 and alt1.timeb = 6, ? impossible to have 2 price blocks and 6 time blocks
alt2.priceb = 2 and alt2.timeb = 6,
alt1.priceb = 3 and alt1.timeb = 3, ? impossible to have the same amount of time and price blocks (except if both are equal to one)
alt1.priceb = 4 and alt1.timeb = 4,
alt1.priceb = 5 and alt1.timeb = 5,
alt1.priceb = 6 and alt1.timeb = 6,
alt1.diff_priceb = 0 and alt1.timeb > 1, ? impossible to have no difference between the price blocks when multiple time blocks
alt2.diff_priceb = 0 and alt2.timeb > 1,
alt1.season > 0 and alt1.timeb < 5, ? impossible to have two seasons and less than 5 time blocks
alt2.season > 0 and alt2.timeb < 5,
alt1.season > 0 and alt1.priceb < 3, ? impossible to have two seasons and less than 3 price blocks
alt2.season > 0 and alt2.priceb < 3
;model:
U(alt1, alt2) = b1 *comp[0,10,20,30,40,50] ? € reduction fixed component distribution cost on bill
+ b2 *diff_priceb[0,10,20,30,40,50] ? percentage point difference between the price blocks (SQ is 100%)
+ b3 *priceb[1,2,3,4] ? no. of price blocks grid tariff
+ b4.dummy *timeb[3,5,6,1] ? no. of time blocks grid tariff
+ b5.dummy *season[1,2,0] ? composition of season structure grid tariff [1 = Winter & other, 2 = Autumn-Winter & Spring-Summer, 0 = 1 season]
+ b6.dummy *capacity[1,2,3,0] ? presence capacity component and X% reduction on kW price during 13-17h time window [0 = no capacity tariff, 1/2/3 = capacity tariff with 0/25/50% reduction in kW price]
$
and
design
;alts = (alt1, alt2, sq)
;rows = 24
;block = 4
;eff = (mnl, d)
;alg = mfedorov(candidates = tariff_candidateset_sq)
;model:
U(alt1, alt2) = b1 *comp[0,10,20,30,40,50] ?(3-5,3-5,3-5,3-5,3-5,3-5) ? € reduction fixed component distribution cost on bill
+ b2 *diff_priceb[0,10,20,30,40,50] ?(3-5,3-5,3-5,3-5,3-5,3-5) ? percentage point difference between the price blocks (SQ is 100%)
+ b3 *priceb[1,2,3,4] ?(4-8,4-8,4-8,4-8) ? no. of price blocks grid tariff
+ b4.dummy *timeb[3,5,6,1] ? no. of time blocks grid tariff
+ b5.dummy *season[1,2,0] ? composition of season structure grid tariff [1 = Winter & other, 2 = Autumn-Winter & Spring-Summer, 0 = 1 season]
+ b6.dummy *capacity[1,2,3,0] ? presence capacity component and X% reduction on kW price during 13-17h time window [0 = no capacity tariff, 1/2/3 = capacity tariff with 0/25/50% reduction in kW price]
+ i1 *priceb * diff_priceb ? how do preferences for price blocks change with the percentage point difference between price blocks & how do preferences for the percentage point difference between price blocks change with the number of price blocks
+ i2 *priceb * capacity.level[1] ? how do preferences for the kW component change with an increasing complexity in the kWh component (relative to a grid tariff without a capacity component)
+ i3 *priceb * capacity.level[2]
+ i4 *priceb * capacity.level[3]
/
U(sq) = b_sq[0] ? ASC for SQ
+ b1 *comp
+ b2 *diff_priceb
+ b3 *priceb
+ b4 *timeb
+ b5 *season
+ b6 *capacity
$
The last script, however, gives no results (not even an error message). Therefore, my questions are the following:
i) What causes the problem in the first script (i.e., not finding a fractional factorial)?
ii) Why is my approach with manually adding the status quo not working?
iii) In case the latter approach (with the candidate set) is preferred, is there a way to obtain a certain degree of attribute level balance in a random design? Because currently for some attributes there is a large imbalance.
iv) Adding a uninformative prior [+] to the monetary compensation attribute leads to equal cost levels across alternatives; and not doing so leads sometimes to sometimes an alternative that is identical to the SQ except from a positive compensation (i.e. dominant to the SQ). Is there a way to avoid these types of choice tasks?
Many thanks for your insights.
External candidate set
Moderators: Andrew Collins, Michiel Bliemer, johnr
-
Michiel Bliemer
- Posts: 2079
- Joined: Tue Mar 31, 2009 4:13 pm
Re: External candidate set
There are a few things happening.
First, to create the candidate set, Ngene randomly generates choice tasks and evaluates each choice task against your reject and require constraints. The require constraints are very strict and despite Ngene rapidly evaluating millions of choice tasks, Ngene does not seem to encounter choice tasks that satisfy all constraints. If you remove the require constraints, Ngene is able to do it. Similarly, manually adding the status quo alternative also works as you noticed.
Second, you added attribute level frequency constraints, which are imposed across ALL alternatives where this attribute appears.
So
b1 * comp[0,10,20,30,40,50] ?(3-5,3-5,3-5,3-5,3-5,3-5)
means that it tries to achieve these level frequencies not only in alt1 and alt2, but also in the status quo. But clearly, the sq alternative will never be able to achieve these level frequency constraints. To overcome this issue, you can simply use in your script:
b1 * comp_sq[0]
This way, you can also avoid having to use require constraints for your numerical attributes.
Third, Ngene cannot do dominance checks if you do not specify the same utility functions across the alternatives (except for the ASC). So you simplyu need to add the interaction effects as all generic alternatives must have identical utility functions.
Once you correct for this, your first script runs, but Ngene is unable to find a design because there are too many (level frequency) constraints, as it will report: "[Modified Fedorov] ERROR: Unable to find a design that satisfies the specified attribute level frequency constraints. You may need to relax some attribute level constraints, combinatorial constraints (if specified), or dominance checks. The candidate set has 2000 rows." I relaxed the level frequency constraints in the script, as otherwise it becomes almost impossible to find a design that satisfies them for all levels. So you will have to play around with it a bit.
If you want to impose dominance constraints, make sure that you specify priors - and + for (almost) all attributes, not just for the price attribute.
Note that you have a huge number of constraints in your design (reject constraints, require constraints, dominance constraints, repetition constraints, level frequency constraints), so it is quite a complex design.
Michiel
First, to create the candidate set, Ngene randomly generates choice tasks and evaluates each choice task against your reject and require constraints. The require constraints are very strict and despite Ngene rapidly evaluating millions of choice tasks, Ngene does not seem to encounter choice tasks that satisfy all constraints. If you remove the require constraints, Ngene is able to do it. Similarly, manually adding the status quo alternative also works as you noticed.
Second, you added attribute level frequency constraints, which are imposed across ALL alternatives where this attribute appears.
So
b1 * comp[0,10,20,30,40,50] ?(3-5,3-5,3-5,3-5,3-5,3-5)
means that it tries to achieve these level frequencies not only in alt1 and alt2, but also in the status quo. But clearly, the sq alternative will never be able to achieve these level frequency constraints. To overcome this issue, you can simply use in your script:
b1 * comp_sq[0]
This way, you can also avoid having to use require constraints for your numerical attributes.
Third, Ngene cannot do dominance checks if you do not specify the same utility functions across the alternatives (except for the ASC). So you simplyu need to add the interaction effects as all generic alternatives must have identical utility functions.
Once you correct for this, your first script runs, but Ngene is unable to find a design because there are too many (level frequency) constraints, as it will report: "[Modified Fedorov] ERROR: Unable to find a design that satisfies the specified attribute level frequency constraints. You may need to relax some attribute level constraints, combinatorial constraints (if specified), or dominance checks. The candidate set has 2000 rows." I relaxed the level frequency constraints in the script, as otherwise it becomes almost impossible to find a design that satisfies them for all levels. So you will have to play around with it a bit.
Code: Select all
design
;alts = (alt1, alt2, sq)
;rows = 24
;block = 4
;eff = (mnl, d)
;alg = mfedorov
;reject:
alt1.timeb = 1 and alt1.priceb > 1, ? impossible to have multiple price blocks when there is only one time block
alt2.timeb = 1 and alt2.priceb > 1,
alt1.priceb = 1 and alt1.timeb > 1, ? impossible to have multiple time blocks when there is only one price block
alt2.priceb = 1 and alt2.timeb > 1,
alt1.diff_priceb > 0 and alt1.priceb = 1, ? impossible to have a difference between price blocks when there is only one price block
alt2.diff_priceb > 0 and alt2.priceb = 1,
alt1.diff_priceb = 0 and alt1.priceb > 1, ? impossible to have zero difference between the price blocks when having more than one price block
alt2.diff_priceb = 0 and alt2.priceb > 1,
alt1.priceb = 2 and alt1.timeb = 6, ? impossible to have 2 price blocks and 6 time blocks
alt2.priceb = 2 and alt2.timeb = 6,
alt1.priceb = 3 and alt1.timeb = 3, ? impossible to have the same amount of time and price blocks (except if both are equal to one)
alt1.priceb = 4 and alt1.timeb = 4,
alt1.priceb = 5 and alt1.timeb = 5,
alt1.priceb = 6 and alt1.timeb = 6,
alt1.diff_priceb = 0 and alt1.timeb > 1, ? impossible to have no difference between the price blocks when multiple time blocks
alt2.diff_priceb = 0 and alt2.timeb > 1,
alt1.season > 0 and alt1.timeb < 5, ? impossible to have two seasons and less than 5 time blocks
alt2.season > 0 and alt2.timeb < 5,
alt1.season > 0 and alt1.priceb < 3, ? impossible to have two seasons and less than 3 price blocks
alt2.season > 0 and alt2.priceb < 3
;require:
sq.timeb = 1, sq.season = 0, sq.capacity = 1 ? fixing the status quo grid tariff
;model:
U(alt1, alt2) = b1 *comp[0,10,20,30,40,50](2-24,2-24,2-24,2-24,2-24,2-24) ? € reduction fixed component distribution cost on bill
+ b2 *diff_priceb[0,10,20,30,40,50](2-24,2-24,2-24,2-24,2-24,2-24) ? percentage point difference between the price blocks (SQ is 100%)
+ b3 *priceb[1,2,3,4](3-24,3-24,3-24,3-24) ? no. of price blocks grid tariff
+ b4.dummy *timeb[3,5,6,1] ? no. of time blocks grid tariff
+ b5.dummy *season[1,2,0] ? composition of season structure grid tariff [1 = Winter & other, 2 = Autumn-Winter & Spring-Summer, 0 = 1 season]
+ b6.dummy *capacity[1,2,3,0] ? presence capacity component and X% reduction on kW price during 13-17h time window [0 = no capacity tariff, 1/2/3 = capacity tariff with 0/25/50% reduction in kW price]
+ i1 *priceb * diff_priceb ? how do preferences for price blocks change with the percentage point difference between price blocks & how do preferences for the percentage point difference between price blocks change with the number of price blocks
+ i2 *priceb * capacity.level[1] ? how do preferences for the kW component change with an increasing complexity in the kWh component (relative to a grid tariff without a capacity component)
+ i3 *priceb * capacity.level[2]
+ i4 *priceb * capacity.level[3]
/
U(sq) = b_sq[0] ? ASC for SQ
+ b1 *comp_sq[0]
+ b2 *diff_priceb_sq[0]
+ b3 *priceb_sq[1]
+ b4 *timeb
+ b5 *season
+ b6 *capacity
+ i1 *priceb * diff_priceb
+ i2 *priceb * capacity.level[1]
+ i3 *priceb * capacity.level[2]
+ i4 *priceb * capacity.level[3]
$Note that you have a huge number of constraints in your design (reject constraints, require constraints, dominance constraints, repetition constraints, level frequency constraints), so it is quite a complex design.
Michiel