Isabelle Blasquez
email: isabelle.blasquez@unilim.fr

Hervé Leblanc
email: leblanc@irit.fr

Experience in Learning Test-Driven Development: Space Invaders Project-Driven

Keywords: Test-Driven Development, Agile Game Development, Sofware Engineering Learning

From Kent Beck's point of view, Test-Driven Development (TDD) really encourages simple design and inspires con dence. This agile software engineering practice suggests a di erent programming way that requires writing tests before writing the code in short cycles to reduce feedbacks loops. To help novice programmers discover and appreciate it, this paper describes an experience based on a laboratory course for learning TDD by developping a Space Invaders game through a step-by-step project-driven approach. To improve student engagement, a game development is chosen. All concepts are taught within the context of this project and students learn by doing. Applied in the context of a basis of object-oriented design course, this experience should raise student awareness of design's and programming's good practices as testing, refactoring, simple design and short releases. The evaluation shows that this experience helps students to engage in the learning process, to re ect on the importance of testing in a software development, to make aware of code quality and to understand the benefits of TDD.

INTRODUCTION

Test Driven Development (TDD) is an agile software engineering practice promoted by eXtreme Programming (XP) [START_REF] Beck | Extreme Programming Explained: Embrace Change[END_REF] which suggests a different programming way that requires writing tests before writing the code in short cycles to reduce feedbacks loops. https://doi.org/10.1145/3197091.3197132

The mantra "Red-Green-Refactor" introduced by [START_REF] Beck | Test Driven Development: By Example[END_REF] outlines the three steps of such a cycle of development. The rst step is to write a new test and check that it fails (Red) because the functionality it is testing for doesn't exist. The second step is to write quickly a code to pass all the tests (Green). The third step is to make code better by refactoring [START_REF] Fowler | Refactoring: Improving the Design of Existing Code[END_REF] or clean code [START_REF] Martin | Clean Code: A Handbook of Agile Software Craftsmanship[END_REF].

As agile methodologies become mainstream in the software industry, many experience reports and surveys have been proposed about the teaching of agile software development. These studies are mainly focused on Scrum [START_REF] Mahnič | Scrum in software engineering courses: an outline of the literature[END_REF] and on agile collaboration and values skills [START_REF] Meier | Experience Report of Teaching Agile Collaboration and Values: Agile Software Development in Large Student Teams[END_REF]. Fewer learning approaches are proposed in litterature to teach TDD. Moreover TDD seems mostly to be taught to nal-year undergraduates [START_REF] Bowyer | Assessing Undergraduate Experience of Continuous Integration and Test-driven Development[END_REF] although the bene ts on student testing and programmer performance have already shown for early programmers [START_REF] Janzen | Test-driven Learning in Early Programming Courses[END_REF].

As we think that students should be rise awareness as soon as possible of design's and programming's good practices promoted by eXtreme Programming, we present in this paper a centered-student learning approach that we apply to introduce TDD for rst-year undegraduates. Unlike a classical Project-Based-Learning approach, the students are strongly guided at rst by detailed instructions and tiny steps so they can adapt their learning progress at their own pace. In the course of time, the students become more and more responsible actors of theirs own choices. To engage students in the learning process, we also provide a concrete and engaging context with a 2D game development about a Space Invaders.

This paper is structured as follow : section 2 discusses related work. Section 3 describes the learning experience. Section 4 evaluates the quality of this learning resource and its impacts on students' perception towards TDD, good design, and programming practices. Section 5 summarizes the experience and gives nal conclusions.

RELATED WORK

The actual approaches to learn TDD can be classi ed into three groups: educational games, coding dojo sessions, and practical works on projects.

Learning TDD through educational games is proposed in [START_REF] Kurkovsky | A LEGO-based Approach to Introducing Test-Driven Development[END_REF] with a A LEGO-based approach developped by agile practitioners who conducted numerous training workshops for professional software developers. This approach introduces TDD concepts more interactively and visually than a classical lecture.

Practising TDD through Coding Dojo sessions is a collaborative approach proposed by [START_REF] Bossavit | The Coder's Dojo -a Di erent Way to Teach and Learn Programming[END_REF] for professional software developpers as a session where a group of programmers would gather to solve a code kata (a problem with further improvements) together. It is a collaborative and non-competitive environment where people can 12. Add a wave of invaders 6. Detect a collision between 2 sprites 7. Finish the game be continuously learning and sharing agile practices [START_REF] Sato | Coding Dojo: An Environment for Learning and Sharing Agile Practices[END_REF]. Professional software developers usually organize coding dojo sessions to learn from others and to improve their design and programming skills by applying technical practices from XP. In academia, the coding dojo is commonly experimented to convey Agile software engineering best practices, to improve testing and programming skills and to improve motivation in students to learn TDD and pair programming [START_REF] Sato | Coding Dojo: An Environment for Learning and Sharing Agile Practices[END_REF]. In a coding dojo session, students have to code, explain their code and they review code of other students [START_REF] Luz | Teaching TDD, the Coding Dojo Style[END_REF]. The limitation is that each session focuses on a speci c and isolated exercise.

Learning TDD through Project-Based Learning is a strategy to explore large, open-ended problems [START_REF] Missiroli | Learning Agile Software Development in High School: An Investigation[END_REF]. Project Based Learning (PBL) is perceived as a student-centered approach [START_REF] Chandrasekaran | Learning through projects in engineering education[END_REF][START_REF] Savery | Overview of problem-based learning: de nition and distinctions, The interdisciplinary[END_REF]. The students must to produce a solution to solve a problem and an outcome in the form of a report. PBL is based on ve principles: students work together in groups; a real world problem that a ects the life of the students is presented for investigation; students discuss ndings and consult the teacher for guidance, input, and feedback; the maturity level of students skills determines the degree of guidance provided by the teacher; resulting products can be shared with the community. In addition to the variety of application domains, PBL promotes sudents commitment and autonomy in a collaborative learning way. Unfortunately, PBL for TDD seem to be not appropiate for rst-year undergraduates which are novices and require guidance.

To engage novice students in learning TDD, we propose a projectdriven approach as a PBL light. The driven side of this approach focus on providing a material o ering a detailled guidance for the rst steps of the project. According to Bloom's taxonomy [START_REF] Bloom | Taxonomy of educational objectives[END_REF], this driven side addresses the knowledge and comprehension of TDD as educational learning objectives. Then, the students will be gradually left autonomous in the development of their project and the application of TDD is also adressed as educational learning objective. The project-driven approach follows the recommendations of the study of Novice Programmers conducted by [START_REF] Lahtinen | A Study of the Di culties of Novice Programmers[END_REF], namely learning by doing, programming by themselves, using example programs, avoiding students su er from a lack of personal instruction, practicing sessions in computer rooms and in small groups.

