Zhenguo Tu

Yong Lu
email: yong.lu@ed.ac.uk

Modifications of RHT material model for improved numerical simulation of dynamic response of concrete

Keywords: constitutive model, concrete, dynamic load, penetration, numerical simulation, hydrocode

Sophisticated numerical models are increasingly used to analyze complex physical processes such as concrete structures subjected to high-impulsive loads. Among other influencing factors for a realistic and reliable analysis, it is essential that the material models are capable of describing the material behaviour at the pertinent scale level in a realistic manner. One of the widely used concrete material models in impact and penetration analysis, the RHT model, covers essentially all macro features of concrete-like materials under high strain rate loading. However, the model was found to exhibit undesirable performance under certain loading conditions and some of the modelling issues have been discussed within a recent review paper by the authors. The present paper provides a more in-depth evaluation of the RHT model and proposes modifications to the model formulation to enhance the performance of the model as implemented in the hydrocode AUTODYN. The modifications include Lode angle dependency of the residual strength surface, tensile softening law and the dynamic tensile strength function. The improvement of the performance of the modified RHT model is demonstrated using numerical sample tests, and further verified via simulations of two series of physical experiments of concrete penetration/perforation by steel projectiles. The results demonstrate an overall improvement of the simulation with the modified RHT model. In particular, the depth of penetration, projectile exit velocity and the crater size are predicted more favourably as compared to the test data. It is also shown that the modelling of the concrete tensile behaviour can affect sensibly the predicted perforation response (e.g. the projectile exit velocity), as is generally expected when the impact velocity exceeds the ballistic limit.

Introduction

Concrete is a common material used in civil and defense constructions. Modeling of the concrete behaviour under static or quasi-static loading has been a subject of extensive studies for many decades. Modeling of the concrete behaviour under high rate loading is relatively new and it has become a topic of wide attention in more recent years. Apart from the needs to cope with the development of civil and defense industries for better protection of structures under extreme loading, a major reason is associated with the advancement of the computational power. Today, it has become possible to carry out large-scale numerical simulations that could reproduce many complex physical processes to great details. Numerical simulation using adequate computational models has become a powerful means in the design process as well as in the investigation into the physical mechanisms. In the high-impulsive load realm, a few examples of using numerical simulation to investigate the effects of the complex response of concrete under ballistic impact and explosion can be found in [1][START_REF] Leppanen | Dynamic behaviour of concrete structures subjected to blast and fragment impacts[END_REF][START_REF] Unosson | Projectile penetration and perforation of high strength concrete: experimental results and macroscopic modelling[END_REF][START_REF] Rabczuk | Modelling dynamic failure of concrete with meshfree methods[END_REF] with either user-developed codes or commercial hydrocodes such as AUTODYN [5] and LS-DYNA [START_REF]LS-DYNA Keyword User's Manual, version 970[END_REF].

Adequate material constitutive modeling and sound computational techniques are both essential to a reliable numerical simulation of complex responses. For brittle materials like concrete, the macroscopic inelastic response stems from material fracture, buckling and crushing of the cement paste and aggregate micro-structure [START_REF] Unosson | Projectile penetration and perforation of high strength concrete: experimental results and macroscopic modelling[END_REF]. These mechanisms become even more complex under high loading rate conditions. It is difficult to model the microscopic mechanical processes in the analysis of a real life problem. Instead, the modeling of the material constitutive behaviour for concrete-like materials is typically made at the macroscopic level that is consistent to the continuum description of the material using finite element methods. Nilsson [START_REF] Nilsson | Impact loading on concrete structures: a constitutive modelling, finite element analysis, and experimental study of nonlinear wave propagation[END_REF] conducted some fundamental studies on the constitutive modelling of concrete subjected to high dynamic loads. A detailed description of the general modelling of concrete response using the theory of plasticity can be found in [START_REF] Chen | Plasticity in Reinforced Concrete[END_REF]. Recent advancements saw the development of several comprehensive concrete models that are aimed at high-impulsive load applications, with consideration of such effects as pressure hardening, strain hardening, material softening and rate-dependency. Models of this category include the RHT model [1, [START_REF] Riedel | Numerical Assessment for Impact Strength Measurements in Concrete Materials[END_REF][START_REF] Riedel | Beton unter dynamischen Lasten: Meso-und makromechanische Modelle und ihre Parameter[END_REF], the K&C model [START_REF] Malvar | A plasticity concrete material model for DYNA3D[END_REF][START_REF] Malvar | K&C concrete material model Release III -Automated generation of material model input[END_REF] and JHC concrete model [START_REF] Holmquist | A computational constitutive model for concrete subjected to large strains, high strain rates, and high pressures[END_REF].

M A N U S C R I P T A C C E P T E D ACCEPTED MANUSCRIPT

With the implementation in AUTODYN, the RHT model has been widely used in the modelling of concrete-like brittle materials for high-impulsive response analysis such as impact and penetration (e.g., [1][START_REF] Leppanen | Dynamic behaviour of concrete structures subjected to blast and fragment impacts[END_REF][START_REF] Unosson | Projectile penetration and perforation of high strength concrete: experimental results and macroscopic modelling[END_REF][START_REF] Hansson | Simulation of concrete penetration in 2D and 3D with the RHT material model[END_REF]). Many of these applications made use of the model available in the software directly to simulate the responses concerned, and some conducted qualitative parametric studies with regard to the effect of critical model parameters on the prediction outcome. For example, Hansson and Skoglund [START_REF] Hansson | Simulation of concrete penetration in 2D and 3D with the RHT material model[END_REF] concluded from their simulation studies of projectile perforation problems that the parameters describing the damage accumulation and the residual strength surface in the material model are most sensitive with regard to the predicted projectile discharge velocity. Such parametric studies are important in that one could subsequently adjust the respective model parameter settings to achieve better predictions of the observed responses from relevant experimental studies.

However, such a treatment could become problem-specific if the material model itself is not robust enough in representing the underlying physical mechanisms, for example the material softening at large deformations.

In a recent review study of concrete material models by the authors [START_REF] Tu | Evaluation of typical concrete material models used in hydrocodes for high dynamic response simulations[END_REF], several issues were identified with regard to the modeling capability of the RHT model in describing the concrete behaviour under certain stress conditions, and recommendations have been given as to how the model parameter settings may be adjusted to indirectly rectify the modeling issues within the existing standard RHT formulation. In the present study, we conduct a more comprehensive evaluation of the RHT model for concrete material and propose a set of changes to the model formulation in order to enhance the robustness of the model.

The model is first evaluated with regard to its ability of representing the stress-strain relationships of concrete subjected to various loading conditions, namely uniaxial tension, biaxial compression and triaxial compression.

Modifications to the standard RHT model

The original RHT model is well documented in previous publications [1,5,9] and a concise overview is also provided in [START_REF] Tu | Evaluation of typical concrete material models used in hydrocodes for high dynamic response simulations[END_REF]. In this section, we will focus on the analysis of a few issues and present the detailed modifications to the original RHT model. The improved model performance due to the modifications is demonstrated by single finite element numerical tests.

Modified residual strength surface

As implemented in AUTODYN, the residual strength surface in the standard RHT model exhibits a circular deviatoric cross section plane in the principal stress space. This simplified treatment creates some difficulties in replicating the material behaviour under certain stress conditions, in that the model tends to exhibit a hardening response after the peak failure strength is reached instead of softening, as would normally be expected.

Let us first take a look of the relevant behaviour of the RHT model. For this purpose singleelement numerical tests are performed. The single-element specimen is given a cubic shape, and it is loaded by monotonically increasing the compressive displacements (hence the compressive strain) along two principal directions, while a constant stress is imposed in the 3 rd principal direction. This loading path corresponds to a Lode angle of zero degree, i.e. on the tensile meridian. Fig. 1 shows typical compressive stress-strain curves as obtained from the above numerical tests using the original RHT model. As can be seen, all the results exhibit

M A N U S C R I P T A C C E P T E D ACCEPTED MANUSCRIPT
a hardening phenomenon, even in the biaxial compression state when the stress in the 3 rd direction is made equal to zero. Such a persistent hardening phenomenon is deemed to be unrealistic for concrete-like materials. Although systematic experimental data about the stress-strain response of concrete under general triaxial extension are not commonly available, the special case of biaxial compression has been studied extensively in the past and softening is typically observed (e.g., [START_REF] Chen | Plasticity in Reinforced Concrete[END_REF]). Besides, numerous triaxial compression tests exist and the general observation also suggests a post-peak softening trend (e.g. [START_REF] Lu | Stress-strain relations of high-strength concrete under triaxial compression[END_REF]).

In order to understand further the reason behind the above-mentioned problem in the model, the path of the yield stress developed in the numerical specimen during the loading process is tracked, as shown in Fig. 2. It can be immediately observed that, as a result of the lode-angle independent residual strength adopted in the model, the (tensile) meridian of the residual surface actually goes beyond that of the failure surface. Consequently, the stress continues to increase (hardens) when it moves from the failure surface towards the residual surface.

To rectify the hardening problem, one possible way, without changing the shape of the residual surface, is to reduce the residual strength constant B (see Eq. (1) below) in the model altogether. However, this would affect the overall model behaviour. A more viable approach, as is proposed here, is to modify the residual strength surface to make it Lode angle dependent in a similar way as for the maximum strength surface, i.e., ( ) ( )

     < ≥ × × = 0 0 0 3 * p p r p B Y M residual θ (1)
where ( )

θ 3 r
is a scalar function of Lode angleθ and the function ψ [8],

( ) ( ) ( ) ( ) ( ) ( ) 2 2 2 2 2 2 2 3 2 1 cos 1 4 4 5 cos 1 4 1 2 cos 1 2 ψ θ ψ ψ ψ θ ψ ψ θ ψ θ - + - - + - - + - = = c r r r ( 2
)
where c t r r = ψ denotes the tensile-to-compressive meridian ratio (refer to Fig. 3) and is a function of the pressure.

The tensile meridian of the above modified residual surface is also shown in Fig. 2 surface. This ensures a softening behaviour, which is deemed to represent the general concrete behaviour, at least within a reasonably high pressure range. It should be noted that in the modified residual strength surface the compressive meridian remains unchanged from the original model.

The above modification to the residual surface of the RHT model is then implemented in AUTODYN by adding user subroutines into the external strength interface module. Eq. ( 1) is used to compute the residual strength value at the current pressure. This value, together with the calculated current failure strength, is then used to solve for the current yield stress.

With the modified residual strength surface, the same numerical tests as for Fig. 1 are repeated, and the results are shown in Fig. 4. It can be seen that with the modification the model reproduces a softening behaviour after reaching the maximum strength. Furthermore, as the compressive stress in the 3 rd (axial) direction increases, the material becomes stronger and more ductile. This is consistent with general experimental observations (e.g., [START_REF] Chen | Plasticity in Reinforced Concrete[END_REF][START_REF] Lu | Stress-strain relations of high-strength concrete under triaxial compression[END_REF]).

It is worth mentioning that, an alternative approach to modelling the post-failure response, without actually using a residual strength function, is to penalize with damage the normalized hydrostatic tension (e.g., [START_REF] Polanco-Loria | Numerical predictions of ballistic limits for concrete slabs using a modified version of the HJC concrete model[END_REF]). In this way one saves two parameters (B and M in Eq. (1)), and avoids the uncertainties associated with the deviatoric shape in the residual function.

However, introducing an independent residual failure surface, as is adopted in RHT and some other models (e.g., [START_REF] Malvar | A plasticity concrete material model for DYNA3D[END_REF][START_REF] Malvar | K&C concrete material model Release III -Automated generation of material model input[END_REF]), is deemed to be a generalized consideration. By bringing in two additional free parameters B and M, it gives more flexibility in accommodating test observations under different loading conditions.

Modified tensile-to-compressive meridian ratio vs pressure relationship

In the RHT model, the tensile-to-compressive meridian ratio ψ is defined to depend linearly on the pressure p as: However, it is found that with Eq. ( 4) the model cannot represent satisfactorily the expected strength of concrete in or close to a biaxial compression. It is generally expected that the strength of concrete under biaxial compression loading is around 1.15 times the unconfined uniaxial compressive strength [START_REF] Malvar | A plasticity concrete material model for DYNA3D[END_REF]. For example, for 35-MPa concrete the biaxial compressive strength should be around 41.0 MPa. But with Eq. ( 4) the model would give a considerably higher biaxial compressive strength (see later in Fig. 6).

Based on a collection of test data, Malvar et al. [START_REF] Malvar | A plasticity concrete material model for DYNA3D[END_REF] recommended a piece-wise linear definition of ψ in the K&C Concrete Model, as follows:

( ) ( ) ( ) [ ]          + + + = 0 . 1 753 . 0 3 2 3 2 2 3 2 1 2 1 2 1 0 c c c c t f a a f a f f f p α α α ψ c c c c f p f p f p f p p 453 . 8 3 3 2 3 0 ≥ = = = ≤ α (5)
The detailed descriptions and the determination ofα , 0 a , 1 a and 2 a in Eq. ( 5) can be found in Malvar et al. [START_REF] Malvar | A plasticity concrete material model for DYNA3D[END_REF][START_REF] Malvar | K&C concrete material model Release III -Automated generation of material model input[END_REF].

In this study, we propose to retain the simple form of Eq. ( 3), but using modified values for 0 C and 1 C so as to better match the trend as represented by Eq. ( 5). For this purpose, three sets of data are obtained from Eq. ( 5) for concrete grade 35 MPa, 70 MPa and 150 MPa, respectively. Actually, in Eq. ( 5) only one control point of ( )

p ψ , at 3 c f p =
, is sensitive to the concrete strength grade. At this point ( ) p ψ is defined as a function of the concrete tensileto-compressive strength ratio, and it is generally known that this ratio tends to be smaller for higher strength concrete.

Through a linear regression analysis with the aforementioned three sets of data points, the best-fit 0 C and 1 C are found to be 0.60 and 0.05, respectively. The relationship using the

Modifications to the modeling of tensile behaviour of concrete

Plain concrete is weak and brittle under tension. Crack softening is a characteristic feature of concrete and requires specific modeling considerations. Besides, the tensile strength of concrete is known to be strain rate sensitive under dynamic loading; the rate dependent law has a significant effect on the modeling result. The standard RHT model has a limited capability in representing the tension-cracking behaviour, whereas its rate-dependent law is not up-to-date.

It is possible to implement through user subroutines a user-defined dynamic increase factor (DIF) to rectify the dynamic tensile strength and a crack softening law to improve the tensile behaviour of the model (e.g., Leppenen [START_REF] Leppanen | Concrete subjected to projectile and fragment impacts: modelling of crack softening and strain rate dependency in tension[END_REF]). In the present study, in conjunction with other modifications we also propose to implement a modified DIF. Furthermore, for the tension softening we propose to use a bi-linear softening function that would enable the retention of a specific fracture energy during the dynamic response. For the sake of completeness, some background information about the rate effect on concrete and the crack softening model will be briefly described along with the proposed modifications.

Concrete dynamic tensile strength increase factor

It has been established through dynamic experiments that concrete behaviour is rate-sensitive.

The general experimental observations tend to indicate that the bulk strength of concrete increases with the increase of strain rate, especially in the high strain rate regime (e.g. [START_REF] Bischoff | Compression behavior of concrete at high strain-rates[END_REF][START_REF] Malvar | Review of strain rate effects for concrete in tension[END_REF]). At this juncture, it may be worth noting that the interpretation of the experimental data from the high strain rate tests is a subject of constant scrutiny; depending on the scale of observation there may be different explanations as to what is the real cause of the experimentally observed rate sensitivity of the concrete strength (e.g., [START_REF] Li | About the Dynamic strength enhancement of concrete like materials in a split Hopkinson pressure bar test[END_REF][START_REF] Cotsovos | Numerical investigation of concrete subjected to compressive impact loading. Part 1: A fundamental explanation for the apparent strength gain at high loading rates[END_REF][START_REF] Lu | Numerical simulation study of the strain rate effect on concrete in compression considering material heterogeneity[END_REF]). A detailed discussion on the underlying mechanisms is beyond the scope of the present paper. The

M A N U S C R I P T A C C E P T E D ACCEPTED MANUSCRIPT

modification discussed here is mainly concerned with a generalized macroscopic modeling framework for which RHT model is best suited, and from a macroscopic point of view it is rational to adopt the experimentally observed rate effect on the dynamic strength of concrete specimens.

Within the framework of a macroscopic model the rate-dependent strength of the concrete material is usually modeled by expanding the failure surface by a certain Dynamic Increase Factor (DIF). In the standard RHT model as implemented in AUTODYN, the DIF for both tension and compression is expressed as a linear function of the strain rate in the logarithmic scale, as:

where d and a are constants. The quasi-static strain rate 0 ε& is taken as The above expressions of DIF are simple, but it is not consistent with experimental observations which tend to support a bi-linear (log-scale, refer to Fig. 7) DIF expression. This discrepancy is particularly significant for the dynamic tensile strength as the transition strain limit in the tensile DIF is low (around 1 s -1 ) and is easily reached. This necessitates a modification of the tensile DIF. For the compressive DIF, the linear expression in Eq. ( 6) may be regarded as acceptable for a large strain rate range of interest, and therefore is not modified in the present study.

There are several bi-linear expressions of DIF, typical of which include the CEB-FIB formulas for both tension and compression [START_REF]Comité Euro-International du Beton, CEB-FIB Model Code 1990[END_REF]. For the dynamic tensile strength of concrete, Malvar and Ross [START_REF] Malvar | Review of strain rate effects for concrete in tension[END_REF] studied a large set of experimental data and proposed a modified version of the CEB-FIB model, as: for tension for compression ( )

                       = a d 0 0 DIF ε ε ε ε ε where s ε& is the quasi-static strain rate, 1 6 10 1 - - × = s s ε&
, δ is a constant relating to the grade of concrete represented by the compressive strength, ( )

co cs f f 8 1 1 + = δ , with co f = 10 MPa (1450 psi). The coefficient β is a function of δ , 2 6 log - = δ β .
To highlight the difference between the "linear" and "bi-linear" expressions, a comparison of the two tensile DIF functions is shown in log-scale in Fig. 7. As noted by Leppanen [START_REF] Leppanen | Concrete subjected to projectile and fragment impacts: modelling of crack softening and strain rate dependency in tension[END_REF],

while Eq. ( 7) reasonably depicts the experimental DIF in tension, the linear expression in Eq. ( 6) cannot achieve a satisfactory match. Therefore, in the present study, we also choose to implement the bi-linear DIF function for an improved representation of the dynamic tension behaviour of the RHT model. It is understood that the effect of modifying the DIF function on the general simulation results can be case dependent. From the simulation of steel projectile penetration in concrete, as will be discussed in more detail later, the severity of material scabbing and spallation can be quite sensitive to the DIF model used.

It is noted that in order for the above modified DIF to take effect in the RHT model the implementation should be done through the crack softening failure option in the model. A more detailed discussion about the cracking softening model follows.

Implementation of a bi-linear softening model with consideration of rate independent fracture energy

In the standard RHT model, the tensile behaviour of the material is described by a plasticitydamage tensile failure model (hereafter referred to as plasticity-damage model), in which the material damage is calculated based on the accumulation of the equivalent plastic strain relative to a pressure-dependent failure strain variable.

Two issues are identified concerning the modeling of the concrete tensile behaviour with the above plasticity-damage model. Firstly, a minimum strain criterion ( min ε ) is used to control the tensile failure and this criterion generally dictates the material response in the low pressure ( 7)

For 1 1 - ≤ s ε& For 1 1 - > s ε& ( )                        = 3 1 DIF s s ε ε β ε ε ε δ M A N U S C R I P T A C C E P T E D ACCEPTED MANUSCRIPT 11
regime, e.g., in uniaxial and biaxial tension cases. As a result, the specific fracture strain energy will tend to increase almost proportionately with the increase of the tensile strength in the strain rate regime. This could result in an overestimation of the energy consumed in the concrete fracture process, and subsequently an underestimation of the damage such as the penetration depth, as will be shown later in the penetration example.

The second issue with such a plasticity-damage model is that it cannot handle properly scenarios where the loading condition is close to the isotropic triaxial tension. This is because in such loading conditions the material incurs only volumetric deformation; however, the RHT model does not consider the volumetric damage, consequently the predicted response would exhibit no softening. Although a pure triaxial tension or a stress path close to it is only a special case and is unlikely to make any significant impact in the real problem analysis, for the sake of rigor and coherency it would be desirable that the material behavior under all plausible stress conditions be well represented in the model.

The crack softening model in AUTODYN could be employed to overcome the abovementioned difficulties in describing the tension behaviour of concrete. This general crack softening model is based on the consideration that in the low pressure region the tension failure of concrete is likely to be governed by the principal tensile stress, instead of the deviatoric straining. Accordingly, a Rankine failure surface is introduced to define the maximum principal strength criteria for the initiation of the tensile failure [START_REF] Clegg | Development and application of Rankine plasticity model for improved prediction of tensile cracking in ceramic and concrete materials under impact[END_REF]. When such a crack softening model is used in conjunction with the RHT model, the Rankine failure surface is superimposed onto the RHT strength functions. In this way, the crack softening model will come into effect when the response of an element falls into the lower pressure regime bounded by the interface between the Rankine and RHT strength surfaces. In such a situation, when the Rankine failure criteria are violated, the stresses are returned to the failure surface following an associative backward Euler method [START_REF] Clegg | Development and application of Rankine plasticity model for improved prediction of tensile cracking in ceramic and concrete materials under impact[END_REF].

At this juncture, it may be worth noting that the post-peak tensile behaviour (softening) is not strictly a material property; and in addition to the tensile strength and fracture energy the shape of the softening behaviour has an influence on the load-carrying capacity of concrete.

The existing crack softening model adopts a linear softening law, which assumes a constant strength degradation rate with respect to the cracking strain in the entire fracture process.

However, general experimental observations tend to support that the tension softening branch

M A N U S C R I P T A C C E P T E D ACCEPTED MANUSCRIPT 12
of concrete is close to an exponential function [START_REF] Weerheijm | Tensile failure of concrete at high loading rate: New test data on strength and fracture energy from instrumented spalling tests[END_REF][START_REF] Gylltoft | Fracture mechanics models for fatigue in concrete structures[END_REF][START_REF] Hillerborg | The theoretical basis of a method to determine the fracture energy G f of concrete[END_REF]; hence, a bi-linear function for softening appears to be a better approximation. Considering the generality, in the present study we choose to follow a bi-linear softening law proposed by Gylltoft [START_REF] Gylltoft | Fracture mechanics models for fatigue in concrete structures[END_REF], as schematically illustrated in Fig. 8. In this model, the tensile strength reduces rapidly at the early stage of failure up to one-sixth of the cracking strain, followed by a slower decreasing rate until the attainment of the total fracture at the maximum cracking strain frac ε (at which point a real crack emerges).

The crack softening model implemented in AUTUDYN follows a smeared crack approach, such that the discrete crack width is smeared out over a certain distance, which is normally equal to the characteristic length of the element. Thus, for a given fracture energy, f G , the following specific strain energy in the entire cracking process should hold:

c f h G d frac el = ∫ ε ε ε σ (8)
where f G denotes the fracture energy, el ε is the strain at peak tensile stress, i.e. the starting strain of softening, c h is the characteristic length of the element. In a two-dimensional analysis, c h is approximately the square root of the area of the element [START_REF] Johansson | Structural behavior in concrete frame corners of civil defense shelters, non-linear finite element analyses and experiments[END_REF], while in a three- dimensional analysis, c h may be approximated by the cube root of the volume of the element.

It is worth pointing out that satisfying Eq. ( 8) also ensures a relative mesh-objectivity in maintaining a target amount of the fracture energy in a finite element model.

In the existing linear softening model in AUTODYN, Eq. ( 8) is used to first establish the crack limit strain frac ε for a given fracture energy f G under a quasi-static condition. This crack limit strain is then kept unchanged during the response. Under dynamic loading, this scheme effectively results in an almost proportionate increase of the fracture energy as the dynamic tensile strength increases with the strain rate. In the bilinear softening model implemented by Leppanen [START_REF] Leppanen | Concrete subjected to projectile and fragment impacts: modelling of crack softening and strain rate dependency in tension[END_REF], which also follows the Gylltoft bi-linear function in Fig. 8, the two softening slope values were evaluated from the linear softening slope calculated by AUTODYN such that the same fracture energy as in the linear softening model is retained.

This implies that the fracture energy achieved in such a bi-linear scheme will also increase with the strain rate in a similar way as the linear softening model.

M A N U S C R I P T A C C E P T E D ACCEPTED MANUSCRIPT

13 However, so far the experimental data regarding the strain rate effect on the fracture energy of concrete has been very scattered [START_REF] Weerheijm | Tensile failure of concrete at high loading rate: New test data on strength and fracture energy from instrumented spalling tests[END_REF][START_REF] Brara | Fracture energy of concrete at high loading rates in tension[END_REF][START_REF] Zielinski | Fracture of concrete and mortar under uniaxial impact tensile loading[END_REF]. Although some individual studies tend to suggest certain increase in the fracture energy at high rates, for example Weerheijm and Doormaal [START_REF] Weerheijm | Tensile failure of concrete at high loading rate: New test data on strength and fracture energy from instrumented spalling tests[END_REF], and Schuler et al. [START_REF] Schuler | Spall experiments for the measurement of the tensile strength and fracture energy of concrete at high strain rates[END_REF], in general it is still difficult to draw any clear correlation. Under such a circumstance, in the present study we choose to adopt a rate independent fracture energy approach in our implementation of the bi-linear softening model, as described in detail in what follows. The general effect will be discussed in association with the penetration simulation examples later.

According to the basic bi-linear relationship shown in Fig. 8, it can be easily figured out that

frac ts f ε / 4 k 1 = and 1 2 k 1 . 0 / 4 . 0 k = = frac ts f ε
, where ts f denotes the static tensile strength.

By satisfying the fracture energy equation ( 8), we have ( )

c f frac ts frac ts frac ts ts h G f f f f d frac / 4 2 6 5 3 2 6 3 0 = × = × × + × + = ∫ ε ε ε ε σ ε (9) Thus: c ts f frac h f G 4 = ε (10)
and hence following Fig. 8,

f c ts frac ts G h f f d d 2 1 / 4 k = = - = ε ε σ , f c ts G h f k d d 10 1 . 0 k 2 1 2 = = - = ε σ (11)
In the damage-based algorithm adopted in AUTODYN, the softening slope parameter is specified and evaluated in terms of the damage index. To distinguish from the slope defined in Eq. ( 11) the softening slope in the damage-strain scale is denoted as k D herein. Also, denoting the damage induced by the tensile cracking as t D , we have

ε d dD t = D k ( 12
)
Similar to the general damage definition, t D varies from 0 to 1. In the calculation, t D is evaluated as the total stress reduction with respect to the concrete tensile strength, i.e.,

ts ts t f f D ) ( σ - = (13)
Subsequently, the two slope parameters become:

f c ts t G h f d dD = = ε D1 k , f c ts G h f 10 k 10 / 1 k 1 D2 = = (14)

M A N U S C R I P T A C C E P T E D

The actual energy dissipation over the softening process in a dynamic loading condition may be controlled by replacing the static tensile strength ts f in Eq. ( 14) with a factored dynamic strength parameter. In the present study, we propose to keep a rate independent fracture energy, and this can be achieved by replacing ts f directly with the variable dynamic tensile strength td f , i.e.,

f c td G h f = D1 k , f c td G h f 10 k D2 =
, where

ts td f f × = ) ( DIF ε& (15)
It should be noted that the damage incurred in the tensile cracking regime ( T D ) mentioned above will understandably cumulate into the general damage (D) in the overall evolution of the material damage. Therefore, if the subsequent response of the element develops into the normal plasticity regime governed by the RHT model, the material behaviour will carry an influence from T D .

To demonstrate the adequacy of using the present bi-linear tension softening model as compared to the linear softening model, numerical tests are performed to simulate the uniaxial tension of class 35-MPa concrete with a quasi-static tensile strength of 3.5 MPa. The characteristic length is assumed to be 10mm, with the specific fracture energy f G = 100 J/m 2 .

The input tensile strength for fracture ( input td f ) is 3.5 MPa. Two strain rates equal to 20 s -1 and 100 s -1 , respectively, are considered.

Fig. 9 shows the tensile stress-strain curves generated by the linear crack softening model for the two different strain rates. It can be seen that the fracture energy measured by the area under the stress-strain curve increases proportionately with the increase of the dynamic tensile strength, and this could result in an overestimation of the energy dissipation. On the other hand, as shown in Fig. 10, the implementation of the present bi-linear softening model enables the realization of a pre-defined fracture energy for different strain rates. In fact, by adjusting the slopes of the bi-linear damage curves (k D1 and k D2 ), as mentioned earlier, it would be possible to reflect a certain degree of the rate effect on the fracture energy if future experimental evidence indicates that this is more appropriate.

Generally speaking, with the adoption of the crack softening model, the triaxial tension behavior of concrete can be well represented, instead of the unrealistic perfectly-plastic

M A N U S C R I P T A C C E P T E D ACCEPTED MANUSCRIPT

response resulted from the use of the plasticity-damage model. Fig. 11 shows the improved isotropic tri-axial tension response generated by the present bi-linear crack softening model.

Numerical examples and comparison with experimental results

The improvements of the RHT model with the proposed modifications have been clearly demonstrated at the constitutive modeling level by the numerical tests on single-element specimens under various stress conditions. In this section, the improved performance of the modified RHT model is further verified through the numerical simulation of a complex problem involving impact and penetration. The key response parameters predicted by the numerical calculations are compared with physical experimental results.

The experiments of impacting plain concrete targets by steel projectile reported by Hansson [START_REF] Hansson | Numerical simulation of concrete penetration[END_REF] and Unosson and Nilsson [START_REF] Unosson | Projectile penetration and perforation of high strength concrete: experimental results and macroscopic modelling[END_REF] are simulated. Two characteristic response parameters, namely the depth of penetration and the projectile exit velocity, are used for a verification purpose. In the experiment by Hansson [START_REF] Hansson | Numerical simulation of concrete penetration[END_REF], the crater size is also available and this is compared with the simulation result as well.

General modeling considerations

For the numerical simulation of solids involving large deformation, such as the present problem with penetration of hard projectile in concrete, several computational methods exist for the modeling of the deformation and the movement of the solid materials for example Lagrangian method, Eulerian method, the Arbitrary Lagrangian Eulerian (ALE) method, and various meshless methods such as the Smooth Particle Hydrodynamics (SPH) method.

In AUTODYN, the RHT model may be used in a standard Lagrangian finite element environment, and it may also be used with the SPH method. In the present simulation of the penetration/perforation tests, the standard Lagrangian finite element method is used for modeling both the projectile and the concrete target. To tackle the numerical difficulty that could arise when elements incur severe distortion, the so-called element erosion technique is employed.

It should be mentioned for the penetration/perforation type of analysis, where the element erosion is primarily engaged for numerical considerations, the erosion strain limit is usually

M A N U S C R I P T A C C E P T E D ACCEPTED MANUSCRIPT 16
assigned to be large enough so as to minimize any adverse effect from removing elements.

However, there is still some trade-off between retaining the residual effect of a distorted element and the numerical errors due to excessive distortion, in addition to the modeling error.

Therefore to some extent the choice of a proper erosion limit is still a case dependent, somewhat empirical matter. For penetration and perforation simulations, our experience by performing a sensitivity study with erosion strains ranging from 50% to 350% tends to suggest that 150% or around that level is a good choice. This also echoes the recommendations made by some other researchers (e.g., [START_REF] Leppanen | Dynamic behaviour of concrete structures subjected to blast and fragment impacts[END_REF]). Hence, in the present simulations a strain limit of 150% is adopted for activating the element erosion.

Simulation of the experiment by Hansson [34]

In the experiment conducted by Hansson [START_REF] Hansson | Numerical simulation of concrete penetration[END_REF], a projectile was shot with zero attack angle into a large cylinder target made of plain concrete. The steel projectile has an ogive nose of caliber-radius-head (CRH) 3.0, length 225mm, diameter 75mm, and density 7830 kg/m 3 . The total mass of the projectile is 6.28 kg. The steel material has the following properties: bulk modulus 159 GPa, shear modulus 81.8 GPa, and yield stress 792 MPa. The impact velocity was measured to be 485 m/s.

The cylindrical concrete target has a length of 2.0 m and diameter of 1.6 m. The concrete compressive strength obtained from tests of 150-mm cubic specimens is about 40 MPa. The tensile strength is determined to be 2.64 MPa and the fracture energy is 100 J/m 2 .

The post-test measurement from two shots gave a penetration depth of 655-660 mm. The dimension of the crater produced was also measured and the diameter was about 800mm.

Four comparative simulations are performed to demonstrate the improved behaviour of the modified RHT model as compared to the results using the standard RHT model. The computational model settings are kept the same among the four simulations, except the RHT material model. A uniform mesh size of 8 mm is found to be suitable and is used in the simulations.

The four different RHT model settings used in the four simulations, respectively, are designated as follows:

-"CSA-NDIF": RHT with linear "crack-softening" model, and without DIF -"CSA-UDIF": RHT with linear "crack-softening" model, and with modified DIF -"RHT-M": modified RHT model, as detailed in Section 2.

Fig. 12 shows the attenuation of the projectile velocity as it penetrates into the concrete target in the four different simulations. The final damage patterns of the concrete targets are compared in Fig. 13.

When the standard RHT with a tensile plasticity-damage model is used (simulation "RHT1"), the predicted depth of penetration is about 430mm as compared to the measured 655 mm in the physical experiment, i.e., with an underestimation by about 50%. As will be shown later, a similar problem also occurs when this model setting is applied in the simulation of the perforation/penetration tests. A significant overestimation of the fracture energy dissipation under the plasticity-damage model, as discussed in section 2.2, is deemed to be responsible for the marked underestimation of the penetration depth. It is also interesting to note from Fig. 13 that a visible rebound occurs in the RHT1 simulation. This phenomenon also tends to indicate that the material appears is overly strong in the fractured zone in front of the penetration tunnel.

In the simulation "CSA-NDIF" where the linear crack softening model is used, without considering any tensile DIF, it can be expected that the material is considerably weak in tension. As a result, the simulated penetration depth is found to be 801mm, which is about 23% higher than the measured result. The concrete damage pattern shown in Fig. 13(b) exhibits much more extensive damage as compared with Fig. 13(a). Besides, from Fig. 13 (b) it can also be observed that noticeable damage in the form of scabbing also occurs at the rear side of the target, and this again can be attributed to the weaker tensile strength of the material as represented by this particular model setting. It is noted that no rebound occurs in this simulation.

In the third simulation "CSA-UDIF", which follows the same model setting as "CSA-NDIF" except the use of the modified DIF for tension, the material behaves much stronger in resisting the penetration. In conjunction with the overly estimated fracture energy due to the linear crack softening model, the predicted depth of penetration sharply reduces to 622 mm, which is lower than the experimental result, while the diameter of the crater becomes significantly under-predicted, with a value of 520 mm as compared to the measured 800 mm.

M A N U S C R I P T A C C E P T E D

In the final simulation "RHT-M", the modified RHT model is used with a proper consideration of the tension DIF, the fracture energy and the residual strength surface. The overall improvement in the simulation results is evident. The depth of penetration is predicted to be 685 mm, which is very close to the measurement of 655 mm, while the simulated crater diameter is 720mm which also agrees well with the experimental result of 800 mm.

It is worth keeping in mind that the experimental data from penetration/perforation tests often involve a large scatter. Therefore, caution should be exercised when interpreting the comparison with limited experimental data. The comparison shown above is focused on a relative observation with regard to the effect of the proposed modifications in a real problem simulation.

Simulation of the experiments by Unosson and Nilsson [3]

Unosson and Nilsson [START_REF] Unosson | Projectile penetration and perforation of high strength concrete: experimental results and macroscopic modelling[END_REF] conducted two series of experiments, namely a series of perforation tests, in which the projectile breached through the target and exited with a residual velocity, and a series of penetration tests, where the projectile came to rest inside the target. In both cases, the projectile was shot in the normal direction to a plain concrete target of cylindrical geometry. The steel projectile has an ogive nose with caliber-radius-head also equal to 3.0.

The total length of the projectile is 225mm and the diameter is 75mm. The total mass of the projectile is 6.3 kg. The steel material of the projectile has a yield stress of 2.0 GPa.

In the perforation experiments, the length (thickness) of the target is 0.4 m and the diameter is For each series of the tests, three shots were performed in order to observe the consistency of the test results. The target specimens were cast from the same batch of concrete. Table 1 gives the projectile impact velocities and the measured results. For the perforation tests, the mean exit velocity is about 291 m/s, while for the penetration tests, the mean penetration depth is approximately 0.5 m. The variation of the individual test results from the mean is within 5%

for the perforation tests and 10% for the penetration tests.

M A N U S C R I P T A C C E P T E D

For the simulations of both series of tests, a uniform mesh size of 5mm is used. This is consistent with the mesh size of 8 mm used in the simulation of Hansson's test, considering the difference in the overall dimensions of the concrete targets. Similar to the simulations for Hansson's experiment, four different simulations are carried out for each type of tests, using the four different concrete material model settings as described in Section 3.2.

Fig. 14 shows a comparison of the attenuation of the projectile velocity with the penetration distance in the perforation simulations using models "RHT1" and "RHT-M", respectively.

Note that the target thickness is 0.4 m, so the terminal velocity at penetration distance of 0.4 m represents the exit velocity. The damage patterns just before the perforation are shown in Fig. 15.

From Fig. 14, it can be observed that the projectile exit velocity from the simulation using the "RHT1" setting with a plasticity-damage model for tension is about 200 m/s, which is much lower than the average test result of 291 m/s. With the modified RHT model, the simulation results are markedly improved, and the simulated exit velocity is about 335 m/s.

The simulation results for the penetration tests are depicted in Fig. 16 and 17. Similar to the observations made from the simulation of Hansson's experiment described in Section 3.2 and the perforation tests described above, the "RHT1" model again exhibits an overly strong resistance and high energy absorption capacity of the concrete, leading to a considerable underestimation of the penetration depth equal to 260 mm as compared to the measured value of 500 mm. Also, after reaching the maximum penetration depth, the projectile is bounced back at a certain speed (herein equal to about 50 m/s), as clearly seen from Fig. 17(a). This phenomenon was contrary to the observation from the actual tests, where the projectile was found to be embedded in the targets.

The simulation results using the modified RHT model show clear improvements. The simulated depth of penetration is about 460 mm, which is very close to the measured 500mm.

It is worth mentioning that Unosson and Nilsson [START_REF] Unosson | Projectile penetration and perforation of high strength concrete: experimental results and macroscopic modelling[END_REF] actually conducted numerical simulations for this penetration test also. Their simulations were performed using LS-DYNA [START_REF]LS-DYNA Keyword User's Manual, version 970[END_REF], and the K&C concrete model [START_REF] Malvar | A plasticity concrete material model for DYNA3D[END_REF][START_REF] Malvar | K&C concrete material model Release III -Automated generation of material model input[END_REF] was employed for modeling the concrete material. Their results

showed that the projectile could not come to rest in the target; instead, perforation occurred with the projectile exit velocity being as high as 200 m/s.

  The evaluation is performed by single finite element numerical tests. The results will highlight the following: a) under a triaxial extension condition (corresponding to the tensile meridian), the model produces a stress-strain behavior that differs from what might generally be anticipated under such stress conditions, b) the default parameter configurations of the tensile-to-compressive meridian ratio requires modification to produce results more consistent with experimental observations, c) the ratedependency of concrete in tension needs to be updated to keep in line with generally accepted macroscopic dynamic enhancement functions. Furthermore, when the crack softening model in AUTODYN is employed to augment the RHT model concerning tension softening, the M A N U S C R I P T A C C E P T E D ACCEPTED MANUSCRIPT 4 softening law should be carefully formulated to ensure an anticipated softening process while maintaining specified fracture energy. The proposed modifications are presented along with brief descriptions of the background theory and experimental observations. These modifications are implemented with user coded subroutines via the respective interface modules provided by AUTODYN. The modified behaviour of the material model is demonstrated with numerical tests. The improvement of the modified material model is further verified via numerical simulations of concrete penetration by steel projectile, and comparisons are made among the predictions using the original RHT model, the modified RHT model proposed in this paper, and experimentalempirical results with regard to such characteristic responses as depth of penetration, projectile exit velocity, as well as size of the crater.

  for a comparison. It can be seen that the modified tensile meridian maintains under the failure M A N U S C R I P T A C C E P T E D ACCEPTED MANUSCRIPT 6

  and 1 C are two constant coefficients and c f is the unconfined concrete compressive strength. In AUTODYN, the suggested values of 0 C and 1 C are respectively

