nrel / solarpilot

SolarPILOT power tower layout and optimization tool

SolarPILOT - Solar Power tower Integrated Layout and Optimization Tool

The SolarPILOT Open Source Project repository contains the source code, tools, and instructions to build a desktop version of the National Renewable Energy Laboratory's SolarPILOT. SolarPILOT is a design, characterization, and optimization tool for concentrating solar power (CSP) tower plants. It is available through this repository as a standalone application with full functionality, and it is also included in several CSP tower models within NREL's System Advisor Model (SAM) in limited form. For more details about SolarPILOT's capabilities, see the SolarPILOT website at https://www.nrel.gov/csp/solarpilot.html. For details on integration with SAM, see the SAM website at sam.nrel.gov.

The desktop version of SolarPILOT for Windows or Linux builds from the following open source projects:

• SolTrace is a general tool for Monte-Carlo ray tracing that allows optical characterization of a wide range of possible systems. The tool is used by SolarPILOT alongside the analytical Hermite polynomial expansion model to ensure model accuracy.

• SSC is a set of "compute modules" that simulate different kinds of power systems and financial structures. It can be run directly using the SAM Software Development Kit. If you are looking for the algorithms underlying the models, they are located in this repository. For a list of SSC release versions that correspond with SolarPILOT GUI releases, see the release list and tags at Mike Wagner's personal GitHub page.

• LK is a scripting language that is integrated into SAM and allows users to add functionality to the program.

• wxWidgets is a cross-platform graphical user interface platform used for SAM's user interface, and for the development tools included with SSC (SDKtool) and LK (LKscript). The current version of SAM uses wxWidgets 3.1.1.

• WEX is a set of extensions to wxWidgets for custom user-interface elements used by SAM, and by LKscript and DView, which are integrated into SAM.

• Google Test is a C++ test framework that enables comprehensive unit-testing of software. Contributions to the project will eventually be required to have associated unit tests written in this framework.

• This repository, SolarPILOT, provides the user interface to assign values to inputs of the computational modules, run the modules in the correct order, and display calculation results. It also includes tools for editing LK scripts, viewing field layout and receiver flux map data, and performing multi-dimensional system optimization.

Quick Steps for Building SolarPILOT

For detailed build instructions see the wiki, with specific instructions for:

• Windows
• Linux

These are the general quick steps you need to follow to set up your computer for developing SolarPILOT:

1. Set up your development tools:

   • Windows: Visual Studio 2017 Community or other editions available here.
   • Linux: g++ compiler available here or as part of the Linux distribution.

2. Download the wxWidgets 3.1.1 source code for your operating system.

3. Build wxWidgets.

4. In Windows, create the WXMSW3 environment variable on your computer to point to the wxWidgets installation folder, or Linux, create the dynamic link /usr/<USERNAME>/local/bin/wx-config-3 to point to /path/to/wxWidgets/bin/wx-config.

5. As you did for wxWidgets, for each of the following projects, clone (download) the repository, build the project, and then (Windows only) create an environment variable pointing to the project folder. Build the projects in the following order, and assign the environment variable for each project before you build the next one:

Project	Repository URL	Windows Environment Variable
wxWidgets	https://www.wxwidgets.org/downloads	WXMSW3
LK	https://github.com/NREL/lk	LKDIR
WEX	https://github.com/NREL/wex	WEXDIR
Google Test	https://github.com/google/googletest	GTEST
SSC	https://github.com/mjwagner2/ssc, -b solarpilot-develop	SSCDIR
SolTrace	https://github.com/NREL/SolTrace	CORETRACEDIR
SolarPILOT	https://github.com/NREL/SolarPILOT

Contributing

If you would like to report an issue with SolarPILOT or make a feature request, please let us know by adding a new issue on the issues page.

If you would like to submit code to fix an issue or add a feature, you can use GitHub to do so. Please see Contributing for instructions.

License