Game development has been widely used in computer science education to increase students motivation, engagement and learning [START_REF] Inge | The Use of Game Development in Computer Science and Software Engineering Education[END_REF]. Moreover, as a game involves a large number of interacting objects, it is well-adapted to introduce object-oriented design [START_REF] Chen | Teaching Object-Oriented Programming Laboratory With Computer Game Programming[END_REF]. As this experience is lead as a part of an object-oriented design course for novices programmers and designers, the domain application of game development improves the required engagement of students.

LEARNING EXPERIENCE DESIGN

In this section, we describe how to set up the experience by a projectdriven approach based on a Space Invaders game development 1 . The goal of this shooting game is to destroy a wave of aliens invaders to earn as many points as possible. The invaders move back and forth across the screen, slowly advancing toward earth. They also re randomly in a single direction. The player res shoots from the ship restricted to a single axis of motion.

The learning objectives are the use of a part of eXtreme Programming best practices [START_REF] Beck | Extreme Programming Explained: Embrace Change[END_REF]: testing, refactoring, simple design, pair programming and short releases.

Kick-o

To simulate an agile development (iterative and incremental approach), the development is divided into three parts with di erent objectives. The rst part is to deliver a minimal viable Space Invaders (only one ship, one alien invader and a single shot from ship on the screen). The second part is to deliver a classical Space Invaders (collection of aliens who re randomly, multiple shots from ship and score). The last part is to deliver the Space Invaders with optional features as pause, levels, speed variation for example. The creativity of the students is encouraged at the last part. The two rst guided parts are divided into features. The features have been prioritized and are listed in the product backlog in the table 1.

To deliver the rst part, two technical tasks are necessary:

-a sprint zero (according in agile terminology) for the preparation of the technical environment and a quick analysis of the problem. The technical stack is composed by: Java for programming language, Eclipse for IDE, In nitest2 for Continuous Testing plug-in (each time a change is made, all the tests are run), git as version control system and a Github as the hosting service. The quick analysis session consist in studying the features of the backlog, according to an ubiqutous language. For example, an enemy can also be named alien or invader. We choose to use invader and we de ne it in a glossary and identify the rst classes of the application as Invader, Ship and Shoot.

the set up of a graphics engine and its integration in the game. We choose a light homemade graphics engine, but real graphics engine as libGDX 3 could also be convenient.

The previous tasks and the rst four features of the table 1 are very detailed. The students are guided step by step to be immersed in the TDD approach and to gradually discover the refactoring tools of the IDE to increase their productivity. For the rest of the features, students are more and more autonomous to develop the game.

Focus on features' intructions

We brie y explain how the rst feature Move the ship in the board is detailed.

First, the feature is decomposed in small stories which are: create a board, place the ship in the board at a certain position, move the ship to the right direction of the board, and move the ship to the left direction of the board.

Stories are implemented one by one. For each story, the same protocol is repeated: rst, de ne the acceptance criteria and then develop using the TDD approach.

For the rst story, the acceptance criteria is to obtain a 2D empty board of desired size. Then, the development begins as a succession of short cycles based on the three steps of the TDD mantra.

Step 1: Add a failing test (Make it fail) The test is given using carefully naming. It must add a new behavior. For example, the rst test is: The test must be run and must fail.

Step 2: Make it work The implementation of SpaceInvaders class, constructor, and method toString is also detailed.

Step 3: Make it better (Refactor) A refactoring is a change made to the internal structure of software to make it easier to understand and cheaper to modify without changing its observable behavior [START_REF] Fowler | Refactoring: Improving the Design of Existing Code[END_REF]. The question Can my code be refactored (both the test and the production code)? is always asked to help students re ect about their code and decide if a refactoring is necessary. Each little refactoring is preceded by questions about local design and mostly references one of the fourth eXtreme Programming simplicity rules [START_REF] Beck | Extreme Programming Explained: Embrace Change[END_REF]:

• pass all tests; • clear, explicit and consistent;

• duplicates no behavior or con guration; • minimal methods, classes, modules. We focus on responsibility of classes and methods, naming of variables and methods, duplication of code, and the code smells long method and magic numbers.

Here only one cycle is necessary to implement this rst story: create a board. The next iteration is concerned by the implementation of the second story: place the ship in the board at a certain position. First, the acceptance criteria must be de ned and the implementation can start by coding the following test: A new method placeANewShip must be implemented in the class SpaceInvaders. The step of Make it work and Make it better will complete this iteration. The developpement of this second story will require several iterations because it is necessary to test that the ship can not be placed outside the board (too far right, left, up and down). Then the two last stories (move the ship to the right and to the left direction) can be implemented.

Concepts and good practices are presented, detailed and frequently repeated in all steps of iterations to make explicit the teacher's design and so transmit his knowledge and expertise. It is also indicated to commit at the end of an iteration.

Over the features, students acquire expertise. The instructions become less and less accurate until providing only the title of the feature. This point is reached from the feature 5 in our experience. At this point, the project-driven switches to a classical projectbased learning. The teacher takes the role of an observator and if necessary helps student team to continously improve their work and remove impediments.

Focus on sessions' organisation

3.3.1 Material. The material includes presentation of the project, the features'instructions and a template for the outcome. The material is available from the rst session. To easily access, Github is used to share on-line public material.

Planning.

Because the project-driven approach aims to o er a self-organized learning space, no planning and no speci c goal are de ned for any session. By analogy with agile development, the project-driven approach can be seen as an implementation of a Kanban pull system [START_REF] Anderson | Kanban: Successful Evolutionary Change for Your Technology Business[END_REF]. Each team takes a new feature (new concepts to understand and implement) when the previous one is nished. Each team manages his own work ow, the only goal being to deliver the minimal skillable learning objective at the end of the last session. As the material is avalaible on line, each student can reworks some parts whenever he wants. To visualize the work ow, the commits history can be consult and an outcome is required to summarize the progression.

Outcome.

