Technical support in the implementation of the Environmental noise directive 2002/49/EU

Transcription

1 Technical support in the implementation of the Environmental noise directive 2002/49/EU General In accordance with EU purchase order /2013/673823/F3 Stapelfeldt Ingenieurgesellschaft mbh, Dortmund (SIG) undertook testing of the noise propagation DLL s developed and provided by CSTB for use in CNOSSOS. Development of the DLL s is based on the JRC Reference Report Stylianos Kephalopoulos, Marco Paviotti, Fabienne Anfosso Lédée (2012), Common Noise Assessment Methods in Europe (CNOSSOS-EU), EUR EN [1]. Also findings and decisions taken and documented in the corresponding Issue Log documents set up during the course of Extrium s contract for Develop and implement harmonised noise assessment methods were integrated into these DLL s. Two DLL s are used to analyse the propagation effects per single path geometries, which is entered into the calculation by user defined calls CnossosPropagation.dll HarmonoiseP2P.dll The calls provided in the DLL s allow calculating the attenuation effects of a propagation path according to 3 different methods: JRC-draft-2010 (Harmonoise/Imagine based approach) ISO (ISO based approach) JRC-2012 (NMPB based approach) The DLL s are developed by CSTB in C++ Code. The version finally used to produce the test results documented in this report was issued on 25 th of April. Test purposes and methodology This report focusses on two kinds of testing for the propagation DLLs: Estimate the calculation performance Comparing transfer function results against measured data or calculation results using existing regulations The necessary model data for the 1 st case was taken from the so called Musterstadt CITY also known as QSDO model supplied by the German DIN Group. For the 2 nd case model data was submitted by the EU Member states. In all cases path-finding needs to go ahead of any call to the DLLs. The main tasks of a pathfinder are: Finding relevant sources in the neighbourhood of a receiver for direct and for reflected image sources Breaking down line and area sources into representative point sources Finding all obstacles, terrain and ground impedance information between source and receiver Hand over each path geometry to the propagation DLL Sum up result return values from the DLL Output total result of receiver noise level Doc. Rev

2 Testing propagation DLL s CNOSSOS Propagation Modules Performance test To test the behaviour of the DLL s in a large and complex model which is comparable to the demands of EU conform noise mapping for agglomerates, the example model data set of the Musterstadt was used. This model is also referred to QSDO model, as it was set up for quality assurance purposes, based on a data set of the city of Dortmund. Within the German DIN working group this model was refined and arranged in QSI standard SHAPE format. Refinement included the use of a triangulated terrain model, as illustrated in the zoom extract of Fehler! Verweisquelle konnte nicht gefunden werden., which helped to ensure that four different commercial software packages could interpret the model, in the same manner and produce similar results, when using the noise propagation logic, as described in German regulation RLS 90. Property rights on the model are with the German DIN (Deutsches Institut für Normung e.v.). The model may generally be used for scientific purposes and it can be downloaded via URL; The modifications applied to this model for the purpose of testing the CNOSSOS propagation DLL s were: Erasing of any roads with an average daily traffic (ADT) of less than 3000 vehicles Instead of RLS 90 road elements line sources at a height of 0.05 m above ground were used. The L me,25 emission data was converted into sound power levels and the octave spectrum of emission was set to the values defined for road noise in the Interim Methods Receiver points were randomly placed within a 2 x 2 (km) area in the centre of the 6 x 6 (km) model area which is displayed in Figure 1. For calculation the DLLs dating were used which helped to reduce the number of exception errors, which fully interrupted the run of the calculation. To avoid such behaviour it will be feasible to use a return code response of the DLL in case of unsolvable geometric situations. It was found that mainly complex terrain situations, for which the ground reflection logic described in the JRC-2012 method could not be applied, were causing the problems. It is suggested to modify this concept before further use in large and complex models. It was not tested whether a terrain representation by contour lines only would be less vulnerable to this issue. In the statistical analysis shown in Table 1, 9039 valid receiver points are represented. The key calculation parameters were: 1500 m fetching radius for sources No neglecting of irrelevant sources, i.e. 0 db dynamic error margin 0.50 as maximum ratio of source segment length to source-receiver distance 0.01 as minimum ratio of source segment length to source-receiver distance No reflection 2 Doc. Rev