SolarPILOT's open source code is copyrighted by the Alliance for Sustainable Energy and licensed under a mixed MIT and GPLv3 license. It allows for-profit and not-for-profit organizations to develop and redistribute software based on SolarPILOT under terms of an MIT license and requires that research entities including national laboratories, colleges and universities, and non-profit organizations make the source code of any redistribution publicly available under terms of a GPLv3 license.

Citing SolarPILOT

If you find SolarPILOT useful, we ask that you appropriately cite it in documentation of your work. We provide the open-source code and executable distributions for free, but find value in being acknowledged in work that advances scientific knowledge and engineering technology. For general use of SolarPILOT, the preferred citation is:

Wagner, M.J., Wendelin, T. (2018). "SolarPILOT: A power tower solar field layout and characterization tool", Solar Energy, Vol. 171, pp. 185-196, ISSN 0038-092X, https://doi.org/10.1016/j.solener.2018.06.063.

The work is also presented in the following publication:

Wagner, M.J., Braun, R.J., Newman, A.M. (2017). "Optimization of stored energy dispatch for concentrating solar power systems." Doctoral Thesis. Colorado School of Mines, Golden, Colorado. Chapter II, pp. 19-45. URL: https://dspace.library.colostate.edu/handle/11124/171000.

For work that builds substantially upon or is derived from the open source project, the preferred citation is:

Wagner, M.J. (2018). "SolarPILOT Open-Source Software Project: github.com/NREL/SolarPILOT." Accessed (dd/mm/yyyy). National Renewable Energy Laboratory, Golden, Colorado.

solarpilot's Issues

Receiver acceptance angle for flat plate

The angular min/max boundaries specified on the solar field page only currently work for external cylindrical receivers. Flat plate and multi-receiver configurations should also support this.

Update SolarPilot cost

I would like to know if there is a database or more recent value for the economic part. Because the values that I have in my versione seems quite old. Hope to see some useful link in the comments :)

Segfault in CoPylot when defining multiple receivers

I am running SolarPILOT via CoPylot. My python kernel crashes when I run the following:

cp = CoPylot() 
r = cp.data_create()
cp.api_callback_create(r);
assert cp.data_set_string(
        r,
        "ambient.0.weather_file",
        "../climate_files/USA CA Daggett (TMY2).csv",
    )
cp.data_set_string(r, "ambient.0.sun_type", "Buie CSR")

#Try from luke
cp.data_set_number(r,'optimize.0.multirec_screen_mult',1.25)
cp.drop_receiver(r,'Receiver 1')
cp.add_receiver(r,'NE')
cp.data_set_string(r, "receiver.0.rec_type", "Flat plate")
cp.data_set_number(r, "receiver.0.therm_loss_base", 0)
cp.data_set_number(r, "receiver.0.piping_loss_coef", 0)
cp.data_set_number(r, "receiver.0.peak_flux", 100000)
cp.data_set_number(r, "receiver.0.rec_width", 4.6)
cp.data_set_number(r, "receiver.0.rec_height", 4.6)
cp.data_set_number(r, "receiver.0.absorptance", 1)
 
 
cp.add_receiver(r,'NW')
cp.data_set_string(r, "receiver.1.rec_type", "Flat plate")
cp.data_set_number(r, "receiver.1.therm_loss_base", 0)
cp.data_set_number(r, "receiver.1.piping_loss_coef", 0)
cp.data_set_number(r, "receiver.1.peak_flux", 100000)
cp.data_set_number(r, "receiver.1.rec_width", 4.6)
cp.data_set_number(r, "receiver.1.rec_height", 4.6)
cp.generate_layout(r);

It is not timing out, so I think this is a C++ segfault issue. I can run the equivalent case with a single receiver.

Visualization of land boundaries

See images below. The first image correctly shows the default land boundaries (-180° to °180°) with the correct radial limits.
For the second image, the land boundaries have been changed to (-175°,+180°). However, the plot shows them as if they were (-180°,-175°).

Conversely, the land boundaries for (-180°,-175°) are plotted as (-175°,+180°) (not shown).

This error only appears in the 'Land Boundaries' plot; heliostats are positioned correctly according to the desired land boundaries.

Performance simulation gauge

The performance simulation gauge tends to freeze after being clicked, or especially when F6 is pressed from a page other than the performance simulation page. This issue appears only on Linux, as far as I can tell.

Parametrics efficiency drops after running more than 200 different variations

I'm trying to simulate different field layouts with around 8 variables at max 3 levels, and my total variation count is around 6500. I've tried to assign more CPUs to the process, but it doesn't get beyond 12% of CPU usage. It also goes really fast for the first 200 or so variations, then slows down to about 1/10 of the speed.

If I am using too many variations I'm happy to cut it down, but maybe is there a way to increase the processing speed? Is there a max limit to the number of variations that SolarPILOT is capable of handling?

High CPU when idle

On Linux, SolarPILOT maxes out CPU when idly sitting on an input page. Only certain pages (input forms) are prone to this problem.

Installation requires file stapi.h - file not found

When installing in Ubuntu 18, went through all previous steps, went through to calling make in /spt_dev/SolarPILOT/build_linux, received the following error:

In file included from ../../ssc/solarpilot/SolarField.h:57:0,
                 from ../../ssc/solarpilot/Flux.cpp:56:
../../ssc/solarpilot/interop.h:63:10: fatal error: stapi.h: No such file or directory
 #include "stapi.h"
          ^~~~~~~~~
compilation terminated.
<builtin>: recipe for target 'Flux.o' failed
make[1]: *** [Flux.o] Error 1
make[1]: *** Waiting for unfinished jobs....
In file included from ../../ssc/solarpilot/SolarField.h:57:0,
                 from ../../ssc/solarpilot/Financial.cpp:55:
../../ssc/solarpilot/interop.h:63:10: fatal error: stapi.h: No such file or directory
 #include "stapi.h"
          ^~~~~~~~~
compilation terminated.
<builtin>: recipe for target 'Financial.o' failed
make[1]: *** [Financial.o] Error 1
In file included from ../../ssc/solarpilot/SolarField.h:57:0,
                 from ../../ssc/solarpilot/LayoutSimulateThread.h:54,
                 from ../../ssc/solarpilot/AutoPilot_API.cpp:58:
../../ssc/solarpilot/interop.h:63:10: fatal error: stapi.h: No such file or directory
 #include "stapi.h"
          ^~~~~~~~~
compilation terminated.
<builtin>: recipe for target 'AutoPilot_API.o' failed
make[1]: *** [AutoPilot_API.o] Error 1
virtual memory exhausted: Cannot allocate memory
<builtin>: recipe for target 'definitions.o' failed
make[1]: *** [definitions.o] Error 1
make[1]: Leaving directory '/home/sarah/spt_dev/SolarPILOT/build_linux'
Makefile:2: recipe for target 'all' failed
make: *** [all] Error 2

In the instructions it says that building SolTrace is optional, so I didn't build it. Would like to know where stapi.h is so that I can install.

Parametric performance inconsistency

Parametrics analysis appears to not account for multiple heliostat templates used in field layout.

To reproduce error:

1. Import a field that consists of two different heliostat templates. (This requires setting up two heliostat templates. In the user example, they had two heliostats with different focal lengths.)
2. Run "Performance Simulation"
3. Save results
4. Run "Parametrics" with using the same "fluxsim: Hour of the day" as the "Performance Simulation"
5. Compare results

From the example the user provided, the biggest difference appears in the image intercept efficiency.
Performance Simulation: 10.03 %
Parametric: 8.68 %

It is expected that these two work flows would provide the same results.

The Parametric resulting image intercept can be reproduced by setting all heliostats to the first template. The heliostat template value must be being reset somewhere in the workflow.