Two outcomes are required per session. At the end of a session, students must push their last commit on their Github repository. For the next session, a summary has been required per team. This summary was based on a template with the following headings : the list of the implemented features and their acceptance criteria, the class diagram of their project (in reverseengineering using Object Aid UML 4 for example), a word cloud of their production code (using Source Code Word Cloud Generator5 ), the di culties they have encountered during the session (optionnal) and, any comments they nd useful. The class diagram helps students to be aware of the emergence of the design over the iterations, the word cloud helps students to improve the naming and code readibility because only domain terminology should appear to re ect the code intent.

Assessment

Two types of assessment are used : report and review. During the last session, the teacher made a code review of the work done by the team after a demonstration of the game. A discussion is engaged to help students to demonstrate their knowledge and skills and to identify any problems. At the end of the experience, a report including a presentation of the project and all the summaries has been delivered by each team.

LEARNING EXPERIENCE EVALUATION

This experience has been designed and delivered as a part of the basis of an object-oriented design course. This course is a part of French National Pedagogical Program (PPN), a common program to all technical colleges specialized in Computer Technology. The rst part of this course focus on classical design with lectures and exercices about object modelling for analysis and design (class diagrams, sequence diagrams). The laboratory is the second part of this course. A total of 40 one-year french undergraduates attended 7 sessions with two 2-hours sessions per week. Students are novice programmers: they have started learning Java for only a few weeks. They are novice designers too.

On one hand, the evaluation concerns the e ciency of this learning resource by the student engagement and the quality of the project-driven approach. On the other hand, it concerns the impacts on student's perception towards TDD, good design, and programming practices. This evaluation is a combination of questionnaires and open-ended questions. The survey is avalaible online and is completed anonymously per each student at the end of the last session.

Student's engagement

For the rst question of the survey, students must indicate the last shipped feature. The answers are:

-Fire a single shoot from the ship (feature 4): 2 students -Detect a collision between 2 sprites (feature 6): 2 students -End the game (feature 7): 10 students -Fire multiple shoots from the ship (feature 8): 8 students -Add a line of invaders in the game (feature 9): 8 students -Fire randomly a shot from an invader (feature 11): 6 students -Add a wave of invaders (feature 12): 4 students These results show that 90% of students achieve the minimal skillable learning objective and even 65% of students exceed this objective by shipping even beyond feature 7. The choice of developing a game seems to have motivated the students to achieve the objective. As the students were in pair-programming, these results also show that 2 groups of students were in di culty, mainly because of their di culties to code in Java and their lack of comprehension and practice of algorithmic techniques. The development was originally only in-class, but the desire to play motivated some students to continue their work in their own time between sessions. Moreover some students have planned to continue this game development as a side project.

Student's perception towards the quality of the learning resource

The evaluation of the project-driven approach has been adapted from a model initially presented in [START_REF] Gresse Von Wangenheim | DELIVER! -An Educational Game for Teaching Earned Value Management in Computing Courses[END_REF]. This model aims to assess the quality of a learning ressource (initially an educational game) through the students' perceptions about levels of motivation, user experience and learning promoted by this ressource. Results of our questionnaire are presented in table. 2. It consists in 17 items on a Likert scale with response alternatives ranging from strongly disagree (-2) to strongly agree (2).

Motivation.

Overall, students perceived a positive contribution of the experience to motivate them to study. The students also indicated that the laboratory captures their attention: especially, the relevancy of laboratory content and its connection with other knowledge. Regarding the con dence dimension, the laboratory helped student to con dent that they were learning, yet taking account the negative ratings of the item on the ease of understanding. Beyond the TDD technique, the lack of oriented-object programming practice can also explain di culties for some novice programmers. The majority of the students also con rmed that the learning content is relevant to their professional work.

User

Experience. The user experience has been rated very positively by the students. This demonstrates that they experienced the laboratory as a positive and engaging learning approach. Students would like practise this kind of lab again (with a game development) which obtain 80% of approbation, the highest rating of this questionnaire. Overall, results are positive in terms of fun, challenge, and social interactions. Regarding the competence dimension, 70% of the students believe that the game has been an e cient way to learn. They also con rmed that they had fun with the activities of this lab. In terms of challenge, the students found the laboratory moving at an adequate pace. The majority of the students agreed that the course promotes moments of cooperation.

Learning.

The course seems to be relevant to the needs of the students. Students expressed that they believe that the lab contributed positively to their learning and 90% of them indicate that it helped them to learn TDD in an e cient way. As Students are only rst undergraduates, it could be di cult to estimate if this lab will improve their professionnal performance in practice even if 50% of students had approved and perceived the impact of TDD.

Student's perception towards the TDD bene ts and disadvantages

From Kent Beck's point of view, Test-Driven Development (TDD) really encourages simple designs and inspires con dence [START_REF] Beck | Test Driven Development: By Example[END_REF]. The students were asked to give their own opinion on this point as novice programmers and designers. The results con rm Kent Beck's vision: 75% feel more con dent about their code and 85% feel to improve the quality of their code.

To help student re ect on the bene ts and disadvantages of TDD, two open-ended questions have been added: Why will you use TDD in your future developments ? What are the disadvantages of using TDD in a software development ?

In terms of bene ts, students have identi ed TDD as "a method easy to follow" which "avoids errors and allows to obtain a cleaner and more understandable code". They think that "testing and refactoring help to improve the readabilty of the code and thus make it possible to easilier change it. " Students appreciate "naming of the tests", "code readibility", that "each feature works in astonishment". One student says "Usually, I code for a long time without testing. This kind of development can help me x this mistake" and an other adds "this saves us from errors due to our precipitation to code".

In terms of disadvantages, students nd the TDD approach dicult to apply and "time-consuming" : "I have a lot of di culty in writting unit tests", "Time spent writing tests"and they add that "TDD requires a minimum of computer expertise to be e ective". E ectively, test code has the same value than production code: it requires tought, design, and care [START_REF] Martin | Clean Code: A Handbook of Agile Software Craftsmanship[END_REF] and the emergence of a simple design is more e cient by the knowledge of advanced concepts as SOLID principles and design patterns.

Student's awareness of good design and programming practices

We also use open-ended questions to help students re ect on testing and refactoring. For each of these techniques the questions are: Why will you use this in your future developments ? What are the disadvantages of using this in a software development ?

