CSP Trough - weather file adaption (.epw file)

Hello,

My ambition (first step) is to implement my own weather data into a running .epw file to simulate a CSP Trough Plant.
I downloaded a file from CapeTown which works fine (btw: i didnt change any power plant modifications at all).

What I did until now:
A): I changed, "ambient Temp", "Dew-Temp" and "Rel. Humidity" --> the simulation worked fine.
: I further figured out (via trial and error principle), that the simulation doesnt need following parameter so i replaced it with 9999:
"Extra-terrestrial solar radiation",
"Extra-terrestrial direct normal solar radiation",
"DHI" --> the simulation worked fine.
C): I didnt change Windspeeds and winddirection so far. --> the simulation worked fine.

Including all those adaptions, the file works well and computes very similar results as before (just bec temp were different).

As soon, as i change GHI and DNI to 'my' hourly based GHI and DNI data, it doesnt work anymore. SAM accepts the file itself but cannot simulate. After about 35% it gives me following error message:
_______________________________________________

MSG[0]: SVAL LOOKUP ERROR trnsys.user_trdsrc
MSG[1]: SVAL LOOKUP ERROR trnsys.user_exe_deck_enabled
MSG[2]: SVAL LOOKUP ERROR trnsys.user_exe_deck_enabled
MSG[3]: SVAL LOOKUP ERROR trnsys.user_exe
MSG[4]: SVAL LOOKUP ERROR trnsys.user_args
MSG[5]: TrnModel::ReadOutput[ncol=72 nalloc=8760 lnchars=3800] = 205 msec
MSG[6]: TrnModel::ReadOutput[ncol=24 nalloc=12 lnchars=2400] = 1 msec
MSG[7]: TrnModel::ReadOutput[ncol=20 nalloc=2 lnchars=1800] = 0 msec
MSG[8]: SVAL LOOKUP ERROR trnsys.target_hourly_folder
MSG[9]: TrnModel Notice: Deleting file 'C:/Users/Sebastian/AppData/Local/SAMEXE/SAMEXE-Sebastian-INST1-2012.11.30/simdata/My_project/BASE/trough.hourly.out'

MSG[10]: BADTYPE OUTPUT system.annual.gross_electric_generation
MSG[11]: BADTYPE OUTPUT system.annual.e_net
MSG[12]: BADTYPE OUTPUT system.annual.q_dni_on_sf
MSG[13]: BADTYPE OUTPUT system.annual.qsf_nipcosth
MSG[14]: BADTYPE OUTPUT system.annual.sfavailableenergy
MSG[15]: BADTYPE OUTPUT system.annual.qsf_abs
MSG[16]: BADTYPE OUTPUT system.annual.qsf
MSG[17]: BADTYPE OUTPUT system.annual.q_to_pb
MSG[18]: BADTYPE OUTPUT system.annual.qsf_pipe_hl
MSG[19]: BADTYPE OUTPUT system.annual.qsf_hce_hl
MSG[20]: BADTYPE OUTPUT system.annual.q_tes_full
MSG[21]: BADTYPE OUTPUT system.annual.q_tes_hl
MSG[22]: BADTYPE OUTPUT system.annual.q_turb_su
MSG[23]: BADTYPE OUTPUT system.annual.fuel_usage

...

*** Notice at time : 0.000000
Generated by Unit : Not applicable or not available
Generated by Type : Not applicable or not available
Message : The TRNSYS Executable (TRNExe.exe) and main DLL (TRNDll.dll) are located in "."

*** Warning at time : 30.000000
Generated by Unit : 2
Generated by Type : 15
Message : The calculated value of the beam radiation exceeded the maximum possible beam radiation for this timestep. The beam radiation has been set to the extraterrestrial radiation for this timestep.

...

*** Warning at time : 2840.000000
Generated by Unit : 2
Generated by Type : 15
Message : The calculated value of the beam radiation exceeded the maximum possible beam radiation for this timestep. The beam radiation has been set to the extraterrestrial radiation for this timestep.

*** Fatal Error at time : 2840.000000
Generated by Unit : Not applicable or not available
Generated by Type : Not applicable or not available
TRNSYS Message 450 : The maximum number of warnings allowed per simulation has been exceeded. Please fix these warnings or increase the limit on the number of warnings allowed per simulation (LIMITS command)
Reported information : Not available

*** Simulation stopped with errors
Total Notices : 1
Total Warnings : 401
Total Fatal Errors : 1
_______________________________________________

I compared GHI and DNI in the well performing time series data to "my" one to make sure, that GHI is not 0 while DNI is >0 and to see irregularities but the dataset was quite similar.

So I am very sure that GHI/DNI is responsible for the error but i have no idea what the reason therefore can be.

(just that you know... I modified everything with excel but i changed the semicolons etc in a right way - that cannot be the problem)

It would be great, if you could help me !

Thanks a lot
Regards
Sebastian

Hi Sebastian,

That message most likely means that the DNI value in your weather data for more than 400 time steps is greater than the extraterrestrial radiation value that SAM's radiation processor calculates as a check to make sure the solar radiation data is within the range of possible values. We've seen this with other weather data sets where the DNI value in the first hour of the day with non-zero solar radiation caused the error.

As it turns out, my colleagues are coincidentally looking into a similar issue with some of the NREL Solar Prospector data this week. I will let you know if they find out anything that might help you here.

Have you checked your data with SAM's flat-plate PV model? The PV model can often read weather data that the CSP models cannot, which might be helpful as you troubleshoot your data.

Sorry I could not be more helpful.

Best regards,
Paul.

Hi Paul,

How can the error message tell me that only DNI is greater than the calculated extraterrestrial radiation, if GHI values can be even greater than DNI?

My data was often used for other applications and it seems to be quite reliable. How can it not match with the calculated extraterr. radiation?

can i set the extraterrestrial radiation to a higher value to avoid this problem (maybe SAM won't calculate it with its radiation processor anymore)?

As you said:
I added DHI to be able to simulate PV issues (now the file includes GHI, DNI, DHI). [Btw: No extraterrestrial values were necessary (i replaced it with 9999)]

Then I checked it with SAMs
-->flat-plate PV model,
-->CSP Molten Salt PT and
-->CSP Lin. Fresnel
and it works fine.
Although i cannot really draw a solution...

Thanks a lot for your effort!

Best regards,
Sebastian

Hi Sebastian,

Can you check the DNI values for a sample of the hours listed in the error message to see a) whether they are unusually high, and b) whether the hour of day is consistently the same (e.g., 11 am, noon, etc.)?

In the current version of SAM, the CSP performance models in SAM use different radiation processors than the PV models. (The radiation processor is code that calculates the radiation incident on the collector from the data in the weather file).

I'm working with the developers on this issue.

Thanks,
Paul.

Hi Paul.
My supervisor helped me to solve it.
The problem was that I obviously used GMT +2 for South Africa but the data (GeoModel) is adjusted to GMT 0. And thats maybe the reason why SAMs radiation processor compared its calculated values with 0 & too lagre DNI values at the beginning and end of the day.
Thanks for your efforts!!
Sebastian

Hi Sebastian,

That is good to know.

In our investigation of a similar issue with some of the TMY2 files in the Solar Prospector data (for U.S. locations), we discovered that a problem in the file's header caused the radiation processor to read the latitude and longitude values incorrectly.

The lesson here is that if you are creating weather files to use with SAM, you should pay special attention to the formatting of the header and to the values for latitude, longitude, and time zone.

Best regards,
Paul.