Project Report 1

REFRIGERATION ENERGY USE IN THE FOODCHAIN

PROJECT REFERENCE (TBA)

CONTRACT REFERENCE (TBA)

by

Professor John MissendenProfessor Graeme Maidment,

Professor Ian W. Eames

Department of Engineering SystemsLondon South Bank University

SummaryThis report summarises the research so far carried out by the LSBU team intothe 'Food Chain Refrigeration Energy Use ' project during months 1 to 3.

17th Aug 2006

1

1. Introduction

A project objective for LSBU is to develop steady state refrigerationsystem models to test (and optimise) various refrigeration systemsused in the industrial production chain for food. Prior to modellingsystems it was important to determine what software platforms areavailable that might be used or adapted for the purpose of the project.This report describes the results of a study into some proprietarysoftware packages and clarifies a specification for the 'model'. Thereport goes on to outline the LSBU team's work on component andsystem modelling.

2. Software Specification

Before going on to look at the various types of package available itwas necessary to record what would be required from the software. Ofparticular importance is a target user profile, which must beestablished. The LSBU team's draft specification for the software isincluded in Appendix A to this report.

3. Software Development Platform

Experience shows that most refrigerator systems manufacturers havetheir own design software, produced in-house and which, forcommercial reasons, would be unlikely to be available to the projectfor further development. Also, it is likely to be 'case specific'.

An internet search, using keywords such as 'refrigerator designsoftware' and variations on this theme, has so far returned nothingdirectly suitable. Plenty of packages for industrial (aesthetic) designof refrigerators were found. Also, the search brought up heat transferand fluid dynamics packages, such as 'Fluent' but nothing on systemsdesign.

Several university centres have produced system design packages,which can be purchased or licensed.

A good example of such a package is COOLPACK, which is a softwaredeveloped at the Danish Technological University. This is a welldeveloped programme. The demonstration copy examined provided a

2

useful tool for single-stage compression, single-evaporator systems.The software provides a HELP facility and includes some informationon the modelling theory. The 'lump-parameter' dynamic simulationmodel was found to be simplistic. No account was taken of theexpansion device or variations in component efficiencies at part-loadconditions. The models are almost entirely based on theory with littleopportunity to input real component data. However, the softwareprovides many useful subroutines for design-point analysis. Theversion looked at may have been a few years old.

University of Valencia's Advanced Refrigeration Technologies (ART)refrigerator design software was also investigated. The copy lookedat was a demonstration version. This provided design-point analysisof a single-stage compression, single evaporator/condenser circuitonly. The software is well presented but provides little informationon the modelling assumptions, unlike COOLPACK. From thedeveloper's website it appears that 'professional versions' of thesoftware are available for purchase.

A further example is RADS. This package was developed at MasseyUniversty in New Zealand. It is based on a database structuresurrounded by 13 sub-programs which perform the calculations.RADS is a essentially a steady state model and therefore isunsuitable for our purpose.

The demand for software that is specifically intended for designingrefrigeration systems is probably very small and therefore has notbeen taken up by the major software houses. Software which isavailable will be coming out of university departments (e.g.COOLPACK and ART). Consequently the support for this software islikely not to be very strong. Also, the source code for this deignpackages is unlikely to be made available to this project. Therefore, ifthe project team ever wishes to modify the model's software it couldnot do so. Therefore, the use of a more flexible proprietarythermofluid system simulation platform, such as TRANSYS orPROTISS, on which to build the teams own model was examined.

TRANSYS is a general thermo-fluids system modelling package,which enables a user to model refrigeration systems including theheat source and sink characteristics both dynamically and at steady-state. The user interface consists of drop-down menus listing icons

3

representing components, such as pumps, valves, compressors,expanders and heat exchangers. Using 'drag-drop' these icons arepositioned on the 'design-screen' and connected by arrow headed linesto illustrate relationships between components. The programmeallows individual component models to be developed and this includesthe use of manufacturer's data as well as theoretical models.However, users are required to process manufactures data (outsideTRANSYS) into a form that the program can accept.

PROTISS was developed by Simulation Science Inc for the chemicalsindustry. It is a similar system analysis platform to TRANSYS andprovides a large data resource library of thermodynamic propertiesconnected to both dynamic and steady state models of componentsand processes used in the chemicals industry. The general nature ofthe software requires the user to have a good working knowledge ofthe platform for it to be useful.

The team considered that both TRANSYS and PROTISS are notsufficiently intuitive in their use. This would cause problems forcasual or occasional users who are not sufficiently familiar with theTRANSYS 'platform', and this would be unsatisfactory. It is probablethat the software would not integrate easily with existing models,(e.g. CoolVan and CoolRoom) and therefore, for the presentapplication neither TRANSYS or PROTISS would be unsuitable.

The relative merits of Visual Basic and Visual C++ were discussed aspotential platforms for the development of the software. Both areMicrosoft products, which are well developed and supported. Both canbe used to produce software packages with professional WINDOWSscreens with all their usual functions. Both platforms are able tointeract easily with other MS WINDOWS products, such as OFFICE.Also, software developed using both these platforms can bedistributed easily as compiled versions on CD-ROM, DVD or over theinternet. At this time Visual C++ is used by many softwarecompanies to develop professional software, because it is thought tobe more 'code' efficient. However, Visual Basic is thought to be ableto provide more intuitive user interfaces for software products. If it isdecided to develop an in-house software, rather than use of modifyanother's, then either V-Basic or V-C++ would be suitable platforms.

4

4. Modelling