4.4.1 Testing. The rst bene t highlighted by most of the students is to use testing as a veri cation tool which ensures the non-regression. They are now aware of the importance of the automation of tests in any software development. Some are more accurate :"they mainly allow me to avoid regressions and serve as documentation of the code", "Tests help to better understand a problem and write a more e cient code", "Make sure to write a code that meets the needs of our test", "Make it possible to predict errors and/or to easily understand them when one is encountered" for example. Overall, the answers re ect the following thought from [START_REF] Martin | Agile Software Development: Principles, Patterns, and Practices[END_REF] the act of writing a unit test is more an act of design than of veri cation. It is also more an act of documentation than of veri cation. As mentioned earlier, the main disadvantage raised by students is writing tests is time-consuming and some students precise "to want test long and complicated applications but not simple applications".

Refactoring.

Students have a positive feeling about refactoring: "The refactoring steps helped me a lot". The readibility and code quality is mentioned by almost all students. Some add: "Refactoring allows a better understanding of the code, not only by others, but also by ourselves", "allows to re ect about the most e ective implementation", "gives us the impression of improving our code". Students don't really notice any disadvantage for refactoring but rather di culties to set up it: "refactoring is the hardest part of TDD for me, I nd it really useful when you need to reuse code. But I still have trouble putting it in place", "Identify where to perform refactoring is di cult".

Global student's perception towards the experience

Two open-ended questions ended the survey to obtain feedback and improvement suggestions. For this experience, students most appreciate:

the "fun" dimension of the experience and the choice of "developing a game from A to Z"; the structured and detailed dimension that o ers the opportunity to "progress at its own pace": "structures steps allowing a better re ection (a guideline)", "easy to understand", "progressive learning", "time to understand", "All the rst steps are extremely detailed which allows to return if we had errors".

To improve the experience, two points have been underlined. Students would like that the "lack of instructions should be more progressive". Students would like "more sessions" to develop advanced features and play with a more complex Space Invaders.

Teacher's point of view

At the end of the course, the teachers organized a retrospective during which they discussed the experience and considered possible future improvements. They appreciated the challenge side of the TDD (green bar-red bar) which prompted students to get involved more than in a traditional lab. They have a positive feeling that the small steps of this project has prompted students to regularly commit and push and it was also a good introduction to practice git. They found that students consistently and seriously provided their outcomes and were pleasantly surprised by the students re ect on TDD techniques. Moreover, they observed that the students had di culty in writing tests for detecting a collision, which shows that the act of design is not easy to practice and requires more training. Teachers also plan to set up code review sessions to reduce the gap between the last shipped features.

CONCLUSION AND FUTHER WORK

In this work, we present an experience in learning Test Driven Development. Because teaching a new programming way is challenging, we propose a game development project-driven.

The project-driven approach o ers a self-organized learning space. The driven side of this centered-student approach o ers step-by-step detailed instructions for students to learn by doing. The project side gives students autonomy to organize their learning process at their own pace. The context of game development engage students in the learning process. By public sharing online all the instructional material, the students will be able to self-organize by building their own pedagogical progression, by imposing their own challenges. Because each student has his own abilities, a minimal skillable learning objective is set to give everyone the opportunity to deliver a minimum viable product.

At the end of the experience 90% of the students achieve the minimal skillable learning objective and 90% of the students are agree that this learning approach help them to learn TDD. Moreover, more than two out of three students feel that TDD inspires con dence and improves code quality. We will continue this experience for the advanced object design and programming course where SOLID principles and design patterns will be studied.

Table 1 :

 1 Space Invaders Product Backlog

	Minimal Viable Space Invaders	Classical Space Invaders	Optional Features
	1. Move the ship in the board	8. Fire multiple shoots from the ship	13. Add a pause
	2. Size the ship	9. Add a line of invaders	14. Suggest other levels
	3. Choose the speed of the ship	10. Add a score	15. Vary speed
	4. Fire a single shoot from the ship	11. Fire a shot from an invader randomly ...
	5. Add an invader

Table 2 :

 2 Online survey results for evaluation of the quality of project-driven approach

	Questions

http://www.classicgaming.cc/classics/space-invaders/

https://in nitest.github.io

https://libgdx.badlogicgames.com

http://www.objectaid.com

https://sourcecodecloud.codeplex.com/


François Dubois
email: francois.dubois@math.u-psud.fr

Danielle Fortuné
email: danielle.fortune123@orange.fr

Juan Antonio Rojas Quintero

Claude Vallée

Pontryagin

Juan Antonio

Rojas Quintero
email: jrojasqu@yahoo.com

Pontryagin calculus in Riemannian geometry

Keywords: robotics, Euler-Lagrange, Riemann curvature tensor. AMS classification: 49S05, 51P05, 53A35

à la diffusion de documents scientifiques de niveau recherche, publiés ou non, émanant des établissements d'enseignement et de recherche français ou étrangers, des laboratoires publics ou privés.

Introduction

As part of studies based on the calculus of variations, the choice of a Lagrangian or a Hamiltonian is essential. When we study the dynamics of articulated systems, the choice of the Lagrangian is directly linked to the conservation of energy. The Euler-Lagrange methodology is applied to the kinetic and potential energies. This establishes a system of second order ordinary differential equations for the movement. These equations are identical to those deduced from the fundamental principle of dynamics. The choice of configuration parameters does not affect the energy value. Because the kinetic energy is a positive definite quadratic form with respect to the configuration parameters derivatives, its coefficients are ideal candidates to define and create a Riemannian metric structure on the configuration space. The Euler Lagrange equations have a contravariant tensorial nature and highlight the covariant derivatives with respect to time with the introduction of the Christoffel symbols.

• For the control of articulated robot choosing a Hamiltonian and a cost function are delicate. Here the presence of the Riemann structure is sound. It enables a cost function invariant when coordinates change. The application of the Pontryagin method from the optimal Hamiltonian leads to a system of second order differential equations for the control variables. Its tensorial nature is covariant and the Riemann-Christoffel curvature tensor is naturally revealed. In this development, the adjoint variables are directly interpreted and have a physical sense.

1) Pontryagin framework for differential equations

We study a dynamical system, where the state vector y(t ; λ(•)) is a function of time. This system is controlled by a set of variables λ(t) and satisfies a first order ordinary differential equation:

(1) dy dt = f (y(t), λ(t), t) .

We suppose also given an initial condition:

(2)

y(0 ; λ(•)) = x .
We search an optimal solution associated to the optimal control t -→ λ(t) in order to minimize the following cost function J :

(3)

J(λ(•)) ≡ T 0 g y(t), λ(t), t dt ,
where g(•, •, •) is a given real valued function.

• Pontryagin's main idea [START_REF] Pontryagin | The Mathematical Theory of Optimal Processes[END_REF] is to consider the differential equation (1) as a constraint satisfied by the variable y. Then he introduces a Lagrange multiplier p associated to the constraint (1). This new variable, due to the continuous nature of the constraint (1), is a covariant vector function of time: p = p(t because δy(0) = 0 taking fixed the initial condition [START_REF] Lovelock | Tensors, Differential Forms and Variational Principles[END_REF]. By canceling the first two terms of the right hand side of the previous relation, we find the adjoint equation ( 4) giving the evolution of the Lagrange multiplier and the associated final condition [START_REF] Rojas Quintero | An alternative to Pontryagin's principle for the optimal control of jointed arm robots[END_REF]. The third term allows to calculate the change in the functional J(•) for a variation δλ of control.

2) Pontryagin hamiltonian

We introduce the Hamiltonian for λ(t) = λ * (t) equal to the optimal value associated to the optimal condition (6).



• Proposition 2. Symplectic form of the dynamic equations. With the notations introduced proviously, the "forward" differential equation (1) and the "backward" adjoint differential equation ( 4) take the following symplectic form:

(8) dy dt = ∂H ∂p , dp dt = - ∂H ∂y .
Proof of Proposition 2.

Since ∂H ∂λ = 0 at the optimum, we have ∂H ∂p = ∂H ∂p = f and the first relation of ( 8) is proven. On the other hand, ∂H ∂y = ∂H ∂y = p ∂f ∂y -∂g ∂y and the property is established.

3) Riemanian metric

We consider now a dynamical system parameterized by a finite number of functions q j (t) like a poly-articulated system for robotics applications, as developed previously in [START_REF] Lazrak | Commande de robots en temps minimal[END_REF][START_REF] Rojas Quintero | Contribution à la manipulation dextre dynamique pour les aspects conceptuels et de commande en ligne optimale[END_REF][START_REF] Rojas Quintero | An alternative to Pontryagin's principle for the optimal control of jointed arm robots[END_REF][START_REF] Vallée | Covariant formulation of optimal control of jointed arm robots: an alternative to Pontryagin's principle[END_REF]. The set of all states q ≡ {q j } is denoted by Q. The kinetic energy K is a positive definite quadratic form of the time derivatives qj for each state q ∈ Q. The coefficients of this quadratic form define a so-called mass tensor M(q). The mass tensor is composed by a priori a nonlinear regular function of the state q ∈ Q. We have

(9) K(q, q) ≡ 1 2 k ℓ M kℓ (q) qk qℓ .
The mass tensor M(q) in ( 9) is symmetric and positive definite for each state q. It contains the mechanical caracteristics of mass, inertia of the articulated system. With Lazrak and Vallée [START_REF] Lazrak | Commande de robots en temps minimal[END_REF] and Siebert [START_REF] Siebert | Mechanical integrators for the optimal control in multibody dynamics[END_REF], we consider the Riemannian metric g defined by the mass tensor M. We set: g kℓ (q) ≡ M kℓ (q) .

• With this framework, the space of states Q has now a structure of Riemannian manifold. Therefore all classical geometrical tools of Riemannian geometry can be used (see e.g. the book [START_REF] Lovelock | Tensors, Differential Forms and Variational Principles[END_REF]): covariant space derivation

∂ j ≡ ∂ ∂q j contravariant space derivation ∂ j : < ∂ j , ∂ k > = δ j k component j, ℓ of the inverse mass tensor M -1 : M jℓ , M ij M jℓ = δ ℓ i connection Γ j ik = 1 2 M jℓ ∂ i M ℓk + ∂ k M ℓi -∂ ℓ M ik , Γ j ki = Γ j ik , d ∂ j = Γ ℓ jk dq k ∂ ℓ , d ∂ j = -Γ j kℓ dq k ∂ ℓ
, relations between covariant components ϕ j and contravariant components ϕ k of a vector field:

ϕ j = M jk ϕ k , ϕ k = M kj ϕ j covariant derivation of a vector field ϕ ≡ ϕ j ∂ j : dϕ = ∂ ℓ ϕ j + Γ j ℓk ϕ k dq ℓ ∂ j covariant derivation of a covector field ϕ ≡ ϕ ℓ ∂ ℓ : dϕ = ∂ k ϕ ℓ -Γ j kℓ ϕ j dq k ∂ ℓ Ricci identities: (10) ∂ j M kℓ = Γ p jk M ℓp + Γ p jℓ M kp , ∂ j M kℓ = -Γ k jp M pℓ -Γ ℓ jp M pk gradient of a scalar field: dV = ∂ ℓ V dq ℓ = < ∇V , dq j ∂ j > and  ∇V = ∂ ℓ V ∂ ℓ gradient of a covector field ϕ = ϕ ℓ ∂ ℓ : dϕ ≡ < ∇ϕ , dq j ∂ j > and ∇ϕ = ∂ k ϕ ℓ -Γ j kℓ ϕ j ∂ k ∂ ℓ second order gradient of a scalar field V : ∇ 2 V = ∇(∇V ) and (11) ∇ 2 V = ∂ k ∂ ℓ V -Γ j kℓ ∂ j V ∂ k ∂ ℓ components R j ikℓ of the Riemann tensor: (12) R j ikℓ ≡ ∂ ℓ Γ j ik -∂ k Γ j iℓ + Γ p ik Γ j pℓ -Γ p iℓ Γ j pk
anti-symmetry of the Riemann tensor: R j ikℓ = -R j iℓk .

• Proposition 3.

Riemanian form of the Euler-Lagrange equations. With the previous framework, in the presence of an external potential V = V (q), the Lagrangian L(q, q) = K(q, q) -V (q) allows to write the equations of motion in the classical Euler-Lagrange form:

(13) d dt ∂L ∂ qi =
∂L ∂q i These equations take also the Riemannian form:

(14) M kℓ qℓ + Γ ℓ ij qi qj + ∂ k V = 0 .
Proof of Proposition 3.

The proof is presented in the references [START_REF] Rojas Quintero | An alternative to Pontryagin's principle for the optimal control of jointed arm robots[END_REF] and [START_REF] Vallée | Covariant formulation of optimal control of jointed arm robots: an alternative to Pontryagin's principle[END_REF]. We detail it to be complete. We have, due to (9),

∂K ∂ qk = M kℓ qℓ .
We have also the following calculus:

d dt ∂L ∂ qk - ∂L ∂q k = d dt ∂K ∂ qk -∂ k K -V (q) = d dt M kℓ qℓ -∂ k 1 2 M ij qi qj + ∂ k V = ∂ j M kℓ qj qℓ + M kℓ qℓ - 1 2 ∂ k M ij qi qj + ∂ k V = M ks Γ s jℓ + M ℓs Γ s jk qj qℓ - 1 2 M is Γ s kj + M js Γ s ki qi qj + M kℓ qℓ + ∂ k V
due to the first Ricci identity (10)

= M ks Γ s ji + M is Γ s jk - 1 2 M is Γ s kj - 1 2 M js Γ s ki qi qj + M kℓ qℓ + ∂ k V = M kℓ qℓ + Γ ℓ ij qi qj + ∂ k V
and the relation ( 14) is established.

• When a mechanical forcing control u is present (forces and torques typically), the equations of motion can be formulated as follows:

(15) qj + Γ j kℓ qk qℓ + M jℓ ∂ ℓ V = u j .



We observe that with this form (15) of the equations of motion, the contravariant components of the control u have to be considered in the right hand side of the dynamical equations.

4) Optimal dynamics

In this section, we follow the ideas proposed in [START_REF] Rojas Quintero | Contribution à la manipulation dextre dynamique pour les aspects conceptuels et de commande en ligne optimale[END_REF][START_REF] Rojas Quintero | An alternative to Pontryagin's principle for the optimal control of jointed arm robots[END_REF][START_REF] Vallée | Covariant formulation of optimal control of jointed arm robots: an alternative to Pontryagin's principle[END_REF]. The space of states Q has a natural Riemannian structure. Therefore, it is natural to choose a cost function that is intrinsic and invariant, and in consequence non sensible to the change of coordinates. Following Rojas Qinteros's thesis [START_REF] Rojas Quintero | Contribution à la manipulation dextre dynamique pour les aspects conceptuels et de commande en ligne optimale[END_REF], we introduce a particular cost function to control the dynamics (15): ( 16)

J(u) = 1 2 T 0 M kℓ (q) u k u ℓ dt .
The controlled system (15) ( 16) is of type (1) ( 3) with

(17) Y = {q j , qj } , f = {Y j 2 , -Γ j kℓ qk qℓ -M jℓ ∂ ℓ V + u j } , λ = {u k } , g = 1 2 M kℓ (Y 1 ) u k u ℓ .
The Pontryagin method introduces Lagrangre multipliers (or adjoint states) p j and ξ j to form the Hamiltonian H(Y, P, λ) function of state Y defined in (17) and adjoint P obtained by combining the two adjoint states:

(18) P = {p j , ξ j } and λ = {u k } as proposed in (17). Taking into account ( 7), ( 17) and (18), we have:

(19) H(Y, P, λ) = p j qj + ξ j -Γ j kℓ qk qℓ -M jℓ ∂ ℓ V + u j - 1 2 M kℓ (Y 1 ) u k u ℓ .
• Proposition 4. Interpretation of one adjoint state. When the cost function J defined in ( 16) is stationary, the adjoint state ξ j is exactly equal to the applied force (and torque!) u j in the right hand side of the dynamic equation ( 15):

(20)

ξ j = u j .
Proof of Proposition 4.

Due to the expression (19) of the Hamiltonian function, the optimality condition ∂H ∂λ = 0 takes the simple form ξ j = M jℓ ξ ℓ . This relation is equivalent to the condition (20).

• The reduced Hamiltonian H(Y, P ) at the optimum can be explicited without difficulty. We just replace the control force u j by the adjoint state ξ j :

H(Y, P ) = p j qj + ξ j -Γ j kℓ qk qℓ -M jℓ (Y 1 ) ∂ ℓ V + 1 2 M kℓ (Y 1 ) ξ k ξ ℓ .
The symplectic dynamics (8) can be written simply:

(21) qj = ∂H ∂p j , qj = ∂H ∂ξ j , ṗj = - ∂H ∂q j , ξj = - ∂H ∂ qj .



Pontryagin calculus in Riemannian geometry

The two first equations of (21) give the initial controlled dynamics (15). We have also

     ∂H ∂q j = -∂ j Γ i kℓ qk qℓ ξ i -∂ j M iℓ ∂ ℓ V ξ i + 1 2 ∂ j M kℓ ξ k ξ ℓ ∂H ∂ qj = p j -2 Γ i kj qk ξ i .
We deduce the developed form of the two last equations of (21):

(22) ṗj = ∂ j Γ i kℓ qk qℓ ξ i + ∂ j M iℓ ∂ ℓ V ξ i - 1 2 ∂ j M kℓ ξ k ξ ℓ (23) ξj = 2 Γ i kj qk ξ i -p j .

5) Intrinsic evolution of the generalized force

We introduce the covector ξ according to its covariant coordinates: ξ = ξ j ∂ j . We have the following result, first established in [START_REF] Rojas Quintero | Contribution à la manipulation dextre dynamique pour les aspects conceptuels et de commande en ligne optimale[END_REF] and [START_REF] Vallée | Covariant formulation of optimal control of jointed arm robots: an alternative to Pontryagin's principle[END_REF]:

• Proposition 5.
Covariant evolution equation of the optimal force. With the above notations and hypotheses, the forces and torques u satisfy the following time evolution:

(24) d 2 u dt 2 j + R i kℓj qk qℓ u i + ∇ 2 jk V u k = 0 .
Proof of Proposition 5.

The time covariant derivative of the covector ξ is given by

dξ dt = ξj -Γ i jk qk ξ i ∂ j that is dξ dt j = ξj -Γ i jk qk ξ i .
We report this expression in (23):

(25)

p j = Γ i jk qk ξ i - dξ dt j .
We wish to differentiate relative to time the expression p j given in (25). The covariant derivatives of the covector p can be evaluated as follows:

dp dt j = ṗj -Γ ℓ jk qk p ℓ .
Then we have, taking into account again the relation (25):

