Fresnel linear focusing systems relationship between "General optical derate" and "Receiver optical derate"

Dear Paul,

my doubt refers to the way SAM processes the two input parameters:

"General optical derate" at the upper right area of the sheet "Collector and Receiver"

and the

"Receiver optical derate" at the buttom of the same sheet.

The "Receiver optical derate" according to my trials is influenced only in case the "Evacuated Tube Model" is selected to determine the "Receiver Geometry and Heat Loss".

In my understanding however, the Optical efficiency to determine how much irradiation is absorbed by the solar field, is determined by multiplying:

1. Tracking error derate
2. Geometry effects derate
3. Solar-weighted mirror reflectivity
4. Dirt on mirror derate
5. General optical derate
AND THE RECEIVER SPECIFIC OPTICAL PROPERTY, i.e.
6. Receiver optical derate

Nevertheless, in case I choose the "Polynomial heat loss model" to account for the "Receiver Geometry and Heat Loss"
the Receiver optical derate is always equal 1 (not impacted as in case I choose the "Evacuated tube model").

Looking in the USERGUIDE, the optical efficiency is defined as being:

Optical Efficiency ="Total Thermal Energy Absorbed by Receiver ÷ ( Direct Normal Irradiance × Actual Aperture Area )"

I.e., this includes the absorptivity of the receiver. In fact, depending on which model I select, the output difference is considerable (more than 4% net output less for the "Evacuated Tube Model" choice).

On the other hand, in case I set all collector derate parameters to 1, and insert the "General optical derate" to the maximum optical efficiency of the collector (in case of normal solar incidence), this is the maximum value that can be found in the output hourly results, no matter which model is selected for the Receiver.

How can this be explained and is it possible that in case of choosing the "Evacuated Tube Model", the absorptivity of the Receiver is considered twice, shrinking the net output of the overall system in comparison to the "Polynomial heat loss model"?

The analyses is even worse when considering that, in case I insert the overall optical efficiency in the field "General optical derate", and set the parameters in "Evacuated Tube Model" such as to achieve the value "1" in the field "Receiver optical derate", even though I get a much lower performance compared to in case "Polynomial heat loss model" is selected.

Thank you very much for any help on this issue.

Kind regards

Dietmar

Dear Dietmar,

The optical efficiency at design is:

Optical Efficiency at Design = Tracking Error Derate x Geometry Effects Derate x Solar-weighted Mirror Reflectivity x Dirt on Mirror Derate x General Optical Derate

or, using SAM variable names from the code:

eta_opt_fixed = TrackingError * GeomEffects * reflectivity * Dirt_mirror * Error

where this value leads to the following values:

eta_opt_fixed -> opteff_des -> m_dot_design

Note that the receiver optical derate is not used in this optical efficiency calculation. The receiver optical derate (opt_derate) is either 1 when the polynomial model is selected or, when the evacuated tube model is selected, the sum of the following for each of the four HCE variants:

Variant Weighting Fraction x Receiver Bellows Shadowing Loss x Dirt on the Receiver Envelope Loss

or, in the code:

opt_derate = sum(HCE_FieldFrac * Shadowing * dirt_env)

This value is calculated only for display in the UI, with the independent values being part of a larger calculation for the equivalent optical efficiency (EqOptEff). This values leads to the following values:

opt_derate -> EqOptEff -> q_dumped (dumped heat)

opt_derate -> colopteff_tot -> q_3SolAbs -> q_12conv -> q_in_W (absorbed heat)

If you want to see the actual calculations, please refer to the file sam_mw_lf_type262_salt.cpp in the open source repository here:

github.com/NREL/ssc/blob/develop/tcs/sam_mw_lf_type262_salt.cpp

Those calculations start with lines 1065-1087, 1136, 1623, and 2458-2468. The last set of line references shows the absorbed irradiance calculation, and following this through does not appear to show it being double counted.

If you believe this to still potentially be a bug, though, please do follow up with us.

Best regards,
Paul.