During the current period the LSBU team have investigating theliterature on modelling refrigeration components and systems. Ofparticular interest to this investigation were: (a) multi-evaporatormulti-temperature systems, (such as those found in display cabinets),(b) multi-stage compression (c) component efficiencies, (d) dynamicmodelling, (e) defrost, (f) component wear, all of which are ofparticular interest to the project. Appendix B lists the range ofrefrigeration systems that a utility software program must be able tosimulate, both in steady-state and dynamically.

5. Component Studies

Steady-state and dynamic models of compressors, heat exchangersand expansion devices have been developed. As part of this study apreliminary investigation of the performance of common refrigerants,compressors and heat exchangers has been undertaken. Thefollowing diagrams summarize the findings so far.

0

0.1

0.2

0.3

0.4

0.5

0.6

0.7

0.8

0.9

1

1 1.05 1.1 1.15 1.2 1.25 1.3

Tc/Te (K/K)

Car

not

Eff

icie

ncy

R407C

R404A

R407A

R134A

Propane

Isobutane

Ammonia

Linear

Tc ranging from 30C to 50CTe ranging from -40C to +20C

Figure 1: Showing the comparative performanceof common refrigerants

5

0.4

0.45

0.5

0.55

0.6

0.65

0.7

1 1.05 1.1 1.15 1.2 1.25 1.3 1.35 1.4 1.45

Cycle temperature ratio (Tc/Te) (K/K)

ise

ntr

op

icef

fici

enc

y

100 kW, Tc = 50 C 100 kW Tc = 40 C100 kW Tc = 30 C 30 kW Tc = 50 C30 kW Tc = 40 C 30 kW Tc = 30 C7 kW Tc = 50 C 7 kW Tc = 40 C7 kW Tc = 30 C 2 kW Tc = 50 C2 kW Tc = 40 C 2 kW Tc = 30 C

Figure 2: Showing the variation in isentropic efficiencywith cycle temperature ratio for a range of reciprocating

compressor operating on R404A

0

0.1

0.2

0.3

0.4

0.5

0.6

0.7

0.8

0.9

0 100 200 300 400 500 600 700 800 900 1000

heat rate (kW)

con

dens

eref

fect

iven

ess

(-)

Series1Series2Series1water-cooled 6-passwater cooled 3-passair-cooled residential rangeair-cooled quite rangeair-cooled standard range

Figure 3: Showing the variation in heat exchangeeffectiveness with heat rate for a range of water and air

cooled condensers

6

6. Conclusions

The following conclusions came from LSBU preliminary study:

1) From the study it is concluded that there are very fewproprietary refrigeration system design packages on themarket. Those which exist appear to have come from universitydepartments.

2) Packages which exist do not appear to have all the systemsconfigurations and sophistications that the project will require.Therefore, the source code would require modification if any ofthese packages is to be of use to the project. This would only bepossible if the developers would provide the LSBU team withsource code. As it is unlikely that the source codes would bemade available then it is proposed that the project uses a moreflexible proprietary platform.

3) Whatever platform package is used to develop the refrigerationmodel software it must have a strongly intuitive and flexibleuser interface. This is important if the software is to be easilyaccessible to the casual or non-expert user.

4) At this time the LSBU team prefer the VBasic platform.However, the final choice can only be made when moreinformation is available on project partners' software, withwhich the proposed system models must integrate.

5) A draft specification for the model has been developed. This islisted in Appendix A.

6) A range of typical refrigeration systems has been identified.These are summarized in Appendix B.

7) A preliminary investigation of component models has beenundertaken and the collation of refrigerant and componentmanufacture's performance data has been carried out.

7

Appendix A

FRIDGE-Soft Specification

This specification is presented in no particular order and none shouldbe inferred.

Specification Comments1. Interface seamlessly with softwarepackages being developed by other partners.

Possibly using ActiveXor similar interfacecontrol

2. A professional WINDOWS interface toinclude all the usual features: SAVE,OPEN, SEARCH, LIST, HELP, PRINT,'WHAT-THIS-KEY' and so on

This should not restrictusers to PC systems.

3. Special TOOLS features to assist inproducing charts, tables and flow diagramsfor report writing.

4. Theoretical models of componentsincluding:

Compressors (screw, scroll andreciprocating types)

Condensers (water cooled, wet and dryair cooled)

Evaporators(flooded and directexpansion) (liquid cooling and aircooling)

De-superheaters Receivers Expansion devises (all common types) Refrigerant fluids (all common types) Oil scavenge systems Solenoid valves Filters and driers Service valves Fans and pumps Pipe work, (including fittings where

necessary)

By 'common type' it ismeant to refer to thosecomponents usuallyfound in foodrefrigeration andchilling systems

8

5. The Software will be able to acceptcomponent manufactures data (please referto the above list of typical components)andprocess this information into a form that E-Soft can use in its models and store theinformation for use by the Model

6. Users will be able to construct systemmodels from icon menus of individualcomponents and/or a list of manufacturer'scomponents.

7. Users will be able to select eithertheoretical models of individualcomponents, based on theory ormanufacturer's data, or any mix of these.

8. The Model will check the User'scomponent selection and the system theyare designing and provide error traps toensure the logic of both the componentarrangement and input data. This willensure that the Model is robust.

9. User's will have the option of selectingeither steady state or dynamic performancepredictions.

10. Outputs will include thermodynamicstate properties around the cycle as well asenergy/power values.

11. Users will be able to select output datain both tabular and graphical formats andcopy these outputs to MS WORD or otherMS OFFICE media, such as PowerPoint.

Appendix BRefrigeration System Diagrams

1 2

10

3 4

56

11

7 8

9

12

10

11