ṗj = d dt Γ i jk qk ξ i - dξ dt j + Γ ℓ jk qk Γ i sℓ qs ξ i - dξ dt ℓ = ∂ ℓ Γ i jk qk qℓ ξ i + Γ i jk qk ξ i + Γ i jk qk dξ dt i - d 2 ξ dt 2 j +Γ ℓ jk Γ i sℓ qk qs ξ i -Γ ℓ jk qk dξ dt ℓ = ∂ ℓ Γ i jk qk qℓ ξ i + Γ s kj Γ i sℓ qk qℓ ξ i - d 2 ξ dt 2 j + Γ i kj qk ξ i  F.
= ∂ ℓ Γ i jk qk qℓ ξ i + Γ s kj Γ i sℓ qk qℓ ξ i - d 2 ξ dt 2 j +Γ i kj -Γ k ℓs qs qℓ -M kℓ ∂ ℓ V + ξ k ξ i due to (15) = ∂ ℓ Γ i jk + Γ s jk Γ i sℓ -Γ s kℓ Γ i sj qk qℓ ξ i - d 2 ξ dt 2 j -Γ i kj M kℓ ∂ ℓ V ξ i + Γ i kj ξ k ξ i and (26) ṗj = R i kjℓ + ∂ j Γ i kℓ qk qℓ ξ i - d 2 ξ dt 2 j -Γ i kj M kℓ ∂ ℓ V ξ i + Γ i kj ξ k ξ i
taking into account the expression (12) of the Riemann tensor. We confront the relations (26) and ( 22). We deduce

(27)      R i kjℓ qk qℓ ξ i - d 2 ξ dt 2 j -Γ i kj M kℓ ∂ ℓ V ξ i + Γ i kj ξ k ξ i = ∂ j M iℓ ∂ ℓ V ξ i - 1 2 ∂ j M kℓ ξ k ξ ℓ .
We take into account the second Ricci identity (10). It comes

∂ j M kℓ ξ k ξ ℓ = -Γ k js ξ k ξ s -Γ ℓ js ξ ℓ ξ s = -2 Γ k jℓ ξ k ξ ℓ = -2 Γ i jk ξ k ξ i .
Then we can write the relation (27) in a simpler way:

R i kjℓ qk qℓ ξ i - d 2 ξ dt 2 j = Γ i kj M kℓ ∂ ℓ V + ∂ j M iℓ ∂ ℓ V ξ i = Γ i kj M kℓ ∂ ℓ V -Γ i js M sℓ ∂ ℓ V -Γ ℓ js M is ∂ ℓ V + M iℓ ∂ ℓ ∂ j V ξ i = ∂ ℓ ∂ j V -Γ s jℓ ∂ s V M iℓ ξ i = ∇ 2
jℓ V ξ ℓ due to the expression (11) of the second gradient of a scalar field. We have established the following evolution equation

d 2 ξ dt 2 j + ∇ 2 jk V ξ k = R i kjℓ qk qℓ ξ i
and the relation ( 24) is a simple consequence of the anti-symmetry of the Riemann tensor and of the identity (20).

Conclusion

We have established that the methods of Euler-Lagrange and Pontryagin conduct to two second order differential systems that couples state and control variables. The choice of a Riemannian metric allows the two systems to be in a well-defined tensorial nature: contravariant for the equation of motion and covariant for the equation of the control variables. The study of a robotic system, of which we try to optimize the control, shows how important is the introduction of an appropriate geometric structure. Riemannian geometry selected on the configuration parameter space favors the metric directly related to the mass tensor as suggested by the expression of the kinetic energy. An undeniable impact is the choice of an invariant cost function with respect to the choice of parameters, this  Pontryagin calculus in Riemannian geometry is a stabilizing factor for numerical developments. Pontryagin's principle applied to contravariant equation of motion associated with the cost function conducts to a mechanical interpretation of adjoint states. The adjoint control equation is established in a condensed form by the introduction of second order covariant derivatives and shows the Riemann curvature tensor. Moreover, this framework exhibits a numerically stable method when discretization is considered. The resolution of the coupled system gives a direct access to control variables without any additional calculation. Thus, future numerical developments will have to juggle between two coupled systems of second-order ordinary differential equations: the equation of motion and the equation for the control.

( 7 )

 7 H(p, y, λ) ≡ p fg and the optimal Hamiltonian H(p, y) ≡ H(p, y, λ * )

  Dubois, D. Fortuné, J.A. Rojas Quintero and C. Vallée due to the simplification of two terms

Contribution published in Geometric Science of Information -Second International Conference,

GSI 2015, Editors: F. Nielsen, F. Barbaresco, Series: Lecture Notes in Computer Science, volume 9389, Springer, pages 541-549, november 2015.


Justyna Jaślan

Alexis De Angeli
email: alexis.deangeli@cnrs.fr

Alexis De

Heterologous expression reveals that GABA does not directly inhibit the vacuolar anion channel AtALMT9

One-Sentence Summary:

GABA, a molecule involved in the regulation of the stomata aperture and drought tolerance, does not modify vacuolar anion fluxes mediated by the anion channel AtALMT9.

Dear Editor, GABA (gamma-aminobutyric acid) is a well-known neurotransmitter activating Cl -channels in synapses and having an inhibitory effect on neural activity. In plants, GABA was proposed to have different functions, for example, in the regulation of the carbon/nitrogen balance and resistance/tolerance to different biotic and abiotic stresses (Steward, 1949;Bouché et al., 2003;Bouché and Fromm, 2004;Fait et al., 2008;Renault et al., 2010;Fait et al., 2011;Sigel and Steinmann, 2012). Plants unable to synthesize GABA present a modified leaf transpiration suggesting a role of GABA in the regulation of stomatal movements (Mekonnen et al., 2016). More recently, it was proposed that GABA regulates vacuolar ion transport in guard cells directly targeting the anion channel AtALMT9 (Arabidopsis thaliana Aluminum Activated Malate Transporter 9; Xu et al., 2021a). Indeed, Xu and colleagues proposed that GABA might affect stomata aperture regulation via direct inhibition of AtALMT9. However, although crucial, straightforward evidence showing a direct effect of GABA on AtALMT9 ion transport activity is missing (Xu et al., 2021b). Therefore, we designed patch-clamp experiments to detect possible direct effects of GABA on AtALMT9 mediated ionic currents.

In the following Letter, we demonstrate that, in our experimental system, GABA has no direct influence on AtALMT9 ion transport activity across the vacuolar membrane.

