WinDelsol 1-0 UG English

WinDelsol 1.
0
Users Guide
WinDelsol 1.0 Users Guide
1. General Considerations on Delsol3 and WinDelsol 1.0 working__________________________ 3

1.1.
General Considerations on Delsol3 working ________________________________________ 3
1.2.
General Considerations on WinDelsol working ______________________________________ 3
2. Using WinDelsol 1.0_____________________________________________________________ 7

2.1.
Starting WinDelsol, the DOC Problem ____________________________________________ 7
2.2.
DOC Normalised Input ________________________________________________________ 8
2.3.
Explanation for Magenta Fixed Values in a DOC Normalised Input _____________________ 10
2.4.
Using Input Editor Tool_______________________________________________________ 13
2.5.
WinDelsol DOC Stage ________________________________________________________ 25
2.5.1.
2.5.2.
2.5.3.
2.5.4.
2.5.5.
2.5.6.
Delsol3 plays its Role ________________________________________________________________

WinDelsol plays its Role ______________________________________________________________
Basic Parameters Analysis ____________________________________________________________
Energetic Analysis __________________________________________________________________
Receiver Analysis ___________________________________________________________________
Heliostat Field Analysis ______________________________________________________________
25
27
29
29
30
41
2.6.
WinDelsol HFA Stage ________________________________________________________ 42
2.7.
WinDelsol PFC Stage ________________________________________________________ 49
3. Installation Procedure __________________________________________________________ 57
1. General Considerations on Delsol3 and WinDelsol 1.0 working

1.1. General Considerations on Delsol3 working
There are two types of problems that are run on Delsol3, Design Optimisation Calculations, DOCs, and
Performance of Field Calculations, PFCs.
In a Design Optimisation Calculation, user specifies the heliostat geometry, basic receiver description,
geographical location, and, of course, the range for all the variables to be optimised, and Delsol3
searches for the set of optimised variables that minimises the energy cost. The results of a Design
Optimisation Calculation, -DOC process-, are generated in the from now on called Optimisation Area, OP.
These results will be tested in the same Design Optimisation Calculation DOC process under the execution
of the so called, Performance Rerun Area, PR, just to verify that requested problem resolution, and
calculated optimum solution fit. Notice that working at this DOC stage, even at PR section, Delsol3 will
never use defined by coordinates heliostat field layout, but only average values for heliostats densities on
field.
In a Performance of Field Calculation, PFC, the user defines a single system, -included definite by
coordinates positions of every reflective unit, that is, the heliostat field layout-. Delsol3 calculates the
optical/energetic performance for that system, well in a single time, or in an annual basis. This annual
performance is presented by means of the called Annual Performance Matrix. Delsol3 doesnt calculate
the definite by coordinates heliostat field layout.
More information on the Delsol3 code working way can be found in the Delsol3 Users Guide, Sandia
Nat. Labs .
1.2. General Considerations on WinDelsol working

WinDelsol code keeps the same strategy of working as Delsol3, with a DOC stage including OP and PR
areas, and a PFC stage based on definite by coordinates heliostat field layout.
Additional features of WinDelsol code over Delsol3 are:
a)
Use of Windows user-friendly interrelation between human and computer.
b)
Inclusion of an Input Editor tool that takes into account all Delsol3 constrains among the about two
hundred variables, that make quite difficult the generation of a free of contradictions Input.txt file
by hand.
c)
d)
e)
f)
Self-Extraction of results from the over more than 50 pages Delsol3 Output.txt file, and
presentation on screen of a selection of the more important ones. The less relevant data can be also
studied into the frame of WinDelsol by the integrated option of accessing to the edition of
Output.txt .
Graphical interpretation of results, especially those that are hard to analyse quickly in Delsol3
Output.txt file, as receiver geometry and flux maps. But WinDelsol allows also to make the quick
interpretation through graphics, of the results related to the heliostat field configuration, mean
annual cosine factor distribution on field, shadows and blocks, spillage, air transmittance, etc
Calculation of the definite by coordinates heliostat field layout.
Automatic generation of the Input.txt file to test the performance of the calculated field, including
the clustering by rows, of the definite by coordinates heliostat field layout. This Input.txt file can be
generated both for PFC in a single time, -Design Point-, or in an annual basis by means of the
-Annual Performance Matrix-. Although it is possible in Delsol3 to do the PFC of a defined single
system in a different single time of the design point, this option has not been considered at
WinDelsol, because of the following two reasons:
This calculus is included in the Annual Performance Matrix and can be deduced from it.
WinDelsol is not considered as an accurate energetic performance tool by the authors of this
work. The main task of WinDelsol code is to generate an optimised heliostats field layout, tower
height calculation and receiver geometry proposal. PFC, Performance of Field Calculation of an
optimised system including the heliostats field coordinates description at design point, can be
only considered as a verification for the correct solution proposed by WinDelsol to the analysed
problem. In some way, this Performance of Field Calculation at design point can be compared to
the Performance Rerun that the code makes at Design Optimisation task, including at this time, a
defined by coordinates heliostat field layout.
Working procedure for WinDelsol is as follows:

a)
DOC Stage, Design Optimisation Calculation
From an Input.txt file Delsol3 is executed. This Input.txt file must be written, of course in a compatible
way with Delsol3 attending to the many constrains, but written too in a compatible way with
WinDelsol. As WinDelsol needs to pick data from the text file Output.txt coming from Delsol3
execution, the pattern for the Input.txt text file must be kept in a fixed way in order that the Output.txt
text file results, are analysable.
INPUT OPTIMIZATION
WinDelsol
Results Analisis
Delsol3
DOC (includes OP & PR)
OUTPUT OPTIMIZATION
This stage works on the first two options of WinDelsol main menu screen:
First 2 options of
Main Menu screen
b)
HFA Stage, Heliostat Field Arrangement
This part is exclusive of WinDelsol. Delsol3 Execution is not necessary at this stage.
WinDelsol, that knows where the information coming from previous DOC stage is located, -Output.txt
file-, will use it to represent the annual energetic efficiency distribution map of the land in front of the
tower, will generate a pattern for heliostats allocation that fits with Delsol3 information, and will select as
many heliostats as necessary in the best positions, to make the plant produce the requested annual
energy.
Possible Heliostats Positions Determination
OUTPUT OPTIMIZATION
WinDelsol
Input of Annual Energy Production
Results Analisis
Heliostats Positions Determination
WinDelsol will represent an annual

energetic efficiency map on the land
where the heliostat field is going to be
allocated. A later annual Energy
Production input will determine the
number of heliostats and their positions
The realisation of this stage fits with the third option in WinDelsol main menu screen:
Option 3 of
Main Menu screen
c)
PFC Stage, Performance of Field Calculation
As it is shown in the next picture, information included in original Input.txt file, is mixed with the
calculated heliostat field to generate PFC new Input.txt files. Two different kinds of PFC Input.txt files
can be generated, attending to the interest in obtaining information on the performance of the proposed
heliostat field defined by coordinates at single time Design Point, or in Annual Basis through the
calculation of a matrix of efficiencies. Once any of these Input.txt files has been generated, Delsol3 is
executed again.
INPUT OPTIMIZATION
INPUT SIMULATION
OUTPUT
SIMULATION
Design Point
Delsol3
Design Point
Simulation
WDelsol
Results Analisis
WinDelsol
Energetical Analisis
Generates
Simulation
Inputs
INPUT SIMULATION
OUTPUT
SIMULATION
Annual Performance
Delsol3
Annual Performance
WDelsol
Simulation
Results Analisis
Annual Performance SOLERGY Matrix
The recent executions of Delsol3 for PFC Design Point or Annual Basis will provide new information in
Output.txt pattern, that will be analysed by WinDelsol through the commands marked in the following
picture:
Options 4 & 5 of
Main Menu screen
This stage works on the options 4 and 5 of WinDelsol main menu screen.
2. Using WinDelsol 1.0

2.1. Starting WinDelsol, the DOC Problem
WinDelsol.exe will start the running of WinDelsol1.0.
A click in the Next button of the presentation screen will lead to the code main menu screen.
At this start point of the program execution, the only possibility that is enabled apart from quitting, is to
begin a DOC problem by pressing Optimisation button. This will lead to the screen in the picture.
Two possibilities are shown, the use of the Input Editor tool, and the direct use of a DOC Input.txt file
prepared with any text editor tool, this last option only recomendable if user is sure that it is a normalised
DOC Input.txt file.
A normalised DOC Input.txt file is that one that has gone through the WinDelsol tool called Input
Editor. Only the use of a normalised Input.txt file can ensure the correct working of WinDelsol, not only
in the accuracy of results, but avoiding halts.
The use of Input Editor allows the loading of a previous Input.txt file. Input Editor will detect
inconsistencies between variables from the point of view of Delsol3 computer code in the loaded
Input.txt file, ensuring then correct results. Input Editor will also give a fixed common pattern to every
Input.txt file that is going to be processed, so that WinDelsol can find the necessary information in the
correct way and place of Output.txt file coming out from the Delsol3 execution.
DOC Input
Success
Bad Results
Delsol3
if unconsistencies
Windelsol
Hanging
Direct Load
if different pattern
WinDelsol
Input Editor
DOC Normalised Input
WinDelsol
Delsol3
DOC Output
Direct Load
WinDelsol
Proccess
As it can be noticed in the picture, only blue path will lead to success.
2.2. DOC Normalised Input

A DOC Normalised Input.txt is composed by two main parts, the properly Optimisation Area (OP) and the
Performance Rerun Area, (PR). (pg 172 Delsol3 UG).
There are 9 different Namelists, small structures that keep the information on every subsystem of the
plant. These Namelists are BASIC, FIELD, HSTAT, REC, NLFLUX, NLEFF, OPT, NLCOST, NLECON. All of them
will be included in OP area, but only six of them will be included in the PR area. Nevertheless, there are
some Namelists that must be included up to 2 times both in OP area and in PR area, as:
OP Area, Namelists that are included twice: REC, NLFLUX, NLEFF
PR Area, Namelists that are included twice: REC
As it can be noticed, Namelist REC is included up to 4 times in a DOC Normalised Input.txt.
Obviously, information included in each of the repeated Namelists should not vary from one to another. If
a Cavity receiver is proposed in the first of the opportunities where we can define REC Namelist, it will not
lead to good results to propose a flat receiver in the second occasion that REC appears, and trying to ask
for the performance of a cylindrical receiver in the first REC Namelist of PR.
Because of this, information included at each of the repeated Namelists will be the same, for the correct
working of Delsol3 and WinDelsol. But it is not necessary to fill all the repeated Namelists with repeated
information. It is possible to leave some of them free or empty, when information has been included in a
previous Namelist. In some other occasions, it is not possible to leave empty the repeated Namelist
because in that case, information used would not be the previously included one, but the Delsol3 default
information.
A DOC Normalised Input.txt will at last appear as follows:
TITULO DEL PROBLEMA
&BASIC
(1 Op)
Iprob=4
Itape=1
Iprint=9*0
Data
/
&FIELD
(1 OP)
Nazm=12
Nrad=12
Iuserf=0
Data
/
&HSTAT
(1 OP)
Indc=0
Data
/
&REC
(1 OP)
Irec=0,2,4
Numcav=1
Data
/
&NLFLUX
(1 OP)
Iflx=1
Nxflx=13
Nyflx=13
Icavf=1
Data
/
&NLEFF
(1 OP)
Iradfl=0
Data
/
&REC
(2 OP)
/
&OPT
(1 OP)
Ihopt=0
Numopt=1
Iotape=1
Irerun=1
Iplfl=1
Ipropt=-1
Ihoptp=0
Data
/
&NLFLUX
(2 OP)
Iflx=1
Nxflx=13
Nyflx=13
Icavf=1
Data
/
&NLEFF
(2 OP)
Iradfl=0
Data
/
&NLCOST
(1 OP)
Data
/
&NLECON
(1 OP)
Data
/
PERFORMANCE RERUN
/
&BASIC
(1 PR)
Iprob=0
Itape=3
Tdesp
/
&FIELD
(1 PR)
/
&HSTAT
(1 PR)
/
&REC
(1 PR)
/
&NLFLUX
(1 PR)
Iflx=1
Ifxout(i,j)=1
Nxflx=13
Nyflx=13
Icavf=1
Data
/
&NLEFF
(1 PR)
/
&REC
(2 PR)
W=-100.
/
The Namelist name is presented in (Blue). Information is presented in (Black). There are some parameters
that are necessary to include in every DOC Normalised Input.txt for WinDelsol, in (Magenta). Other
necessary fixed parameters, those that no need to be written because their values are Defaults, are
presented in (Dark Magenta).
A signal referred to the Namelist location is presented in (Green). The text (OP/PR) and number of
repetitions that in the own area this Namelist appears, identify the location.
A DOC Normalised Input.txt including the only information just presented in magenta will be perfectly
treated by WinDelsol, assuming all the rest of the information not included with Delsol3 default values.
2.3. Explanation for Magenta Fixed Values in a DOC Normalised Input

&BASIC
(1 OP)
Iprob=4 Control parameter specifying Delsol3 working mode as an OP Optimisation at this occasion.
This parameter is fixed because of the general concept of WinDelsol, that works on a DOC initial stage
including both OP and PR steps.
Itape=1 Control parameter that fits perfectly with Iprob=4 at DOC working. (Pg 65 Delsol3 UG).
Iprint=9*0 Control parameter to indicate the printing of a detailed day by day (from 1 to NYEAR), or
time step by time step in the days (from 1 to NYEAR), performance of the zone by zone field. WinDelsol
works on the information of the annual zone by zone performance, and this is always written when
Iprint=0. As a matter of fact, it would be more exquisite to include at DOC Input.txt file the expression
Iprint=NYEAR*0, depending on NYEAR value, but as NYEAR ranges from 1 to 9, and Delsol3 will use
always a 9 positions matrix to look for Iprint values, we can fix all positions there equal to 0, the work will
be perfect. Not necessary to be included because Default.
Data
/
&FIELD
(1 OP)
Nazm=12 Number of zone divisions azimuthally around the tower. Maximum value is 12. Computers are
quick enough at present moment to manage with the biggest sizes of matrixes that Delsol3 can handle
without delaying time execution appreciably. For that reason, all variable size matrixes for Delsol3 have
been fixed at their highest values to allow the more accurate information disposal to WinDelsol. Not
necessary to be included because Default.
Nrad=12 Number of zone divisions in the radial direction from the tower. Maximum value is 13. Delsol3
Default value is 12. For that reason, WinDelsol will use this Default value and so, it will never more be
necessary to include Nazm nor Nrad in an input file.
Iuserf=0 Parameter specifying field option. It must be Iuserf=0 for a DOC working mode. Not necessary
to be included because Default.
Data
/
&HSTAT
(1 OP)
Indc=0 Control parameter for more accurate heliostat images calculation in PFC working mode. It must
be Indc=0 for a DOC working mode. Not necessary to be included because Default.
Data
/
&REC
(1 OP)
Irec=0,2,4 Parameter specifying type of receiver. Cavity with elliptical aperture (IREC=1) nor elliptical
shape flat plate (Irec=3) are not considered in WinDelsol.
Numcav=1 Lets work receiver by receiver better. Not necessary to be included because Default.
Data
/
&NLFLUX
(1 OP)
Iflx=1 Parameter specifying flux calculation. For OP stage, flux calculations are made at the design point
just to verify the values of flux at receiver in order to dimensionate it not overpassing stablished limits.
Nxflx=13 Number of divisions of a grid in the horizontal length of the receiver in order to calculate flux.
Maximum value is 13. Computers are quick enough at present moment to manage with the biggest sizes
of matrixes that Delsol3 can handle without delaying time execution appreciably. For that reason, all
variable size matrixes for Delsol3 have been fixed at their highest values to allow the more accurate
information disposal to WinDelsol.
Nyflx=13 Number of divisions of a grid in the vertical length of the receiver in order to calculate flux.
Icavf=1 Parameter specifying aperture(s) through which incident light can reach the flux surface under
consideration, =0, no light reaches flux surface from aperture i, <>0 light reaches flux surface from
aperture i.
WinDelsol considers only one aperture or receiver for a plant. So, for WinDelsol the only possibility is
Icavf=1.
Data
/
10
&NLEFF
(1 OP)
Iradfl=0 Flag to indicate which radiation/convection loss algorithm to use. It is considered that losses
calculated on a basis of experimental analysis is the best option (mainly because other options didnt work
in some tests). Not necessary to be included because Default.
Data
/
&REC
(2 OP)
/
&OPT
(1 OP)
Ihopt=0 Control parameter for optimising the heliostats densities. Tower height can not be varied when
Ihopt=1, and this is not in the spirit of a DOC working mode. Not necessary to be included because
Default.
Numopt=1 Number of equally spaced net electrical design power levels from Poptmn to Poptmx (in
Watts) considered for optimal design. When developed WinDelsol, it was considered that the wide range
of possibilities to design a plant in Delsol3 should be reduced to make easier the analysis of the goodness
of results. Moreover it was found that capabilities of Delso3 code are more accurate and profitable when
concentrating in a smaller number of parameters to optimise. The parameter that could be thought more
defined when designing a plant is the electrical power, (or thermal power onto receiver). Its true that in
some occasions this could be the first parameter to optimise to make more profitable the investment. In
that occasion the procedure for acting would be to optimise independently in different WinDelsol
problems, plants from P1 to Pn powers. The final selection would be made on these results.
Iotape=1 Parameter specifying if user desires to write the results of an optimisation run on Unit30. This
option is necessary when working in a DOC strategy that includes both OP and PR areas. Default is 0, so
it is necessary to be included.
Iplfl=1 Parameter identifying the subsets of the Numopt power levels at which field layouts are printed,
and descriptions of optimised systems written on Unit30. As Numopt=1, it is not necessary to define a
matrix of Iplfls. Output will be generated for the 1 considered power level, Poptmn=Poptmx=Tdesp.
Irerun=1 Parameter for automatically rerunning a detailed performance calculation of an optimised
system. That means the execution of the PR area of the DOC problem. As Default is 0, this value is
necessary.
Ipropt=-1 Parameter for detailed output of zone by zone build up. Ipropt=-1 is highly recommended by
Delsol3 as the output offers then a breakdown of these calculations. Thats all the information requested
by WinDelsol, so this parameter can be fixed.
Ihoptp=0 Parameter for detailed print out of heliostat density optimisation. No additional information is
required by WinDelsol, so this parameter can be fixed.
Data
/
&NLFLUX
(2 OP)
Iflx=1 Parameter specifying flux calculation. For OP stage, flux calculations are made at the design point
just to verify flux limits at receiver in order to dimensionate it.
Nxflx=13 Number of divisions in the horizontal length of the receiver for a grid in order to calculate flux.
Nyflx=13 Number of divisions in the vertical length of the receiver for a grid in order to calculate flux.
aperture i.
Icavf=1.
Data
/
11
&NLEFF
(2 OP)
Iradfl=0 Flag to indicate which radiation/convection loss algorithm to use. It is considered that losses
calculated on a basis of experimental analysis is the best option (mainly because other options didnt work
in some tests), and this fits with the value Iradfl=0. Not necessary to be included because Default.
Data
/
&NLCOST
(1 OP)
Data
/
&NLECON
(1 OP)
Data
/
PERFORMANCE RERUN
/
&BASIC
(1 PR)
Iprob=0 Control parameter specifying Delsol3 working mode. A PR Performance Rerun at this occasion.
This parameter is fixed because of the general concept of WinDelsol, that works on a DOC initial stage
including both OP and PR steps.
Itape=3 Control parameter that fits perfectly with Iprob=0 at DOC working. (Pg 65 Delsol3 UG)
Tdesp Power level in MWe, for optimised system stored on Unit30 in a PR execution into a DOC
problem. This parameter has to be included when Itape=3. Tdesp value is automatically fixed by Input
Editor based on Poptmn and Poptmx values from &OPT (1OP).
/
&FIELD
(1 PR)
/
&HSTAT
(1 PR)
/
&REC
(1 PR)
/
&NLFLUX
(1 PR)
Iflx=1 Parameter specifying flux calculation. For PR stage, flux calculations are made at the one time of
the year specified by Ifxout.
Ifxout(i,j)=1 Parameter allowing the selection for the one time of the year. This parameter must be
included for WinDelsol, as Fluxmaps are elaborated and presented by this code. The absence of flux
calculations would take off, some interesting features of WinDelsol.
Nxflx=13 Number of divisions in the horizontal length of the receiver for a grid in order to calculate flux.
Nyflx=13 Number of divisions in the vertical length of the receiver for a grid in order to calculate flux.
aperture i.
Icavf=1.
Data
/
&NLEFF
(1 PR)
/
&REC
(2 PR)
W=-100. End of DOC Input.txt file flag.
/
12
2.4. Using Input Editor Tool

In order to help in the preparation of a DOC Normalised Input.txt file, WinDelsol offer their users a very
interesting tool called Input Editor. Using this tool user will take profit on the following advantages:
a) User will only fill once the values for any of the Namelist that should appear repeated in a DOC
Normalised Input.txt file, avoiding so, mistakes debt to the introduction of different values for
the same variables.
b) User will not be allowed to introduce values for variables that are in conflict with values of any
other variables keeping the rules of Delsol3 code.
c) Variables that are necessary for the proper working of WinDelsol are self-included.
d) When importing an Input.txt file previously generated without Input Editor, automatic
detection of mistakes or incompatibilities will be performed, in order to keep the rules a), b)
and c). These suggestions for modifications will be presented in red colour, in order that user
can review the cause of the mistake, and introduce his own and personal resolution.
e) Input Editor will leave free those Namelist that doesnt need to be filled.
f) Delsol3 aid for input variables is presented automatically on screen, helping in this way the
quick realisation of an Input.txt file finding in an efficient way the causes why a variable is
allowed or not allowed depending on constraints, the causes of errors, and the proposition of
solutions.
The selection of Input Editor option in the WinDelsol screen will activate this tool:
File Edition Menu
Errors Detected LOG

Problem Title
OP Stage
PR Stage
Namelist Search
Namelist Edition
Input Presentation
7 are the main parts of this Input Editor:

a)
b)
c)
d)
e)
f)
g)
File Edition Menu

Problem Title
OP / PR Stages
LOG of Errors Detected
Variables Search Help
Namelist edition
Input.txt Presentation
13
a)
File Edition Menu
When selected, the following options will come to us:
New will clear the value of any stored variable allowing the creation of an entirely new Input.txt file.
Open will allow the aperture of any previously existing Input.txt file. This command will work as an
import order.
Save and Save as will allow to storage actual information.
Exit will allow coming back to WinDelsol process.
b)
Problem Title
First line of a DOC Input.txt file is the problem identification, or title that is presented in this screen. Any
title including all kind of characters is allowed.
c)
OP / PR Stages
A selection between the two different stages of a DOC process, OP or PR, must be done on to this
combo menu:
14
When selected OP option, all Namelists that are included in this stage are enabled.
When selected PR option, only NLFLUX among all the Namelists that are included in this stage is enabled.
This way to proceed is debt to the fact that all information that is needed by PR stage comes from OP
stage through a stored file called Unit30. This means that no additional information has to be included in
BASIC, FIELD, HSTAT, REC, nor NLEFF Namelists. This information should not be included again in these
Namelists because this could be only a source for problems from the point of view of inconsistencies. As
an example, user can define a 90m2 heliostat in OP stage of DOC Input.txt , and redefine a 30m2 unit at
PR stage without being aware. To avoid this possibility, Input Editor will not fill the referred Namelists.
A different analysis can be made with NLFLUX Namelist. Some NLFLUX parameters values can be different
from OP stage to PR stage. So, while in OP stage NLFLUX parameters must be referred to the whole, and
only the whole surface of the receiver, just to impose flux limit restrictions on it, in PR stage NLFLUX can
be referred just to the area of absorber surface in which user wants to take a picture of the flux
distribution. This area can be larger or can be smaller than receiver, and usually will be used to examine
spillage if bigger than receiver limits, or to study in detail a flux maxim.
15
d)
LOG Report on Errors
When loading an input file that includes errors on the general structure, for example, mistakes on
variables allocation, an Errors LOG file will be generated, and Error button will be activated. By pressing it
user will access to the edition of the LOG file that will offer information about the problem in the
importation of parameters values.
e)
Variables Search Help
Sometimes it results as a help when trying to locate a variable, the disposal of an alphabetically ordered
list including a reference to the Namelist where it belongs. This list is presented in Input Editor tool into a
combo box as presented in the next picture.
16
f)
Namelist Edition
The Namelist Edition pages compose the core of the Input Editor Tool.
Default not applicable to this
problem: DESPISE
Obligatory: Write
Delsol3 Online Help
Different to Default
but not applicable to
this problem:
DESPISE
Default applicable to this
problem: NOT WRITE
Enabled and Different

to Default: WRITE
Conflict: CHANGE
Colors Code
Magenta Name: Obligatory Value
Black Font: Default Value
Blue Font: Read from imported INPUT FILE and Different to Default Value
Red Font: Read from imported INPUT FILE in conflict with another variable: Delsol3 Constrain Detection
White Background
Enabled Value for considered Problem. If Blue will be written in output INPUT FILE.
Grey Background
Not Enabled Value for considered Problem. Will not be written in output INPUT FILE.
Some information about the working of these pages can be extracted from previous picture. There are
two different kind of cells to include information in these pages, free cells where user will write a number,
and prefixed cells in which user will only select a number from several possibilities that are presented.
These last ones are marked with an arrow, and reflect the only possibilities that Delsol3 admits for that
entry. For those cells in which user has a freedom for writing, a online correction is done, not allowing so
to make an entry for a floating number if this must be an entire one.
When beginning an Input.txt file directly from Input Editor user will get a screen similar to the one
presented on next picture any time that selects a Namelist.
17
It can be appreciated that all variables for the Namelist include values. These are the Default values that
Delsol3 proposes for variables when no other value has been already assigned. As it can also be noticed,
there are some variables that include white background, are enabled, and many others that include grey
background, are not enabled. This fact is because the values of some other variables, that make an effect
on the whole number of Input Editor pages, dont consider them. Lets see some examples.
Nazm and Nrad variables are not enabled because they are not allowed to be changed. The reason for this
is referred in point 2.3 Explanation for Magenta Fixed Values in a DOC Normalised Input of this
manual. WinDelsol will work with the Delsol3 Default values, 12 for both variables.
The next parameter that is not allowed is Ilay. If we point the cursor over this parameter we will get online
Delsol3 help on screen. And we will read as follows:
No comments.
Another parameter, as an example that is not allowed is Amaxn. Lets go through Delsol3 online help:
18
We can understand that this value will be enabled when its constrainer parameter Inorth will be changed
to 1. So we proceed:
Its perfect, we have made an entry for Inorth as 1 and Amaxn cell has resulted activated. Something else
has happened too. A message appears informing about the incompatibility of Inorth=1, North Field, and
the actually considered receiver Irec=0, Cylindrical type. Inconsistencies between variables are not
automatically corrected, but informed, so user can adopt the more convenient solution.
But, another thing, quite interesting too, has also happened. Inorth font colour that was previously black
has changed into blue. There is a reason for this. Previously, Inorth value was the Delsol3 Default one,
and at present moment, Inorth value is just different from Default. This is the reason why the original
screen when user opened the Namelist FIELD was so black coloured. All values considered for parameters
were the default ones.
19
We can notice something strange. Nradmn(12)=12*1, Nradmx(12)=12*1, Is this ok? When a parameter
includes in its name a value into brackets it means that it is an arrow with a number of positions
depending of another parameter. Does this value between brackets change when dominant parameter
changes? Yes, of course. In the example for Nradmn(12) and Nradmx(12) we are not going to be able to
see this change, as dominant parameter, Nazm, as we have seen before, was fixed because WinDelsol
operation strategy.
But it can be seen that in brackets numbers are actualised depending on their dominant parameter
value in the next example. Lets consider Alp(0) depending from Nland=0. We can find that in Delsol3,
Default value for Nland is 0. Nland can take values from 0 to 5. The way to solve the filling of the values
for the Alp string in Delsol3 Default strategy, an arrow that may have 0 positions, 1 position, 2 positions,
5 positions, is to fill all the 5 possible positions with a 0.0 value. Not a very exquisite method from
computing point of view, but effective. It would probably have taken more memory to define a dynamic
arrow to solve this problem in a smarter way. But, coming back to the proposed example for in
brackets numbers, user decides that Nland is going to be 3:
As user can find, all values depending from Nland=3 have been automatically actualised. The code is
working properly and does not allow us to introduce something different that 3 values for Alp(3). We can
make a correct entry with 3*0.0, or three floating values separated by colons:
20
Something similar appears when an Input.txt that has not been generated with Input Editor is loaded.
However in this occasion, number of blue font cells is quite high, that means abundance of different to
Default values. The existence of blue font grey background cells will give a first impression on the quality
of the imported Input.txt, as these cells will indicate that have been proposed values for parameters that
are not necessary keeping Delsol3 rules.
In the example of the picture user had
defined Nuaz and Nuel variables for an
Iprob=4 problem, when these values must
be
only
entered
when
Iprob=3,
performance calculation at user specified
sun angles defined by NUAZ, NUEL,
UAZ(M), and UEL (N). Nevertheless,
Delsol3 would have directly despised this
suggestion.
The second analysis for a blue font on grey
background points towards Tdesp. In this
occasion the access to the Tdesp cell is not
enabled because this variable has no sense
under the Iprob=4 OP stage. Anyway this
variable does not need to be accessible
ever, because it is automatically set by the
code depending on the values for the
electrical power of the plant to design in
the Iprob=0 PR stage.
However the third analysis of blue fonts over grey background shows as there was a mistake trying to
define the weather. So no information should have been introduced for Dweath(Nyear) but to
Dpress(Nyear).
When working on an imported Input.txt not prepared with Input Editor, the use of the TAB button will
lead user through the different cells. This way to proceed will allow user to do a quick verification about
the rightness of the parameters in the Input.txt , being this procedure a useful tool to detect
inconsistencies, mistakes, not necessary overinformation, etc. The Input.txt file coming out from Input
Editor will be perfectly suitable for WinDelsol, will not incorporate inconsistencies and will be free of
typing mistakes.
A red font will indicate wrong pattern for the introduced value.
21
g)
Input Presentation
A large white pad is the area that Input Editor tool offers to verify the state of the Input.txt that it is
being generated. It is not a writeable pad, and parameter values can not be entered in text mode on this
screen, but through the Namelist pages. It is a pad that shows the result of the changes proposed in the
Namelist pages. Just after opening Input Editor, or as a result of a New command, the pad will appear
completely empty.
The first operation that user will do when opening a New Input.txt file is to Save it with a Title for the
problem and a Name:
From the moment that user has saved ExampleUG file, the appearance of white pad changes completely:
22
As it can be observed in the previous picture, the Input.txt file that user has generated under the name of
ExampleUG, shows at present moment, when no value for any parameter has been entered through
Namelist pages, the only values that the Input.txt file will include, those called fixed magenta. Those are
the ones that are strictly necessary for WinDelsol working. As it can be observed too, values for Flux
boundary limits are included in black fonts. This is because Default values for these variables in Delsol3
are not coherent with the Default receiver, (Fazmin=180, Fazmax=180, Pg 190 Delsol3 UG).
Of course, when executing ExampleUG Input.txt file, the analysis of the problem will consider more
information that the presented in the pad. Obviously, all the Default Delsol3 values will be included. This
way of acting, not including parameters whose values are the Defaults for Delsol3, makes much easier to
identify the rightness of the real information that user has decided to put into the problem. Including
Default values parameters only conduit to add unnecessary information to Delsol3/WinDelsol codes, in
very large Input.txt files.
Changes over Delsol3 Default values are presented in the next screen of Input Editor. A north field
instead a circular one with cavity receiver has been proposed. Some information about flux limit
calculation has been included.
23
As a result the following Input.txt file in text form is generated:

File ExampleUG
EXAMPLE FOR WINDELSOL USERS GUIDE VERSION 1.0
&BASIC
Iprob=4
Itape=1
/
&FIELD
RADMAX=12.5
INORTH=1
/
&HSTAT
/
&REC
THT=100.0
TOWL=100.0
IREC=2
W=12.0
H=12.0
IAUTOP=2
RY=7.2
/
&NLFLUX
Iflx=1
DIAMF=12.0
Nxflx=13
FAZMIN=90.0
FAZMAX=270.0
Nyflx=13
FZMIN=-4.0
FZMAX=12.0
Icavf=1
NFLXMX=4
NMXFLX=70,74,83,87
FLXLIM=4*0.6E+10
/
&NLEFF
/
&REC
/
&OPT
NUMTHT=10
THTST=50.0
THTEND=150.0
NUMREC=10
WST=10.0
Numopt=1
Iplfl=1
Iotape=1
Irerun=1
/
&NLFLUX
Iflx=1
DIAMF=12.0
Nxflx=13
FAZMIN=90.0
FAZMAX=270.0
Nyflx=13
FZMIN=-4.0
FZMAX=12.0
Icavf=1
NFLXMX=4
NMXFLX=70,74,83,87
FLXLIM=4*0.6E+10
/
&NLEFF
/
&NLCOST
/
&NLECON
/
PERFORMANCE RUN
&BASIC
Iprob=0
Itape=3
TDESP=20.
/
&FIELD
/
&HSTAT
/
24
&REC
/
&NLFLUX
Iflx=1
Ifxout(1,1)=1
DIAMF=12.0
Nxflx=13
FAZMIN=90.0
FAZMAX=270.0
Nyflx=13
FZMIN=-4.0
FZMAX=12.0
Icavf=1
/
&NLEFF
/
&REC
W=-100.
/
2.5. WinDelsol DOC Stage

2.5.1. Delsol3 plays its Role
After having pressed the Exit command in Input Editor tool, the control of the situation comes back again
to WinDelsol. In this occasion user must select Load Normalised INPUT option.
To carry on with the proposed example we will open the Input.txt file ExampleUG:
25
This pad for Input.txt edition does allow the possibility to make modifications in the text of the opened
file, so it is really important for the correct working of the whole system to be very sure of the proposed
changes. As an advice, the best policy to keep at this stage of the process is to be not to vary any
parameter without going again through Input Editor.
Pressing Ok button, the execution of Delsol3 is launched. It will take some minutes (1 to 5) for this
process.
If you intend to use your own Delsol3 compiled code you will need to call it like DelsolV98.exe, and a
copy of this file will be placed in every of the following folders:
c:\WinDelsol\optima
c:\WinDelsol\opnormal
c:\WinDelsol\iapc
c:\WinDelsol\ipmc
When the problem that is being worked out includes land restrictions, being the parameter Nland>0,
DelsolV98.exe will be executed twice by technical requirements.
26
2.5.2. WinDelsol plays its Role

The access to the second part of WinDelsol for the DOC stage comes just after the end of the Delsol3
execution. A short menu gives the user the opportunity to open and edit the Delsol3 Output.txt file, or
just to go to the results breakdown analysis that WinDelsol offers.
Selecting Output Edition option, user will directly access to the Delsol3 Output.txt text file that will be
located at c:\WinDelsol\Opnormal folder. The edition of this Output.txt file will be done with
Windows Wordpad, a tool that results to be the quicker and useful instrument to go through this kind of
long text files. For the purpose that WinDelsol is able to start automatically Wordpad, a copy of this exe
file should be located at c:\WinDelsol\Accesorios\Wordpad.exe
Once that user has selected Output Edition and Wordpad has started, some precautions should be kept.
As the complete resolution of an Optimisation/Simulation problem will include at least 3 Delsol3
executions, -one for optimisation, one for simulation at Design Point, and a third one for simulation for
Annual Performance-, and even a fourth Delsol3 execution is possible if user problem includes land
restrictions, it is possible to find up to 4 different Output files at WinDelsol folders.
Just to open the right output file it is necessary to act as described:
1. Select in Archivo /File, -(Spanish Worpad)/(English Wordpad)-, the Abrir/ Open (Spanish)/ (English)
option.
2. Worpad is then automatically directed to the correct Output.txt version, pointing out on screen an
only file called Output.doc . This is the document that must be opened.
Selecting Output.doc directly in Archivo (Spanish) File (English) menu, can lead to mistake, as
Output.doc file that was used in last occasion will be opened, but this could be not the right one.
27
The selection of the option Optimisation Results will allow

user to go through the main results that define the
solution of the problem in a direct way, without having to
do the tedious labour of extracting them from the text
Output.txt file. Moreover, many parameters will be
presented in a graphical way just to make more friendly its
interpretation and analysis.
28
2.5.3. Basic Parameters Analysis

Selecting Basic Parameters option it is possible to edit a file that contains the most basic information for
the problem that it is being solved:
The information presented in this screen

c:\WinDelsol\Opnormal\Parbasop.txt .
is
available
in
Parbasop.txt
file,
placed
in
2.5.4. Energetic Analysis

Optimisation Results Analysis menu offers also the possibility to show breakdown for energetic predictions
both for Design Point and Annual Basis.
Efficiencies are presented in Red fonts.

29
2.5.5. Receiver Analysis