Parametric table error with no sun

When an hour with no sun (such as 1am) is simulated in the "parametric simulation setup" then the whole parametric table gives an error.

A bug when doing paramatrices calculation

When doing paramatrices calculation, I set the variable with a financial variable and keeping the heliostat layout unchanged, but in the result, it shows a little difference with the peak flux.

1. And this happens no matter which design variable.
2. If I set the aiming strategy as "single point", there would be such a problem. This happens only when I set the aiming strategy as "image size priority".
   Here is the model file I use:
   ParametricesError.zip

CoPilot API is lacking a load .spt file functionality

CoPilot API and therefore CoPylot API is missing the function to load in .spt files. This function should be added to enable users the ability to load in SolarPILOT UI files to improve the CoPylot interface.

UI crashes after script window closed

If a new script window is opened and then closed, the program crashes if any simulation or layout is attempted. This is due to the progress callback being assigned to the script window and then never returned to the program's built-in callback after the script window is destroyed.

Site Improvement Cost

It seems that "Site Improvement cost" is not taken into account in the Total Direct cost.

The following image is an example of how forcing he rest of the direct cost variables to 0, total direct cost is 0 when site improvement cost is not.

Selection of heliostats on field plot by group

When inspecting individual heliostat performance on the Layout Results page plot, users must right click each heliostat in order to add it to the results table. It would be better to have an option to select a region of heliostats within a rectangle or circle, or by drawing a shape that contains the heliostats of interest.

Heliostat field losses energy balance problem

SolarPILOT calculates energy losses for each heliostat, including:

1. Cloudiness loss
2. Shading loss
3. Cosine loss
4. Mirror reflection loss
5. Blocking loss
6. Attenuation loss
7. Intercept loss
8. Receiver reflection loss

Each loss is expressed as an efficiency, and the order in which losses are calculated as efficiencies is important to understanding the relationship between efficiency and power loss. The order in the above list indicates the order in which the losses are calculated. The power loss at each step is affected by those items "upstream" (i.e., with lower index numbers) such that increased mirror reflection loss, for example, reduces the power associated with blocking, attenuation, intercept, and receiver reflection.

The current method for calculating individual heliostat efficiency and the power at each loss step is correct. However, the method used to calculate field-wide losses is incorrect. Each loss is taken as the mean across all active heliostats. The product of the mean values of all losses does not reproduce the total field efficiency, even though the total heliostat field efficiency is accurately calculated by taking the mean total efficiency for all heliostats.

To accurately calculate field-wide individual losses, the power associated with each loss mechanism must be summed and divided by the total power remaining at the "inlet" to the loss.

In this equation, the total field-wide power loss associated with mechanism 'j' (from list above) is equal to the quotient of the summation of power loss from mechanism 'j' across all heliostats 'N' divided by the difference of (i) the sum of incident power on all heliostats and (ii) the double summation of all prior losses from 'j-prime' equals 1 to the preceding loss at 'j-1'. The total field efficiency is then accurately calculated by taking the product of all losses 'J':

Crash when rendering field plot for specific case

SolarPILOT crashes when attempting to render the field performance plot for the attached case file. The issue seems to be related to incorrect pointer addresses for the child nodes in the binary search tree. The plot uses the search tree to determine the closest heliostat to a mouse click. The code is based on the SolTrace binary tree, not the SolarPILOT zonal tree.

Oddly enough, the same case file works with 12.2x12.2m heliostats, but crashes when 8x8m heliostats are used.

crash-case.zip

Linux control focus

When running on linux machines (Ubuntu 14.04, 16.04, Mint), SolarPILOT UI input controls stop working after switching between pages. The control can still accept text entry or dropdown selection, but does not display the change until switching back and forth between pages or forcing redraw by maximizing the window.

I have confirmed this issue using native builds and distributions.

Better interaction with heliostat field plot