above 0 C and 1 C

 1 values is shown in Fig. 5. As can be observed, the corresponding ( ) p ψ appears to match the piecewise expression given by Eq. (5) in almost the entire pressure range, except for pressure well below 3 together with the change of the residual strength surface as described in Section 2.1, the concrete biaxial compression response can be reasonably reproduced by the model. As shown in Fig. 6, for the 35-MPa concrete, the biaxial compressive strength produced by the modified model becomes very close to the expected value of 41 MPa, while the result produced using the default ( ) p ψ in the standard RHT is about 30% larger.

1. 4 m

 4 . The target used in the penetration experiments has a length of 0.8 m and a diameter of 1.4 m. The targets are all made of high strength concrete, with an unconfined compressive strength of 153 MPa. The tensile strength of the concrete is determined to be 8.2 MPa and the fracture energy is 162 J/m 2 . The density of the concrete is 2770 kg/m 3 .

  The RHT material model has a comprehensive framework that encompasses many important features of concrete-like brittle materials under high impulsive loading. However, numerical tests indicate that this material model, as implemented in AUTODYN, falls short in representing the concrete behaviour under certain loading conditions, particularly concerning the tension response and softening behaviour. To a certain extent, these problems may be corrected by appropriately determining the influencing model parameters. The present paper proposes to rectify the issues by incorporating modifications to the model formulation. The proposed modifications include the adoption of a Lode angle dependent residual strength surface, a modified definition of the pressure-dependency of the tensile-to-compressive meridian ratio, and the use of a common (bi-linear) dynamic increase factor function for the tensile strength. Furthermore, a modified bi-linear crack softening law is proposed to control the dynamic tension softening process.The above modifications are implemented to the RHT model in AUTODYN through user codes. With the modifications, the RHT model is found to behave more realistically in modeling the concrete behaviour in tension as well as in compression. The unwanted hardening phenomenon of the model under specific stress conditions such as a biaxial compression is eliminated due to the incorporation of the Lode angle dependent residual strength. The proposed bi-linear crack softening function is capable of satisfying a given fracture energy for varying strain rates, and thus avoids the overestimation of the energy consumption in the fracture process.Numerical simulation of penetration of concrete targets by steel projectile is conducted to further evaluate the performance of the modified RHT model in real applications. The results from simulations of a series of physical penetration/perforation experiments demonstrate appreciable improvements in the damage patterns, as well as in the predicted parameters including the depth of penetration, projectile exit velocity and the size of the crater5. References[1] Riedel W, Thoma K, Hiermaier S. Penetration of reinforced concrete by BETA-B-500-numerical analysis using a new macroscopic concrete model for hydrocodes. Proceedings of 9 th

Fig. 1 .Fig. 2 .Fig. 3 .Fig. 4 .Fig. 5 .

 12345 Fig. 1. Stress-strain curves under different loading conditions corresponding to the tensile meridian.

Fig. 6 .Fig. 7 .

 67 Fig. 6. Improved biaxial compression stress-strain relationship by the proposed ( ) p ψ .

Fig. 8 .Fig. 9 .Fig. 10 .Fig. 11 .Fig. 12 .Fig. 13 .Fig. 14 .

 891011121314 Fig.8. Illustration of uniaxial tension bi-linear crack opening model[START_REF] Gylltoft | Fracture mechanics models for fatigue in concrete structures[END_REF].

Fig. 15 .Fig. 16 .Fig. 17 .

 151617 Fig. 15. Simulated damage patterns for the 400 mm thick perforation tests.

Table - 1

 - Measured results of the perforation and penetration tests

	Test category	Shot no.	Projectile impact velocity (m/s)	Projectile exit velocity (m/s)	Depth of penetration (m)
		1	616	276	N.A.
	Perforation test	2	616	303	N.A.
		3	618	293	N.A.
		1	617	N.A.	0.45
	Penetration test	2	612	N.A.	0.54
		3	619	N.A.	0.51

& & & & &(6)

& & & & &

M A N U S C R I P T A C C E P T E D ACCEPTED MANUSCRIPT


Ivan Ruchkin
email: ruchkin.ivan@gmail.com

Vladimir Prus
email: vladimir.prus@gmail.com

Single-window integrated development environment

Keywords: integrated development environment (IDE), graphical user interface (GUI), usability, widget, single-window interface/design/approach, tool view (utility window), KDevelop, Microsoft Visual Studio, Eclipse, Code::Blocks, NetBeans. I

This paper addresses the problem of IDE interface complexity by introducing single-window graphical user interface. This approach lies in removing additional child windows from IDE, thus allowing a user to keep only text editor window open. We describe an abstract model of IDE GUI that is based on most popular modern integrated environments and has generalized user interface parts. Then this abstract model is reorganized into single windowed interface model: access to common IDE functions is provided from the code editing window while utility windows are removed without loss of IDE functionality. After that the implementation of single-window GUI on KDevelop 4 is described. And finally tool views and usability of several wellknown IDEs are surveyed.

INTRODUCTION

There is a wide variety of tools that software engineers use to write the codefrom simple text editors, such as Notepad or Kate (which offer only basic text highlighting) to elaborate integrated development environments (IDEs) like Eclipse or Microsoft Visual Studio. IDEs bring together different tools improving convenience, and also providing features not possible with individual tools. For example, reliable code-completion is only possible when the editor, the compiler, and the build system work closely together.

But despite those attractive features many developers find IDE hard to use and stick with simple editors [START_REF] Developpez | Les meilleurs environnements de developpement[END_REF]. Reasons for that are different and large usability study [START_REF] Nielsen | Usability Engineering[END_REF] is required to completely and accurately determine them. However, anecdotic evidence shows that many users complain about the IDE tool viewswhich are auxiliary windows typically docked around the editor area, also called utility windows [START_REF] Szymczyk | Reducing XCode's Window Clutter[END_REF] [START_REF] Stephens | 10 Things NetBeans Must Do to Survive[END_REF]. One problem is that a dozen of available tool views just confuse a new user. But a deeper problem is that the tool views are actually required in a number of common workflows. And if a given tool view is repeatedly required, a user is faced with unpleasant choiceeither to keep the window always visible, taking space from the source editor, or to constantly open and close it. One way to address this usability issue with tool views is to remove them altogether. Of course, we propose this only as research experiment: remove all tool views, design alternative mechanism to support common workflows and then perform a usability study. These steps allow us to determine a set of tool views that users cannot live without and have to be put back. But we also hope that some utility windows can be eliminated, resulting in an overall usability improvement. One apparent example of removable tool view is build results view which shows errors and warnings. It only makes sense to process error messages from the first to the last one (as later error can be induced by the earlier) and therefore there's no necessity of showing a list of errorswe can immediately display the first error inside the text editor.

So we come to the idea of IDE with the single window hosting a text editor. Researching such approach requires:

 designing conceptual single-window IDE interface,  implementing it in certain IDE,  usability testing [START_REF] Nielsen | Usability Engineering[END_REF] of implemented GUI and comparing results to existing popular IDEs. This paper is a work-in-progress report that covers only first two steps. The exact plan of this paper:

 Create a model of IDE tool views by observing them in the most popular development environments [1][5]. This model includes a set of abstract tool views with description of their structure and usage.  Design a conceptual single-window IDE GUI by removing the utility windows from IDE tool view model.  Implement the single-window interface in KDevelop integrated development environment.  Survey existing IDE and find out whether they can be used without tool views. It is difficult to move functionality of all tool views to text editor window. Trying to do this can cause usability problems [START_REF] Krug | Don't Make Me Think A Common Sense Approach to Web Usability[END_REF]. To solve this issue we introduce new widgets and mechanisms to display information inside and near text editor. These widgets are described while designing a conceptual single-window interface.

In the following section the IDE tool view model is proposed.

II. MODEL OF IDE TOOL VIEWS

In this section we build a model of IDE tool views. This model describes a set of abstract tool views and their functions. Each abstract tool view is generalization of similar real tool views from existing IDEs. We build such model to be able to construct a generally useful set of interface improvements, as opposed to fixing problems in a single arbitrary selected IDE.

Development process greatly depends on the programming language. To limit the scope of research we only consider development in a compiled object-oriented language such as C++, Java, or C#. According to [START_REF] Developpez | Les meilleurs environnements de developpement[END_REF] [START_REF] Garvin | Software Development Platforms -2009 Rankings[END_REF], the most popular IDEs for these languages are Visual Studio, NetBeans, Eclipse, KDevelop, and Code::Blocks. powerful tool to provide various operations: a user accesses it quicker than the main menu and learns faster. Due to work-in-progress paper size limit, we omit the full study of several IDEs and their tool views. The result of this study is a set of abstract tool views, collected from examined IDEs. The key abstraction points were tool view structure and functionality.

We should remark that some tool views are actually documents, displayed outside editor. A good example of document-window is "Output View" in Visual Studio. Such views should be promoted to regular documents and shown in one of text editor tabs. We take only Variables view as an example of such document-like windows, though there are more of them in existing IDEs.

Here we name only the most significant abstract tool views, which compose the tool view model:

 Project view. It

III. CONCEPTUAL SINGLE-WINDOW DESIGN

This section shows the process and reasoning of creating a single-window IDE design based on tool view model from the previous section.

A. Single-window design: idea

The idea of this paper is creating a usable graphical interface design for IDE without tool views. Our goal is to reduce the number of open tool views while working with IDE and to carry over the tool views functionality into the text editor.

It is very difficult to meet this goal with the only text editor window. Thus we should introduce several new GUI elements for our single-window design. Those elements address tool view usability problems by (i) taking, when inactive, much less screen space than a tool view (or no space at all) and (ii) appearing when necessary, without explicit user interaction. These visual elements are covered in the next subsection. `

B. Single-window design: additional widgets

We add widgets into single-window interface or considerably enhance the functionality of existing widgets and use them to achieve the goal from the previous subsection. Each of following paragraphs is dedicated to an additional widget.

Breadcrumbs navigation bar. It is a widget that represents a path in a certain tree to a currently selected object. The most common example is a file system breadcrumbs bar that shows a path to current file or directory. The bar is separated into blocks, each one representing a node in the path. Each block can be decorated with an icon or color and, on mouse click, displays a context menu with the list of elements on the same level of hierarchy. The context menu is used to change the currently selected object or to operate over other objects. The benefit of breadcrumbs lies in the principle of locality [START_REF] Krug | Don't Make Me Think A Common Sense Approach to Web Usability[END_REF] [8]: a user tends to work with objects closer to his current work context. For our purposes, we propose that a single breadcrumbs bar supports different modesthat is, different meanings of what a current item mean and what hierarchy is displayed. Mode of breadcrumbs can be conventional (navigation in file system) or advanced (navigation in frame stack or classes). We describe it in detains in following subsections. Breadcrumbs navigation for file path is shown on the Picture 1.

Enhanced status bar.

Although status bar is a standard part of IDE GUI, it has to be considerably enhanced to meet the needs of single-window design. The enhanced status bar has two parts: static and dynamic. The former part is place for small (not bigger than icon plus a couple of symbols) customizable widgets that are to display information on current IDE state (for instance, number of changed files in VCS working copy). The static area should contain information that user requires occasionally [START_REF] Kauffman | GUI Bloopers 2.0 Common User Interface Design Don'ts and Dos[END_REF]. The dynamic part shows messages about events in the IDE (for example, project build finished). This part shows one message at a time and can display a dropdown list of recent events so a user can choose any of them. Both status bar areas support customizable actions for left click on their parts (static widgets and messages respectively). You can see the enhanced status with several static widgets, dynamic area and setup dialog on the picture 2.

Text editor inserts. We want to show information linked with certain objects (variables, functions, etc.) in program code. Along with traditional ways of presenting information in text editor window (tooltips, context menus) we are going insert widgets between lines. These inline widgets can contain some information and control elements like buttons. Inline widgets are preferable when we want to display something independent on user's action. Good example is showing build errors in text (see picture 3): after build system encounters an error it should be displayed

` immediately, not after user hovers mouse over error line or invokes context menu

We come to the discussion of creating single windowed interface from the model created in section II. Now we discuss each of abstract tool views listed in the previous section. We determine their main use cases and show how these tool views can be removed from user workflows.

C. Single-window design: project view

Project view is probably the most common type of utility window. It contains a tree of project files. Exact tree items can vary among IDEs, but the main use case is navigation through existing documents. The project view can be replaced with breadcrumbs bar. Breadcrumbs should display the path to current document, each block is a directory, and the final block is the edited document. In popup display for each block there is a tree view for directory represented by that block. In such way we allow user to navigate through project structure.

D. Single-window design: files view

Files view is very similar to project view in terms of structure and use cases. To replace files view we introduce a new mode for breadcrumbs. In this mode breadcrumbs bar shows a path from the root of file system to the currently edited file. Similarly to previous subsection each block is a directory, except the final one.

E. Single-window design: build results view

Build results window shows a list of errors and warnings. Its main use cases are viewing errors and warnings and showing corresponding source location in the editor. We replace this view functionality by displaying build issues between the lines of text and upgrading breadcrumbs bar.

Concerning errors, it's well known that the first error should be examined first, as other errors can be induced. So, it's reasonable to show the first error as inline widget, and just highlight other errors (for example, with red underlining). The inline widget should contain the text of error message, as well as "Next" and "Previous" to cycle through errors.

Warnings can't be handled like errors: their importance doesn't depend on their order. But displaying all warnings with inline widgets would takes a lot of place and can confuse a user [START_REF] Norman | The Design of Everyday Things[END_REF]. So, we just underline code lines with warnings and display the warning text (either as inline widget or as a tooltip) only when a user clicks on the line. Also, there should be an action "Ignore this warning forever" because if warning has been shown and wasn't fixed then developer most probably won't ever touch it.

In that way the navigation is carried over to text editor. But what about overview of errors and warnings? We want to handle this use case as well. Thus we mark the blocks of file system breadcrumbs (as well as objects in popup for blocks) with red dots, reflecting that there is an error in corresponding document or that there is a document with an error in the directory.

A user also wants to have information about the number of errors and warnings. We add "Errors number" static widget to status bar. Context menu allows user to enable/disable inline text widgets and breadcrumbs marks. Also there should be a dynamic status bar message about build end with the same functionality. So the build results view has been replaced.

F. Single-window design: code objects view

Code objects view is used to view program structure and go to declaration of a class or any other symbol (variable, function). As shown in the previous subsection breadcrumbs bar can provide navigation through tree structures. So we can add another mode to breadcrumbs or extend the document mode: each document in the tree contains all classes, functions, global variables and macros declared in it. Thus we can remove classes view by replacing it with breadcrumbs navigation.

G. Single-window design: tasks view

Tasks view contains a list of tasks, which are taken from text (from comments like "// TODO" in C/C++). We replace this view similar to build results view. First, we want to carry overview functionality, so we add marks to breadcrumbs indicating that a document has a task inside. Second, we add a several characters-wide inline element after each special word ("FIXME", "TODO", etc.) with buttons for going to next and previous task. And finally we add a static status bar element that displays a number of tasks in project and allows switching on/off breadcrumbs marks and inline widgets.

H. Single-window design: breakpoints view

Breakpoints view contains a list of breakpoints in the project with their attributes: file, line and condition. This utility window is used when a user wants to  create a new breakpoint,  view breakpoints and navigate to a random breakpoint,  edit properties of a certain breakpoint. We want to cover all three use cases using single-window interface. Creating new breakpoints can easily be transferred to a thin vertical line on the right of text (many IDEs already maintain such operation). Overview of breakpoints can be provided by special marks in the breadcrumbs navigation bar, while it displays path to current file, just like we did it with errors in subsection III-D.

Let's assume that properties editing mostly often occurs after the breakpoint is hit. Then we handle this use case through sending dynamic message to status bar and showing inline widget with breakpoint editable properties. Navigation and global editing of breakpoints are made available through breadcrumbs like build errors (see the previous subsection).

I. Single-window design: thread view and call stack view

Call stack view shows called subroutines for each of program threads. We can replace both these views by organizing following tree structure: the top-level element is a thread and its descendants are function calls in stack. With that said, we introduce a new mode for viewing call stack. Breadcrumbs bar automatically switches to that mode when debugging is paused. User can handle changing modes manually through the first block of breadcrumbs. That's it for call stack view and thread view.

J. Single-window design: variables view

This utility window shows a list of variables and expressions that are watched during debugging process. As ` stated before, this view is document-like and should be placed in text editor tabs. A user wants contents of this view during debugging, so we should split the text editor window and display watched variables and expression in parallel with debugged code.

K. Single-window design: resulting interface

In this part of the paper we described a single-window interface design based on IDE tool views model. We have determined only some of single-window interface functional capabilities, used to carry tool views functionality to text editor and additional widgets. Much more functions can be added to that interface to improve usability. For example, contents of context menus for breadcrumbs can be prioritized upon user's selections, but such enhancements are outside of this paper's topic.

Let's proceed to the implementation details of singlewindow interface.

IV. IMPLEMENTATION DETAILS

The single-window design has been implemented on the base of KDevelop 4 IDE, part of KDE project [10]. The source code of all components of KDevelop is open, which facilitated implementation of desired modifications. Implemented GUI parts can be seen on pictures 1 -3 above.

A. KDevelop 4 GUI

KDevelop GUI consists of interface parts that have been described in section II. The main window consists of dockable tool views and tabbed text editor view. KDevelop tool views include "File System" view, "Project" view, "Errors" view, "Breakpoints" view. Status bar is almost empty, containing only the progress bar for showing pending operations progress, so this space can be used to implement enhanced status bar. To plug text editor inside the main window KDevelop uses KParts [START_REF] Fremy | KDE Technology: KParts Components[END_REF], thus allowing a user to edit text with Kate editor [START_REF]Kate webstite[END_REF]. So, single-window interface can be implemented in KDevelop.

B. Implementation

To create single-window GUI in KDevelop the following components have been implemented:

 breadcrumbs navigation bar,  showing of errors and warnings between lines,  extended status bar. Breadcrumbs navigation bar is placed above the code editing window and shows the path to currently edited document. When user clicks any node of the bar, a context menu with file system for that node appears. To speed up access to frequently opened documents the list of currently opened files appears above other files.

Errors and warnings are shown in following way: only the first one appears after the line it refers to. The decision to show only one line has been made because programmer usually tries to fix the first errors as later ones can be caused by the first one. Along with the error information two navigation buttons are shown: "Next" and "Previous". These buttons can take user to neighboring errors.

Enhanced status bar meets the description from section III: it has dynamic and static parts. The static part accepts small widgets for changed files in working copy, number of tasks and number of background parser errors. Presence and order of these widgets can be customized by user. The dynamic part shows messages from removed tool views: that build is started and finished, messages from debugger, background parsing results. Clicking on a message allows user to open the tool view that sent the message.

Here follows a survey of the most popular IDEs.

V. EXISTING IDES This section examines the sets of tool views and their usability in several popular IDEs [START_REF] Developpez | Les meilleurs environnements de developpement[END_REF][5] [START_REF] Garvin | Software Development Platforms -2009 Rankings[END_REF]. Along way we note whether any of these IDEs can be used without tool views.

A. Visual Studio

Microsoft Visual Studio [START_REF]MSDN, Microsoft Visual Studio[END_REF] is one of the most popular commercial IDEs for developing in the C++ and C# programming languages. Visual Studio has several often used tool views described below.

 "Solution Explorer"a view displaying the tree of projects and files in current solution. A user operates with this view to create new files, open files (unless they are present in text editor's tabs), and observe the structure of projects.  "Class View" is a two-part window with a list of classes in the first part and contents of classes (attributes and methods) in the second part. This window is useful for looking through class structure and navigating to their declaration or their methods implementation in code.  "Output View"a view containing the results of code build with errors and warnings among them or program execution results. This window is vital for building process because a user views errors and navigates to them with this window.  "Code Definition Window"a utility window, browsing the definition for the currently selected object or function. It is used to quickly look at and probably edit the definition of class or function. Tool views in Visual Studio behave like described in section II and can be put in auto-hide mode, in which they expand only mouse cursor moves to their header and collapse to the screen border when cursor leaves them. That decreases the time user spends with tool views, but user can't remove them permanently: too much information is concentrated in them. For example, user can't open a new file without "Solution Explorer" and can't navigate through errors without the "Output" view. So there's no way to use Visual Studio without tool views.

B. Eclipse

Eclipse [14] is an open-source cross-platform IDE, mainly used for C++ and Java development. Tool views organization in Eclipse is similar to the one in Visual Studio but Eclipse auto-hide mode is less usable than in Visual Studio: it requires an extra click to open a hidden tool view. Also, a user can only toggle auto-hide mode of a certain tool view, not a whole dock area, like in Visual Studio.

Eclipse tool views resemble Visual Studio tool views. "Navigator", "Outline" and "Make targets" windows provide the navigation service through project files, identifiers, and make targets correspondingly. "Problems" and "Console" views are similar to Visual Studio "Output" view: they allow a user to look at errors and program output and go to errors in code. Thus, tool views in Eclipse play an important role in user's workflow and cannot be removed without replacing their functions with some other interface elements.

C. Code::Blocks

Code::Blocks [START_REF]Blocks website[END_REF] is an open source cross platform IDE, which is designed for convenient usage with different C++ libraries: GTK+, Qt4, OpenGL, FLTK, wxWidgets, Lightfeather. The user interface of Code::Blocks is less complex (fewer tool views and less their customizability) than one of Visual Studio and Eclipse, but that's just because of lower number of integrated features. Code::Blocks GUI has several tool views necessary for normal work:

 "Projects"a window for tree navigation through opened projects. This is counterpart of Visual Studio "Solution Explorer" and Eclipse "Navigator" window.  "Symbols"a tree navigation window through functions, classes and global variables. It is similar to Visual Studio "Class View".  "Logs" is a tabbed set of several windows: "Search results" (the list of found items), "Build log" (plaintext output of build tool), "Build messages" (a clickable list of errors and warnings), and some others. Code::Blocks has no auto-hide mode for tool views, and this makes its interface even less suitable for reducing user's interaction with tool views.

D. NetBeans

NetBeans [16] is an open source cross platform IDE, used massively for development on Java platform, but also can be used for some other languages including C++.

Tool views in NetBeans are organized just like in Visual Studio. The most used tool views are:

 "Projects" and "Files" windowstree views for navigating through projects and file system.  "Classes"a window for viewing classes and functions, like "Class View" in Visual Studio and "Symbols" in Code::Blocks.  "Build"a window with build results log, allowing a user to move to any error or warning.  "Navigator" windowa dynamic version of classes window, shows at which place in class and function tree a user's cursor is situated. This window is useful while browsing through highly nested code. Tool views in NetBeans can be put in auto-hide mode, called "Minimized" in the NetBeans interface. Unfortunately, a user can change the mode of only one window at a time. Tool views contain information and operations, which are essential for development process (for example, opening a new file through "Files" window), so IDE can't be used without constant interaction with utility windows. So we can conclude that NetBeans IDE envisages use of tool views in common developer workflows.

VI. CONCLUSION AND FUTURE WORK

This paper has proposed the single-window user interface for IDE to solve the usability problem of tool views. The first result is a model of IDE tool views. The second result of this paper is the conceptual design of single-window IDE interface. Key GUI elements of this interface are:

 breadcrumbs navigation bar,  enhanced status bar,  text editor window with inline message display functionality. The third result of this work is the partial implementation of this single-window design in KDevelop IDE.

Future work involves usability testing [START_REF] Nielsen | Usability Engineering[END_REF][6] of singlewindow interface to find whether usability problems are solved or at least reduced compared to traditional IDE GUI.

Picture 2 .

 2 Enhanced status bar. Picture 1. Breadcrumbs navigation bar. Picture 3. Inline error message.

  First, we need to list the common parts of an IDE interface to show the context in which tool views are used.GUI of a contemporary IDE consists of: Main menu, typically with a vast set of commands. It isn't easy for a new developer to discover all of operations in the main menu, that fact can cause usability issues[START_REF] Kauffman | GUI Bloopers 2.0 Common User Interface Design Don'ts and Dos[END_REF].

	 Customizable toolbar with command buttons. It
	facilitates accessing and learning IDE functions, but
	requires a careful selection of command to expose b
	default.
	 Text editor window. Obviously that's where
	program code is being edited. This area contains
	source code and is usually tabbed. Unfortunately, in
	common IDEs developer is drawn away from the
	text editor window because a lot of functions and
	information are spread across other UI elements,
	mostly utility windows.
	 Tool views. These are additional utility child
	windows inside IDE GUI that contain special
	instruments: errors view, call graph, project view
	and many others. Typically views can be docked on
	any side of text editor window, resized and made
	auto hiding -popping up when mouse cursor hovers
	over their header and closing when it leaves. Tool
	views occupy considerable amount of screen space
	and compete for it with text editor.
	 Status bar. It is a horizontal one text line-high widget
	in the bottom of IDE GUI that traditionally contains
	information on current operation progress and rarely
	some static information about current state of
	development.
	 Context menus in text editor window. That's a

  Code objects view. It is a tree view of code objects: classes, global functions, global variables and macros. Exact appearance and naming can vary depending on IDE, but all code objects views display class hierarchy as well as class methods and attributes.  Build results view. Shows a list of build errors and warnings if there were any. Allows a user to navigate to any issue by clicking on it.  Tasks view. Contains a list of tasks and lets a user navigate from them to text; in most cases, task is a comment from code, marked with a special word, for example "TODO", "FIXME", or "HACK".  Breakpoint view. Shows a list of all breakpoints, allows a user to switch them on/off, edit their condition and navigate to certain breakpoint.

	 Files view. It is a tree view of files in file system.
	This view allows a user to observe the files structure
	and operate over them.
	
	is a tree view of categorized project
	documents. This window is used to navigate through
	project and interact with documents.

 Threads view. This window contains a list of debugged application threads. Clicking on a thread results in navigating to its current execution point.  Call stack view. This view shows the stack of subroutine calls for every program thread while debugging an application. By clicking on any function call a user can open the definition of it in code editor.  Variables view. This utility window shows a list of variables and expressions monitored while debugging and their current values. So we have described a model of IDE tool views. This model is sufficient to introduce the single-window design.