This place looks nicer than old one ^^ I have been a big beneficiary of this forum.

I feel very lucky to learn CPO. I see huge publication opportunities as a researcher and huge real-world implementation opportunities as a practitioner. Currently, I am working with semiconductor & display industries to introduce CPO. It has been very difficult due to the bad experience with CPO about 20 years ago in that particular companies ^^. They don't know how much CPO has been improved. I think the door will be soon open because of CPO's own merits.

This is the continuation of https://www.ibm.com/developerworks/community/forums/html/forum?id=11111111-0000-0000-0000-000000002067&ps=25

I think we are getting close to the solution.
The revised code generates a following tour.
Depot=>S1=>65=>98=>S1=>20=>24=>57=>S15=>Depot (Where S refers the charging station).
The truck recharges (12 units) at S1 immediately after departing from the depot. The truck starts with a full battery level of 78 units. Since both the depot and S1 are located at the same cords. This recharging is not valid.
The code seems to using this invalid charging to give the truck enough energy until the next charging. Note the distance S1=>65=>98=>S1 is equal to 90 (12+78).
The code seems to allow the battery go beyond the maximum level of 78.

Thanks,
Andy

 dischargeValues[j][t] == - dNtoN[j.id][typeOfNext(seqTrk[t], itvJ2T[j][t], j.id, j.id)];​

Truck 1 events:   (Battery starts charged with level 78.)  Time 0 at S01 discharging -13  Time 4 at S01 charging +12  Time 67 at C65 discharging -36  Time 157 at C65 (no change)  Time 193 at C98 discharging -31  Time 283 at C98 (no change)  Time 314 at S01 discharging -10  Time 340 at S01 charging +78  Time 350 at C20 discharging -5  Time 440 at C20 (no change)  Time 445 at C24 discharging -38  Time 535 at C24 (no change)  Time 989 at C57 discharging -11  Time 1079 at C57 (no change)  Time 1090 at S151 (no change)  Time 1116 at S151 discharging -24  Time 1116 at S151 (no change)  Time 1116 at S151 charging +78  Time 1140 at DN (no change)  Time 1140 at DN (no change)

This place looks nicer than old one ^^ I have been a big beneficiary of this forum.

I feel very lucky to learn CPO. I see huge publication opportunities as a researcher and huge real-world implementation opportunities as a practitioner. Currently, I am working with semiconductor & display industries to introduce CPO. It has been very difficult due to the bad experience with CPO about 20 years ago in that particular companies ^^. They don't know how much CPO has been improved. I think the door will be soon open because of CPO's own merits.

This is the continuation of https://www.ibm.com/developerworks/community/forums/html/forum?id=11111111-0000-0000-0000-000000002067&ps=25

I think we are getting close to the solution.
The revised code generates a following tour.
Depot=>S1=>65=>98=>S1=>20=>24=>57=>S15=>Depot (Where S refers the charging station).
The truck recharges (12 units) at S1 immediately after departing from the depot. The truck starts with a full battery level of 78 units. Since both the depot and S1 are located at the same cords. This recharging is not valid.
The code seems to using this invalid charging to give the truck enough energy until the next charging. Note the distance S1=>65=>98=>S1 is equal to 90 (12+78).
The code seems to allow the battery go beyond the maximum level of 78.

Thanks,
Andy

After changing to typeOfPrev as you suggested, the work-around code seems working! Owing to the postscript, I was able to confirm the model. 

dischargeValues[j][t] == - dNtoN[j.id][typeOfPrev(seqTrk[t], itvJ2T[j][t], j.id, j.id)]; 

Only concern is the speed. This work-around could not find the optimal after 10 mins run-time, compared to immediate results from MIP. I guess I need to wait the next release of CPO that addresses the cumulative function issue.

Thanks for all your help.

Andy

 dischargeValues[j][t] == - dNtoN[j.id][typeOfNext(seqTrk[t], itvJ2T[j][t], j.id, j.id)];​

Truck 1 events:   (Battery starts charged with level 78.)  Time 0 at S01 discharging -13  Time 4 at S01 charging +12  Time 67 at C65 discharging -36  Time 157 at C65 (no change)  Time 193 at C98 discharging -31  Time 283 at C98 (no change)  Time 314 at S01 discharging -10  Time 340 at S01 charging +78  Time 350 at C20 discharging -5  Time 440 at C20 (no change)  Time 445 at C24 discharging -38  Time 535 at C24 (no change)  Time 989 at C57 discharging -11  Time 1079 at C57 (no change)  Time 1090 at S151 (no change)  Time 1116 at S151 discharging -24  Time 1116 at S151 (no change)  Time 1116 at S151 charging +78  Time 1140 at DN (no change)  Time 1140 at DN (no change)

This place looks nicer than old one ^^ I have been a big beneficiary of this forum.

I feel very lucky to learn CPO. I see huge publication opportunities as a researcher and huge real-world implementation opportunities as a practitioner. Currently, I am working with semiconductor & display industries to introduce CPO. It has been very difficult due to the bad experience with CPO about 20 years ago in that particular companies ^^. They don't know how much CPO has been improved. I think the door will be soon open because of CPO's own merits.

This is the continuation of https://www.ibm.com/developerworks/community/forums/html/forum?id=11111111-0000-0000-0000-000000002067&ps=25

I think we are getting close to the solution.
The revised code generates a following tour.
Depot=>S1=>65=>98=>S1=>20=>24=>57=>S15=>Depot (Where S refers the charging station).
The truck recharges (12 units) at S1 immediately after departing from the depot. The truck starts with a full battery level of 78 units. Since both the depot and S1 are located at the same cords. This recharging is not valid.
The code seems to using this invalid charging to give the truck enough energy until the next charging. Note the distance S1=>65=>98=>S1 is equal to 90 (12+78).
The code seems to allow the battery go beyond the maximum level of 78.

Thanks,
Andy

After changing to typeOfPrev as you suggested, the work-around code seems working! Owing to the postscript, I was able to confirm the model. 

dischargeValues[j][t] == - dNtoN[j.id][typeOfPrev(seqTrk[t], itvJ2T[j][t], j.id, j.id)]; 

Only concern is the speed. This work-around could not find the optimal after 10 mins run-time, compared to immediate results from MIP. I guess I need to wait the next release of CPO that addresses the cumulative function issue.

Thanks for all your help.

Andy

 dischargeValues[j][t] == - dNtoN[j.id][typeOfNext(seqTrk[t], itvJ2T[j][t], j.id, j.id)];​

Truck 1 events:   (Battery starts charged with level 78.)  Time 0 at S01 discharging -13  Time 4 at S01 charging +12  Time 67 at C65 discharging -36  Time 157 at C65 (no change)  Time 193 at C98 discharging -31  Time 283 at C98 (no change)  Time 314 at S01 discharging -10  Time 340 at S01 charging +78  Time 350 at C20 discharging -5  Time 440 at C20 (no change)  Time 445 at C24 discharging -38  Time 535 at C24 (no change)  Time 989 at C57 discharging -11  Time 1079 at C57 (no change)  Time 1090 at S151 (no change)  Time 1116 at S151 discharging -24  Time 1116 at S151 (no change)  Time 1116 at S151 charging +78  Time 1140 at DN (no change)  Time 1140 at DN (no change)

This place looks nicer than old one ^^ I have been a big beneficiary of this forum.

I feel very lucky to learn CPO. I see huge publication opportunities as a researcher and huge real-world implementation opportunities as a practitioner. Currently, I am working with semiconductor & display industries to introduce CPO. It has been very difficult due to the bad experience with CPO about 20 years ago in that particular companies ^^. They don't know how much CPO has been improved. I think the door will be soon open because of CPO's own merits.

This is the continuation of https://www.ibm.com/developerworks/community/forums/html/forum?id=11111111-0000-0000-0000-000000002067&ps=25

I think we are getting close to the solution.
The revised code generates a following tour.
Depot=>S1=>65=>98=>S1=>20=>24=>57=>S15=>Depot (Where S refers the charging station).
The truck recharges (12 units) at S1 immediately after departing from the depot. The truck starts with a full battery level of 78 units. Since both the depot and S1 are located at the same cords. This recharging is not valid.
The code seems to using this invalid charging to give the truck enough energy until the next charging. Note the distance S1=>65=>98=>S1 is equal to 90 (12+78).
The code seems to allow the battery go beyond the maximum level of 78.

Thanks,
Andy

Your model works great! Thanks! Although you mentioned that it is not a good problem for CPO, the code still beats MIP and combined model of MIP/CP  for VRP+ time-of-use pricing problem in most of benchmark instances.

This paper addresses an electrical vehicle routing problem with time window (E-VRPTW) under time-of-use (TOU) pricing aiming to minimize the electricity-cost as well as the number of used vehicles and total travel distance. In particular, the proposed solution cleverly shifts battery charging to off-peak periods and adjusts the charging duration to reduce the cost. First, the problem is carefully carved in a mixed integer linear programming model. Second, a constraint programming model is built. Third, a combined model is constructed to exploit the strengths of both models. The computational study demonstrates we can reduce the electricity-cost by ??% on average while not compromising other objectives.

I am sorry but I have one more favor. The benchmark instances have float values for battery capacity and refueling rate. When I solve the problems with simple ftoi conversion, it worked well. However, when I tried to consider the exact values with scaling factor, the battery restriction does not work any more, as you can see in below. There must be my errors, but I could not find them ^^

Truck 2 cumBattery levels:
From time 0 value 7775
From time 67 value 6475
From time 193 value 2875
From time 321 value -925
From time 416 value -1425
From time 989 value -5225
From time 1090 value -6325
From time 1114 value -8725

int Q=ftoi(ceil(QQ*scale)); //77.5; // Vehicle fuel tank capacity
int g=ftoi(ceil(gg*scale));//  3.47; //inverse refueling rate

 //Battery consumption 
dischargeValues[j][t] == - scale*dNtoN[j.id][predecessor[t][j]]; 
dischargeValues[j][t] ==  scale*dischargeExprs[j][t]; 

//Battery charging 
forall(j in aJobs,t in Trucks: j.t=="f")      chargeValues[j][t] == g*sizeOf(itvJ2T[j][t]);
forall(j in aJobs,t in Trucks)                   chargeValues[j][t] == scale*chargeExprs[j][t];

After changing to typeOfPrev as you suggested, the work-around code seems working! Owing to the postscript, I was able to confirm the model. 

dischargeValues[j][t] == - dNtoN[j.id][typeOfPrev(seqTrk[t], itvJ2T[j][t], j.id, j.id)]; 

Only concern is the speed. This work-around could not find the optimal after 10 mins run-time, compared to immediate results from MIP. I guess I need to wait the next release of CPO that addresses the cumulative function issue.

Thanks for all your help.

Andy

 dischargeValues[j][t] == - dNtoN[j.id][typeOfNext(seqTrk[t], itvJ2T[j][t], j.id, j.id)];​

Truck 1 events:   (Battery starts charged with level 78.)  Time 0 at S01 discharging -13  Time 4 at S01 charging +12  Time 67 at C65 discharging -36  Time 157 at C65 (no change)  Time 193 at C98 discharging -31  Time 283 at C98 (no change)  Time 314 at S01 discharging -10  Time 340 at S01 charging +78  Time 350 at C20 discharging -5  Time 440 at C20 (no change)  Time 445 at C24 discharging -38  Time 535 at C24 (no change)  Time 989 at C57 discharging -11  Time 1079 at C57 (no change)  Time 1090 at S151 (no change)  Time 1116 at S151 discharging -24  Time 1116 at S151 (no change)  Time 1116 at S151 charging +78  Time 1140 at DN (no change)  Time 1140 at DN (no change)

This place looks nicer than old one ^^ I have been a big beneficiary of this forum.

I feel very lucky to learn CPO. I see huge publication opportunities as a researcher and huge real-world implementation opportunities as a practitioner. Currently, I am working with semiconductor & display industries to introduce CPO. It has been very difficult due to the bad experience with CPO about 20 years ago in that particular companies ^^. They don't know how much CPO has been improved. I think the door will be soon open because of CPO's own merits.

This is the continuation of https://www.ibm.com/developerworks/community/forums/html/forum?id=11111111-0000-0000-0000-000000002067&ps=25

I think we are getting close to the solution.
The revised code generates a following tour.
Depot=>S1=>65=>98=>S1=>20=>24=>57=>S15=>Depot (Where S refers the charging station).
The truck recharges (12 units) at S1 immediately after departing from the depot. The truck starts with a full battery level of 78 units. Since both the depot and S1 are located at the same cords. This recharging is not valid.
The code seems to using this invalid charging to give the truck enough energy until the next charging. Note the distance S1=>65=>98=>S1 is equal to 90 (12+78).
The code seems to allow the battery go beyond the maximum level of 78.

Thanks,
Andy

Your model works great! Thanks! Although you mentioned that it is not a good problem for CPO, the code still beats MIP and combined model of MIP/CP  for VRP+ time-of-use pricing problem in most of benchmark instances.

This paper addresses an electrical vehicle routing problem with time window (E-VRPTW) under time-of-use (TOU) pricing aiming to minimize the electricity-cost as well as the number of used vehicles and total travel distance. In particular, the proposed solution cleverly shifts battery charging to off-peak periods and adjusts the charging duration to reduce the cost. First, the problem is carefully carved in a mixed integer linear programming model. Second, a constraint programming model is built. Third, a combined model is constructed to exploit the strengths of both models. The computational study demonstrates we can reduce the electricity-cost by ??% on average while not compromising other objectives.

I am sorry but I have one more favor. The benchmark instances have float values for battery capacity and refueling rate. When I solve the problems with simple ftoi conversion, it worked well. However, when I tried to consider the exact values with scaling factor, the battery restriction does not work any more, as you can see in below. There must be my errors, but I could not find them ^^

Truck 2 cumBattery levels:
From time 0 value 7775
From time 67 value 6475
From time 193 value 2875
From time 321 value -925
From time 416 value -1425
From time 989 value -5225
From time 1090 value -6325
From time 1114 value -8725

int Q=ftoi(ceil(QQ*scale)); //77.5; // Vehicle fuel tank capacity
int g=ftoi(ceil(gg*scale));//  3.47; //inverse refueling rate

 //Battery consumption 
dischargeValues[j][t] == - scale*dNtoN[j.id][predecessor[t][j]]; 
dischargeValues[j][t] ==  scale*dischargeExprs[j][t]; 

//Battery charging 
forall(j in aJobs,t in Trucks: j.t=="f")      chargeValues[j][t] == g*sizeOf(itvJ2T[j][t]);
forall(j in aJobs,t in Trucks)                   chargeValues[j][t] == scale*chargeExprs[j][t];

After changing to typeOfPrev as you suggested, the work-around code seems working! Owing to the postscript, I was able to confirm the model. 

dischargeValues[j][t] == - dNtoN[j.id][typeOfPrev(seqTrk[t], itvJ2T[j][t], j.id, j.id)]; 

Only concern is the speed. This work-around could not find the optimal after 10 mins run-time, compared to immediate results from MIP. I guess I need to wait the next release of CPO that addresses the cumulative function issue.

Thanks for all your help.

Andy

 dischargeValues[j][t] == - dNtoN[j.id][typeOfNext(seqTrk[t], itvJ2T[j][t], j.id, j.id)];​

Truck 1 events:   (Battery starts charged with level 78.)  Time 0 at S01 discharging -13  Time 4 at S01 charging +12  Time 67 at C65 discharging -36  Time 157 at C65 (no change)  Time 193 at C98 discharging -31  Time 283 at C98 (no change)  Time 314 at S01 discharging -10  Time 340 at S01 charging +78  Time 350 at C20 discharging -5  Time 440 at C20 (no change)  Time 445 at C24 discharging -38  Time 535 at C24 (no change)  Time 989 at C57 discharging -11  Time 1079 at C57 (no change)  Time 1090 at S151 (no change)  Time 1116 at S151 discharging -24  Time 1116 at S151 (no change)  Time 1116 at S151 charging +78  Time 1140 at DN (no change)  Time 1140 at DN (no change)

This place looks nicer than old one ^^ I have been a big beneficiary of this forum.

I feel very lucky to learn CPO. I see huge publication opportunities as a researcher and huge real-world implementation opportunities as a practitioner. Currently, I am working with semiconductor & display industries to introduce CPO. It has been very difficult due to the bad experience with CPO about 20 years ago in that particular companies ^^. They don't know how much CPO has been improved. I think the door will be soon open because of CPO's own merits.

This is the continuation of https://www.ibm.com/developerworks/community/forums/html/forum?id=11111111-0000-0000-0000-000000002067&ps=25

I think we are getting close to the solution.
The revised code generates a following tour.
Depot=>S1=>65=>98=>S1=>20=>24=>57=>S15=>Depot (Where S refers the charging station).
The truck recharges (12 units) at S1 immediately after departing from the depot. The truck starts with a full battery level of 78 units. Since both the depot and S1 are located at the same cords. This recharging is not valid.
The code seems to using this invalid charging to give the truck enough energy until the next charging. Note the distance S1=>65=>98=>S1 is equal to 90 (12+78).
The code seems to allow the battery go beyond the maximum level of 78.

Thanks,
Andy