Develop methods for mouse interaction with plotted heliostats. Display ID, data, dimensions, etc. Allow selection and addition/removal of heliostats from the layout.

See https://github.com/NREL/SolarPILOT/tree/feature-plot-interact

Report estimated annual efficiency

After layout, it would be useful to report the total field annual efficiency (estimated) and the annual efficiency of each heliostat. This can be estimated from the sample of layout sun positions that are simulated. It would also be nice to do a DNI-weighted efficiency (essentially annual production) to give a better picture of which heliostats are actually contributing the most or least throughout the year.

Flux constraint on multiple receivers

The optimization routine enforces a maximum allowable flux constraint on the receiver surface. This works as expected for a single receiver, typically ensuring that the max flux constraint isn't significantly violated during optimization.

The maximum flux constraint is not working correctly for multiple receivers, as it only limits flux for the first receiver and allows the remaining receivers to exceed flux. The flux constraint should apply independently to all receivers and take into account the specified max flux limit on each receiver page. The COBYLA algorithm uses a linearized constraint approximation and makes use of estimated slack between the current flux and the flux limit to proceed through iterations.

Script window messages not appearing

Messages issued from script methods are not appearing in the script window log.

Installation require LKD_LIB LK_LIB, the variables are used in the project but set to NOTFOUND

When installed and went through the steps, after type in cmake -G "Visual Studio 16 2019" -DCMAKE_CONFIGURATION_TYPES="Debug;Release" -DCMAKE_SYSTEM_VERSION=10.0 -Dskip_tools=1 . in cmd

Occured following errors

CMake Error: The following variables are used in this project, but they are set to NOTFOUND.
Please set them or make sure they are set and tested correctly in the CMake files:
LKD_LIB
linked by target "wexsandbox" in directory C:/YS Program/solarpilot_dev/wex/tools
LK_LIB
linked by target "wexsandbox" in directory C:/YS Program/solarpilot_dev/wex/tools

-- Generating done
CMake Warning:
Manually-specified variables were not used by the project:

skip_tools

CMake Generate step failed. Build files cannot be regenerated correctly.

I tried many times and installed in different computers, same errors appeared. Really appreciate if anyone would teach me how to solve this.

'st_optic' function does not take 18 arguments

When I build CoPILOT in Windows following the wiki steps, at the 8th step (Build SolarPILOT.dll), I’ve got the following error:
'st_optic' function does not take 18 arguments

Something similar happens when I built SolarPILOT in windows at the 8th step.

Any idea why it happens?

CSP Adjustment

Good Day Sir or Madam. I was wondering the results of tampering with the settings in the tool tab. Does it increase the speed of simulation-parametric analysis? Does it change the outcomes somehow?

Variable reference in scripting language

The process for locating the variable ID in the script language is not clear, and variables are not easily accessible from the script window. A variable reference dialog of some type should be added to the script window that gives a listing of all variables, their ID, and a brief description. It would also be nice to insert variables directly from the dialog.

Image assets missing from source distribution

The images assets that are supposed to be in the exelib/ directory don't appear to be checked into the git repository, and I don't see any documentation saying where to download them.

Multiple receiver flux uniformity

In systems with multiple receivers, we observe that minor differences in efficiency among heliostats lead to systematic receiver aimpoint assignments that cause larger images to hit a single receiver, smaller to hit another, and so on. While this solution to the aimpoint optimization problem is the optimal solution, it is not always practical, as receivers in a single system often require consistent flux profiles among all receivers.

For example, the following 3 receiver flux profiles are drawn from a system with identical receiver geometry but with slight displacement of 2 receivers on the z axis. Images are in order - Top, Middle, Bottom

The aimpoint strategy for this field gives evidence as to the difference between receivers:

A strategy should be implemented that modifies heliostat assignments to encourage more consistent flux results among receivers.

Cosine overwitten by intercept in _detail_results

