Thermotun 프로그램을 사용한지도 어언 9년 정도 되어가는 것 같다.
처음에는 버전 5 를 사용하다 6 으로 7 로 변하였다.
감회가 새로운 것은
이 프로그램의 버그 문제 수정에 대해 3가지 정도 기여했다는 점이다.
이 프로그램은 영국의 던디대학교의 바디 교수가 만든 프로그램인데
터널 시스템내의 공기압 및 열환경 해석에 있어 나름 스페셜한 프로그램이다.
물론 나도 이 프로그램을 잘 다루고 있지만, 아직 부족한 것도 사실이다.
아래에는 이 프로그램의 그간 개발 과정이 담긴 릴리즈 노트를 담았다.
아~ 이 프로그램 배우러 영국 스코틀랜드로 갔었던 일주일간의 추억이 떠오른다.
넓은 들판,, 막 기사가 말타고 튀어나올것 같은 그 들판.
보는 곳마다, 역사가 서려있는 뭐랄까 암튼 분위기 짱.
다시 가고 싶다.
Release Notes: ThermoTun/7.1 & PPNet/1.1
8 October 2015
Bugs
Two bugs have been eliminated. One, in speed?distance Speedsets, caused abrupt failure, but calculations up to that point were unaffected. The other is more important. It caused error in the post?processing calculation of maximum pressure changes in prescribed “comfort” intervals. The internal calculations were not affected, but almost ALL comfort output was incorrect.
11 September 2015
Bugs
Two minor bugs have been eliminated. One was unrelated to calculation routines, but nevertheless had the potential to cause abrupt failure. The other was in the SAVE/RESTORE feature. It caused wagon definitions to be recovered incorrectly even though they were saved correctly.
4 July 2015
Tables
Tables have been enhanced. There are now 4 different types inside the program, although the input process is almost the same for all of them. The initial purpose of the development was to make it possible to output Tabular data in the same manner as other time?history graphs. However, the development has other potential uses that might be followed up at a future date.
15 June 2015
Bugs
A few bugs have been detected by DTR and eliminated. Of these, only one seems likely to have been capable of causing serious errors and it is very unlikely to have done so in practice ? because its consequences would have been obvious and yet it has not been reported. This particular bug affected boundaries with (i) exactly two limbs and (ii) very large loss coefficients in both limbs. If the loss coefficients were so large that the boundary should have behaved as though it were closed, ThermoTun closed it to flow in one direction, but not the other. Now it prevents flow in either direction. It is not good practice to use loss coefficients to close boundaries, but there can be special conditions when it is convenient to do so.
1 March 2015
MPW boundaries
A new boundary type has been introduced. It is a portal that emits micro?pressure waves (MPWs) into the surrounding atmosphere. This is a highly informative development that extends the conventionally accepted scope of 1?D prediction tools. However, there are major limitations that must be fully understood before any use is made of the facility. In no circumstances should the facility be regarded as enabling ThermoTun to predict MPWs that would be caused by predicted pressures waves generated by trains.
First the good news: If a single pressure wave with a clearly defined shape approaches a portal, the new boundary type will give a good estimate of the resulting MPW pressure history. It will do this on the assumption that the external flow field is spherically symmetric within a user?prescribed solid angle.
Now the bad news: No 1?D software can predict the correct shape of, say, nose?entry wavefronts.
Nor can it model correctly the subsequent evolution of the detailed shapes of wavefronts as they propagate along tunnels. These phenomena are influenced by 3?D effects that can, at best, be estimated only crudely in 1?D software. Therefore it is not possible to use software such as ThermoTun to generate wavefronts of sufficient accuracy for the purposes of MPW prediction.
So what is the use of the new boundary type? Well there are at least two possibilities. First, pressure histories obtained from other sources can be input directly to ThermoTun. Second, although quantitative information cannot be deduced from ThermoTun?generated pressure waves, qualitative comparisons of alternative rain?tunnel geometries and speeds can be meaningful. Use should be made of these possibilities only by users who have a deep understanding of the limitations and who will never use the predictions as a basis for quantitative guidance
19 January 2015
Dedicated output for the program THERMO
An error in the specification of arrays for use in preparing output for the program THERMO has been eliminated. This is relevant only to users who have access to that program, which is not supplied by DTR.
19 January 2015
Selection of atmospheres
In ThermoTun/7.1, boundaries must be associated with a specific atmosphere. That is, for each boundary, the parameter LATM must be given a value greater than zero. A new data check has been introduced to trap attempts to declare LATM < 1.
31 August 2014
Input of Saccardo boundaries
A small change has been made to the input of Saccardo boundaries. Instead of appending the jet area and angle to the end of the data for side?3, these data are now input on a separate line. This more logical format was previously avoided because it causes complications in ThermoTun’s internal checking processes. A new type of boundary that is under development needs to use the more logical format so it has now been adopted as standard. The new boundary (as yet incomplete) is expected to be useful for many users.
23 April 2014
Convection along path lines
Mode?1 now has the ability to track fluid particles as they progress along a pipe. At some future date, this ability might be used as a starting point for simulations in which fluid properties depend on factors other than the pressure. In the meantime, its main purpose is to enable pollution to be tracked. This can be useful in its own right and it can also be used to monitor phenomena such as the mixing of different streams or the penetration distances of flows entering a network from a reservoir.
18 April 2014
Skin Friction
Skin friction calculations in all solvers (Modes 1, 5 & 6) now depend on the Reynolds number, Re. This can be important in some types of pipe flow. For large?Re simulations typical of most train:tunnel flows, however, it should have only a very small influence. If any strong differences are detected, please report them to DTR.
10 April 2014
Train cabs
Coach leakage calculations in Mode?5 no longer assume that powered coaches have a driver cab that is sealed from the rest of the coach. Instead, leakage in powered coaches is simulated in the same manner as in unpowered coaches. In both cases, an average pressure is calculated along the inside of the coach and is assumed to exist along the whole coach ? except for small changes to allow for differences in elevation between the two ends. In Mode?6, further differences exist because of leakage between coaches and wave propagation inside coaches.
27 March 2014
Pulse Engines
Pulse Engines are now available in Mode?1, but only to the owner of the patented technology for the associated hardware.
16 January 2014
Animation window
By default, a simple animation is now displayed whilst the program is running. The main advantage of this is visual, but animations can sometimes draw your attention to unexpected behaviour that might indicate a fault in your data ? or in your preconception of the resulting flow. The main disadvantage is that the animations consume CPU time and therefore slow the program somewhat.
A line in GLOBAL data enables you to choose whether to display the animation and, if so, whether to animate pressures, velocities or flow rates.
The window displays:
? The name of the data file;
? Time graphs of pressure (say) at locations along Route?1 (or Tunnel?1 if no routes exist);
? A colour display of instantaneous pressures (say) along the route;
? A progress bar and two boxes showing progress numerically.
To avoid cluttering your screen, the animation self?destructs at a user?prescribed interval after the simulation ends.
19 November 2013
Principal differences from ThermoTun/6.3
1. Software language and compiler
The code has been re?written in Fortran95. One reason for this was to remove an annoying limitation of all previous versions of ThermoTun, namely that arrays sizes had to be chosen before DTR compiled the program and sent it to users. Now they are now chosen after reading the user data file. As a consequence, there is no longer any software limit on the numbers of tunnels/fans/switches/trains/etc. There may still be hardware limits, but this is unlikely unless such large arrays are required that the program cannot fit into the available memory. In that case, the compiler might try to use hard disk as to supplement the core memory. That would slow the program considerably. This matter is within user’s own control.
2. Solver Mode?1
A new solution mode (Mode?1) now exists. It simulates unsteady flows in liquid?filled pipe networks. A restricted version of this mode is available to all users, but it is outwith the scope for which ThermoTun licences are issued (trains and tunnels) and so there are no contractual obligations for support. Users are welcome to use it ? and to report any difficulties to DTR ? but it is new and so its predictions should be inspected with special care. Why? All software has bugs. New software tends to have more bugs than well?established software.
3. Fluid properties
One consequence of the introduction of Mode?1 is a need to define liquid properties. This is done in new data blocks before inputting atmospheres. In principle, there may be more than one gas type and more than one liquid type. For train/tunnel simulations, the working fluid is gas?1 and the default is air; for liquid?filled networks, it is liquid?1 and the default is water.
4. Atmospheres
Atmospheres now consist of a gas overlying a liquid ? analogous to air overlying an ocean. In the gas, the pressure varies isentropically with elevation. In the liquid, it varies isothermally (based on the prescribed bulk modulus and reference density). For tunnel simulations, the elevation of the free surface in each relevant atmosphere must be below the tunnel portals. For liquid simulations, it should be above all external boundaries.
5. Tables
Users may now input special?purpose data in dedicated Tables. This could be used for experimental data, for example. The data may be given in any units. Scaling factors are used to tell the software how to convert the values into standard SI Units.
6. Prescribed?pressure histories
In all three modes, new boundary types are now available. One of these enables tabulated input to be used to define the pressure history at an end of a tunnel/pipe. An obvious use for this is to impose measured pressures at a location in a network. There are important physical limitations on the validity of such analyses, but there can be important benefits in special cases. Another use is to impose very simple conditions for the purposes of software testing and user?training.
7. Prescribed?velocity histories
Another new boundary condition enables tabulated input to be used to define the velocity history at an end of a tunnel/pipe. The purposes are essentially the same as for prescribed?pressure boundaries. The introduction of this boundary type eliminates the need to use “fans” to simulate (non?physical) constant flow at shaft portals.
8. Closed ends
A third new boundary type is prescribed zero flow.
9. Changes to DDD files
Some changes have been made to DDD files. Most of these relate directly to the developments listed above. Attention is drawn to two others:
(i) The Solver?Mode is now declared at the beginning of the Global data block
(ii) The re?numbering of some output parameters (introduced in August 2012) has been
finalised. Items 11?14 now yield stresses in pipe walls. Items 6?9, 22 & 48 are rejected, but have not yet been re?allocated for new purposes.
10. I M P O R T A N T W A R N I N G
Although the conversion of the software to Fortan95 has provided valuable benefits, it also has the short?term disadvantage of increasing the risk of bugs. The biggest changes to the code are in the input routines (to enable automated array sizing), but changes have also been made to the main solver routines. There are two ways in which users can protect themselves from the consequences of bugs:
(i) Make direct comparisons between solutions obtained with the new and old software (i.e. versions 6.3 and 7.1). If differences exist ? and are not caused by errors in the data files ? report them urgently to DTR. In this case, please send both DDD files and an annotated sketch of the system to be simulated;
(ii) Take special care when checking the validity of any simulations used in the preparation of reports for clients.
Please note that DTR has already made extensive checks of the new software. Therefore, it is unlikely that many obvious bugs will exist. Nevertheless, ThermoTun is used in many ways that DTR has never even though of. It is inevitable that some combinations of features will not have been checked explicitly. This does not mean that they are bug?ridden, of course, but it does mean that the risk is greater than with the extensively?checked version 6.3 of the software.
The following notes relate to versions of ThermoTun up to version 6.3
4 April 2013
Revision of dedicated output for use with the program THERMO
The first item in each of the files ‘root’.tht and ‘root’.tms has been corrected. It now averages over the same interval duration as subsequent output.
19 January 2013
Revision of pressure alongside trains before entry The pressure alongside a train before it enters the tunnel system for the first time is now equal to the pressure in the atmosphere at the elevation of the tunnel entrance. Previously, it was equal to
the global default pressure P0 that applies at the elevation datum (z=0) in the default atmosphere (i.e. Atm? 1).
11 November 2012
Revision of mass?flux output for users of “THT”
The output file “root.tms” now provides the average swept mass flux along each tunnel, including the displacement effect of trains. When a train nose enters a tunnel, air ahead of the nose moves in the same direction as the train, but air behind the nose moves in the opposite direction. In previous versions of ThermoTun, the output values of mass?flux were based on the air only and so could reverse during train passage. In the new version, the train is imagined to be replaced by a slug of air moving at the train speed and this slug is included in the calculated mass flux. This eliminates the discontinuous effects inherent in the former approach.
8 August 2012
Re?numbering of output items
The second stage of an output re?numbering process has begun (the first stage began in 2006).
From today, output types 6?9, 11?14 & 22 have been re?numbered as 61?64, 81?84 & 25. For several months, both the old and the new numbering methods will work ? so there is no immediate need to change existing DDD files. However, all new files should use the new numbering system. For releases after 1st August 2013, automatic numbering will not be undertaken. Instead, attempts to use the old numbers will trigger a failure message. At some future date, the old numbers will be reallocated
for new purposes. In a similar way, this second stage of the process uses space that was
freed up in the first stage.
A few new output parameters have been introduced. A few others that were previously available only to DTR have been made generally available.
7 August 2012
Reduced minimum length
It is recommended that no tunnel should be shorter than the default grid length DXW0. Indeed, it is good practice to ensure that all tunnel lengths are at least 2 x DXW0. Nevertheless, there are special circumstances in which users might wish to use tunnel lengths shorter than DXW0 despite an inevitable resulting loss of numerical accuracy. This has always been permitted in Mode?5, but a minimum value of DXW0 was originally imposed in Mode?6. Some years ago, this minimum was reduced to DXW0/4, but only at the user’s own risk. The minimum has now been reduced to DXW0/10, again at the user’s own risk ? not as a formally supported feature of the software.
3 August 2012
New feature ? Valves
Release 6.3 of ThermoTun includes a new feature ? Valves. These may be specified on any side of many types of boundary. The manner in which their areas vary in time is defined by a switch.
Please see Section 5.12.3 of the Manual. In addition to giving details of how to input valves, the Manual explains an important limitation of valves when they are used in Mode?5. This limitation is believed not to exist in Mode?6.
WARNING: Valve?switches necessitate the specification of an extra item of data for each side of every boundary. If this item is omitted, ThermoTun will detect a problem, but the resulting failure message will depend upon the manner in which other data are specified. This is because integer data can be read as a real number, but a real?number data (e.g. 0.0 or 3.45) causes failure when ThermoTun is expecting an integer.
30 July 2012
New feature ? Variable time steps
All previous releases of ThermoTun have used unchanging time steps. This is still the default condition, but a new feature exists in which small adjustments are made to time steps in response to instantaneous flow conditions. It is expected that the variable?time?step solutions will be more accurate that the fixed?time?step solutions. However, it is also expected that the differences will be very small. Please see Section 5.2.2 of the Manual.
13 June 2012
New feature ? Flights
Release 6.3 of ThermoTun includes a new feature ? Train?Flights and Flight?Groups. These are described in §5.18 of the User?manual and an example of their use is given in §12.
13 June 2012
New default values
? The default values of train rolling resistance coefficients have been changed.
? The default value of the tunnel wall thickness has been increased from perimeter/1000 to diameter/50.
? Users are advised never to rely on default values except for numerical grid sizes in the input of tunnels.
6 June 2012
New feature ? Mass Flux output
This version of ThermoTun includes a new feature (for one specific user).
Requests for THERMO?output now cause two files to be output.
One file (root.tht) lists train heat into each tunnel. This is the same as before.
The other (root.tms) lists average mass flows along each tunnel. This is new.
Related change: The DDD input specification for THERMO?output requests now has only three items. Use of a fourth item was discontinued long ago when we decided that the only sensible time over which averaging should be made is the same as the interval between successive lines of output. Bugs fixed
16 Apr’11
Tunnel pressures were sometimes initialised incorrectly.
18 Apr’11
The values of some "Maximum?so?far" parameters were output incorrectly.
25 May’11
Calculations of flows axially along the insides of trains did not allow for train compressibility. These calculations are available in Mode?6 only.
20 Jun’11
In Mode?5, the boundary type “JOIN” did not handle lateral flows through tunnel walls correctly.
3 Nov’11
In Mode?6, the temperatures of coach surfaces and brakes were never updated.
29 Dec’11
The program would sometimes stop abruptly when the end of a coach was exactly coincident with a calculation grid point at a calculation instant. NB: In this context, “exactly” means “to a precision of 15 significant figures” ? i.e. to about one?millionth of one micron.
29 Feb’12
Flight groups continued beyond their stated end times.
21 Jul’12
Improvements have been made to the manner in which energy and pollution are handled at boundaries.
ThermoTun/7.1
27 Mar’14
A number of bugs in Mode?1 in the early version of ThermoTun/7.1 have been identified and eliminated. Some were detected by a user and others by DTR. The most important of them was an error in the input of pipe wall thickness. This influenced the calculation of wavespeeds and stresses and strains in pipe walls.
