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.

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.

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;

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

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.

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:

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)

This gives me an error

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.

Which does make sense, because the equation is not compiled and therefore it’s marginal value is not set.

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?

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: