Solar-thermal system modelling: Difference between revisions
Jump to navigation
Jump to search
No edit summary |
No edit summary |
||
| (2 intermediate revisions by the same user not shown) | |||
| Line 5: | Line 5: | ||
* [[data reader]] for TMY2, TMY3, CSV weather data files | * [[data reader]] for TMY2, TMY3, CSV weather data files | ||
* [[calculation of sun position]] by NREL, Grena and Duffie & Beckman algorithms. | * [[calculation of sun position]] by NREL, Grena and Duffie & Beckman algorithms. | ||
* power cycle models: Rankine cycle {{src|models/johnpye/fprops/rankine_fprops.a4c}} and also [[CCGT]] models. More | * power cycle models: Rankine cycle {{src|models/johnpye/fprops/rankine_fprops.a4c}} and also [[CCGT]] models. More detailed model would still be helpful. | ||
* we have reviewed the [http://energy.sandia.gov/?page_id=6530#tab1 SOLERGY] tool from Sandia National Labs (see [[Media:Solergy-callgraph.png]]), and started some work on converting it to Python. With a bit more work, it might be possible to connect Python SOLERGY with ASCEND, using detailed component models in ASCEND to calculate performance curves for key components like receiver and power block, then the SOLERGY port to calculate the annual performance. It might even be possible to implement the economic model in ASCEND as well. | |||
Key issues remaining: | Key issues remaining: | ||
* more detailed power block model and/or simplified correlation of power block behaviour as per Patnode<ref name=patnode/>. | * more detailed power block model and/or simplified correlation (eg linear regression models) of power block behaviour as per Patnode<ref name=patnode/>. | ||
* implementation of aspects of control logic including | ** do we need to develop a method for generating the linear regression performance model, somehow? our our power block models efficient/robust enough yet for this? | ||
* implementation of aspects of control logic, including: | |||
** collector off-steer during excess solar gain, | ** collector off-steer during excess solar gain, | ||
** cut-off triggering during low cloud, | ** cut-off triggering during low cloud, | ||
** turbine ramp rate and grid | ** turbine ramp rate and grid synchronisation, | ||
** start-of-day warm-up period. | ** start-of-day warm-up period. | ||
* [[event handling]] as a general feature to aid in the implementation of the above control logic. | * [[event handling]] as a general feature to aid in the implementation of the above control logic. | ||
** need to understand the implications on solver performance of using event handling in this way. | |||
* whether dynamic modelling using the [[IDA]] solver is appropriate for this, or whether we need a new dynamic solver specifically to handle the outer loop for this specific task of annual performance modelling (hopefully not!) | |||
** do we need to extend our derivative routines for [[external relations]] in order the [[IDA]] can work with models that include fluid property calculations, eg [[FPROPS]]. | |||
* some method/interface for entering/important 2D matrix data, eg for optical field efficiency as function of sun position. This could be done via another [[external relation]] potentially (does the code from [http://xongrid.sourceforge.net/ XonGrid] offer us something useful?) | |||
* need models of storage-to-fluid heat exchangers (whether we can increase the flexibility of [[FPROPS]] to a point that {{src|models/johnpye/fprops/heatex_pinch.a4c}} model is useful as-is, or whether something different is needed) | |||
* need to develop receiver models with a range of levels of accuracy | |||
* is there a way to run approximate annual performance by looking at some statistical reduction of the weather data? | |||
Contributors to aspects of this work include [[Vikram Kadam]], [[Ksenija Bestuzheva]], [[Ben Allan]], Emily Do and [[John Pye]]. | Contributors to aspects of this work include [[Vikram Kadam]], [[Ksenija Bestuzheva]], [[Ben Allan]], Emily Do and [[John Pye]]. | ||
Latest revision as of 06:56, 23 October 2014
Some work is underway to tackle solar-thermal system modelling with ASCEND. Our immediate aim is to be able to produce an annual performance model of the SEGS VI parabolic trough system including the sun position, tracking, concentrator, receiver, power block, parasitics and startup/shutdown with cloud transients. We aim to produce a model that can be benchmarked against other solar thermal modelling software under the modelling guidelines of the SolarPACES round 2 'tool cross check'. Much remains to be done, but we hope that the result will be an accurate and fully open-source model that is ready for adaptation by a wide range of users including researchers, students and industry.
Progress so far on this task includes:
- steady-state model of a parablic trough collector models/solar/solar_field.a4l following the approach of Patnode[1]
- data reader for TMY2, TMY3, CSV weather data files
- calculation of sun position by NREL, Grena and Duffie & Beckman algorithms.
- power cycle models: Rankine cycle models/johnpye/fprops/rankine_fprops.a4c and also CCGT models. More detailed model would still be helpful.
- we have reviewed the SOLERGY tool from Sandia National Labs (see Media:Solergy-callgraph.png), and started some work on converting it to Python. With a bit more work, it might be possible to connect Python SOLERGY with ASCEND, using detailed component models in ASCEND to calculate performance curves for key components like receiver and power block, then the SOLERGY port to calculate the annual performance. It might even be possible to implement the economic model in ASCEND as well.
Key issues remaining:
- more detailed power block model and/or simplified correlation (eg linear regression models) of power block behaviour as per Patnode[1].
- do we need to develop a method for generating the linear regression performance model, somehow? our our power block models efficient/robust enough yet for this?
- implementation of aspects of control logic, including:
- collector off-steer during excess solar gain,
- cut-off triggering during low cloud,
- turbine ramp rate and grid synchronisation,
- start-of-day warm-up period.
- event handling as a general feature to aid in the implementation of the above control logic.
- need to understand the implications on solver performance of using event handling in this way.
- whether dynamic modelling using the IDA solver is appropriate for this, or whether we need a new dynamic solver specifically to handle the outer loop for this specific task of annual performance modelling (hopefully not!)
- do we need to extend our derivative routines for external relations in order the IDA can work with models that include fluid property calculations, eg FPROPS.
- some method/interface for entering/important 2D matrix data, eg for optical field efficiency as function of sun position. This could be done via another external relation potentially (does the code from XonGrid offer us something useful?)
- need models of storage-to-fluid heat exchangers (whether we can increase the flexibility of FPROPS to a point that models/johnpye/fprops/heatex_pinch.a4c model is useful as-is, or whether something different is needed)
- need to develop receiver models with a range of levels of accuracy
- is there a way to run approximate annual performance by looking at some statistical reduction of the weather data?
Contributors to aspects of this work include Vikram Kadam, Ksenija Bestuzheva, Ben Allan, Emily Do and John Pye.