Instruction: Write an abstract for the following acadamic paper.

Input:
Paper: we have recorded the flight of a fly during take off and landing using digital high speed photography . it is shown that the dynamics of flexible wings are different for these procedures . during this observation fly flew freely in a big box and it was not tethered .
Abstract: in this fluid dynamics video , we demonstrated take off and landing of a fly . the deformation of wings is in focus in this video .

Paper: the disciplined software engineering relies on software architectures to describe systems  @xcite . for modeling a software architecture , the academy proposed the architecture description language ( adl ) and their toolsets  @xcite . also , the industry has used adls to develop systems . industry examples are ( i ) @xmath0-adl has been used to architect and refine federated knowledge management systems in engineering ingegneria informatica - italy  @xcite ; ( ii ) and aadl ( architecture analysis & design language ) is a standard language for the society of automotive engineers  @xcite . according to the state - of - the - art  @xcite , the following concepts are relevant to describe software architectures : components and connectors ( respectively computational and communication elements ) , architectural constraints , non functional properties , and behaviour . software systems evolve over their life time  @xcite . dynamic reconfiguration is when the evolution is performed at runtime with no service disruption . the dynamic reconfiguration can be handled by architectural concepts in an adl . however among many existing adls , only few allow modeling dynamic reconfiguration . @xmath0-adl  @xcite , acme / plastik  @xcite , c2sadl  @xcite , daop - adl  @xcite , darwin  @xcite , dynamic wright  @xcite , rapide  @xcite , weaves  @xcite , and xadl  @xcite are typical examples . nevertheless , there is no current consensus about how adls should address reconfiguration , e.g. , what language constructs should be provided .    in this work , the goal is twofold : ( i ) to investigate the adls support for handling dynamic reconfiguration in the literature ; and , ( ii ) to illustrate how four well - known adls support dynamic reconfiguration : @xmath0-adl , acme , c2 sadl and dynamic wright . we chose these four languages because they rely on different paradigms : the higher order typed @xmath0-calculus  @xcite , first order predicate logic  @xcite , compo - nent- and event - based  @xcite , and , graph grammars and communicating sequential processes ( csp )  @xcite , respectively . they also complement each other as @xmath0-adl models the behavior of architectures , acme focuses on the structure , c2sadl make the attention for components and their concurrent events , and dynamic wright supports the definition of structure and behavior . this work is structured as follows . section  [ section : motivation ] motivates this work thanks to the example of a tcp / ip stack system . three scenarios illustrate three facets of dynamic reconfiguration . section  [ section : concepts ] presents the basics concepts of software architecture and dynamic reconfiguration . section  [ section : related - works ] details the related works about dynamic reconfiguration at the architecture level . section  [ section : comparison ] compares the four above - mentioned adls in the light of our example of section  [ section : motivation ] . section  [ section : conclusion ] concludes the paper with open issues that we note in the adl support for dynamic reconfiguration . dynamic reconfiguration aims at modifying the software systems at runtime with no service disruption . critical systems usually want to benefit of a dynamic reconfiguration because any service disruption may have substantial consequences . examples of critical systems are stock market quotation systems , telecommunications systems , safety systems , and air traffic control systems . however , there is no current consensus about how the software architecture should address dynamic reconfiguration at architecture level . does regular syntax for dynamic architectures allow the same reconfigurations as specific language constructs ? should the state of components and connectors be taken into account at the architecture level ?    to support this work , we rely on a simplified version of the tcp / ip stack ( fig . [ fig : tcpip - stack ] ) . each of the four layers ( application , transport , internet , and link ) is modeled as a component ( fig . [ fig : tcpip - system ] ) . we consider the three following reconfigurations :    1 . _ switch the application component . _ assume two alternatives : mpeg - decoder and h263-decoder . mpeg - decoder is used if _ bandwidth _ is high ( fig . [ fig : tcpip - mpeg ] ) . otherwise h263-decoder is selected ( fig  [ fig : tcpip - h263 ] ) . switching between mpeg and h263 starts a new stream . therefore , no state in the decoder needs be kept . we can therefore replace one component by another . insertion of a new component type . _ presume that the internet protocol version 6 ( ipv6 ) replace the version 4 ( ipv4 ) ( fig . [ fig : tcpip - ipv6 ] ) . the ipv6 component has backward compatibility with the ipv4 component . so it has the ports for both ipv4 ( for compatibility reason ) and for ipv6 ( new feature ) . therefore , the type of the component at the internet layer is changed : it has 2 additional ports . _ update a component type . _ assume that the algorithm of error control of the transport component is improved . when the error control algorithm is changed , the new behaviour needs to know the status of each packet ( acknowledged , sent , timeout , ... ) as well as the content of non - acknowledged packets ( in order to resend them ) . therefore , only the behaviour part of the component should be replaced . the state of the component should be unchanged . these scenarios cover a wide spectrum . they can either be programmed at design - time or be discovered at run - time . they feature reconfiguration at both type and instance level . they target both the structure and the behaviour of the architecture . we investigate the adls literature in order to illustrate how reconfiguration is supported in these scenarios .    in this paper , we focus on four adls that are representative of the main trends . each adls complement the other . the complement at the sense for describing an initial architecture as well as dynamic reconfiguration . we choose @xmath0-adl because it provides both description with behaviours thanks to its @xmath0-calculus roots . whilst the acme / plastik is a declarative language with focus on the architecture structure for both descriptions . while c2sadl is used to compose architectures based on component and dynamic reconfiguration based on architectural events . finally , dynamic wright provides support for architectural description based in graph - grammars and dynamic reconfiguration specification with a variant of communicating sequential processes ( csp ) . [ [ software - architecture - concepts ] ] software architecture concepts + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +    software architectures + describe systems by specifying their elements and the interactions between them  @xcite . in this work , we use the basics concepts defined in  @xcite : a _ component _ is an unit of computation and storage ; a _ connector _ is an unit of communication ; and , a _ configuration _ is a specification of a software architecture in terms of components , connectors , and relationship between them .    ports , roles , behaviours , constraints , and non - functional properties are other concepts defined in  @xcite used to describe these architectural elements . ports and roles are used to define the way of interaction , ports for configurations and components , and roles for connectors . behaviours are the architectural element internal computation . and the last two concepts , constraints and non - functional properties , are used to denote the assertions , invariants , quality of service that architectural elements are expected to meet .    also , we consider types and instances of configurations , components , and connectors for modelling a software architectures  @xcite . the types are abstractions like classes in the object - oriented paradigm which encapsulate both the structure and the behaviours that can be performed on its structure . these types will be used to build the instances and these instances will be used to describe software architectures .    fig . [ code : tcpip - acme ] illustrates in acme the basics concepts with our example tcp / ip stack system ( sec . [ section : motivation ] fig . [ fig : tcpip - system ] ) at instance and type level . the types are defined in the ` family ` statement block ( lines 1 - 18 ) while the instance level in ` system ` ( lines 20 - 30 ) . .... family tcpip_mf {    . . connector type tcpip_conn2layers {      providedrole source ;      requiredrole sink ;    } ;    component type tcpip_component {      port type datafrom extends providedport with { } ;      port type datato extends revidedport with { } ;      property type layer = enum{application , transport , internet , link }    } ;    component type tcpip_application extends tcpip_component with {      port datareceivedfromtransport : datafrom ;      port requiredservice : datato ;      property layer = " application " ;    } ;    . . }    system decoderstream : tcpip_mf = new tcpip_mf extended with {    component application : tcpip_application ;    component transport : tcpip_transpot ;    component internet : tcpip_internet ;    component link : tcpip_link ;        connector       application2transport , transport2internet , internet2link : conn2layers ;    attchments {      application.requiredservice to application2transport.source ;      application2transport.sink to transport.service ;        transport.requiredservice to transport2internet.source ;      transport2internet.sink to internet.service ;        internet.requiredservice to internet2link.source ;      internet2link.sink to link.service ;    }    . . } ....    [ [ dynamic - reconfiguration - concepts ] ] dynamic reconfiguration concepts + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +    a dynamic reconfiguration is a set of operations to modify an existing configuration at runtime . at the software architecture level , the operation is defined in terms of the architectural elements at type or instance level . scenario 1 is an example of reconfiguration at the instance level ( mpeg and h263 share the same type ) ; and scenario 2 is an example of reconfiguration at the type level ( ipv6 extends the type of ipv4 ) .    also , the dynamic reconfiguration can be foreseen or unforeseen  @xcite . the foreseen is a programmed dynamic reconfiguration specified at design time . while the unforeseen is an ad - doc defined at runtime . example of foreseen and unforeseen is the scenario 1 and 3 , respectively . in the scenario 1 , the architect specify at design time that the system modify itself when the bandwidth change . whereas the behaviour improvement is built at runtime as defined in scenario 3 . medvidovic and taylor  @xcite created a classification framework based on architectural elements and illustrated them with the following adls : acme , aesop , c2 , darwin , metah , rapide , sadl , unicon , weaves , and wright . however , this work has no focus on the dynamic reconfiguration . hence , its discussion about dynamic reconfigurations is limited , e.g. all adls were assessed only at the instance level , not at the type level . kacem _ et al . _ @xcite described the capabilities of darwin , archjava , olan , rapide , wright , and acme to support dynamic reconfiguration . they classify the adls as configuration and description language . the configuration language supports the description of a software system and limited dynamic reconfigurations , while the description language supports the specification of modifications to be applied to an existing architecture . despite this work focus is on dynamic reconfiguration , it also presents some limitations such as the fact that the evolution is applied only at instance level and do not take into account the behaviour of the architectural elements . bradbury  @xcite and bradbury _ et al . _ @xcite proposed a framework to compare fourteen formal specification approaches which support dynamic software architectures . amongst the criteria , bradbury _ et al . _ considered the basic operations , how they can be composed and whether they apply to variable sets of architectural element types . about the basic operations ( addition and removal of components and connectors ) , bradbury et al . showed that most approaches support them . also , they considered the criterion of operations composition ( basic , sequence , choice , and iteration ) . only 3 approaches ( community , dynamic wright , and gerel ) provide full support while the other only support basic composition . finally , bradury _ et al . _ mentioned that all approaches support only the types of architectural elements defined prior runtime , fixed sets of architectural elements . while adl surveys have reached good understanding of the concepts underlying software architectures ( medvidovic and taylor  @xcite ) , this is not true regarding dynamic reconfiguration at the architecture level . even bradbury  @xcite and bradbury _ et al . _ @xcite , probably the most complete surveys , do not consider operations such as insertion of configuration and behaviour modification . they do not recognize _ link _ and _ unlink _ as basic operations . however , they present the examples of these operations on some approaches , like gerel and c2sadl . considering the scenarios of section  [ section : motivation ] , these related works address only the first scenario ( partially ) but not the two last . consequently , it is clear that to discuss the three scenarios presented in section  [ section : motivation ] is essential to have a better understanding of the dynamic reconfiguration issues . these scenarios consider both instance and type levels , the basic operations include configurations , components , and connectors , as well as their structures and behaviours . in this subsection , we describe the scenarios defined in sec . [ section : motivation ] in all four adls : @xmath0-adl ( subsection  [ sec : pi - adl ] ) , acme / plastik ( subsection  [ sec : acme ] ) , c2sadl ( subsection  [ sec : c2sadl ] ) , and dynamic wright ( subsection  [ sec : wright ] ) . for each adl we show the purpose , the tcp / ip stack system , a solution for three scenarios , and discussion about this implementation .      [ [ purpose - of - the - adl ] ] purpose of the adl + + + + + + + + + + + + + + + + + +    @xmath0-adl is based on @xmath0-calculus and it is designed to describe the concurrent and mobile systems  @xcite . the description of architectural elements is mainly represented by ports and behaviour . [ [ dynamic - reconfiguration - support ] ] dynamic reconfiguration support + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +    this adl provides + support for foreseen and unforeseen dynamic reconfiguration . the foreseen can be described in the behaviour of any architectural elements . while unforeseen needs some support , e.g. , in the virtual machine ( vm ) , in order to obtain a root reference to the reconfigured system . in archware , this issue is addressed by the deep intrication between the toolset ( including the visual and textual editors ) and the vm thanks to the hyper - code technology  @xcite . [ [ initial - architecture ] ] initial architecture + + + + + + + + + + + + + + + + + + + +    the implementation of tcp / ip stack system is shown in fig . [ code : tcpip - piadl ] . the configuration is composed at lines 1 - 18 basically with a behaviour , statement ` behaviour ` is ... where ... ! ( lines 2 - 17 ) . this architectural behaviour defines the instances of components ( lines 3 - 6 ) and connectors ( lines 7 - 9 ) . the statement ` where ` in behaviour specifies the connections between components and connectors ( lines 11 - 16 ) . the example of component ` tcpip_application ` is partially showed at lines 20 - 35 : two ports and a behaviour . the component behaviour is implemented with two internal methods ( lines 24 - 25 ) and the definition of communication between its ports ( lines 27 - 33 ) .    .... archictecture tcpip is abstraction ( ) {    behaviour is compose {      application is tcpip_application ( )      and transport   is tcpip_transport ( )      and net         is tcpip_internet ( )      and link        is tcpip_link ( )      and app2transp is conn2layers ( )      and transp2net is conn2layers ( )      and net2link    is conn2layers ( )    } where {      appliation::request     unifies app2transp::source      and app2transp::sink    unifies transport::service      and transpost::request unifies transp2net::source      and transp2net::sink    unifies net::service      and net::request        unifies net2link::source      and net2link::sink      unifies link::service    } }    component tcpip_application is abstraction ( ) {     port service is { ... } .     port request is { ... } .     behaviour is {        processrequest is function(d : datatype):datatype { unobservable}.        processresponse is function(d : datatype):datatype { unobservable}.          choose {           via service::wait receive entrydata : datatype .           via request::call send processrequest(entrydata ) .        or           via request::response receive replydata : datatype . via service::reply send processresponse(replydata ) .        }     } }    component tcpip_transport is abstraction ( ) { ... }    component tcpip_internet is abstraction ( ) { ... }    component tcpip_link is abstraction ( ) { ... }    connector conn2layers is abstraction ( ) {    ...    port source is { ... }    port sink is { ... }      behaviour is { ... } } ....    [ [ scenario-1 ] ] scenario 1 + + + + + + + + + +    the implementation of scenario 1 in @xmath0-adl is composed by a component that performs the dynamic reconfiguration ( fig . [ code : scenario1-piadl ] ) . this component has two parameters : the application component and the system component . both are represented as a behaviour . the application component is a mpeg - decoder or h263-decoder . still , this component is structured with seven `` variables '' and a behaviour , lines 2 - 4 and 5 - 27 , respectively . the variables are used for behaviours of components and connectors . to perform the modification , the behaviour component use the following steps : decomposition the system behaviour ( line 6 ) ; assign the behaviours to variables ( lines 8 - 14 ) ; compose a new system behaviour ( lines 16 - 26 ) with a replaced application component ( line 20 ) . .... component reconfiguration is abstraction(application : behaviour , system : behaviour ) {     behaviours : sequence[behaviour ] . transport : behaviour . net : behaviour . link : behaviour . app2transp : behaviour . transp2net : behaviour . net2link : behaviour . behaviour is {        behaviours : = decompose system . transport : = behaviours::1::bhvr . net : = behaviours::2::bhvr . link : = behaviours::3::bhvr . app2transp : = behaviours::4::bhvr . transp2net : = behaviours::5::bhvr . net2link : = behaviours::6::bhvr . compose {           application and transport and net and link           and app2transp and transp2net and net2link        } where {           appliation::request     unifies app2transp::source           and app2transp::sink    unifies transport::service           and transpost::request unifies transp2net::source           and transp2net::sink    unifies net::service           and net::request        unifies net2link::source           and net2link::sink      unifies link::service        }     } } ....    [ [ scenario-2 ] ] scenario 2 + + + + + + + + + +    the implementation for the unforeseen scenario 2 is shown in fig . [ code : scenario2-piadl ] . this code is applied in a system at runtime to deploy the two new component `` type '' . first , the component type is a new protocol _ ipv6 _ ( lines 1 - 3 ) , and the second is a component to perform dynamic reconfiguration ( lines 4 - 32 ) . in order to execute this dynamic reconfiguration two steps are applied : ( i ) to obtain the root behaviour of the system , and ( ii ) to invoke the computation of the reconfiguration component . both operations are aided by toolset and hyper - code . the code of the reconfiguration component is described using the following steps : ( i ) to decompose the behaviours of the system in components and connectors ( lines 9 ) ; ( ii ) to assign to `` variables '' the instances of components that represent application , transport , and link ( lines 11 - 13 ) ; ( iii ) to attribute connectors to `` variables '' ( lines 15 - 17 ) ; ( iv ) to compose a new system behaviour ( lines 19 - 30 ) with a new instance of the protocol ipv6 component ( line 21 ) . as in the scenario 1 , when performing a new composition , the behaviour of the system is automatically updated . .... component tcpip_ipv6 is abstracion ( ) {    ... } component reconfiguration is abstraction(system : behaviour ) {     behaviours : sequence[behaviour ] . application : behaviour . transport : behaviour . link : behaviour . app2transp : behaviour . transp2net : behaviour . net2link : behaviour . behaviour is {        behaviours : = decompose system . application : = behaviours::0::bhvr . transport : = behaviours::1::bhvr . link : = behaviours::3::bhvr . app2transp : = behaviours::4::bhvr . transp2net : = behaviours::5::bhvr . net2link : = behaviours::6::bhvr . compose {           application and transport and link           and net is tcpip_v6           and app2transp and transp2net and net2link        } where {           appliation::request     unifies app2transp::source           and app2transp::sink    unifies transport::service           and transpost::request unifies transp2net::source           and transp2net::sink    unifies net::service           and net::request        unifies net2link::source           and net2link::sink      unifies link::service        }     } } ....    [ [ scenario-3 ] ] scenario 3 + + + + + + + + + +    in the scenario 3 it is also used the process of decomposition , modification , and composition , as showed above . we use the archware virtual machine facility to get a reference to the root of the target transport component . after , we make a modification into the behaviour of the component . at last , the archware virtual machine synchronize the system with this modification .    [ [ summary - of - pi - adl ] ] summary of @xmath0-adl + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +    with these implementations , some issues are identified on @xmath0-adl support for dynamic reconfiguration :    1 . changing types needs external help , e.g. toolset , hyper - code and @xmath0-arl . toolset and hyper - code are used for capturing , specifying the changes , and applying the changes . while @xmath0-arl is a language to specify refinements in the system ; 2 . instances modifications can be specified in architectural elements or also with toolset and hyper - code help . at first , usually the dynamic reconfiguration is tangled with nominally behaviour . however , we used other approach with a specific component to specify dynamic reconfiguration ; 3 .   for the third scenario , the @xmath0-adl do not provide a mechanism to design the intermediate states for updating the instances with the improvement of behaviour . however , if we use the @xmath0-arl approach , we can have better control ; 4 .   also with @xmath0-arl is possible build constraints and non - functional properties for architectural elements . however , it s not used to assess dynamic reconfiguration . [ [ purpose - of - the - adl-1 ] ] purpose of the adl + + + + + + + + + + + + + + + + + +    acme / armani is a declarative language based on the first - order predicate logic  @xcite . its initial purpose was to define a common interchange language for architecture design tools . also , its statements are designed to describe the architectural structures at instance and type levels . the extensions  @xcite to support dynamic reconfiguration preserves these initials purpose , and are named as acme / plastik . thereafter , any configuration and dynamic reconfiguration specified using this extension ( acme / plastik ) are based on the structure of an architecture . [ [ dynamic - reconfiguration - support-1 ] ] dynamic reconfiguration support + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +    acme / plastik permits to describe foreseen and unforeseen dynamic reconfiguration . to unforeseen reconfiguration it is possible to describe as a specific behaviour of a configuration with the ` on ( $ conditional\_expression$ ) do { $ operations$ } ` statement . unforeseen reconfiguration can be expressed in a script that will be applied in the system at runtime aided by a toolset provided by the plastik framework . both , @xmath1 and script are composed with acme statements and its acme / plastik extension . the @xmath2 is composed in the armani language  @xcite . [ [ initial - architecture-1 ] ] initial architecture + + + + + + + + + + + + + + + + + + + +    the example of the tcp / ip stack system in acme is showed in fig . [ code : tcpip - acme ] . the types are specified in the ` family ` statement while the instances are in the ` system ` statement . for types , a connector ( lines 3 - 6 ) and two components ( lines 7 - 11 and 12 - 16 ) are implemented as example . the configuration is composed by the component instances ( lines 21 - 24 ) , connector instances ( lines 26 - 27 ) , and the connections between them ( lines 28 - 37 ) . [ [ scenario-1 - 1 ] ] scenario 1 + + + + + + + + + +    the implementation in acme / plastik of scenario 1 is showed in fig . [ code : scenario1-acme ] . the configuration is named with ` streamdecodersystem ` and it extends the ` tcpip_mf ` and ` plastikmf ` . the ` tcpip_mf ` is showed in fig .  [ code : tcpip - acme ] while ` plastik_mf ` in  @xcite . such configuration consists of : the insertion of two new components ( type and instance ) in lines 2 - 5 and line 6 ; the instantiation of components and connectors ( omitted with comment and @xmath3 in lines 7 - 8 ) ; the linking of components and connectors ( omitted with comment and @xmath3 in lines 7 - 8 ) ; and the specification of two dynamic reconfiguration situations , lines 12 - 19 and 21 - 28 . both dynamic reconfigurations use the same similar description . first , the conditional expressions are ` link.bandwidth = = ' low ' ` and ` link.bandwidth = = ' high ' ` . second , the @xmath1 are described as two unlinking ( lines 13 - 14 , 22 - 23 ) and one linking ( lines 15 - 18 , 24 - 27 ) statements . these @xmath1 specified the replacement of an instance of the component . .... system streamdecodersystem : tcpip_mf , plastikmf {    component mpeg - decoder : tcpip_mpegdecoder = new tcpip_application extend with {      property decoder - type = " mpeg " ;      property algorithm = ... ;    }    component h263-decoder : tcpip_h263decoder = new tcpip_application extend with { ... } // other instances of component and connector    ... // initial attachments    ... // programmed dynamic reconfiguration to low bandwidth    on ( link.bandwidth = = ' low ' ) do {      detach mpeg-decoder.requiredservice to application2transport.source ;      detach transport2application.sink to mpeg-decoder.datareceivedfromtransport ;      attachments {        h263-decoder.requiredservice to application2transport.source ;        transport2application.sink to h263-decoder.datareceivedfromtransport ;      }    } // programmed dynamic reconfiguration to high bandwidth    on ( link.bandwidth = = ' high ' ) do {      detach h263-decoder.datato to application2transport.source ;      detach transport2application.sink to h263-decoder.datareceivedfromtransport ;      attachments {        mpeg-decoder.requiredservice to application2transport.source ;        transport2application.sink to mpeg-decoder.datareceivedfromtransport ;      }    } } ....    [ [ scenario-2 - 1 ] ] scenario 2 + + + + + + + + + +    the scenario 2 , an unforeseen insertion of a new component type , is describe with an acme / plastik script in fig .  [ code : scenario2-acme ] . for this scenario , the script is composed by : the insertion of a type and instance of a component ( lines 1 - 3 ) , the unlinking of the old component instance ( lines 5 - 6 ) and the linking of the new component ( lines 7 - 10 ) .    .... component ipv6 : tcpip_ipv6 = new tcpip_internet extended with {    ... }    detach ipv4.requiredservice to internet2link.source ; detach link2internet.sink to ipv4.datareceivedfromlink ; attachments {    ipv6.requiredservice to internet2link.source ;    link2internet.sink to ipv6.datareceivedfromlink ; } ....    [ [ scenario-3 - 1 ] ] scenario 3 + + + + + + + + + +    the unforeseen upgrade of a behaviour in scenario 3 can be described by the script illustrated in fig . [ code : scenario3-acme ] . this script defines a new version of a component with an improvement on its behaviour . the behaviour in acme / plastik is expressed as a property and it can be also described in other languages , such as external formal languages , see lines 3 - 5 in fig . [ code : scenario3-acme ] . .... component type tcpip_transport extends tcpip_component with {    ...    property behaviour = {       \\ description of behaviour in other languages , e.g. csp    }    ... } ....    [ [ summary - of - acmeplastik ] ] summary of acme / plastik + + + + + + + + + + + + + + + + + + + + + + +    the dynamic reconfiguration issues for acme can be summarized as follows :    1 . dynamic reconfiguration in terms of structure is supported by acme / plastik . in terms of behaviour , dynamic reconfiguration is described using any external language embedded inside the property element . usually , this is used for foreseen reconfiguration . this approach is limited in the sense that components and connectors usually needs the dynamic reconfiguration of their behaviour but as acme / plastik does not provides elements for behaviour specification , the architect has to rely on an external language . e.g. if the ` tcpip_transport ` component needs to decide if it has a buffer or not , and if it uses a error detecting or not , and so on . these situations have to be described using an external language ( in general formal languages such as csp ) . 2 .   acme / plastik does not provide a mechanism to control the intermediate states of a reconfiguration . e.g. the implementation of the scenario 3 , the architect can not define the approach used to update the instances . 3 .   for unforeseen reconfiguration acme / plastik relies on external scripts . this approach requires an external interpreted associated to the adl to interpret the external script in order to reconfigure the system . [ [ purpose - of - the - adl-2 ] ] purpose of the adl + + + + + + + + + + + + + + + + + +    initially , the purpose of c2 was to describe the architecture of a software based on a graphical user interface ( gui )  @xcite . therefore , the adl is based on hierarchically concurrent components . c2 also allows the use of messages to notify the architectural elements . c2 is subdivided in 2 languages : c2 idl ( interface description language ) for describing the components types , and c2 adl to specify the configurations . for components it is possible to specify top and bottom ports , to declare internal methods , and to specify the behaviour of its ports . the implementation of the internal methods is done by the developer in the source code generated by a toolset . with c2 adl it is possible to define instances of components and connectors , as well as links between them .    [ [ dynamic - reconfiguration - support-2 ] ] dynamic reconfiguration support + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +    the architectural + modification language ( aml ) was created to extend c2 for supporting dynamic reconfiguration  @xcite . aml is a declarative language that uses the structure view of an existing configuration and messages to notify this configuration about a dynamic reconfiguration . this language provides statements to build the scripts that specify dynamic reconfiguration . however , in these scripts it is not possible to determine the moment to apply a dynamic reconfiguration . because that , human intervention is needed via a toolset to trigger dynamic reconfiguration . [ [ initial - architecture-2 ] ] initial architecture + + + + + + + + + + + + + + + + + + + +    the tcp / ip stack system is described in c2 idl in fig . [ code : tcpip - c2idl ] and c2 adl in fig . [ code : tcpip - c2adl ] .    ....     ...     component tcpip_transport is        interface // define the component ports           top_domain is // ports to link high level connectors              out                 ... in                 receivedata(package : applicationpackage ) ;           bottom_domain is // ports to link low level connectors              out                 sendtointernt(package : transportpackage ) ;              in                 ...        methods // define interfaces of internal behaviours           function pack(data : applicationpackage ) : transportpackage ) ;           ...        behaviour // describe the external behaviour            ...           received_messages receivedata ;              invoke_methods pack ;              always_genarate sendtointernet ;           ...     end tcpip_transport     ... ....    ....     architecture decoderstream is        component_intances {           mpeg instantiates tcpip_mpegdecoder ;           h263 instantiates tcpip_h263decoder ;           transport instantiates tcpip_transport ;           internet instantiates tcpip_internet ;           link instantiates tcpip_link ;        }        connectors {           application2transport ;           transport2internet ;           internet2link ;        }        topology {           connector application2transport {              top_ports { mpeg filter no_filtering ; }              bottom_ports { transport filter no_filtering ; }           }           connector transport2internet {              top_ports { transport filter no_filtering ; }              bottom_ports { internet filter no_filtering ; }           }           connector internet2link {              top_ports { internet filter no_filtering ; }              bottom_ports { link filter no_filtering ; }           }        }     end decoderstream ; ....    [ [ scenario-1 - 2 ] ] scenario 1 + + + + + + + + + +    for scenario 1 , for changing the component according to the low or high bandwidth state , it is necessary two c2sadl scripts . in fig . [ code : scenario1-c2sadl ] is described the script for dynamic reconfiguration when bandwidth is low . this script uses two statements , a ` unweld ` for unlinking the @xmath4 instance and ` weld ` for linking the @xmath5 instance . other aml s statements are ` addcomponent ` , ` addconnector ` , ` removecomponent ` , and ` removeconnector ` . all these statements are used with a defined configuration , e.g. line 2 and 3 in fig . [ code : scenario1-c2sadl ] with the configuration named as ` decoderstream ` . despite of the fact that aml statements are based on services of the archstudio tool suite , there are services that are not provided by the aml language , e.g. ` start ( ) ` and ` stop ( ) ` . .... \\ bandwidth is low decoderstream.unweld(mpeg , application2transport ) ; decoderstream.weld(h263 , application2transport ) ; ....    [ [ scenario-2 - 2 ] ] scenario 2 + + + + + + + + + +    the second scenario , the unforeseen insertion of component instance and type , is inferred as shown in fig . [ code : scenario2-c2sadl ] . inference because both work about aml  @xcite stated that it is possible to make insertion and deletion of types . however , they only show examples how to build dynamic reconfiguration at the instance level . et al . _ @xcite mention types and subtypes but at design level . dynamic reconfiguration in fig . [ code : scenario2-c2sadl ] specifies : the insertion of a new type of component ( lines 2 - 5 ) , the creation a new instance of component ( line 9 ) , the unlinking of the instance of ipv4 ( lines 12 - 13 ) , and the linking of the instance of ipv6 ( lines 16 - 17 ) . the component type name is inferred by a toolset before performing dynamic reconfiguration .    .... \\ creata a new type of component component tcpip_ipv6 is subtype    all < = all tcpip_internet ( ... )    ... end tcpip_ipv6    // create a new instance of component //    the name of the type is implicitly discovered decoderstream.addcomponent(tcpip_ipv61 ) ;    // unlink the instance of component ipv4 decoderstream.unweld(trasport2internet , tcpip_ipv41 ) ; decoderstream.unweld(tcpip_ipv41 , internet2link ) ;    // link the instance of component ipv6 decoderstream.weld(trasport2internet , tcpip_ipv61 ) ; decoderstream.weld(tcpip_ipv61 , internet2link ) ; ....    [ [ scenario-3 - 2 ] ] scenario 3 + + + + + + + + + +    the third scenario is an improvement of the behaviour that can be modeled by the ` behaviour ` statement via a sequence of invocations to internal methods . example of this change , see line 6 in fig . [ code : scenario3-c2sadl ] , the invocation is modified to verify the received and packed data before sending a transport package to the internet layer . if the change is an improvement of an internal method , it is not possible to describe with c2sadl .    .... component tcpip_transport is        ...        behaviour // describe the external behaviour            ...           received_messages receivedata ;              invoke_methods verifydata , pack ;              always_genarate sendtointernet ;           ...     end tcpip_transport     ... ....    [ [ summary - of - c2sadl ] ] summary of c2sadl + + + + + + + + + + + + + + + + +    after the c2sadl implementation of the three scenarios , we identified these issues :    1 . archstudio tool provides some services for supporting dynamic reconfiguration , e.g. to start and to stop architectural elements . however , these services are not available in aml . thus , the dynamic reconfiguration specification in aml is limited . 2 .   foreseen dynamic reconfiguration needs human intervention because c2sadl do not provide statements for the system apply dynamic reconfiguration . 3 .   it does not support the specification of dynamic reconfiguration inside of the architectural elements . because that , the foreseen dynamic reconfiguration is implemented only at the implementation level ; 4 . it does not provide a mechanism for controlling and monitoring the intermediate states of a dynamic reconfiguration ; 5 . it also does not support the assessment of dynamic reconfiguration . [ [ purpose - of - the - adl-3 ] ] purpose of the adl + + + + + + + + + + + + + + + + + +    dynamic wright has focus on the structure and behaviour of an architecture  @xcite . dynamic wright supports the description of the architectural elements types structures and behaviours , and initial configuration . structure , initial configuration , instances , and links are described in a declarative form , while behaviours are specified in a graph - based and a variant of the communicating sequential process ( csp ) form .    [ [ dynamic - reconfiguration - support-3 ] ] dynamic reconfiguration support + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +    dynamic wright only supports foreseen dynamic reconfiguration . it is built as a special behaviour of the initial configuration . it has the same base of a `` nominally '' behaviour of architectural elements . the extension described in  @xcite proposes additional statements and control events . the statements are ` new ` , ` remove ` , ` attach ` , and ` detach ` . the control events are used to define the specific moment to perform a dynamic reconfiguration . as dynamic wright does not support unforeseen reconfiguration , the scenarios 2 and 3 can not be implemented . [ [ initial - architecture-3 ] ] initial architecture + + + + + + + + + + + + + + + + + + + +    the initial configuration of the tcp / ip stack system is illustrated in fig . [ code : scenario1-wright ] . the component and connector types are specified in the ` style ... endstyle ` ( lines 1 - 16 ) statements . the implementation of the ` tcpip_``mpeg - decoder ` component is described with two ports ( lines 3 - 4 ) and a behaviour ( lines 6 - 7 ) . the configuration is described with the ` configuror ... endconfiguror ` statement . the initial configuration instances and connections are specified at lines 18 - 27 . [ [ scenario-1 - 3 ] ] scenario 1 + + + + + + + + + +    fig . [ code : scenario1-wright ] also illustrates the specification of scenario 1 . it uses the ` configuror [ initial configuration ] where [ behaviours ] ` statement . _ behaviours _ are special named behaviours of the configuration for specifying dynamic reconfiguration . in this case , there are two specification : lines 29 - 36 for low bandwidth and lines 37 - 44 for high bandwidth . the following steps were used to define the first and the second dynamic reconfiguration situations :    1 .   to define a name ( lines 29 and 37 ) . 2 .   to specify the control events that define the moment for performing the operations of dynamic reconfiguration ( lines 30 and 38 ) . 3 .   to determine the type of configuration to use ( lines 31 and 39 ) . dynamic wright use the term ` style ` for this purpose . 4 .   to specify the operations to perform dynamic reconfiguration ( lines 32 - 35 and 40 - 43 ) . 5 .   to use the statements of the external choice ( @xmath6 ) and successfully terminate ( @xmath7 ) , lines 36 and 44 . .... style tcpip - style     component tcpip_mpeg - decoder        port datareceivedfromtransport = ...        port requiredservice = ...            [ describe the port behaviour using a variant of csp ]        computation = ...            [ describe the component behaviour using a variant of csp ]     ...     connector conn2layers        role source = ...        role sink = ...        glue = ...            [ describe the connector behaviour using a variant of csp ]     constraints        ... endstyle configuror decoderstream    style tcpip - style      new.mpeg : tcpip_mpeg - decoder      $ \rightarrow$ new.h263 : tcpip_h263-decoder      ... [ other component instances ]      $ \rightarrow$ new.app2trans : conn2layers      $ \rightarrow$ new.trans2net : conn2layers      $ \rightarrow$ new.net2link : conn2layers      $ \rightarrow$ attach.mpeg.requiredservice.to.app2trans.source      $ \rightarrow$ attach.app2trans.sink.to.transport.service      ... [ other attachments ]    where      waitforbandwidthlow = (      link.control.bandwidthdown $ \rightarrow$ mpeg.control.off $ \rightarrow$ h263.control.on      $ \rightarrow$ style tcpip - style        detach.mpeg.requiredservice.to.app2trans.source        $ \rightarrow$ attach.h263.requiredservice.to.app2trans.source        $ \rightarrow$ detach.trans2app.sink.to.mpeg.datareceivedfromtransport        $ \rightarrow$ attach.trans2app.sink.to.h263.datareceivedfromtransport      ) $ \box$ $ \s$      waitforbandwidthhigh = (         link.control.bandwidthup $ \rightarrow$ h263.control.off $ \rightarrow$ - > mpeg.control.on         $ \rightarrow$ style tcpip - style            detach.h263.requiredservice.to.app2trans.source            $ \rightarrow$ attach.mpeg.requiredservice.to.app2trans.source            $ \rightarrow$ detach.trans2app.sink.to.h263.datareceivedfromtransport            $ \rightarrow$ attach.trans2app.sink.to.mpeg.datareceivedfromtransport       ) $ \box$ $ \s$ endconfiguror .... [ [ summary - of - dynamic - wright ] ] summary of dynamic wright + + + + + + + + + + + + + + + + + + + + + + + + +    the following issues are identified after the implementation of the scenario 1 :    1 .   it does not provide operations to define dynamic reconfiguration for the type level of architectural elements ; 2 . this adl provides a refined mechanism of control events to determine the moment to perform a dynamic reconfiguration . although , it does not provide a mechanism to control and monitor the intermediate states . e.g. if the application of the scenario 1 is a banking system , the state must be copied from the instance of the replaced component to the new component . dynamic wright does not provide operations for this purpose . 3 .   despite of providing the specification of behaviour for components and connectors , it is not possible to define dynamic reconfiguration for this architectural elements ; 4 . similarly to the other adls , dynamic wright does not provide a mechanism for the assessment of dynamic reconfiguration . the summary of the four adls support for dynamic reconfigurations is shown in tab . [ tab : reconfiguration ] . @xmath0-adl and acme / plastik are the only adls that support both foreseen and unforeseen dynamic reconfigurations . as c2sadl with the aml language do not provide a way to specify an internal initiation of dynamic reconfiguration , foreseen dynamic reconfiguration can not be automatically triggered . dynamic wright supports only foreseen reconfiguration by defining the special behaviour of a configuration . .foreseen and unforeseen dynamic reconfiguration support in adls . [ cols="<,<,<",options="header " , ] none of the four adls has a mechanism for assessing the system . @xmath0-adl can rely on @xmath0-aal for defining and analyzing the architectural constraints and non - functional properties . while acme / plastik has armani . even though it has no formal semantics , and therefore , it is not liable to rigorous analysis  @xcite . c2sadl provides type verification for events communication . dynamic wright provides a refined mechanism of control events to determine the moment to perform a dynamic reconfiguration . although , the assessment of dynamic reconfiguration is not provided on four adls . in this paper we analysed the support of adls for handling dynamic reconfigurations . we started with a motivation example and some reconfiguration scenarios and we described the example and the scenarios using four well - known adls . we used the example and the specifications to discuss the following issues : ( i ) how each adl addresses the issue of consistently reconfiguring both instances and types ; ( ii ) how each adl takes into account the behaviour of the architectural elements during reconfiguration ; and ( iii ) how each adl supports the assessing of dynamic reconfiguration .    in comparison to related works , we analysed some important issues for the dynamic reconfiguration support at the architectural level : foreseen and unforeseen changes ; instance and type level modifications ; structure and behaviour for all architectural elements ; definition of nominally and dynamic reconfiguration behaviour for all architectural elements ; and , the analysis of dynamic reconfiguration .    we can conclude that some issues still remain open as no adl provides support for all of them together : how to apply the changes made in type level to their respective instances ? how to control the set of intermediate states of a software system during a dynamic reconfiguration ? how to assess dynamic reconfiguration ? special thanks to collge doctoral international ( cdi)/uni - versit europenne de bretagne ( ueb ) for financial support this work . r.  allen , r.  douence , and d.  garlan . specifying and analyzing dynamic software architectures . in _ proceedings of the 1998 conference on fundamental approaches to software engineering ( fase98 ) _ , lisbon , portugal , march 1998 . an expanded version of a the paper `` specifying dynamism in software architectures , '' which appeared in the proceedings of the workshop on foundations of component - based software engineering , september 1997 . t.  v. batista , a.  t.  a. gomes , g.  coulson , c.  chavez , and a.  f. garcia . on the interplay of aspects and dynamic reconfiguration in a specification - to - deployment environment . in _ proceedings of the 2nd european conference on software architecture _ , ecsa 08 , pages 314317 , berlin , heidelberg , 2008 . springer - verlag . k.  h. bennett and v.  t. rajlich . software maintenance and evolution : a roadmap . in _ proceedings of the conference on the future of software engineering _ , icse 00 , pages 7387 , new york , ny , usa , 2000 . acm . d.  garlan , r.  monroe , and d.  wile . acme : an architecture description interchange language . in _ proceedings of the 1997 conference of the centre for advanced studies on collaborative research_. ibm press , 1997 . a.  gomes , t.  v. batista , a.  joolia , and g.  coulson . . in r.  de  lemos , c.  gacek , and a.  romanovsky , editors , _ architecting dependable systems iv _ , volume 4615 of _ lecture notes in computer science _ , pages 237261 . springer berlin / heidelberg , berlin , heidelberg , 2007 .        j.  magee and j.  kramer . self organising system structuring . in _ joint proceedings of the second international software architecture workshop ( isaw ) and international workshop on multiple perspectives in software development ( viewpoints 96 ) on sigsoft 96 workshops _ , isaw 96 , pages 3538 , new york , ny , usa , 1996 . acm press . n.  medvidovic , p.  oreizy , j.  e. robbins , and r.  n. taylor . using object - oriented typing to support architectural design in the c2 style . in _ proceedings of the 4th acm sigsoft symposium on foundations of software engineering _ , sigsoft 96 , pages 2432 , new york , ny , usa , 1996 . acm . p.  oreizy , m.  m. gorlick , r.  n. taylor , d.  heimbigner , g.  johnson , n.  medvidovic , a.  quilici , d.  s. rosenblum , and a.  l. wolf . an architecture - based approach to self - adaptive software . , 14(3):5462 , may / june 1999 . p.  oreizy , n.  medvidovic , and r.  n. taylor . architecture - based runtime software evolution . in _ proceedings of the 20th international conference on software engineering _ , icse 98 , pages 177186 , washington , dc , usa , 1998 . ieee computer society . p.  oreizy and r.  n. taylor . on the role of software architectures in runtime system reconfiguration . in _ configurable distributed systems , 1998 . fourth international conference on _ , pages 6170 , may 1998 . m.  pinto , l.  fuentes , and j.  m. troya . daop - adl : an architecture description language for dynamic component and aspect - based development . in _ proceedings of the 2nd international conference on generative programming and component engineering _ , gpce 03 , pages 118137 , new york , ny , usa , 2003 . springer - verlag new york , inc . r.  n. taylor , n.  medvidovic , k.  m. anderson , j.  whitehead , e.  james , j.  e. robbins , k.  a. nies , p.  oreizy , and d.  l. dubrow . a component- and message - based architectural style for gui software . , 22(6):390406 , june 1996 . j.  vera , l.  perrochon , and d.  c. luckham . event - based execution architectures for dynamic software systems . in _ proceedings of the tc2 first working ifip conference on software architecture ( wicsa ) _ , wicsa , pages 303318 , deventer , the netherlands , the netherlands , 1999 . kluwer , b.v . p.  waewsawangwong . a constraint architectural description approach to self - organising component - based software systems . in _ proceedings of the 26th international conference on software engineering _ , icse 04 , pages 8183 , washington , dc , usa , 2004 . ieee computer society .
Abstract:

Answer: dynamic reconfiguration is the action of modifying a software system at runtime . several works have been using architectural specification as the basis for dynamic reconfiguration . indeed adls ( architecture description languages ) let architects describe the elements that could be reconfigured as well as the set of constraints to which the system must conform during reconfiguration . in this work , we investigate the adl literature in order to illustrate how reconfiguration is supported in four well - known adls : @xmath0-adl , acme , c2sadl and dynamic wright . from this review , we conclude that none of these adls : ( i ) addresses the issue of consistently reconfiguring both instances and types ; ( ii ) takes into account the behaviour of architectural elements during reconfiguration ; and ( iii ) provides support for assessing reconfiguration , e.g. , verifying the transition against properties .


Instruction: Write an abstract for the following acadamic paper.

Input:
Paper: we have recorded the flight of a fly during take off and landing using digital high speed photography . it is shown that the dynamics of flexible wings are different for these procedures . during this observation fly flew freely in a big box and it was not tethered .
Abstract: in this fluid dynamics video , we demonstrated take off and landing of a fly . the deformation of wings is in focus in this video .

Paper: the study of transport and mixing in coastal flows is of major interest because of their economic and ecological importance . due to the particularities that they present , like influence of complex topography , coastline shape and the direct driving at the surface by highly variable wind forcing , coastal flow dynamics remains still poorly understood . recently , coastal observations and modeling efforts in different regions have been addressed from the lagrangian point of view : @xcite showed that lagrangian coherent structures ( lcss ) computed from velocity fields obtained from hf radar measurements can be used to predict pollutant dispersion in the coast of florida ; @xcite and @xcite detected lcss with hf radar data in the gulf of eliat , israel , and in monterey bay , respectively . @xcite studied small - scale properties of dispersion measurements obtained from hf radar data in the gulf of la spezia , italy . also @xcite have detected lscs in a coastal region with a lyapunov method based on in situ observations . besides radar measurements , lcss obtained from velocity data of high resolution numerical models have been used to analyze the effect of the waves on lcs in the bay of palma , spain @xcite , to study the transport in the tidal flow of ria de vigo , spain @xcite , or to study the water quality of a very small coastal region , the hobie beach , usa @xcite also , data from drifters released in the santa barbara channel were used by @xcite to characterize relative dispersion , very useful to improve lagrangian stochastic models . the application of lagrangian techniques to study the dynamics in a shallow lake ( small closed basin ) has been performed in @xcite . palma is the largest city in the balearic islands . human activities , in particular recreational ones , give to water quality in the bay of palma a large economic value . a proper analysis of transport can be useful to understand the fluid dynamics in the bay and therefore help protect the coastal water . previous studies performed in the bay of palma used eulerian techniques to understand the coastal dynamics @xcite . in this work we study some transport properties in the bay of palma using lagrangian techniques developed from dynamical systems theory . computing both lcss and residence times the bay of palma can be sorted in regions of different properties , for example having more or less connectivity with the open ocean . this kind of studies have demonstrated to be useful to identify pollution pathways or conditions for red tides @xcite . the bay is a semi - enclosed basin located in the southwest of the island of mallorca ( western mediterranean sea ) , whose coastal flow is mainly induced by the wind @xcite . forcing by tides is almost negligible with a tidal amplitude of less than 0.25@xmath1 . this makes the dynamics here different form other locations ( e.g. @xcite ) where tides are dominant , and then provides the opportunity to test the performance of dynamical systems tools in this situation in which forcing only acts directly on the sea surface , and in which there are rather different forcing regimes depending on the season . the lagrangian diagnosis will be obtained from velocity data of a realistic numerical model at high resolution , which resolves spatial scales of a few hundred of meters . we investigate the surface horizontal transport during two months corresponding to different seasons ( autumn and summer ) , and therefore to different wind conditions , in order to highlight the effect of the wind on transport . in the case of july we also study the deepest bottom layer . we compute the barriers and avenues to transport ( lcs ) from lines of high values of finite - size lyapunov exponents ( fsle ) . we also present calculations of residence times and show synoptic lagrangian maps ( slm ) of these times @xcite , which will allow us a detailed visualization of the interchange of fluid particles between the bay and the open sea . the relationship between lcss and areas of different residence times will be analyzed . the organization of this paper is as follows . the data set used in the computations and the area of study is described in section [ sec : data ] . section [ sec : metodo ] presents a brief overview of the lagrangian tools that are used . before presenting the lagrangian results , we show in section [ sec : vel ] a short summary of eulerian results by studying the velocties in the bay . we present in section [ sec : results ] a characterization of stirring in the bay of palma in terms of fsle and residence times . using the definition of lcs given in section [ sec : metodo ] , lagrangian barriers are identified in the domain of interest . we compute escape rates and residence times of fluid particles to describe the transport relation between the bay and the open ocean . we provide possible mechanisms to explain differences in the residences times and fsle between different seasonal months . finally we summarize the main results in section [ sec : conclusion ] . the island of mallorca ( fig . [ fig : location ] ) is part of the balearic islands archipelago and is located in the center of the western mediterranean ( between 39@xmath2 and 40@xmath2n and 2.50@xmath2 and 3.50@xmath2 e ) . the bay of palma is a nearly semi - circular and semi - enclosed basin located in the southwest coast of mallorca and it can reach depths of more than 60 @xmath1 . the bay of palma is defined as the water mass inside the square in fig.[fig : location ] , consisting of a northern limit at 39@xmath234@xmath3n , a southern limit at 39@xmath224@xmath3n , and 2@xmath230@xmath3e and 2@xmath245@xmath3e as the western and eastern limits , respectively . the open boundary to the sea is in the southern part and it is 20 km wide .    the size of the bay is smaller than the rossby radius of deformation at these latitudes , and the main circulation is determined by the bathymetry at the bottom layer and by local and remote winds at the surface layer . in particular the studies by @xcite have shown that the major forcing mechanisms come from wind - induced island trapped waves ( itw ) propagating at an island scale and by locally wind - induced mass balance . the intense itw can produce new instabilities which can generate coastal gyres at submesoscale ( see @xcite ) . during summer there are persistent sea breeze conditions . in july and august , the weather is often almost identical from one day to the next . in the vicinity of the bay and along the southern coast of mallorca the breeze blows from the south - west . several studies @xcite , have pointed out that the meteorological conditions of mallorca ( intense solar radiation , clear skies , soil water deficit , dryness , weak surface pressure gradients , etc . ) favors the development of sea breeze , often from april to october , and almost every day during july and august . winds in autumn , and particularly in late september and october are more irregular , with episodes of strong storm activity @xcite . the velocity data sets were obtained from the numerical model roms ( regional ocean model system ) . roms is a free surface , hydrostatic , primitive equation ocean model . the model uses a stretched , generalized nonlinear coordinate system to follow bottom topography in the vertical , and orthogonal curvilinear coordinates in the horizontal @xcite . at each grid point , horizontal resolution @xmath4 is the same in both the longitudinal , @xmath5 , and latitudinal , @xmath6 , directions . we run the simulation with a resolution of @xmath7 ( @xmath8300@xmath1 , roms300 ) , which is itself nested into a larger and coarser grid with @xmath4 = 1/74@xmath2 ( @xmath81500@xmath1 ) . boundary conditions for the coarser domain were taken from daily outputs of the mediterranean forecasting system @xcite . the roms300 domain covers @xmath912@xmath3n - @xmath936@xmath3n ( latitude ) , and @xmath1024@xmath3e - @xmath116@xmath3e ( longitude ) . the total number of grid nodes is 260 @xmath12 148 . vertical resolution is variable with @xmath13 layers in total . all domains were forced using realistic winds provided by the psu / ncar mesoscale model mm5 . the initial vertical structure of temperature and salinity was obtained from the levitus database @xcite . we will manage velocity data from the surface layer and the bottom layer for the grid of @xmath4 @xmath14 300@xmath1 . this domain allows us to analyze the fluid interchange between the bay and the open ocean , using a high resolution velocity field . only horizontal velocities are considered , so that vertical displacements are neglected in the surface layer , and particles in the bottom remain in the bottom layer . this is justified by the small integration times we will use . nevertheless , close to the coast they can have an impact that will be the subject of future work . the output of the model was compared with data from drifters ( see @xcite ) and a reasonable agreement was found , although it improved when adding the influence of wave intensity . thus the present study should be considered as a simplified baseline case against which to compare the future consideration of the full 3d dynamics , or the influence of small scale process such as waves @xcite . we will study two different intervals of time corresponding to two different wind regimes : one starting on october @xmath15th , @xmath16 and finishing on october @xmath17th , @xmath16 ; and the other extending from july @xmath18st , @xmath19 until july @xmath20th , @xmath19 . temporal resolution is 15 minutes and 10 minutes for october and july , respectively , resulting in a total of @xmath21 snapshots of the velocity field for october , and @xmath22 for july . our methodology is based on the lagrangian analysis of marine flows . in the lagrangian view , particles are advected by the flow and their horizontal motion ( neglecting motions between model layers ) is governed by the differential equations @xmath23 where ( @xmath24 ) are the west - east and the south - north coordinates of the trajectories and ( @xmath25 ) are the eastwards and northwards components of the velocity . because of the small sizes involved , we will use a cartesian coordinate system . lcss @xcite , are roughly defined as the material lines organizing the transport in the flow . they are the analogs , for time - dependent flows , of the unstable and stable manifolds of hyperbolic fixed points . among other approaches @xcite , ridges of the local lyapunov exponents provide a convenient tool to locate them . in our case , we use the so - called finite - size lyapunov exponents ( fsles ) which are the adaptation of the asymptotic classical lyapunov exponent to finite spatial scales @xcite . fsles are a local measure of particle dispersion and thus of stirring and mixing , as a function of the spatial resolution , serving to isolate the different regimes corresponding to different length scales of the oceanic flows , very useful in coastal systems @xcite . in fact the first applications of the fsle technique in oceanography were for closed or semi - closed basins @xcite .    for two particles of fluid , one of them located at @xmath26 , the fsle at time @xmath27 and at the spatial point @xmath26 is given by the formula : @xmath28 where @xmath29 is the initial distance of the two given particles , and @xmath30 is their final distance . thus , to compute the fsles we need to calculate the minimal time , @xmath31 , needed for the two particles initially separated @xmath29 , to get a final distance @xmath30 ( in this way the fsle represents the inverse time scale for mixing up fluid parcels between length scales @xmath32 and @xmath33 ) . to obtain this time we need to know the trajectories of the particles ( from eqs . ( [ eqsmotiona ] ) and ( [ eqsmotionb ] ) ) which gives the lagrangian character to this quantity . the fsles are computed for the points @xmath26 of a square lattice with lattice spacing coincident with the initial separation of fluid particles @xmath32 . we can obtain a good estimation of the minimal @xmath31 at each site by selecting the trajectory which diverges the first among the four trajectories starting at the neighbors of the given site in the grid of initial conditions . numerically we integrate the equations of motion using a standard , fourth - order runge - kutta scheme , with an integration time step corresponding to the time resolution of the velocity data : @xmath34 minutes in october and @xmath35 minutes in july . we have checked in selected trajectories that using in july the same time step @xmath34 as in october does not alter the trajectories . since velocity information is provided just in a discrete space - time grid , spatiotemporal interpolation of the velocity data is achieved by bilinear interpolation . for the spatial scales that define fsles , we take @xmath36 , i.e. , final separations of about @xmath37 , because of the size of the bay . on the other side , we take @xmath29 equal to @xmath38 , four times smaller than the resolution of the velocity field , @xmath39 . since we are interested only in fast time scales , our integrations are restricted to 5 days . locations for which the final separation at the end of this period has not reached the prescribed @xmath40 ( or for which particles have been trapped by land ) are assigned a value @xmath41 . fsles can be computed from trajectory integration @xmath42 and @xmath43 in time . their highest values as a function of the initial location , * x * , organize in filamental structures approximating relevant manifolds : ridges in the spatial distribution of backward ( forward ) fsles identify regions of locally maximum compression ( separation ) , approximating attracting ( repelling ) material lines or unstable ( stable ) manifolds of hyperbolic trajectories , which can be identified with the lcss @xcite , and characterize the flow from the lagrangian point of view @xcite . attracting lcss associated to backward integration ( the unstable manifolds ) have a direct physical interpretation @xcite . tracers ( chlorophyll , temperature , ... ) spread along these attracting lcss , thus creating their typical filamental structure @xcite . when not stated explicitly , by fsle we will mean the _ backwards _ fsle values . in addition to locate spatial structures , time - averages of fsle give an indication of the intensity of stirring in given areas , which we analyze in sect . [ stirring_mallorca ] . we close this section by noting that the relationship between lcss and lyapunov exponents is based on heuristic arguments which may not be correct in some cases ( see for example @xcite ) . we identify as possible lcss only the locations having the largest values of fsle , which align in linear structures . in this way we effectively select only the highest fsle ridges which are more likely to organize the flow . even in this case , it is possible that the fsle technique identifies regions of high shear which are not hyperbolic and then may lack some of the properties of _ bona fide _ lcss . thus , direct inspection of particle trajectories and comparison with complementary techniques would be needed to confirm the validity of the fsle approach in this situation . one of such complementary techniques is residence time maps that we present in the following section . another characteristic time - scale for transport processes in open flows is the so - called escape rate @xcite . this quantity measures how quickly particles trajectories escape from a domain . if we initiate @xmath44 particles in a flow , we can measure how the trajectories escape the preselected region . in the case in which the decay in the number of particles remaining in the region up to time @xmath45 , @xmath46 , decays exponentially with time , @xmath47 , there is a well - defined escape time defined as the inverse of the escape rate @xmath48 : @xmath49 . for the range of times explored in our work , we will see that the particle escape is close to exponential and then we can estimate the value of @xmath50 . @xmath50 is a global quantity associated to the whole basin . a more detailed description of the transport processes can be obtained by other suitable lagrangian quantities such as residence times @xcite . the particle residence time ( rt ) is defined as the interval of time that a fluid particle remains in a region before crossing a particular boundary . for each fluid particle inside the bay at an initial time , we need to compute two times : the forward exit time , @xmath51 , computed as the time needed for a particle to cross the line delimiting the bay , taking the forward - in - time dynamics ; and the backward exit time , @xmath52 , the same but in the backward - in - time dynamics . the residence time is defined as @xmath53 . rts can be displayed in plots named lagrangian synoptic maps @xcite , in which the residence time of each fluid particle is referenced to its initial position on the grid . a first approach to the transport process in the bay can be a description from the eulerian point of view , by studying averages of the velocity field . to do this we consider separately the meridional @xmath54 and zonal @xmath55 components of the surface flow , and we analyze the time evolution of their spatial averages .             figures [ fig : velo ] a ) and b ) show the time series of data taken every 15 min in october and 10 min in july ( black lines ) , and daily average time series ( red lines ) of @xmath56 and @xmath57 for october and july , respectively . the impact of the more variable and stormy weather in october is clear in the high frequency variability of the time - series . during the two months both components of the flow present daily variability related to the presence of land and sea breezes . in july the zonal fluctuations are much more noticeable and regular than the meridional ones , being @xmath58 very small . we have computed the power spectra for both months ( see fig . [ fig : espectro ] ) . in october , in addition to higher power at high frequencies , there are also stronger low - frequency fluctuations . from such features in their spectra of adcp - derived velocities @xcite identified wind - induced island trapped waves as the main source of variability in the bay dynamics , in addition to the local wind ( essentially sea breeze ) . in contrast , the dominant role of sea breeze in july is seen as the very strong dominance of the daily frequency peak at the july zonal spectrum .    comparing the velocity components of both months we observe quantitative differences . the values of @xmath57 in the case of october range from -1.0 to 1.5 @xmath59 ( bottom panel of fig . [ fig : velo ] a ) , while in the case of july , @xmath57 is two orders of magnitude smaller , ranging from -0.1 to 0.02 @xmath59 ( bottom panel of fig . [ fig : velo ] b ) . on other hand , @xmath56 are similar during october and july . in october , @xmath56 ranges from -1.5 to 0.5 @xmath59 ( top panel of fig . [ fig : velo ] a ) , the same order of magnitude than the meridional velocity , resulting in circular motions ( clockwise along the bay ) . in july the situation is significantly different . the zonal velocity ranges from -1.5 to 0.7 @xmath59 ( top panel of fig . [ fig : velo ] b ) , much larger than the meridional velocity , resulting in a flow consisting on oscillations along the zonal direction . in october the mean values ( and the standard deviations given in parenthesis ) of the time series are @xmath60 and @xmath61 . in july we have @xmath62 and @xmath63 . the large standard deviation in the zonal velocity in july is an indicator of the large ( breeze induced ) daily fluctuations in this month , but restricted to a single direction of motion . we now describe our lagrangian results . first we compute the temporal average ( over the months of october and july ) of the fsles for the surface layer , and for july in the bottom layer . this calculation helps us to unveil areas of different stirring and the differences between layers and months .        the surface computations for the different seasonal months , october and july ( fig . [ fig : promedios_fsle ] a , b ) show different values and spatial distributions of stirring . we use the same colorbar to compare the stirring in both months . the bay of palma appears to be an area with important activity . average fsle field looks more homogeneous in july than in october . during october filamental structures of high values of fsle are accumulated over the northeast side of the bay , forming a linear structure running from north to south - east which comes from similar structures in the instantaneous ( non - averaged ) fields that can act as barriers , therefore dividing the bay in two flow regions of qualitatively different dynamics . the difference in wind regularity and intensity between these months , and the fact that local and remote winds are the main drivers of the bay dynamics , explains the difference in mean stirring distribution among the two months . the importance of wind will be replaced by bottom topography when going to the deep layers . the effect of the terrain topography on stirring is clear in fig . [ fig : promedios_fsle ] c ) , where fsles are computed at the deepest layer for july . the high values of time - averaged fsles are located close to a region of high bathymetry gradient , which seems to act as a barrier along which the flow is stretched . the temporal averages computed in sec . [ stirring_mallorca ] give us a rough idea of stirring in the bay . more detailed information is obtained by looking at non - averaged quantities , that may reveal the existence of barriers to transport . figure [ fig : lcs_oct ] shows the location of the high backward fsle values ( lcss ) , appearing as a network of lines , computed at successive instants of time in october . these temporary structures can remain for one or more days , as happens in october , or they can appear in the same location periodically ( not shown ) . we stress here the appearance of a clear barrier , from north to south - east , that divides the bay in two areas that correlates with the temporal average in fig . [ fig : promedios_fsle ] a ) . this barrier appears in almost the same position in different days , remaining without displacing too much . to effectively see that it acts as a barrier we have considered the evolution of virtual particles released at both sides of the barrier . red and black particles do not mix and they tend to spread along the barrier ( confirming that , as expected , it is an attracting line ) .    in july the situation is rather different . lines of high lyapunov exponents ( forward and backwards ) are mainly oriented zonally in the bay ( except close to the opening to the sea ) , which is also the dominant direction of motion . thus , it does not seem that they represent hyperbolic lcs , but rather lines of intense shear between zonally moving strips . in this section we study the surface transport of particles in and out of the bay . to have an idea of the time scales involved in this interchange we proceed by computing the number of particles remaining in the bay , @xmath46 , averaged over different starting times ( separated by @xmath64hours in order to collect the information of diurnal and nocturnal signal ; this gives us 15 different simulations to be averaged for each month ) as a function of the integration time @xmath45 . a particle is considered to leave the bay when crossing the red open - sea boundary in fig . [ fig : location ] , so that particles landing on the coast are considered not escaped . [ fig : promedios_muestreo ] shows the different average decays for october and july . in both cases @xmath46 is reasonably fitted by an exponential in the considered time - range , thus identifying the escape rates @xmath48 = 0.62 and 0.47 @xmath65 , respectively . the corresponding escape times , given by the inverse of the escape rate , are , respectively , @xmath50 = 1.61 and 2.12 @xmath66 . the relative difference of the escape rates of july with respect to october , @xmath67 , is 0.32 . thus the exchange of fluid particles between the bay and the open ocean is a 32@xmath0 more active in autumn than in summer . next we compute synoptic maps of the residence times . as was indicated in sec . [ sec : methods_erslm ] the residence time of the particles throughout the study area is considered as the sum of the entry time ( @xmath68 ) and the escape time ( @xmath69 ) . to compute @xmath69 and @xmath68 particles are initialized every 6 hours in a regular grid of 75@xmath1 spacing and they are integrated forward and backward in time during 5 days . we consider that 5 days is a proper integration time according with the time scales associated with the coastal processes of this small bay , and also owing to the short period of the available data . in these computations we assign the maximum possible value of @xmath51 and @xmath52 ( 5 days ) to the fluid particles that remain in the pre - selected area after the 5 days of integration .        in fig . [ fig : snapshots_rt ] we color the initial positions of particles in the bay attending to the time they transit through the bay ( @xmath53 ) for different days . initial positions of particles with short residence times are indicated in blue in fig . [ fig : snapshots_rt ] . regions from where particles have longer residence time ( i.e. take more time between entry and escape ) are marked in red / brown . these maps show that the spatial distribution of residence times of particles can be complex and time depending , presenting different patterns at different times . a number of small structures can be observed , including thin filaments or small lobes . comparing both months , one can see differences in the rt distributions . the most noticeable is the approximate east - west alignment of the zones of similar rt in july , which is not seen in october . also , in october the values of residence times of the particles are smaller , in agreement with the global rate estimations showed before . a common feature is the southwest region with low values of residence times , because in this region there are not coastal boundaries and it is totally open to the ocean .        in order to reveal regions with different persistent transport properties we compute time averages of the spatial distributions of residence times . we average 6-hourly snapshots of rt during 15 days ( i.e. 60 snapshots ) for each month . the results , plotted in fig . [ fig : mean_rt ] a ) and b ) , show the common features that , in general , the low values of rt are for particles initiated close to the open ocean , specially in the southwest part , and high values are for particles started near the coast , as expected . however , on average , the residence time is larger in july than in october ( 3.25 days in july and 1.51 days in october ) consistent with the behavior of the corresponding values of @xmath50 . also , in july there is a clear boundary between the interior of the bay to the north , with large average residence times and the open sea to the south , whereas the boundary between high and low residence times in october is well inside the bay , aligned with the lagrangian structure identified from the fsle analysis , as will be discussed in the next section . another feature observed in movies of particle trajectories ( not shown ) is that in october fluid particles tend to circulate mostly clockwise , while in july they are oscillating along the zonal direction ( see section [ sec : vel ] ) . this difference , arising as discussed in sect . [ sec : vel ] from the different regimes of wind forcing , is likely to be responsible for most of the different behavior between both months . we now examine the connection between regions of different residence times with lcss . to compare rt and fsle we have superimposed in fig . [ fig : snapshots_rt ] the filaments of high values of forward ( white ) and backward fsle ( black ) values on the spatial distribution of residence times . the figure shows a good correspondence between many structures of rt and fsle . note that rt is the sum of a forward and a backward exit time , so that some of the strong gradients of rt will correspond to forward and some others to backwards lcss . fig [ fig : snapshots_tb_tf ] shows clearer the correspondence between fsle backwards in time with entry times , and fsle forward with escape times . at least in october , the lcss given by high values of fsle clearly separate regions with different values of residence times , confirming the value of the fsle technique to identify boundaries between different flow regions and barriers to transport . there are however some lines of fsle that are not associated to gradients of rt , and viceversa . for the first this happens mainly because we only integrate 5 days backward and 5 days forward in time , and the time assigned to the particles that not cross the open - ocean boundary in the 5 days of integration corresponds to the maximum time integration ( 5 days ) . this makes the spatial distribution of the residence time more homogeneous . we need to integrate the trajectories longer to unveil more areas with different rt . in the same way not all abrupt changes in rt are captured by fsle lines since we only plot the highest ridges . this illustrates that both techniques have limitations and that the complementary use of both could give a rather complete overview of the geometric structure of flow in marine areas . @xcite studied the relation between residence time and fsle for a wind - forced hydrodynamical model of a shallow lake . they found that areas with long residence time visualize the stable manifolds of the so - called chaotic saddle , a structure controlling the escape properties at long times . in our case , our integrations are restricted to times too short to characterize long - time chaotic behavior , but still there is a good correspondence between the fsle structures characterizing attracting or repelling trajectories , and escape or residence times . [ fig : mean_rt ] a ) shows a time average over october of the spatial distribution of rt , to be compared with the corresponding average figure ( fig . [ fig : promedios_fsle ] a ) for fsle . it is evident that the region in the north and east side of the bay with high values of rt is separated from the rest by a region of high values of fsle . this can be explained by the presence of persistent barriers which do not allow particles to escape from the northeast side of the bay , and thus separating the bay in regions with different residence times . in july the situation is different , because the spatial distribution of fsle ( fig.[fig : promedios_fsle ] b ) and rt ( fig . [ fig : mean_rt ] b ) is almost homogeneous , with higher values over the whole area of the bay , and lower values in the small region bordering the open ocean . this indicates that the instantaneous configurations of high fsle lines ( fig . [ fig : snapshots_rt ] ) are not persistent , and that only there is a persistent large difference between the interior of the bay and its opening to the ocean . the predominantly zonal direction of particle motion in the bay is consistent with the orientation of the boundaries between areas of different rts in july . the differences of residence times and fsles in the two considered months indicate that the dynamics of the flow is qualitatively different , as anticipated by the different wind regimes that are the main drivers of the bay . now we analyze the time evolution of their spatial averages . figures [ fig : fsle_rt ] a ) and b ) show the time series of the spatial mean of residence times ( top panel ) and backward fsle ( bottom panel ) for october and july , respectively . comparison between time evolution of spatial average of the rt for the different months confirms , again , that particles tend to stay longer times in the bay during july than in october . the values of rt vary approximately from 0.25 days to 3 days in october ( fig . [ fig : fsle_rt ] a , top ) , and from 2 days to 6 days in july ( fig . [ fig : fsle_rt ] b , top ) . the same happens with fsle , higher values correspond to july and lower ones to october . diurnal fluctuations , likely related to the effect of the sea breeze , are evident in rt and fsle for both months . in october there are some large fluctuations of low frequency in rt , probably induced by the variability of remote forcing winds . on the other hand , during october , minima of rt correspond to maxima of fsle , and maxima of rt correspond to minima of fsle . in july , the relationship between fsle and rt is looser and only observed in the high - frequency fluctuations . to be more quantitative , pearson correlation coefficient between rt and fsle time series is -0.526 in october , but just -0.223 in july . this difference in behavior probably arises from the fact that high values of fsle determine clear and well - defined barriers to transport only in the case of october ( see sect . [ sec : interchange ] and [ sec : connetion ] ) . in july lines of high fsle remain nearly zonal and parallel to dominant particle direction of motion . thus , as commented in sect . [ sec : lcss ] , they probably represent regions of high zonal shear everywhere in the bay . their high or low values indicate large or small differences in east - west velocities but by themselves they do not imply stronger or weaker escape towards the south .          in this subsection we compare the main lagrangian characteristics at the bottom layer , not driven directly by wind , with those at the surface . in fig . [ fig : mean_rt_bottom ] a ) we show an instantaneous map of the residence times in the bottom layer one day of july , overlayed with lines of high fsle values . again , the spatial distribution is inhomogeneous , and we find high values of rt over all the bay except very close to the ocean . the correlation of rt values with fsle lines is weaker than in the upper layer , but still we see that the relatively lower values of rt in the western part of the bay at that particular day appear bounded by backwards fsle lines , indicating a temporal escape route of particles in that region towards the southwest . the spatial distribution of the time average of rt plotted in fig . [ fig : mean_rt_bottom ] b ) shows that highest average values of rt are concentrated in the northwestern region of the bay . [ fig : promedios_fsle ] c ) displays high values of fsle located precisely in the same region where the rt qualitatively change to high values . this suggests the presence of persistent barriers that separate this southeastern region from the rest in this bottom layer . the formation of these persistent lcss is associated to the gradient of the bathymetry ( see fig . [ fig : location ] ) . the time evolution of the spatial average of rt and fsle are plotted in top and bottom panel of fig . [ fig : fsle_rt_bottom ] respectively . contrarily to the surface , in the bottom layer the diurnal fluctuations in the time series of rt disappear , showing that the flow at this depth is not directly influenced by breeze . the rt values are larger than in the surface , and therefore the interchange between the ocean and the bay is less intense at bottom layers . this is a consequence of the slowness of the flow produced by the absence of direct wind forcing at deepest levels . there is a strong negative correlation ( @xmath70 ) between stirring and residence times : when the flow is more dispersive the particles transit during less time over the bay , so that maxima of rt correspond to minima of fsle and vice - versa . properties of coastal transport in the bay of palma , which is a small semi - enclosed region of the island of mallorca , were studied in a lagrangian framework , by using model velocity data at high resolution . we have applied two complementary lagrangian methods ( fsles and rt ) to analyze the small scales of these coastal currents . lcss have been detected as high ridges of fsle , and virtual experiments with particle trajectories have shown that these structures really act as barriers in most cases , organizing the coastal flow . global and average aspects of the transport in different seasonal months show that , in the period studied , in autumn there is more exchange between the bay and the open ocean than in summer . this arises from the different wind regimes in both months , that during july induce a flow that restricts motion of the coastal marine surface to the zonal direction , preventing the flow to enter or escape toward the open ocean . the transport of particles at the deepest layer is less active than at the surface and not directly driven by wind , but influenced by the bottom topography . regions with different values of rt are generally separated by ridges of fsle , proving the fact that fsle separate regions of qualitatively different dynamics also in small coastal regions . thus , we think that these lagrangian quantities can be used as key variables able to determine the dynamics and health of other bays or estuaries , particularly in relation with human activities . future improvements include the adaptation of these methods to three - dimensional spaces and capture three - dimensional effects , such as upwelling and downwelling in coastal areas , and analyzing longer periods of time . i.h - c , c.l and e.h - g acknowledge support from micinn and feder through projects fisicos ( fis2007 - 60327 ) , intense@cosyp ( fis2012 - 30634 ) , and escola ( ctm2012 - 39025-c02 - 01 ) . ao acknowledges financial support from micinn and eu - med programme through projects bus2 ( cgl2011 - 22964 ) and tosca ( 2gmed-09 - 425 ) . we acknowledge the icmat severo ochoa project ( sev-2011 - 0087 ) for the funding of the publication charges of this article . antonov , j.  i. , locarnini , r.  a. , boyer , t.  p. , mishonov , a.  v. , and garcia , h.  e. : world ocean atlas 2005 , volume 2 : salinity . s. levitus , ed . noaa atlas nesdis 62 , u.s . government printing office , washington , d.c , 2006 . buffoni , g. , falco , p. , griffa , a. , and zambianchi , e. : dispersion processes and residence times in a semi - enclosed basin with recirculating gyres : an application to the tyrrhenian sea , j. geophys . res , 102(c8 ) , 1869918713 , 1997 . dobricic , s. , pinardi , n. , adani , m. , tonani , m. , fratianni , c. , bonazzi , a. , and fernandez , v. : daily oceanographic analyses by mediterranean forecasting system at the basin scale , ocean science , 3 , 149157 , 2007 . dovidio , f. , isern - fontanet , j. , lpez , c. , hernndez - garca , e. , and garca - ladona , e. : comparison between eulerian diagnostics and finite - size lyapunov exponents computed from altimetry in the algerian basin , deep - sea res . i , 56 , 1531 , 2009 . fiorentino , l.  a. , olascoaga , m.  j. , reniers , a. , feng , z. , beron - vera , f. , and macmahan , j.  h. : using lagrangian coherent structures to understand coastal water quality , continental shelf research , 47 , 145149 , 2012 . gildor , h. , fredj , e. , steinbuck , j. , and monismith , s. : evidence for submesoscale barriers to horizontal mixing in the ocean from current meauserements and aerial photographs , journal od physical oceanography , 39 , 19751983 , 2009 . haza , a.  c. , zgkmen , t.  m. , griffa , a. , molcard , a. , poulain , p .- m . , and peggion , g. : transport properties in small - scale coastal flows : relative dispersion from vhf radar measurements in the gulf of la spezia , ocean dynamics , 60 , 861882 , 2010 . huhn , f. , von kameke , a. , allen - perkins , s. , montero , p. , venancio , a. , and prez - muuzuri , v. : horizontal lagrangian transport in a tidal - driven estuary transport barriers attached to prominent coastal boundaries , continental shelf research , 39 - 40 , 113 , 2012 . lekien , f. , coulliette , c. , mariano , a.  j. , ryan , e.  h. , shay , l.  k. , haller , g. , and marsden , j. : pollution release tied to invariant manifolds : a case study for the coast of florida , physica d , 210 , 120 , 2005 . lipphardt , b. , jr . , small , d. , kirwan , a. , jr . , wiggins , s. , ide , k. , grosch , c. , and paduan , j. : synoptic lagrangian maps : aplication to surface transport in monterey bay , journal of marine research , 64 , 221247 , 2006 . locarnini , r.  a. , mishonov , a.  v. , antonov , j.  i. , boyer , t.  p. , and garcia , h.  e. : world ocean atlas 2005 , volume 1 : temperature . s. levitus , ed . noaa atlas nesdis 61 , u.s . government printing office , washington , d.c , 2006 . mancho , a.  m. , small , d. , and wiggins , s. : a tutorial on dynamical systems concepts applied to lagrangian transport in oceanic flows defined as finite time data sets : theoretical and computational issues , physics reports , 437 , 55  124 , 2006 . oddo , p. , adani , m. , pinardi , n. , fratianni , c. , tonani , m. , and pettenuzzo , d. : a nested atlantic - mediterranean sea general circulation model for operational forecasting , ocean science , 5 , 461473 , 2009 . orfila , a. , jordi , a. , basterretxea , g. , vizoso , g. , marba , n. , duarte , c. , werner , f. , and tintor , j. : residence time and posidonia oceanica in cabrera archipelago national park , spain , continental shelf research , 25 , 13391352 , 2005 . rypina , i. , scott , s.  e. , pratt , l.  j. , and brown , m.  g. : investigating the connection between complexity of isolated trajectories and lagrangian coherent structures , nonlin . processes geophys , 18 , 977987 , 2011 . shadden , s.  c. , lekien , f. , and marsden , j.  e. : definition and properties of lagrangian coherent structures from finite - time lyapunov exponents in two dimensional aperiodic flows , physica d , 212 , 271304 , 2005 . shadden , s.  c. , lekien , f. , paduan , j.  d. , chavez , f.  p. , and marsden , j.  e. : the correlation between surface drifters and coherent structures based on high - frequency radar data in monterey bay , deep sea research part ii : topical studies in oceanography , 56 , 161  172 , 2009 .        , e. , rossi , v. , sudre , j. , weimerskirch , h. , lpez , c. , hernndez - garca , e. , marsac , f. , and garon , v. : top marine predators track lagrangian coherent structures , proceedings of the national academy of sciencies of the usa , 106 , 82458250 , 2009 .
Abstract:

Answer: coastal transport in the bay of palma , a small region in the island of mallorca , spain , is characterized in terms of lagrangian descriptors . the data sets used for this study are the output for two months ( one in autumn and one in summer ) of a high resolution numerical model , roms , forced atmospherically and with a spatial resolution of 300 m. the two months were selected because its different wind regime , which is the main driver of the sea dynamics in this area . finite - size lyapunov exponents ( fsles ) were used to locate semi - persistent lagrangian coherent structures ( lcs ) and to understand the different flow regimes in the bay . the different wind directions and regularity in the two months have a clear impact on the surface bay dynamics , whereas only topographic features appear clearly in the bottom structures . the fluid interchange between the bay and the open ocean was studied by computing particle trajectories and residence times ( rt ) maps . the escape rate of particles out of the bay is qualitatively different , with a 32@xmath0 more of escape rate of particles to the ocean in october than in july , owing to the different geometric characteristics of the flow . we show that lcss separate regions with different transport properties by displaying spatial distributions of residence times on synoptic lagrangian maps together with the location of the lcss . correlations between the time - dependent behavior of fsle and rt are also investigated , showing a negative dependence when the stirring characterized by fsle values moves particles in the direction of escape .