3 Table 1 Average time consumption for receiver point calculation in large and complex model No emit No seg Obs /seg Total (s) 2010 Prop (s) 2010 Path (s) 2010 Total (s) 2011 Prop (s) 2011 Path (s) 2011 Total (s) 2012 Prop (s) 2012 Path (s) , , ,2421 4,6398 5,5607 1,5488 4,0119 5,9660 1,9184 4,0476 Explanation of the header in the table above The columns of the table represent average values per receiver: No emit No seg Obs/seg Total (s) Prop (s) Path (s) Number of emitters taken into account Number of segments into which sources were split which is equivalent to the number of propagation paths per receiver position Number of obstacles or terrain edges encountered per path Total calculation time in seconds Time consumption related to CnossosPropagation.dll Time consumption related to path finding The year indices represent 2010 JRC-draft ISO JRC-2012 Figure 1 Large and complex model as extract of the QSDO model in a 6 x 6 (km) area Doc. Rev

4 Testing propagation DLL s CNOSSOS Propagation Modules Figure 2 Extract of the complex model showing road, buildings and TIN terrain model 4 Doc. Rev

5 Transfer function test Based on a range of different test cases the magnitude of the transfer function of each of the 3 methods under consideration was calculated with help of the DLL s mentioned before. The geometrical models as well as relevant acoustic properties of the test cases have been submitted by EU member states. On intention all test cases are of limited size. For some cases corresponding measurement results could be provided. For other cases calculated results had been submitted by member states using existing national regulations. In support of comparison of the transfer function deriving from the measured or calculated results against the results calculated by each of the 3 methods, an XLS table was submitted by the client. After several rounds of testing and refining the model in coordination with the model data suppliers 3 resulting XLS sheets represent all results generated for the transfer function. Selection_of_methods_results_HAR.XLS for JRC-draft-2010 Selection_of_methods_results_ISO.XLS ISO Selection_of_methods_results_CNO.XLS JRC-2012 Description of test cases for the transfer function test The text following presents a brief description of extra assumptions and modifications applied to the cases in order to fulfil the aim of this study. The case naming used is identical to the XLS result sheets. Model pre-processing Some general modifications were applied to most of the cases: Order the receiver points in line with the name descriptors For case with provided result levels were calculated according to RLS90, a hard road surface was added where no near source ground property was defined. A lane width of 3.8 m was used for this purpose. This change is taking into account that calculation according to RLS90 already reflects a hard source near to the source. For all other regions without a defined ground surface property, a soft ground of type A was assumed during calculation Road emission spectra were set to the octave spectral distribution recommended for the Interim Methods. Only in case of the Austrian example a specific spectrum was provided as it had been used in the RVS based calculation Interim Method RVS In cases where initial road polylines had very dense vertexes, e.g. with road elements of a few cm in length, geometry was simplified (smoothed) with a maximum horizontal pitch of 0.1 m and a vertical pitch of 0.01 m. Smoothing was also used for terrain lines and screens. It is regarded necessary for screens to ensure the geometry conditions for reflective surfaces. Positions of all road axes were used as provided and no further split up and relocation with respect to the defined width of road was undertaken. Emission heights were set to 0.05 m above terrain for all cases, disrespecting different source heights used in national regulations. Doc. Rev

6 Testing propagation DLL s CNOSSOS Propagation Modules Input data in QSI SHAPE format for reflection loss was interpreted as no reflection for values of 200 instead of Ground impedance was set to index A to H, as described for the use in the DLL s. In cases were the input values provided for the models are not directly represented by these indices, a suitable substitute was chosen. Absorption of reflective walls was set to the A1 for an initial input value of 4.0 provided in the model. 4 db is right on the class edge for the indices used in CNOSSOS, i.e. A1 : < DL < 4 db A2 : < DL < 7 db In cases where the model had originally been calculated according to RLS90 emission data was assumed to represent Lme,25 and 19 db were added to these values to create sound power level per m as input data for CNOSSOS calculations. The table below gives an overview of all test cases. The case and the sub case index is used in the XLS sheets for further analysis of the results. The SIG case index represents the folder and file name used for a specific case. All model and result data is supplied as shape files using this name structure. For each SIG case two sub cases A and B are handled, to deal with the requested variation in meteorological condition, defined by % favourable wind. Case Sub case name Origin SIG case %fav A %fav B 1 1 FR-Massiac SETRA TCN_ FR-MolsheimNord TCN_ FR-MolsheimSud TCN_ FR-Mulhouse TCN_ FR-SaintOmer TCN_ Austria TCN_ TC1ac Italy TCN_ TC1bd TCN_ TC2a TCN_ TC2b TCN_ TC3ab TCN_ TC4ab TCN_ ISPRA TCN_ Greece TCN_ figure Meteorological Condition In line with the information given in the XLS sheets for result documentation and postprocessing, meteorological condition was either set to favourable or homogeneous. 6 Doc. Rev

7 Calculation parameters For calculation no extra simplification of the model was undertaken. Key calculation parameters are Fetching radius for sources (m) 2500 Max. relation of length of segmented source lines vs. distance 0.5 Order of reflection 1 Fetching radius for reflectors (m) 100 The fetching radius for reflectors is seen similar around the source segment as well as the receiver position. Only first order of reflection was taken into account to keep calculation similar to the RLS90 test case results provided for case 3 with subcases 1 to 5. For segmentation of sources the method of projection was used. So the 0.5 relation will just represent the potential maximum. Figures In the final section of this report screenshots of each case are shown to provide an impression of the scenarios. To improve the 3-d visualisation terrain next to the receiver and road area was represented by a dense triangulated surface net (TIN). Where explicit TOP objects (ground impedance) were defined the TIN was coloured in relation to the Ground property. Each page shows one test case and for each test case there is a fixed order of screenshots: 1. Plan view of full model 2. Plan view of region next to the receiver positions 3. 3-d slant view for region next to the receiver position Dortmund, the 27 th of June, Dipl.-Ing. H. Stapelfeldt Doc. Rev

8 Testing propagation DLL s CNOSSOS Propagation Modules TCN_11 / Case 1 A, 1 B 8 Doc. Rev

9 TCN_12 / Case 2 A, 2 B Doc. Rev

10 Testing propagation DLL s CNOSSOS Propagation Modules TCN_13 / Case 3 A, 3 B 10 Doc. Rev

11 TCN_14 / Case 4 A, 4 B Doc. Rev

12 Testing propagation DLL s CNOSSOS Propagation Modules TCN_15 /Case 5 A, 5 B 12 Doc. Rev

13 TCN_21 / Case 17 AT Road Doc. Rev

14 Testing propagation DLL s CNOSSOS Propagation Modules TCN_31 / Case 13 3A, 14 3B 14 Doc. Rev

15 TCN_32 / Case 12 2B Doc. Rev

16 Testing propagation DLL s CNOSSOS Propagation Modules TCN_33 /Case 10 1D 16 Doc. Rev

17 TCN_34 / Case 15 4A, 16 4B Doc. Rev

18 Testing propagation DLL s CNOSSOS Propagation Modules TCN_35 / Case 7 1A 18 Doc. Rev

19 TCN_36 /Case 11 2A Doc. Rev

20 Testing propagation DLL s CNOSSOS Propagation Modules TCN_41 / Case 18 IT 20 Doc. Rev

21 TCN_51 / Case 6 GR Doc. Rev