Two different points of view for the receiver analysis can be considered, the description of its geometry,
and the flux distribution of solar radiation on it. A menu allows the user to access to any of these different
areas.
There are 3 main sets of different receiver dimensions that are used during WinDelsol normal working
process. It is necessary to know perfectly what set of dimensions is used for every calculation in order to
avoid undesirables mistakes. Receiver dimensions are defined in a complex join of data, as radios, aperture
dimensions, inclination, distance between aperture and absorbing surface or tower centerline, etc But
in every receiver type, cylindrical, cavity or rectangular flat plate there are four very important variables
that are going to define every of the 3 sets of considered receivers. These variables that are included
explicitly in Input.txt file are Fzmin, Fzmax, Fazmin and Fazmax, and define the boundary limits of the
considered receiver in a common defined absorbing surface.
These four variables are included in both DOC-OP stage (Optimisation) and DOC-PR stage (Performance
Rerun) and can take different values. Lets call Set 1 to DOC-OP stage Fzmin, Fzmax, Fazmin and
Fazmax variables, and Set 2 to the DOC-PR Fzmin, Fzmax, Fazmin and Fazmax variables.
Set 1 variables belonging to DOC-OP stage, -that are included up to 2 times in NLFLUX Namelist of OP
stage in an Input.txt file, Ref. 2.2 DOC Normalised Input.txt -, are used to define the boundary limits
of a 13x13 nodes grid to verify flux limits conditions in the optimisation problem.
Set 2 variables belonging to DOC-PR stage, -that are included only 1 time in NLFLUX Namelist at PR
stage in an Input.txt file, Ref. 2.2 DOC Normalised Input.txt -, define the receiver dimensions in order
to represent it, both for geometrical description, or for incident flux analysis. These Fzmin, Fzmax,
Fazmin and Fazmax dimensions will be used for graphical representations, not for energy-power
calculations. In this sense, it can be observed in the following tables how a variation in Fzmin, Fzmax,
Fazmin and Fazmax variables at DOC-PR stage of reference Input.txt file ExampleUG produce some
changes in receiver representation but not in energetic results:
Input DOC-PR:
&NLFLUX
Energetic Results
Heliostats Number 1500
DP Power 20.11MW
FZMIN=-4.5
FZMAX=7.5
FAZMIN=90.0
FAZMAX=270.0
AB Energy 53.97GWh
Flux Peak = 705 kW/m 2
Input DOC-PR:
Energetic Results
&NLFLUX
DP Power 20.11MW
FZMIN=-4.5
FZMAX=7.5
FAZMIN=100.0
FAZMAX=240.0
AB Energy 53.97GWh
30
Input DOC-PR:
Energetic Results
&NLFLUX
DB Power 20.11MW
FZMIN=-14.5
FZMAX=17.5
FAZMIN=160.0
FAZMAX=270.0
AP Energy 53.97GWh
Set 3 of variables is composed by those that are proposed by WinDelsol, after a first Delsol3 execution.
These Fzmin, Fzmax, Fazmin and Fazmax dimensions are those ones used by Delsol3 and WinDelsol
for energetic analysis. It is highly recommendable to consider these values during the execution of a
WinDelsol problem. For this purpose, WinDelsol will present the following screen to the user:
Receiver Dimenssions: Set 1
The screen shows the values for the receiver and absorber geometry and size that has been proposed for
the optimisation calculus -sets 1 and 2-, and the values that WinDelsol has found as optimised for
allowing in the required power without overpassing flux limits.
These values are shown for both Areas of the Design and Optimisation Calculation DOC problem where
can be found with different values, OP stage and PR stage.
This screen appears after a first execution of Delsol3 code, and allows the user to go ahead with his
receiver proposal -Sets 1 and 2 for receiver grid and picture dimensions-, or incorporate in a second
iteration step including a new Delsol3 execution, the receiver dimensions proposed by WinDelsol.
31
User can select the option of keeping the originally proposed values, or integrate the new WinDelsol
proposal in the original input file. This last option leads to an iterative process that finishes when the
proposed values and the calculated by WinDelsol are the same. Code will propose user to integrate
WinDelsol proposal until proposed values are less than 25% different from considered ones. The iterative
process usually finishes in two or three steps.
It results interesting to incorporate WinDelsol absorber dimensions to the input file, because flux maps
pictures are always well centred and with proportionate dimensions.
In our example it had been originally defined a receiver with a 180 absorber of 16 meters height, 6 meter
radio and aperture of 6mx12m. WinDelsol proposes to begin the optimisation with a 180 absorber of
12.96 meters height, 6 meter radio and aperture of 10mx7.2m. The second step leads to the
convergence.
Original Proposal
Final Result after 2 Iterations

32
The selection of the WinDelsol values proposal will automatically generate a new input file incorporating
all the necessary changes to perform a new optimisation with well fitted parameters for the receiver. So
the following changes are included:
&REC
W: This value is actualised according to Delsol3/WinDelsol proposal, fitting with new Fazmin and Fazmax.
H: This value is actualised according to Delsol3/WinDelsol proposal, fitting with new Fzmin and Fzmax.
&NLFLUX
Fzmin: This
Fzmax: This
Fazmin:This
Fazmax:This
value
value
value
value
is
is
is
is
actualised
actualised
actualised
actualised
according
according
according
according
to
to
to
to
Delsol3/WinDelsol
Delsol3/WinDelsol
Delsol3/WinDelsol
Delsol3/WinDelsol
proposal.
proposal.
proposal.
proposal.
Always that one of the options selected for DOC-OP or for DOC-PR includes the WinDelsol Proposal, a
new Delsol3 execution will be performed. Only selecting for both stages the so called, -user proposal-,
will allow the entrance in the optimisation results module.
Once that a final receiver proposal is accepted for the problem, Optimisation Results Receiver Menu is
presented. Both, The geometrical and the flux distribution analysis, are then available to the user.
Geometry
Following pictures show the geometrical analysis of a receiver. This is presented through the 3D
perspective and the 3 usual views used to define an object, Plant, Frontal and Lateral pictures.
33
In any of these screens, user can adjust some parameters in order to take a good picture of the receiver.
For these purpose there are two main areas, -Move and Zoom-.
Move commands will allow to change Horizontal and Vertical values for the picture representation. The
steps for these changes will be determined by the Increment value just near the Move arrows.
34
Zoom commands will allow to change the object size representation values. The steps for these changes
of Zoom will be determined by the Increment value just near the Zoom lenses.
35
The flux analysis onto the receiver can be done both through the edition of the Output.txt file of Delsol3
Optimisation Process, or through the visual tool that offers WinDelsol. The following picture shows the
analysis by means of the text option:
Flux Distribution
The graphical representation of this matrix is performed by WinDelsol through the 2D Flux Map screen:
36
There are only 2 places in Delsol3 Input.txt file where instantaneous time points of the year are defined
in the selected DOC-OP/PR working mode. The first of them is called Design Point. It is defined in
Namelist BASIC from DOC-OP area. It is the instant of the year in which the plant must work at nominal
power. The second one, that appears in Namelist NLFLUX from DOC-PR, has the purpose of defining a
time for a flux simulation with the just recently optimised field. The flux map that is calculated in this
section is the one that it is later represented in the 2D Flux Map screen. It will be the same as calculated
during optimisation in DOC-OP module for determining receiver dimensions with flux limit requirements
only if time selected for this calculation is Design Point, and aiming strategy is not varied from DOC-OP to
DOC-PR. So, in the analysed problem called Example for WinDelsol Users Guide, Version
1.0 the NLFLUX Namelist of DOC-PR kept the same values as considered for time in BASIC Namelist of
DOC-OP, and for aiming strategy in REC Namelist of DOC-OP module. The map of flux that has been
calculated corresponds in this occasion to the conditions of Design Point. Justification is shown in the
table.
DOC-OP Module: Flux Definition
DOC-PR Module: Flux Definition
a-Time: Design Point that is set in BASIC (DOC-OP)
a-Time: Flux Instant that is set in NLFLUX (DOC-PR)
&BASIC
Iprob=4
Itape=1
&NLFLUX
Iflx=1
Ifxout(3,1)=1
Diamf=12.0
Fazmin=90.0
Fazmax=270.0
Fzmin=-4.5
Fzmax=7.5
/
In the example, Julian Day 81, Solar Time 0:0 as default.
/
In the example, Julian Day when Ifxout(3,1)=1 and Nyear=5 is 81
Solar Time when Ifxout(3,1)=1 is 0:0.
b-Aiming Strategy: Iautop set in REC (DOC-OP)
b-Aiming Strategy: Iautop set in REC (DOC-PR)
&REC
Tht=100.0
Towl=100.0
Irec=2
W=12.0
H=12.0
Iautop=2
Ry=7.2
/
&REC
/
This Rec Namelist must be obligatorily kept empty, in order that it
gets the same values for receiver that defined in DOC-OP module.
So it is not possible in WinDelsol to have a different aiming
strategy from DOC-OP to DOC-PR.
In the example, Iautop=2, that means 2D spread images.
c-Receiver Dimensions: are set in REC (DOC-OP)
c-Receiver Dimensions: are set in REC (DOC-PR)
&REC
Tht=100.0
Towl=100.0
Irec=2
W=12.0
H=12.0
Iautop=2
Ry=7.2
&REC
/
This Rec Namelist must be obligatorily kept empty, in order that it
gets the same values for receiver that defined in DOC-OP module.
So it is not possible in WinDelsol to have different receiver
geometry from DOC-OP to DOC-PR.
/
In the example, a cavity receiver with cylindrical absorber surface of
6m radius and 12m height , and aperture is defined.
d-Flux Calculation: is set in NLFLUX (DOC-OP)
d-Flux Calculation: is set in NLFLUX (DOC-PR)
&NLFLUX
Iflx=1
Diamf=12.0
Nxflx=13
Fazmin=90.0
Fazmax=270.0
Nyflx=13
Fzmin=-4.5
Fzmax=7.5
Nflxmx=4
Nmxflx=70,74,83,87
Flxlim=4*0.6E+6
/
&NLFLUX
Iflx=1
Ifxout(3,1)=1
Diamf=12.0
Fazmin=90.0
Fazmax=270.0
Fzmin=-4.5
Fzmax=7.5
With the objective of taking a picture of the flux distribution in the

time, receiver, and under the aiming strategy selected, a 13x13
cells grid is stabilised on receiver absorbing surface, from y1 m to
y2 m in height and x1 to x2 in angular aperture, fitting with
To calculate and design the plant, a 13x13 cells grid is stabilised on receiver geometry determined in REC (DOC-OP) Namelist.
receiver absorbing surface, from 4.5m to 7.5m in height and 90
to 270 in angular aperture, fitting with receiver geometry In the example flux is calculated in a surface that is the same that
determined in REC (DOC-OP) Namelist. Up to 4, can be selected in absorber surface in extension, but it could have been different.
order to verify that the achieved flux stays under a limit value. In
the example nodes are 70, 74, 83, 87, and flux limit 600 kW/m2.
37
The following picture shows the nodes relative positions in order to verify flux limits:
1
14
27
40
53
66
79
92
105
118
131
144
157
2
15
28
41
54
67
80
93
106
119
132
145
158
3
16
29
42
55
68
81
94
107
120
133
146
159
4
17
30
43
56
69
82
95
108
121
134
147
160
5
18
31
44
57
70
83
96
109
122
135
148
161
6
19
32
45
58
71
84
97
110
123
136
149
162
7
20
33
46
59
72
85
98
111
124
137
150
163
8
21
34
47
60
73
86
99
112
125
138
151
164
9
22
35
48
61
74
87
100
113
126
139
152
165
10
23
36
49
62
75
88
101
114
127
140
153
166
11
24
37
50
63
76
89
102
115
128
141
154
167
12
25
38
51
64
77
90
103
116
129
142
155
168
13
26
39
52
65
78
91
104
117
130
143
156
169
Some experiments in order to show the practical procedure of working of the flux calculation system will
be performed:
1.- Experiment to verify that grid Limits to represent flux picture are defined in:
DOC-PR
Keeping the same example as previously used, the User can take profit from this working procedure to
following changes are included in the Input file:
examine in detail the high flux area: so keeping the same
example as previously used, the following changes are
DOC-PR
included in the Input file:
&NLFLUX
Iflx=1
Ifxout(3,1)=1
Diamf=12.0
Fazmin=120.0
Fazmax=270.0
Fzmin=-10.
Fzmax=10.
/
DOC-PR
&NLFLUX
Iflx=1
Ifxout(3,1)=1
Diamf=12.0
Fazmin=157.0
Fazmax=207.0
Fzmin=-1.6
Fzmax=3.3
As it can be observed, geometrical limits for flux /
representation have changed, but flux distribution result

must be the same, as nor time, nor receiver dimensions
have been modified:
The following result is obtained:
The result seems to be satisfactory, nor flux distribution nor As it can be observed, geometrical limits for flux
flux peak have changed.
representation have changed, but flux distribution and flux
peak remain constant.
38
2.- Experiment to verify that Time to

represent flux picture is defined in:
DOC-PR
3.- Experiment to verify that Aiming

Strategy to represent flux picture is defined
in:
DOC-OP
Keeping the same example as previously used, the Keeping the same example as previously used, the
following change is included in the Input file:
following change is included in the Input file:
DOC-PR
DOC-OP
&NLFLUX
Iflx=1
Ifxout(5,5)=1
Diamf=12.0
Fazmin=120.0
Fazmax=270.0
Fzmin=-4.5
Fzmax=7.5
/
&REC
Tht=100.0
Towl=100.0
Irec=2
W=12.0
H=12.0
Iautop=1
Ry=7.2
/
As it can be observed, geometrical limits for flux Aiming Strategy has been changed from 2D-Smart to 1Drepresentation havent changed, but time for flux Smart.
calculation has been modified. At this occasion, flux in 21
of June (JD=172.25) at 16:00 solar time has been selected.
The result is satisfactory. However, it has to be pointed that

there is not possibility in Delsol3 to modify the value for
solar irradiation from the one considered at DOC-OP BASIC
Refsol, fixed for this example at 0.95kW/m2. This value is
not logical for the time simulated at this occasion. User will
perform some additional work to transform this flux
distribution into a more realistic one in terms of input solar
irradiance.
It can be noticed that flux peak has increased till

643kW/m2. The same result is obtained if Aiming Strategy
is changed in DOC-PR REC Iautop instead of in DOC-OP
REC Iautop. Nevertheless, Editinput tool doesnt allow to
include a value for DOC-PR REC Iautop so this is kept the
same as DOC-OP REC Iautop, to avoid inconsistencies.
However this change can be made manually in WinDelsol
edition pad if necessary.
The following step for flux representation onto receiver is the 3D picture. The convenient use of
displacement, zoom and rotation controls will provide user the adecquated view for the picture.
It must be noticed that rotation units are radians, so a quarter of spin is got when Increment for rotation
value is 1.57 rads.
The Save Image command will generate a bmp picture that will be stored in the folder:
c:\WinDelsol\Images\flux3d.bmp
39
In the Users Guide Example Input.txt file a cavity

receiver is considered. Back side of the receiver is
only partially drawn, mixing flux representation
with a blue triangulated pattern.
DOC-OP
&REC
Tht=100.0
Towl=100.0
Irec=2
W=12.0
H=12.0
Iautop=2
Ry=7.2
\
Including the Irec parameter modification, -in

blue at the left-, a change to a cylindrical
receiver configuration is done.
DOC-OP
&REC
Tht=100.0
Towl=100.0
Irec=0
W=12.0
H=12.0
Iautop=2
Ry=7.2
/
DOC-OP
&REC
Tht=100.0
Towl=100.0
Irec=4
W=12.0
H=12.0
Iautop=2
Ry=7.2
/
&NLFLUX
Iflx=1
Diamf= 12.0
Nxflx= 13
Fazmin=-6.0
Fazmax=6.0
Nyflx=13
Fzmin=-4.5
Fzmax=7.5
Nflxmx=4
Nflxmx=4
Flxlim=4*0.6E+6
/
DOC-PR
&NLFLUX
Iflx=1
Ifxout(3,1)=1
Diamf=12.0
Fazmin=-6.0
Fazmax=6.0
Fzmin=-4.5
Fzmax=7.5
To consider a flat receiver configuration involves

not only a change in the Irec parameter that
specifies receiver shape, but changes in the
boundary limits for the receiver flux calculation
and representation. This is debt to the fact that
boundary limits are considered in degrees for
cavity and cylindrical configurations, and in
meters for flat receivers.
40
2.5.6. Heliostat Field Analysis

Selecting the Heliostat Field analysis option user will access to a menu screen that allows the study of the
annual performance of the heliostat field from different efficiencies factors. In the picture, Cosine option
has been selected.
The efficiency factors representation screen gives information on maxim and minim reached values, and
makes possible visual variations of the picture appearance.
The selection of the All button makes possible the access to a screen where, all annual values for the
different efficiency factors of the field are presented.
The product of the factors Cosine, Shadowing+Blocking, Transmisivity and Spillage compose the Optical
Efficiency of the Heliostat field. Mirrors reflectivity factor is not included in this Optical Efficiency factor.
This Optical Efficiency factor has been calculated in annual basis, and so, it represents the best locations to
install heliostats, due that annual efficiency of every position can be easily compared.
It is necessary to generate images of different efficiency factors one by one to see all of them in the
general screen. In other way, correspondent cell will be presented empty.
The most important button for the Heliostat field screen is that called Coordinates Arrangement. It allows
the access to the Heliostat Field Arrangement, HFA stage, closing the DOC, Design and Optimisation
Calculation, process.
41
2.6. WinDelsol HFA Stage

Screen that opens the HFA stage presents the Annual Optical Efficiency distribution of the optimised
heliostat field, and some important values that WinDelsol has extracted from Delsol3 Output.txt file.
Every of the information elements that this screen present are analysed.
The title of the screen is: COORDINATES FIELD: North. In case that a circular plant was analysed the title
would have been COORDINATES FIELD: Circular.
The subtitle of the screen is AUTHOMATIC METHOD. This means that heliostats will be located one after
another in the best possible places. In contraposition there is the possibility of running a MANUAL
METHOD. This option is automatically activated when land restrictions are present in the problem. In this
option, WinDelsol will present possible gaps for heliostats together with land restriction boundaries, and
user will fill the allowed land with heliostats in a manual way.
As a matter of fact, there is always the possibility of making some changes manually heliostat by heliostat
when working in automatic way, and it is not really completely true that all the heliostats must be placed
one by one manually in manual working way. Many of the heliostats are placed fitting with the proposed
area, but some changes will have to be always done.
Below the subtitle it is possible to find an area called Delsol3 Radial-Azimutal Grid Estimate. Values
presented into this area correspond to the Delsol3 DOC stage calculations. DOC stage proposes that it is
possible to put into the receiver at design point 88.432MWth, and that it is possible to put into the
receiver 181.487GWhth in a year, with only 1481 heliostats, using the proposed heliostats, and the Annual
Optical Efficiency field that has been calculated.
Just under the area called Delsol3 Radial-Azimutal Grid Estimate, user can find the area called
Coordinates Field. This area is referred to the control of the heliostat field that it is going to be
generated. The management for the heliostat field arrangement is described. The process begin when
Delsol3 through the WinDelsol DOC stage proposes densities of heliostats allocation for every of the
12x12=144 radial-azimuthal subareas of the field. WinDelsol reads these results from Delsol3
42
Output.txt file and proposes a distribution of organised gaps over the field that accomplishes with
densities of heliostats proposed by Delsol3 in every sector. The entire field is then filled with gaps in the
way that the next image shows.
Three cells are related in WinDelsol Coordinates Field area to the number of heliostats, Active
Heliostats, Inactive Heliostats, and Possible Heliostats.
Possible Heliostats: Total number of gaps that can be transformed in heliostats.
Active Heliostats: Number of gaps that have been transformed into heliostats.
Inactive Heliostats: Possible Heliostats - Active Heliostats, Number of gaps that remain.
Another two cells are related to the maximum energy -GWhth- that in a year this heliostat filed could
supply if every gap was transformed into heliostat, and to the energy -GWhth- that in a year user requests
this heliostat field to supply.
xxxx
First of these two cells, the one that in the picture shows the value xxxx, is automatically filled with a
number by the computer. For the overall geometry of the plant and the considered annual solar radiation
distribution, there is a maximum value that this heliostat field can supply if every possible position called
gap, is filled with a heliostat.
The second of these two cells must include a value proposed by user, from 0 to MAX GWhth. Code will
then transform gaps into heliostats from best positions to worse till the heliostat field is able to put into
the receiver the necessary energy in a year.
43
To access to this option, user must press Automatic Layout, the only enabled possibility at present.
A message will then appear on to the screen:
Code proposes automatically a value of thermal energy in AB, Annual Basis-, to be delivered by heliostat
field onto receiver that fits with the value of thermal energy that Delsol3 proposed during the
optimisation process developed in WinDelsol DOC-OP stage. This value corresponds to the energy that
proposed heliostats to delivery nominal power at design point are able to supply in Annual Basis.
Has there been then a change in the logics of optimisation process? Has Nominal Thermal Power at
Design Point concept been replaced by Annual Basis Thermal Energy in order to optimise the plant?
No, Nominal Thermal Power at Design Point -88.432MWth in the example-, was the main requirement to
optimise the plant during DOC-OP stage, always from the point of view of the lower cost of the produced
energy. As a result, code proposes a defined heliostat field, -1481 units in example-. From this
optimisation, maps of annual optical efficiency for heliostat field are generated, and annual energy to be
supplied by the heliostat field can be then calculated, -181.487GWhth in a year in the example-.
At this point, now user can keep the Annual Energy value that coming from optimisation the code
proposes, or can include any other value from 0 to MAX. Of course user will know that only requesting an
Annual Energy value close to the proposed one, plant design could be considered optimised.
The purpose of leaving user the possibility to include any other value for the requested Annual Energy has
a clear explanation. When designing a plant, user will select in a first approach the proposed Annual
Energy value. Code will select as many heliostats as necessary to supply that value, and then in the last
PFC stage, Performance of Field Calculation, code will test the proposed coordinates heliostat field. The
result of this stage will be very similar to expected values both in power supplied onto receiver at nominal
conditions, or in energy delivered in Annual Basis, but some minimum differences of about less than 5%
between proposed and calculated values can be also found. User then has the possibility of coming back
in the code development and request to the heliostat field to supply an Annual Energy increased or
decreased in the percentage difference, in order that the final result of the PFC stage fits with the initial
requirements of optimisation at DOC stage.
The next pictures show the results obtained for different requirements of Annual Energy introduced by
user, from a very low 0.1 GWhth , to the maximum 201.74 GWhth going through the optimum value
181.49 GWhth. Energetic results for every of the examples proposed are shown in the last three cells of
Coordinates Field area.
44
Input Data
MAX Energy :
201.74 GWhth/year
Requested Energy:
Possible Heliostats:
0.10 GWhth/year
1649
Results
Active Heliostats:
Energy Supplied:
0.16 GWhth/year
Nominal Power at D.P.:
0.08 MWth
Annual Optical Efficiency: 71.14%

Input Data
MAX Energy :
201.74 GWhth/year
Requested Energy:
181.49 GWhth/year
1649
Results
Active Heliostats:
1342
Energy Supplied:
181.69 GWhth/year
88.53 MWth

Input Data
MAX Energy :
201.74 GWhth/year
Requested Energy:
201.74 GWhth/year
1649
Results
Active Heliostats:
Energy Supplied:
1649
201.74.69 GWhth/year
98.3 MWth
Some other controls of the HFA stage main screen are related to the possibility of making manual
changes in the proposed heliostat field. A legend shows the state of every heliostat when making manual
changes just clicking the mouse over the heliostat in field.
An active heliostat will be presented in magenta. A gap is a transparent
circle. When a gap is transformed into a heliostat by clicking the mouse on
it, it will be presented in green. When an active heliostat is rejected by
clicking the mouse on it, and transformed in a gap it will be presented in
red. Pressing the New Image Button, information on the heliostats status is
actualised, and all active heliostats are again presented in magenta. The gaps
are presented then as transparent circles.
45
Manual changes on an automatic layouts are often made just to leave free some paths or restricted areas.
After having made some manual changes in a heliostat field, the New
Image option will regenerate the proposed configuration picture. The
energetic results for this new configuration must be recalculated again
by pressing the New Energetic Results option. To save the actual picture
in bmp format it will be pressed the Save Image option.
c:\WinDelsol\Images\coorfield.bmp
Back selection will take user to the previous screen. This option will be of special interest when interaction
between heliostats are detected. Then, in menu screen, the negative selection for the New Field option
will be done.
In the picture representation, maximum diagonal length of the heliostat + 0.15m is considered as a
diameter to draw the representative circles. When heliostats are in supervivency status in horizontal
position, it must be avoided any possibility of collision between them. In case any circle is coincident with
another, some expansion coefficient must be applied to densities parameters calculated during
optimisation. This effect is shown in the next pictures:
In case there are land restrictions in the original Input.txt file, the manual method to generate
coordinates fields is activated. The basic working procedure of this option is basically the same as the used
in the automatic method, with the only difference that in this occasion, user doesnt request for an
Annual Energy value. Code automatically places heliostats in gaps till the Annual Energy coming from
WinDelsol DOC stage is reached. This way of acting is based on the supposition that in this occasion,
land restrictions will be higher than energetic restrictions, and that at last, what user requests to the code
is to have the higher Annual Energy production with the available land. User will at last fill all the available
gaps into the available land.
46
Coming from WinDelsol-DOC stage, code enters in WinDelsol-HFA stage through the Hand Method
screen.
Step 1.- WinDelsol-HFA Screen.
Step 2.- Visibility is increased by putting off Efficiency Map.
Step 3.- Some Heliostats are defused. Some Gaps are activated. Step 4.- Only Active Heliostats selected. Image Regeneration.
Next button will take user out of Heliostat Field Coordinates Arrangement main screen, saving an ASCII
text file containing all the information about the coordinates field in the following path and form:
c:\WinDelsol\Coordenadas\Norte-Circular\coordenadas.val
X<0 East
-0000038.39
-0000060.59
0000060.59
0000000.00
0000052.32
-0000052.32
0000020.29
0000038.39
Y>0 North
0000049.32
0000015.34
0000015.34
0000062.50
0000034.18
0000034.18
0000059.11
0000049.32
Some significant time, 5-15 minutes, could be used for this task.
47
From WinDelsol-HFA main screen, user accesses to a menu screen that allows the study of the designed
coordinates heliostat field, over the different annual performance maps factors.
Each represented efficiency factor screen gives information on maxim and minim reached values.
Total SCALE 01 option is enabled once that Total option has been generated.
The selection of the All button makes possible the access to a screen where all annual values for the
coordinates field of the different efficiencies factors are presented.
The product of the factors Cosine, Shadowing+Blocking, Transmisivity and Spillage compose the Optical
Efficiency of the Heliostat field. Mirrors reflectivity factor is not included in this Optical Efficiency factor.
This Optical Efficiency factor has been calculated in Annual Basis, and so, it represents the best locations
to install heliostats, due that annual efficiency of every position can be easily compared.
It is necessary to generate images of different efficiency factors one by one to see all of them in the
general screen. In other way, correspondent cell will be presented empty.
Coordinates Simulation option closes WinDelsol-HFA stage. User can access then to the Performance
of Field Calculation, WinDelsol-PFC stage.
48
2.7. WinDelsol PFC Stage

The last stage for WinDelsol working strategy is the so-called, Performance of Field Calculation. In this
stage, WinDelsol will test the Design Point and the Annual Basis performances for the coordinates field
that has been generated. Two different Input.txt files will then be generated, one for the Design Point
PFC-DP option, based on the Iprob=2 Delsol3 option, single time performance calculation defined by
Uday and Utime, and one for the PFC-AB Annual Basis calculation based on the Iprob=3 option,
performance calculation at user specified sun angles defined by Nuaz=m, Nuel=n, Uaz(m), and Uel(n). This
option with default values for angles will generate input required for the STEAEC code or SOLERGY code.
Simulation of the Plant at Design Point
The Input.txt file for a Design Point Performance simulation will be composed in the following pattern:
TITULO DEL PROBLEMA
&BASIC
(1 DPP)
Iprob=2
Uday=Refday (DOC-OP Stage)
Utime=Reftim(DOC-OP Stage)
Data
/
&FIELD
(1 DPP)
Iuserf=3
Data
/
&HSTAT
(1 DPP)
Data
/
&REC
(1 DPP)
Data
/
&NLFLUX
(1 DPP)
Data
/
&NLEFF
(1 DPP)
Data
/
COORDINATES FIELD
Hels.N Rows.N
Row i
Hels.N
X1
Y1
X2
Y2
.
.
.
/
&REC
(2 DPP)
W=-100.
/
DFocal1
DFocal2
Magenta parameters are always present in a PFC-DP, because are inherent to Iprob=2 Delsol3 working
procedure. In the special case that Design Point is Default, that means JD=81 and ST=12:00, nor Refday
and Reftim will be included at WinDelsol DOC-OP Input.txt file, and so, nor Uday and Utime will be
included at WinDelsol PFC stage.
Apart from the fixed Magenta parameters, all Namelists are filled with the same Data that coming from
the Normalised Input.txt from WinDelsol DOC, is necessary for the Iprob=2 Delsol3 Option. In this
occasion, the only parameter that it is not considered is the time instant calculation for flux distribution
onto receiver, Ifxout(i,j)=1, from WinDelsol DOC-PR Input.txt file, because nor flux calculation is
included at this option.
Example Input.txt file is automatically composed as follows :
&BASIC
Iprob=2
/
&FIELD
Inorth=1
Iuserf=3
/
&HSTAT
Ncantx=2
Ncanty=8
49
/
&REC
Tht=100.00
Towl=100.00
Irec=2
W=12.00
H=12.96
Ry=12.00
Rx=10.00
Iautop=2
/
&NLFLUX
Iflx=1
Diamf=12.0000
Nxflx=13
Nyflx=13
Fazmin=90.00
Fazmax=270.00
Fzmin=-5.52
Fzmax=7.44
/
&NLEFF
/
CAMPO DEFINIDO POR COORDENADAS
1342
37
1
7
0.00
62.49
20.29
59.11
38.38
49.31
52.32
34.18
-52.33
34.18
-38.39
49.31
-20.30
59.11
2
6
11.63
69.73
33.65
62.18
499.98
499.98
499.98
499.98
499.98
499.98
499.98
499.98
499.98
&REC
w=-100
This Input.txt file is presented in a pad screen similar to the one presented in the next picture. Time for
this screen to appear depends on the number of heliostats composing the field, and of course, of the
computer capabilities too. For a several thousands heliostats field time could reach half an hour.
For fields over 5000 heliostats, time could reach even more than half an hour.
Generated Iprob=2 Input.txt file
Path to find WinDelsol PFC-DP Input.txt file is:

C:\WinDelsol\iapc\iapc.val
50
Selecting the Ok option user executes Delsol3 code. After the running of Delsol3 has finished, A men is
presented on screen.
Selecting Output Edition option, user will directly access to the Delsol3 Output.txt text file, that will be
located in c:\WinDelsol\iapc path. The edition of this output file will be done with Windows Worpad.
restrictions, it is possible to find up to 4 different Output files in WinDelsol folders.
option.
4. Accessing to C:\WinDelsol\iapc, WordPad will point on screen to an only file called Output.rtf. This
is the document that must be opened.
Selecting Output.doc directly in Archivo (Spanish) File (English) menu, can lead to mistake, as Output.rtf
file that was used in last ocassion will be opened, but this could be not the right one.
51
Selecting the Energy at Design Point option,

user will go through the main results that
define the Design Point energetic solution of
the problem.
Energy values will be presented in black
fonts. Efficiencies in red fonts.
The example that has been used for this Users Guide tried to optimise a 20MW electric plant. As we can
find out from this Design Point Energetic Results screen, our designed plant supplies only 19MW electric,
around 5% under requested. As a matter of fact, Delsol3 proposed in main screen of HFA Stage about
1481 heliostats, while user selected at last only 1342 units, around 10% under proposal. It is the occasion
now to come back to HFA Stage main screen and request in the Annual Energy to Produce input message
about 5% increased the code proposal. When arrived to this PFC-DP Stage results user will compare
again the results with original requisitions, acting depending on results, closing the design of the field if
obtained 20MW electric, or coming back to HFA Stage design main screen as in an iterative procedure.
52
Simulation of the Plant at Annual Basis

The Input.txt file for an Annual Basis Performance simulation will be composed in the following pattern:
TITULO DEL PROBLEMA
&BASIC
(1 ABP)
Iprob=3
Nuel=7
Nuaz=7
Uel=0.5,25.,45.,65.,75.,85.,89.99
Uaz=0.,30.,60.,75.,90.,110.,130.
Data
/
&FIELD
(1 ABP)
Iuserf=3
Data
/
&HSTAT
(1 ABP)
Data
/
&REC
(1 ABP)
Data
/
&NLFLUX
(1 ABP)
Data
/
&NLEFF
(1 ABP)
Data
/
COORDINATES FIELD
Hels.N Rows.N
Row i
Hels.N
X1
Y1
X2
Y2
.
.
.
/
&REC
(1 ABP)
W=-100.
/
DFocal1
DFocal2
Magenta parameters are always present in a PFC-AB, because are inherent to Iprob=3 Delsol3 working
procedure. Efficiencies matrix that is going to be calculated for Solergy input is defined through fixed
values of Nuel, Nuaz, Uel, Uaz.
Apart from the fixed Magenta parameters, all Namelists are filled with the same Data that coming from
the Normalised Input.txt from WinDelsol DOC, is necessary for the Iprob=3 Delsol3 Option. The only
parameter that it is not considered is the time instant calculation for flux distribution onto receiver,
Ifxout(i,j)=1, from WinDelsol DOC-PR Input.txt file, because nor flux calculation is included at this
option.
Example Input.txt file is automatically composed as follows:
&BASIC
Iprob=3
Nuel=7
Nuaz=7
Uel=0.5,25.,45.,65.,75.,85.,89.99
Uaz=0.,30.,60.,75.,90.,110.,130.
/
&FIELD
Inorth=1
Iuserf=3
/
&HSTAT
Ncantx=2
Ncanty=8
/
&REC
Tht=100.00
Towl=100.00
Irec=2
W=12.00
H=12.96
Ry=12.00
53
Rx=10.00
Iautop=2
/
&NLFLUX
Iflx=1
Diamf=12.0000
Nxflx=13
Nyflx=13
Fazmin=90.00
Fazmax=270.00
Fzmin=-5.52
Fzmax=7.44
/
&NLEFF
/
CAMPO DEFINIDO POR COORDENADAS
1342
37
1
5
0.00
62.49
20.29
59.11
38.38
49.31
-38.39
49.31
-20.30
59.11
2
6
11.63
69.73
33.65
62.18
499.98
499.98
499.98
499.98
499.98
499.98
499.98
&REC
w=-100
This Input.txt file is presented in a pad screen similar to the one presented in the next picture. Time for
this screen to appear depends on the number of heliostats composing the field, and of course, of the
computer capabilities too. For a several thousands heliostats field time could reach half an hour.
For fields over 5000 heliostats, time could reach even more than half an hour.
Generated Iprob=3 Input.txt file
Path to find WinDelsol PFC-AB Input.txt file is:

C:\WinDelsol\ipmc\ipmc.val
54
Selecting the Ok option user executes Delsol3 code. After the running of Delsol3 has finished, A menu is
presented on screen.
Selecting Output Edition option, user will directly access to the Delsol3 Output.txt text file, that will be
located in c:\WinDelsol\ipmc path. The edition of this output file will be done with Windows Worpad.
restrictions, it is possible to find up to 4 different Output files in WinDelsol folders.
option.
6. Accessing to C:\WinDelsol\ipmc, WordPad will point on screen to an only file called Output.rtf. This
is the document that must be opened.
7. . This is the document that must be opened.
Selecting Output.doc directly in Archivo (Spanish) File (English) menu, can lead to mistake, as Output.rtf
file that was used in last occasion will be opened, but this could be not the right one.
55
Selecting the Energy at Design Point option,

user will go through the main results that
define the Design Point energetic solution of
the problem. Energy values will be presented in
black fonts. Efficiencies in red fonts.
This matrix is stored in C:\WinDelsol\ipmc\matsol.txt file.

All Output documents for a finished problem are stored in C:\WinDelsol\Output under the following
names: Output.opt, Output.apc, Output.pmc .
56
3. Installation Procedure
In the Installation CD-ROM user will find three different folders:
WinDelsol
WinDelsol Setup
EditInput Setup
User first will copy entire WinDelsol folder to hard disk C of personnal computer.
User will access to WinDelsol Setup folder and will select Setup code.
User will access to EditInput Setup folder and will select Setup code.
Dont Forget:
Copy Wordpad
To run properly WinDelsol it is neccesary to copy your own Wordpad.exe file placed into your
computer in the path:
c:\Archivos de Programa\Windows\Accesorios\Wordpad.exe
or
c:\Programe Files\Windows\Accesories\Wordpad.exe
into your new WinDelsol path:
c:\WinDelsol\Accesorios\Wordpad.exe
replacing so the copy installed at that location during WinDelsol setup by your own copy.
Change Number Configuration from Regional Configuration of Windows Control Pannel.
Floating Character should be the dot .
Thousands Character should be the space
57

WinDelsol 1-0 UG English

Uploaded by

Document Information

Original Description:

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

WinDelsol 1-0 UG English

Uploaded by

Copyright:

Available Formats

WinDelsol 1.

1. General Considerations on Delsol3 and WinDelsol 1.0 working__________________________ 3

General Considerations on Delsol3 working ________________________________________ 3

General Considerations on WinDelsol working ______________________________________ 3

2. Using WinDelsol 1.0_____________________________________________________________ 7

Starting WinDelsol, the DOC Problem ____________________________________________ 7

DOC Normalised Input ________________________________________________________ 8

Explanation for Magenta Fixed Values in a DOC Normalised Input _____________________ 10

Using Input Editor Tool_______________________________________________________ 13

WinDelsol DOC Stage ________________________________________________________ 25

Delsol3 plays its Role ________________________________________________________________

WinDelsol HFA Stage ________________________________________________________ 42

WinDelsol PFC Stage ________________________________________________________ 49

3. Installation Procedure __________________________________________________________ 57

WinDelsol 1.0 Users Guide

1. General Considerations on Delsol3 and WinDelsol 1.0 working

1.2. General Considerations on WinDelsol working

WinDelsol 1.0 Users Guide

Working procedure for WinDelsol is as follows:

DOC Stage, Design Optimisation Calculation

WinDelsol 1.0 Users Guide

HFA Stage, Heliostat Field Arrangement

Input of Annual Energy Production

WinDelsol will represent an annual

WinDelsol 1.0 Users Guide

PFC Stage, Performance of Field Calculation

Annual Performance SOLERGY Matrix

WinDelsol 1.0 Users Guide

2. Using WinDelsol 1.0

DOC Normalised Input

2.2. DOC Normalised Input

WinDelsol 1.0 Users Guide

WinDelsol 1.0 Users Guide

2.3. Explanation for Magenta Fixed Values in a DOC Normalised Input

WinDelsol 1.0 Users Guide

WinDelsol 1.0 Users Guide

2.4. Using Input Editor Tool

Errors Detected LOG

7 are the main parts of this Input Editor:

File Edition Menu

WinDelsol 1.0 Users Guide

File Edition Menu

When selected, the following options will come to us:

WinDelsol 1.0 Users Guide

LOG Report on Errors

Variables Search Help

WinDelsol 1.0 Users Guide

Delsol3 Online Help

Enabled and Different

WinDelsol 1.0 Users Guide

WinDelsol 1.0 Users Guide

WinDelsol 1.0 Users Guide

WinDelsol 1.0 Users Guide

WinDelsol 1.0 Users Guide

WinDelsol 1.0 Users Guide

As a result the following Input.txt file in text form is generated:

WinDelsol 1.0 Users Guide

2.5. WinDelsol DOC Stage

WinDelsol 1.0 Users Guide

2.5.2. WinDelsol plays its Role

WinDelsol 1.0 Users Guide

The selection of the option Optimisation Results will allow

WinDelsol 1.0 Users Guide