AtALMT9 is a vacuolar anion channel mediating Cl -influx into the vacuole during stomatal opening (De Angeli et al., 2013). Notably, GABA inhibits TaALMT1 ionic currents in Xenopus oocytes from the cytosolic side (Long et al., 2020). Based on these findings, we decided to test whether the application of GABA from the cytosolic side (GABA cyt ) impacts AtALMT9 mediated Cl -currents. Since AtALMT9-GFP complements almt9 knock-out phenotypes (Xu et al., 2021a), indicating that GFP tagging does not modify ion channel properties, we transiently expressed AtALMT9-GFP into Nicotiana benthamiana for electrophysiological experiments. We performed patch-clamp experiments in cytosolic-sideout configuration from isolated vacuoles (De Angeli et al., 2013;[START_REF] Zhang | Identification of a probable pore-forming domain in the multimeric vacuolar anion channel AtALMT9[END_REF] as this experimental design allows us to directly access the cytosolic face of the vacuolar membrane and to apply different cytosolic conditions to the same patch, i.e. to the same population of ion channels (Zhang et al., 2014). In planta GABA concentrations are in the range of 60 µM -1 mM (Renault et al., 2011;Xu et al., 2021a). Therefore, we spanned a concentration range applying 100 µM, 2 mM and 10 mM GABA at the cytosolic side of AtALMT9 (Fig 1A). We measured AtALMT9 mediated Cl -currents in presence of 100 mM Cl -in the cytosol (black triangles; Figure 1B), and subsequently upon addition of different GABA cyt concentrations (Figure 1A and B; open triangles). We could observe typical AtALMT9 mediated inward currents, with no rundown over 20 minutes (Figure 1D). However, we could not measure any significant effect after the application of the three different concentrations of GABA cyt on AtALMT9 mediated Cl -currents (Figure 1A). Notably, even a concentration as high as 10 mM GABA cyt was unable to inhibit AtALMT9 ion transport activity (Figure 1A). Cytosolic malate is a known activator of AtALMT9 (De Angeli et al., 2013), thus we tested whether application of GABA cyt modifies the activation of AtALMT9 mediated Cl -currents by 1 mM malate 2- cyt . Therefore, we quantified the activation by 1 mM malate 2- cyt of AtALMT9

in the presence and in the absence of 2 mM GABA cyt sequentially applied to the same patch (Figure 1A, B; black squares and C). Additionally, we tested the effect of 100 µM or 10 mM GABA cyt on the activation by 1mM malate 2- cyt . Also under these conditions we did not observe any reduction of the ionic currents over time (i.e. no rundown; Figure 1E).

Importantly, our data show that the application of GABA cyt does not influence the activation of AtALMT9 mediated ionic currents by malate 2- cyt (Figure 1A andB). Since the regulation of the vacuolar ion channels can also occur from the vacuolar lumen side, in a last set of experiments, we tested this possibility for GABA. To check whether GABA lum modifies

AtALMT9 mediated Cl -currents and also malate 2- cyt activation of AtALMT9 we used a vacuolar side buffer (i.e. pipette solution) containing, in addition to all the components used in the previous experiments, 2 mM GABA (full description in the legend of the Figure 1). We could not detect any effect of GABA lum (Figure 2A).

Overall, the results we have obtained answer the question whether GABA directly regulates AtALMT9 ion transport activity (Xu et al., 2021b). Indeed, the present findings show that GABA, applied from either the cytosolic or the vacuolar side, has no effect on AtALMT9 mediated Cl -currents. Consequently, GABA does not have a direct influence on the ion transport activity of AtALMT9 across the vacuolar membrane. Interestingly, by analogy with TaALMT1, it was proposed that AtALMT9 harbors a putative "GABA binding motif" (Ramesh et al., 2015;Xu et al., 2021a). However, the lack of a direct effect of GABA on AtALMT9 ionic currents shows that direct inhibition by GABA is not a feature of all ALMT's. Notably, AtALMT9 and AtALMT1 belong to different clades of the ALMT family (Kovermann et al., 2007), therefore the different behavior possibly reflects structural differences between the two ion channels.

Overall, evidence suggests that GABA influences stomata aperture (Mekonnen et al., 2016;Xu et al., 2021a) but our data suggest that this does not occur through a direct inhibition of AtALMT9. In this context different scenarios are possible. Indeed, we can speculate that in vivo GABA could indirectly modify AtALMT9 transport activity via a so far unknown regulatory factor (e.g. a GABA activated protein, Figure 2B). Alternatively, GABA could regulate other vacuolar ion channels and transporters residing in the vacuolar membrane (Figure 2B). Finally, GABA metabolism modifies organic acid homeostasis in Arabidopsis (Arabidopsis thaliana) leaves (Mekonnen et al., 2016) and therefore we cannot exclude that this indirectly modifies guard cell responses. In summary, our data show that more research is needed to identify the molecular mechanism mediating the effects of GABA in vivo. Recordings were performed in cytosolic-side-out configuration using as cytosolic side solution: 100 mM BTP-Cl -, 0,1 mM CaCl 2 , pH = 7,5 adjusted with BTP and π = 500 mOsm adjusted with D-sorbitol with or without 1 mM malate 2- cyt (as indicated). Pipette solution (i.e. vacuolar side) contained 11,2 mM malate 2-, 100 mM HCl, pH = 6 adjusted with BTP and π = 550 mOsm adjusted with D-sorbitol. To study GABA effect 100 µM, 2 mM or 10 mM GABA was added to the cytosolic side (GABA cyt ) solution or 2 mM GABA was added to the pipette solution (GABA lum ; Figure 2).

Figure 1 .

 1 Figure 1. Cytosolic GABA does not directly inhibit AtALMT9-mediated Cl -currents.

Figure 2 .

 2 Figure 2. Vacuolar GABA does not directly influence AtALMT9 currents.

Downloaded from https://academic.oup.com/plphys/advance-article/doi/10.1093/plphys/kiac132/6553674 by INRA Avignon user on 25 March 2022

Downloaded from https://academic.oup.com/plphys/advance-article/doi/10.1093/plphys/kiac132/6553674 by INRA Avignon user on 25 March 2022 Downloaded from https://academic.oup.com/plphys/advance-article/doi/10.1093/plphys/kiac132/6553674 by INRA Avignon user on 25 March 2022 Downloaded from https://academic.oup.com/plphys/advance-article/doi/10.1093/plphys/kiac132/6553674 by INRA Avignon user on 25 March 2022

ACKNOWLEDGMENTS

We acknowledge the Heterologous Expression and Plant Electrophysiology (EHEV) platform from BPMP lab in Montpellier for their advices and assistance. ADA and JJ were funded by CNRS ATIP-AVENIR grant 2018 and ANR PARASOL (2021-2024).

Authors:

Justyna Jaślan and Alexis De Angeli * Affiliations: