Hey,

in my model I have a few equations that are turned on or off by parameters like:

eTest$[pEnable]..

sum[a, vGeneration(a)]

=l=

sum[a, pDemand(a)]

;

So this equation only gets activated, when pEnable is set to 1 (or anything other than 0).

In the .lst file, some of the equations that are turned off do not appear in the SolEQU list, instead they just appear above the first equation listed as such:

LOWER LEVEL UPPER MARGINAL

---- EQU eTest (EMPTY)

Other euqations that are also turned off do appear in the SolEQU list, and when you click on them they are displayed as follows:

---- EQU eTest2 test equation 2

NONE

Why do some turned off equations still appear in the SolEQU list and some do not? What is the difference between them?

It would be much more clearer, if no turned off equation shows up in the SolEQU list.

Thanks for helping me understand this,

Robert

## SolEQU Empty vs. None

### Re: SolEQU Empty vs. None

The ones that do not show up in the Studio or IDE listing file summary and in the solution listing in the listing file as "(EMPTY)" are the scalar equations (no index). The ones that show up in the summary and are marked with "NONE" are squeezed out indexed equations. I guess in the solution listing the difference exists because indexed equations are handled different, the indexed ones get a header saying "LOWER, LEVEL, UPPER, MARGINAL" if there is data. That squeezed out scalar equations don't show up in the listing file summary, I would consider a bug.

GAMS shows the squeezed out equations because there are different reasons why an equation block is squeezed out, not only a switch to include them or not. If a real condition, e.g. e(i)$(sum(ij(j),1)>2), is never met and the block stays empty it sticks much more out that not listing the empty equation. But that's probably a matter of taste.

If you want to squeeze out equations for good you need to do that at compile time. So if your pEnable is available is available at compile time, than you can do the following.

If pEnable is determined at execution time (e.g. via an assignment) nothing you can do.

-Michael

GAMS shows the squeezed out equations because there are different reasons why an equation block is squeezed out, not only a switch to include them or not. If a real condition, e.g. e(i)$(sum(ij(j),1)>2), is never met and the block stays empty it sticks much more out that not listing the empty equation. But that's probably a matter of taste.

If you want to squeeze out equations for good you need to do that at compile time. So if your pEnable is available is available at compile time, than you can do the following.

Code: Select all

```
set i /i1/;
scalar pEnable /0/;
scalar qEnable /0/;
$inlineCom { }
variable obj;
equation e3, e4, e1(i), e2(i);
e1(i){$pEnable}.. obj =e= 0;
e2(i).. obj =e= 0;
e3{$qEnable}.. obj =e= 0;
e4.. obj =e= 0;
$set SQUEEZELIST ""
$ifE pEnable=0 $set SQUEEZELIST %SQUEEZELIST% - e1
$ifE qEnable=0 $set SQUEEZELIST %SQUEEZELIST% - e3
$log Building model with all %SQUEEZELIST%
model m / all %SQUEEZELIST% /;
solve m min obj us lp;
```

-Michael

### Re: SolEQU Empty vs. None

Thank you very much Michael.

This clearifies my question (and gives a good tip).

This clearifies my question (and gives a good tip).

### Re: SolEQU Empty vs. None

In very large models, does it make a performance difference if I squeeze out the equation at combile time
or do it that way?
Thanks,

Robert

Code: Select all

```
set i /i1/;
e1(i).. obj =e= 0;
e2(i).. obj =e= 0;
model m / all -e1 /;
solve m min obj using lp;
```

Code: Select all

```
set i /i1/;
scalar pEnable /0/;
e1(i)$pEnable.. obj =e= 0;
e2(i).. obj =e= 0;
model m / all /;
solve m min obj using lp;
```

Robert

### Re: SolEQU Empty vs. None

Compile time is faster but the GAMS execution system is smart. Even if your i is very large (1e8) is takes less than a second with the $pEnabled method.

-Michael

-Michael

### Re: SolEQU Empty vs. None

Thank you so much for your help. Now another question popped up.

I wanted to exclude the equations at compile time to check how much faster the compile time gets.

Problem is, I also have ex post calculations after the model is solved. This includes the dual value of equations like that:
This gives me an error

BUT, why is it needed in the first place, if pCalc is set to only be calculated, when pENable=1?

Is there a way to keep the ex post caculcation, but without giving me an error, when pEnable=0?

Thanks.

I wanted to exclude the equations at compile time to check how much faster the compile time gets.

Problem is, I also have ex post calculations after the model is solved. This includes the dual value of equations like that:

Code: Select all

```
set i /i1/;
scalar pEnable /0/;
parameter pCalc(i);
variable obj;
equation e1(i), e2(i);
$inlineCom { }
e1(i){$pEnable}.. obj =e= 0;
e2(i).. obj =e= 0;
$set SQUEEZELIST ""
$ifE pEnable=0 $set SQUEEZELIST %SQUEEZELIST% - e1
$log Building model with all %SQUEEZELIST%
model test / all %SQUEEZELIST% /;
solve test min obj using lp;
pCalc(i) $[pEnable] = e1.m(i)
```

Which does make sense, because the equation is not compiled and therefore it's marginal value is not set.Symbol declared but no values have been assigned. Check for missing data definition, assignment, data loading or implicit assignment via a solve statement.

A wild shot: You may have spurious commas in the explanatory text of a declaration. Check symbol reference list.

BUT, why is it needed in the first place, if pCalc is set to only be calculated, when pENable=1?

Is there a way to keep the ex post caculcation, but without giving me an error, when pEnable=0?

Thanks.

### Re: SolEQU Empty vs. None

The compiler does not know that pEnable will have value 0 at execution time. So it needs to make sure that all data is available for this potentially to be executed statement. You can go two ways. Exclude the calculations based on the dropped equation also at compile time (this might ripple in case you use pCalc in other calculations further down) or initialize the dual value of the equation to 0:

or

-Michael

Code: Select all

```
$ifE pEnable<>0 pCalc(i) $[pEnable] = e1.m(i)
```

Code: Select all

```
e1.m(i) = 0;
pCalc(i) $[pEnable] = e1.m(i)
```