Just found this in the text while browsing the source for intercept calculation methods.

https://github.com/NREL/SolarPILOT/blob/develop/app/scripting.cpp#L709

            p.hash_item( "cosine", H->getEfficiencyIntercept() );
            p.hash_item( "intercept", H->getEfficiencyIntercept() );

Enhanced flux control for multiple receivers

The current approach for determining which heliostats point at which receiver in the case of multiple receivers is too simplistic. Specifically, the heliostat-to-receiver view factor is calculated for each receiver, and the heliostat is assigned an aim point on the receiver with the greatest view factor.

Rather, we would like to have a method for specifying the desired fraction of power delivered to each receiver, and a method for optimizing which heliostats then deliver that power, maximizing overall optical efficiency while maintaining flux limits on each receiver.

A related issue is that current flux aiming algorithms are not providing accurate results during performance simulation using the analytical engine. This is likely a bug. The issue can be reproduced with the attached case file.

Differences in intercept efficiency when using the Hermite approximation vs. SolTrace

The reported intercept efficiency from the SolTrace flux simulation model is higher than that predicted by the Hermite method for the cylindrical receiver type. The difference can be substantial for very small fields and small receivers. The cylindrical receiver setup in SolTrace includes both the cylinder and a bottom "blocking" surface to prevent rays from entering the interior of the cylinder. Currently all rays that hit any surface in the receiver stage are being counted toward the intercept efficiency, and thus the rays intercepted by the bottom blocking surface are leading to an artificially high reported intercept efficiency when using the SolTrace flux simulation model. If only rays that hit the cylinder surface are counted, then the SolTrace intercept efficiency matches the Hermite method very closely.

Angular land boundaries not working for flat plate receivers

The heliostat field does not seem to respect the land boundaries. In this example the limits are (-60, 60 degrees). The receiver is planar and aimed down -50 degrees.

Temporary workaround

The field limits appear only to be working for the cylindrical receiver option. As a temporary workaround, create a constraining polygon in addition to the radial bounds that cuts off the field at +/0 the desired deg. The settings on the Layout Setup page might look something like the following for the 60deg example:

User-defined focal lengths not working

The focal length for heliostats can be specified by the user on the heliostat template page(s). Doing so currently does not produce any effect, as it appears the slant range is always used for each heliostat. For example, the following parametric on user-defined focal lengths with a single focal length in X and Y produces:

Mac version

Hello,

I'm not sure this should be classified as an issue but found nowhere else to post it so here it goes.

Is there any chance of a SolarPilot Mac version?

Thanks,

--
Andre Luiz Tietbohl Ramos, PhD

Layout calculation bug

Field layout and cost values aren't correctly updating after heliostats are removed or added.

Error with power incident on multiple receivers

When running a performance simulation with multiple receivers in "image size priority" mode, one or more receivers often produces an unrealistically low power.

Customize currency units

Feature request: Allow users to specify currency and conversion factor between dollars and alternate currencies for display on the costs page. Possibly allow unit specification for other units.

Performance as a function of wind velocity

Heliostat tracking error (and possibly slope error) increases with wind velocity, so it may be important to capture wind speed during design or performance calculations. The interface should be modified to allow specification of relevant error mechanisms as a function of wind velocity, and take specification of wind velocity as an input on the performance simulation page. Data exported to SAM might also be modified to include some functional dependence on wind velocity, with a form TBD.

Improvements to optimization log

A couple of improvements to the log window on the optimization would improve functionality.

1. Optimization logging

Optimization iterations are only reported in the optimization log. When (gasp!) the program crashes during optimization, all progress and optimization results are lost. The user may wish to echo optimization progress to a hard file in addition to live reporting in the window.

2. Better log formatting

Log readability would be improved with consistent column widths between the variable label line and the iteration data lines.

Plot info not rendering correctly on Windows

Feature for #7 works on Linux, not on Windows. Rendering of special characters (newline, tab) is messed up.

More heliostat layout methods

There are quite a lot of heliostat layout methods in research papers, for example, biomimetic methods that organize the heliostat like a sunflower(https://www.sciencedirect.com/science/article/abs/pii/S0038092X11004373). It might be more helpful if solarPILOT allows users to define a new layout method or includes more layout methods as options.

Using SolarPILOT in Matlab through CoPylot

CoPylot can be used directly in MATLAB through the MATLAB API for Python which is embedded in the software since version R2014b. If you are accessing from Windows, you will need to acquire a Python interpreter which has to be compatible with your version of MATLAB. The easiest way to do that is to download the installer from python.org. The Mathworks website is full of information about that. If you are on a Linux® or Mac platform, you already have Python installed but you should be careful to have the MATLAB compatible version.
Once Python is installed, you can check which version of Python MATLAB has selected to use. In your MATLAB shell type:

>> pe=pyenv

If you already have several copies of Python on your computer, then you can tell MATLAB which one you want it to use by passing the absolute path to the python executable or the version you want to pyenv. For example:

>> pe=pyenv('Version','3.8') 

Depending on your Python installation, you may need to install some additional Python libraries from the PYPI package index such as for example Pandas. The easiest way to do it is through the Python pip program. Type in your MATLAB shell:

>> pypath=char(pe.Executable);
>> system([pypath,' -m pip install pandas']);

Now, you are ready to use CoPylot. In MATLAB shell, the only thing you need is call it through py. operator:

>> cp=py.copylot.CoPylot();

This instruction works when the copylot.py and solarpilot.dll are in the current working folder. If this is not the case, you have to tell Python and CoPylot where these files are located. For example:

>> CoPylot_path='C:\Users\adelacal\source\solarpilot_dev\solarpilot\deploy\api';
>> if count(py.sys.path,CoPylot_path) == 0
      insert(py.sys.path,int32(0),CoPylot_path);
   end
>> cp = py.copylot.CoPylot(path=CoPylot_path);

After this, we can use CoPylot exactly in the same way as we would in Python. Note that the minimum example requires the TMY file to be passed.

>> r = cp.data_create();
>> TMY_file="C:\Users\adelacal\source\solarpilot_dev\solarpilot\deploy\climate_files\USA CA Daggett (TMY2).csv";
>> cp.data_set_string(r,"ambient.0.weather_file",TMY_file);
>> cp.generate_layout(r);
>> field = cp.get_layout_info(r);
>> cp.simulate(r);
>> flux = cp.get_fluxmap(r);
>> res= cp.summary_results(r);
>> eff=res.get('Solar field optical efficiency')
>> cp.data_free(r);

You must remember that you are running Python code in MATLAB so the inputs and outputs are Python variables. Floats and strings are the same variables on both platforms, but everything else must be converted if you want to use it. There are numerous examples of how to do this in test_script.m

AutoPilot::Optimize function does not take 6 arguments

When building SolarPILOT in Windows through VS 2017, getting error code C2660 from the following files:

• GUI_OptimizationPage.cpp, line 335 and line 373
• scripting.cpp, line 885 and line 913

Build fails after these two errors.

Is this an issue with the previous files or is this a patch issue. Trying to install latest patch to fix the crashing error for SolarPILOT layouts.

Load SolarPILOT field performance error

Bug description:
If an user:

1. Generates a solar field
2. Saves the file
3. Closes SolarPILOT
4. Reopens SolarPILOT
5. Loads previous made file (in step 2)
6. Simulates performance
   The receiver flux profile generated in step 6 differs slightly to that if the user generates a solar field and simulates performance without the steps outlined above.

Benchmark difference: (using SP default parameter values)

Flux Profile when field is generated then simulated:

System Summary Table

Flux Profile generated using steps 1-6 above:

System Summary Table:

• Highlighted values are discrepancies between generate then simulate method above.