Pierre Cochard

Maxime Popoff

Antoine Fraboulet

Tanguy Risset
email: tanguy.risset@insa-lyon.fr

Stéphane Letz

Romain Michon

A Programmable Linux-Based FPGA Platform for Audio DSP

Recent projects have been proposing the use of FPGAs (Field Programmable Gate Array) as hardware accelerators for high computing power real-time audio Digital Signal Processing (DSP). Most of them imply specific developments which cannot be re-used between different applications. In this paper, we present an accessible FPGA-based platform optimized for audio applications programmable with the FAUST language and offering advanced control capabilities. Our system allows fast and simple deployment of DSP hardware accelerators for any Linux audio application on Xilinx FPGA platforms. It combines the Syfala compiler -which can be used to generate FPGA bitstreams directly from a FAUST program -with a readymade embedded Linux distribution running on the Xilinx Zynq SoC. It enables the compilation of complete audio applications involving various control protocols and approaches such as OSC (Open Sound Control) through Ethernet or Wi-Fi, MIDI, web interfaces running on an HTTPD server, etc. This work opens the door to the integration of hardware accelerators in high-level computer music programming environments such as Pure Data, Su-perCollider, etc.

INTRODUCTION

Whether we're talking about physical modeling, spatial audio, virtual analog, etc., real-time audio Digital Signal Processing (DSP) is always begging for more computational power. Different techniques have been used to increase the performances of real-time audio DSP: optimizing compilers, using dedicated DSP chips, and even hardware accelerators. However, that last approach requires highly specialized skills that most audio DSP engineers don't have. Moreover, audio processing languages such as CSound [START_REF] Lazzarini | Csound: a sound and music computing system[END_REF], FAUST [START_REF] Orlarey | New Computational Paradigms for Computer Music[END_REF], Pure Data [START_REF] Puckette | Pure data: Another integrated computer music environment[END_REF], etc. have been mostly optimized for CPU-based targets and not for hardware accelerators. FPGAs 1 have been used in the past couple of years as po-tential hardware accelerators for audio programs [START_REF] Popoff | Towards an FPGA-Based Compilation Flow for Ultra-Low Latency Audio Signal Processing[END_REF][START_REF] Wegener | Fpgaaccelerated real-time audio in pure data[END_REF][START_REF] Vannoy | Enabling rapid prototyping of audio signal processing systems using system-on-chip field programmable gate arrays[END_REF]. [START_REF] Popoff | Towards an FPGA-Based Compilation Flow for Ultra-Low Latency Audio Signal Processing[END_REF] introduced Syfala2 [START_REF] Popoff | Towards an FPGA-Based Compilation Flow for Ultra-Low Latency Audio Signal Processing[END_REF][START_REF] Risset | Faust2FPGA for Ultra-Low Audio Latency: Preliminary work in the Syfala project[END_REF], the first compilation tool-chain from FAUST to FPGA which automatically maps the kernel DSP computation of a FAUST program on a hardware IP. 3In Syfala, control rate computations (user input, wave table initializations, etc.) are executed on a regular CPU closely connected to the FPGA. The control portion of audio DSP algorithms was not integrated in an Operating System (OS) making the use of software components such as TCP/IP stack, HTTP protocol, OSC or MIDI interfaces, WAV of MP3 codec libraries, etc., inaccessible.

These elements are naturally present on all major operating systems. This is why audio applications are often executed within such an environment (as standalone or hosted processes). When hardware acceleration is needed, design is significantly more complex. First, the accelerated part must be handled separately using a specific technology (e.g., GPU, FPGA, dedicated accelerator, DSP chip, etc.). Then, it must be interfaced with the OS through a dedicated driver (i.e., a kernel driver on Linux). Providing this driver and handling concurrent access to a memory shared by the operating system and the accelerator is in general a complicated task as well.

In this paper we propose a platform which significantly simplifies the hardware/software integration task. It targets Xilinx FPGA-based boards and it provides a ready-touse system that can automatically implement any hardware audio DSP accelerator controlled by an application running on a Linux operating system embedded on the Xilinx Zynq SoC. The Alpine Linux distribution that we provide can be easily tuned for different needs. Any audio DSP application can be compiled from a FAUST code down-to an FPGA IP and interfaced with the application.

Section 2 presents more precisely the goals of our work and also reviews existing comparable approaches. Section 3 presents the Syfala compiler that we rely on for FPGA IP generation and describes how Linux integration is performed in the Syfala toolchain. Section 4 provides some insights on the building of an embedded Linux distribution for Xilinx SoCs. Section 5 presents the specific software components that we added to our Linux distribution to handle the various needs of audio applications. Finally, Section 6 presents how we could, with very few additional efforts, implement a Minimoog emulation (al-ready implemented in the FAUST libraries [START_REF] Smith | Signal processing libraries for faust[END_REF]) on the Xilinx Zybo board.

CONTEXT AND STATE OF THE ART

Since the end of Moore's law, hardware acceleration is seen as a major mean for increasing the performances of digital systems. The vast ecosystem of dedicated accelerators is difficult to handle by regular software programmers though. This is very pregnant in computer vision and image processing [START_REF] Hajirassouliha | Suitability of recent hardware accelerators (DSPs, FPGAs, and GPUs) for computer vision and image processing algorithms[END_REF] and it is also a new tendency in audio signal processing.

FPGA-based platforms have been used a lot for dedicated audio processing during the past 20 years [START_REF] Pfaff | Implementing digital audio effects using a hardware/software co-design approach[END_REF][START_REF] Dragoi | Efficient FPGA Implementation of Classic Audio Effects[END_REF]. More recently, some projects have proposed the use of embedded Linux in this context [START_REF] Wegener | Fpgaaccelerated real-time audio in pure data[END_REF][START_REF] Vannoy | Enabling rapid prototyping of audio signal processing systems using system-on-chip field programmable gate arrays[END_REF][START_REF] Vannoy | An open audio processing platform using soc FPGAs and model-based development[END_REF][START_REF] Scheibler | Pyramic: Full stack open microphone array architecture and dataset[END_REF]. However, none of them focus on real compilation of audio programs: they all propose a dedicated hardware IP design for each implemented audio application.

Recent technical developments of FPGA-based platforms make them more suitable for the acceleration of audio applications. Modern FPGA chips include a powerful CPU integrated in a SoC tightly connected to the FPGA fabric. The integrated SoCs (Zynq on Xilinx/AMD platforms, Intel SoC for Altera/Intel platforms) are powerful enough to run an operating system. OS integration is generally facilitated by FPGA vendor tools that can be used to generate drivers easing the interfacing of the IP synthesized on the FPGA with the OS present on integrated SoCs, etc. This whole process remains complex to settle and is very dependent on the quality of the tools provided by the vendors.

For instance, Xilinx/AMD proposes Petalinux, which is a Linux distribution dedicated to the Zynq SoC family. Petalinux is built using the Yocto open-source toolchain which is widely used but quite complex. We could not effectively configure and build Xilinx's Petalinux on desktop computers using recent OS, hence we decided to build our distribution from scratch. Using a custom Linux distribution has many advantages: precise control of the content of the distribution, facilitated re-using of existing software components, etc.

In this paper, we describe a generic way of building a Linux system compatible with Xilinx Zynq platforms. We use the Linux kernel provided by Xilinx but we do not use Petalinux. This has the major advantage of being much simpler as this process doesn't rely on Yocto. This also gives us a more direct control on the deployed components.

As far as we know, Syfala is the only compilation flow for audio applications on FPGA-based boards. The work presented here enriches the Syfala compilation flow with the simple deployment of a lightweight embedded Linux distribution.

NEW DEVELOPMENTS IN THE SYFALA COMPILER

The Syfala compiler has been developed for Zynq-based Xilinx FPGA-based boards. 4 These include a CPU (dual core Cortex-A9 ARM) running the control part of the compiled audio application while core DSP computations are executed on the FPGA. This initial flow is presented in Fig. 1 where the whole compilation process starts from a single FAUST file named audio.dsp. [START_REF] Popoff | Towards an FPGA-Based Compilation Flow for Ultra-Low Latency Audio Signal Processing[END_REF], gray boxes are generated during the compilation flow. The whole process is automatic, the user only has to write the audio.dsp file. The audio IP hardware component is referred as the Syfala IP in the rest of the paper.

The focus of the initial version of Syfala was on the compilation of FAUST programs down-to an ultra-low latency FPGA IP. Hence, less efforts went on the control/interface of the system. The control of the application (audioCtl.cpp on Fig. 1) is carried out through a single main() program running bare-metal (i.e., without any operating system) on the ARM processor. This main() program communicates with the host computer in a very primitive way by sending characters on a UART port which is embedded in the USB connection between the host and the FPGA board. The user interface of the audio application (audioUI.cpp on Fig. 1) re-uses a FAUSTgenerated GUI and sends in a infinite loop the controller values to the ARM via the USB/UART connection.

The improvements presented in this paper concern the way the user interface is handled on the ARM processor. As mentioned in the previous section, using an operating system on the ARM allows the user to re-use many software components that are already compiled for Linux.

The new compilation flow is presented in Fig. 2. An embedded Linux distribution is built once (see Section 4). It includes libraries for managing control protocols such as OSC and MIDI as well as any other standards supported by the FAUST ecosystem. Once the FPGA platform boots on the SD card containing this Linux distribution, the user has access to the Linux shell via the dedicated USB/UART port. It is also possible to connect to the board via Ethernet (DHCP protocol used by default) and possibly add new packages to the Linux distribution on the SD card. After this, the Linux system doesn't have to be rebuilt: any other Syfala audio application will run with the same Linux SD card. Compiling a new applica-

U A R T /U S B
Figure 2. The extension to the original Syfala tool-chain (shown in Fig. 1) proposed in this paper with an embedded Linux OS booting from an SD-card. The user interface can now use many common communication protocols (e.g., OSC, MIDI, etc.) to control the audio DSP.

tion "audio2.dsp" on the FPGA board only requires to copy the new "audio2Ctl.elf" on the SD card using an ssh connection.

AD-HOC EMBEDDED LINUX BUILDING

This section describes the building process of the Linux distribution. It insists on the specificity related to our platform, in particular the fact that the FPGA IP driver must be handled properly. The complete procedure is described in more details on the Syfala GitHub 5 It is a standard Linux building procedure with a focus on driver construction for the Syfala IP. The procedure is split in two stages which build the boot and root partitions present on the SD card. The boot partition contains the first and second stage bootloader (U-Boot), the Linux kernel image and modules as well as the device-tree describing the peripherals used on the platform. The root partition contains the complete Linux filesystem that will be mounted after booting. It includes in particular the audioCtl.elf application as well as the FPGA bitstream, both built by the Syfala compiler.

Boot Partition: The U-Boot binary and the Kernel sources are provided by Xilinx 6 (we used the version 2022.2 of Xilinx tools). We added a custom configuration file activating the userspace I/O system (for the Syfala IP), as well as various drivers (i.e., ALSA, Wi-Fi, etc.).

The device-tree is a set of tools and a data structure for describing the hardware. It is read by the operating system at boot time to avoid hard coding information in the system.

In general, the complete device-tree is described in the text file: system.dts. Due to the difficulties encountered when generating a device-tree suiting our very specific needs with the Xilinx tools, we added a static devicetree source file that has been modified by hand in order to facilitate the procedure. The following presents some of the changes and additions that we made to the standard Zybo Z7 device-tree:

• The boot arguments were modified in the following way:

bootargs = "earlycon uio_pdrv_genirq.of_id=generic-uio root=/dev/mmcblk0p2 rootfstype=ext4 rw rootwait";

• A section of 128 MB of reserved memory used by both the Syfala IP and the Linux applications was reserved. This section is not managed by the memory management unit (MMU):

reserved-memory { #address-cells = <1>; #size-cells = <1>; ranges; reserved: buffer@35000000 { no-map; reg = <0x35000000 0x08000000>; }; }; reserved-driver@0 { compatible = "xlnx,reserved-memory"; memory-region = <&reserved>; };

• Our Syfala IP was added as a generic-uio device. It is accessible through an axilite bus as /dev/uio0: syfala: syfala@40010000 { clock-names = "ap_clk"; clocks = <&misc_clk_0>; compatible = "generic-uio"; status = "okay"; reg = <0x40010000 0x10000>; xlnx,s-axi-control-addr-width = <0x7>; xlnx,s-axi-control-data-width = <0x20>; };

Root Partition: We chose an Alpine Linux distribution in order to build the root filesystem. It is known to be lightweight, not relying on glibc and systemd, but instead on musl, busybox, and OpenRC. The required files, such as the u-boot, apk-tools or linux-firmware archives, can be directly downloaded from the official Alpine Linux repositories. We then used the QEMU ARM CPU emulator and a chroot operation to install and configure our file system (Zynq SoCs include an ARM CPU).

The procedure for the creation of the rootfs structure and contents is standard (see on GitHub for details). We selected a certain number of packages to be pre-installed, activated the required drivers to configure the board's peripherals, and installed the additional files needed for the control of the Syfala IP (i.e., the FPGA bitstream and its associated Linux control application).

For the compilation of the control application audioCtl.cpp in Fig. 2, the Xilinx driver library generated by vitis hls needs to be included. Its API contains for instance all the UIO system calls required for the communication between the application and the Syfala IP. For instance, below is the initialize() function that initializes the IP after booting:

void initialize(XSyfala& x) { [...] XSyfala_Initialize(&x, "syfala"); [...]
The shared-memory that we explicitly reserved in our device-tree also needs to be mapped in a certain way in order to be properly accessed from our Linux control application (it has to be coherent with the kernel):

SOFTWARE CONTROL

While MIDI is still widely-used as a protocol for controlling generic audio interfaces, other standards have also made their way into the audio software ecosystem. Examples are Open Sound Control (mainly over UDP), OS-CQuery (using a HTTP/WebSocket layer on top of the traditional UDP OSC 7 ), or even just plain HTTP. The main advantage of these protocols reside in their flexibility over the type of value transmitted. 8 These protocols are also import("stdfaust.lib"); declare options "[midi:on]"; declare options "[osc:on]"; // sliders oscFreq = hslider("oscFreq [midi:ctrl 13]", 80,50,500,0.01); lfoFreq = hslider("lfoFreq [midi:ctrl 14]", 1,0.01,8,0.01); lfoRange = hslider("lfoRange [midi:ctrl 15]", 1000,10,5000,0.01) : si.smoo; noiseGain = hslider("noiseGain [midi:ctrl 16]", 0,0,1,0.01) <: _ * _; masterVol = hslider("masterVol [midi:ctrl 17]", [...] supported by the large diversity of devices that can be used to control an audio process remotely: computers, smartphones or tablets, with plethora of dedicated third-party applications and interfaces.

The FAUST ecosystem has been supporting these protocols for many years, facilitating their use on a wide range of devices. The link between the FAUST program and the controllers is established by writing metadata in the FAUST DSP code itself. An example of such metadata is shown in the program depicted in Fig. 4. The FAUST compiler and the various tools associated with the FAUST ecosystem generate the code needed to communicate with the chosen protocol on the targeted architecture.

The Linux distribution that we propose natively supports Xilinx Zybo and Genesys FPGA boards. It also contains the FAUST architecture files, meaning that its MIDI, OSC, and HTTP features and interfaces are already enabled and ready-to-use on the board. This is of course much harder to implement in a bare-metal configuration, due to the multitude of drivers and additional libraries that would have been required.

After Linux booting, MIDI control can be accessed through its USB "On The Go" port (configured as "host" in our device-tree), by plugging-in a compliant controller. This requires the board to be powered-up by an external source (unless the controller itself is already powered up), and its jumper configuration to be arranged accordingly. The ALSA kernel modules, with the addition of a few RtMidi and FAUST utilities, then take care of properly mapping the received control values to the DSP code.

The implementation of the OSC and HTTP-based interfaces consists of a set of FAUST wrappers around the liblo and libmicrohttpd libraries, which are both available as dev packages in the Alpine Linux repositories. These interfaces are launched at the initialization of the control application, and have the advantage of being synchronized with one another, meaning that playing with a slider on a MIDI hardware controller effectively updates the same (virtual) slider on both the HTTP and OSC interfaces. An excerpt from the control application code, showing the initialization of the MIDI, OSC and HTTP interfaces in the audioCtl.cpp on the ARM, can be seen in Fig. 5. By default, the OSC Uniform Resources Identifiers (URI) of these control parameters are automatically attributed by FAUST in a very specific way, following its own GUI hierarchical tree and format (DSP/group/slider). For more flexibility, it is also possible to add aliases directly in the FAUST code metadata, in the case where the client device has a fixed OSC URI format. 9 On the other hand, the HTTP interface does not require any configuration from the user: it uses a dedicated JSON-based protocol, which describes the application's control interface set in the DSP code, and is used internally by the underlying JavaScript engine to build the graphical user interface. 10Finally, in order to make the connection process from the client devices a bit less cumbersome on DHCP-configured networks, an Avahi service is also started whenever the control application is initialized. Given that the client device is on the same network as the FPGA board, one can conveniently discover all the registered Syfala devices (with the help of the avahi-browse command, for instance), pick up their IP address and UDP/TCP ports, etc. Once this information has been retrieved, the user can finally connect to the OSC/HTTP servers from various applications, such as a browser or an OSC-compliant interface.

APPLICATION: MINIMOOG ON FPGA

As part of the developments made on our new Linuxbased toolchain, we set up a standalone synthesizer, which is largely based on the emblematic virtual-analog "Minimoog" (Model D) emulation written in the FAUST language by Julius O. Smith. 11 This monophonic synthesizer has 1 external audio input, 2 audio outputs, and is composed of 3 oscillators (with, for each one of them, a set of 6 different waveforms to choose from, in real time), as well as a pink/white noise-generator, an amplitude envelope, and, of course, a Moog Ladder 4pole virtual-analog filter. In this specific configuration, the Zybo board has its own external power source and is (i) configured to boot automatically on a microSD card containing our syfala-linux build and (ii) connected to a MIDI-USB controller, a network router, and a pair of speakers with 3.5mm jack inputs (see Fig. 6 and7). When powered up, the Linux Kernel image is booted up, and its drivers and peripherals are initialized. Once the process is complete, the root filesystem is then mounted, and, with the help of an autologin and initialization script, the Minimoog FPGA bitstream and its associated Linux control application are immediately loaded. The system can still be accessed through SSH, allowing the user to load other bitstreams and control-applications remotely.

It takes between 25 and 30 seconds for the whole boot process to complete on average, from the moment the board is powered-up to the moment the user is able to play a note on the MIDI controller and hear the resulting sound. Given the time needed to load the FPGA bitstream (between 50 and 100 milliseconds) and to initialize the control application (between 2 to 5 seconds), the boot time could be improved a lot.

For MIDI control, we managed to map a widely-used controller, the Novation LaunchControl XL, to some of the FAUST DSP control parameters, using the metadata system. These parameters include: the oscillators' tuning, amplitude and waveform selection, the Moog Ladder corner frequency and "Q" factor, the pink/white noise levels, etc. We have also set up the controller's pads to be used as "keys" in order to control the main pitch frequency and the triggering of the main amplitude envelope, which also forced us to introduce some minor changes to the original Minimoog FAUST DSP code.

The hardware/software split is handled as usual by Syfala: all audio-rate computations are directly handled on the FPGA while all control-rate and initialization computations are carried out in the ARM.

For anyone knowing FAUST Minimoog implementation, this experiment is not really unique as the Minimoog FAUST program can actually run on a regular PC. Indeed, the Syfala tool-chain has been optimized for ultra-low latency. The resource used by this design, detailed hereafter, could be improved a lot in many ways: allow for longer latency, use fixed point computations, etc. We are actively working in this direction. However, what is unique is the speed with which the whole hardware/software design was realized (a few hours), compared to a traditional VHDL/Verilog IP manual implementation.

The resources used by the Minimoog IP are shown in Figure 8. The Zybo Z7-10 board model was insufficient to implement the Minimoog (164% of the number of available lookup tables were needed), but the Zybo Z7-20 model was large enough: bringing down LUT resources usage to only 46%. Concerning the computation time for each sample, it takes approximately 1899 cycles for the FPGA to perform the computation of a single sample (15.601 µs). If the sampling frequency is 48KHz, the time between two sample is approximately 22.385 µs. Therefore, while resource usage is far below its maximum in our case (46% on a Zybo-Z7-20), we are approaching more rapidly (at 69%) the maximum allowed latency for the computation of the Syfala IP. The total allocated DDR memory (mainly used for the oscillator wavetables) for this project is 50 kBytes. DDR is accessed 18 times per sample and that is where the latency comes from. Concerning control signals which are flowing between the ARM and the FPGA, the FPGA code accesses and copies 80 integer/floating point values at every sample. These values are the result of the control-rate expression computations made by the ARM and shared with the Syfala IP through a memory-mapped AXILITE bus (while DDR accesses use the M AXI bus). The GUI interface is able to tune 60 input parameters which are control values coming from the FAUST virtual controllers (e.g., sliders, knobs, buttons, etc.). These values are continuously retrieved and updated by the OSC, HTTP, and MIDI inter-faces, the HTTP interface generated for the Minimoog is shown in Fig. 9. It takes on average 110 to 115 µs for the ARM to compute all the control-rate expressions and write the result in memory. As one can see, this does not fit in a one sample time interval but it does not need to as we are in the control rate space. Regarding build and compilation times: it takes for this project 15 seconds, for the FAUST compiler to generate both FPGA and ARM C++ code. To give an order of magnitude, the C++ code generated for the audio-rate computation function is 180 lines long, 80 lines for the controlrate function. The High Level Synthesis (HLS) process takes approximately 2 minutes to compile the FAUSTgenerated code down-to FPGA Hardware Description Language (HDL). The full project synthesis, made with Vivado, remains the toolchain's longest process, taking about 30 to 40 minutes to complete for this specific DSP target. Finally, given that the Linux root partition has already been previously built, only 1 to 2 minutes are usually required in order to build the control application, either directly on the board, or within a chroot environment.

CONCLUSION

In this paper, an extension of the Syfala tool-chain providing a Linux-based hardware accelerator for audio applications has been presented. This work is freely accessible (open source) on the Syfala Github 5 (except for Xilinx synthesis tools of course). While it is currently only targeting Xilinx Zynq-based platforms, it could easily be modified to support other SoC-based FPGAs.

This work should open the door to other kinds of applications relying on Linux. For example, embedding FAUST generated IP as externals in Pure Data, CSound or Super-Collider which would run the ARM processor. This would be an easy way to extend these tools with hardware acceleration. This would however require to work on the interface between these tools with the Syfala IP, this is something that we would like to explore in the future. As mentioned before, the current performances of the Syfala compiler have to be improved as it has been designed for ultra-low latency. In a future version of Syfala, the balance between performance and latency will be a parameter of the compilation flow.

More generally, we believe that FPGAs have an important role to play in the field of real-time audio DSP by providing more computational power, but also unparalleled performances in terms of latency, number of channels that can be processed in parallel, ultra-high audio sampling rate, etc. We're currently exploring all these new domains of applications.

#

  define MEM_ADDR 0x35000000 #define MEM_LEN 0x08000000 int fd = open("/dev/mem", O_RDRW | O_SYNC); void * mem = mmap(NULL, MEM_LEN, PROT_READ | PROT_WRITE, MAP_SHARED | MAP_FILE, fd, off); if (mem == MAP_FAILED) { perror("Can't map reserved memory space"); exit(1); }Once the boot and root partition are flashed on the SD card, and the FPGA board is booted, the Linux shell can be accessed through the USB serial port connection as shown in Fig.3.DHCP is used for IP address attribution.

Figure 3 .

 3 Figure 3. Linux boot console received by the host computer on serial port /dev/ttyUSB1 from the Zybo board booting on our Linux distribution (simple sinewave audio DSP program).

Figure 4 .

 4 Figure 4. Example of a FAUST program with metadata indicating which FAUST slider will be associated with which MIDI controller. OSC control can be used too.

Figure 5 .

 5 Figure 5. Excerpt from the audioCtl.cpp main initialization function, showing how the control interfaces are instantiated, linked with one another, and started.

Figure 6 .

 6 Figure 6. Zybo-based Minimoog (Model D) standalone synthesizer emulation (hardware view of the setup).

Figure 7 .

 7 Figure 7. The Zybo Minimoog synthesizer set-up.

Figure 9 .

 9 Figure 9. HTTP interface example, generated for the Minimoog application.

https://github.com/inria-emeraude/syfala -All URLs presented in this paper were verified on Feb. 6, 2023.

Throughout this paper, IP stands for Intellectual Property, i.e., a circuit component. Proceedings of the Sound and Music Computing Conference 2023, Stockholm, Sweden

https://www.xilinx.com/products/ silicon-devices/soc/zynq-7000.html

Proceedings of the Sound and Music Computing Conference 2023, Stockholm, Sweden

https://github.com/inria-emeraude/syfala/ tree/dev/linux

https://github.com/Xilinx/u-boot-xlnx and https://github.com/Xilinx/linux-xlnx

https://github.com/Vidvox/OSCQueryProposal

MIDI, with the exception of the 14-bits pitchbend control values, only allows for 7-bits-based integer values.

See https://faustdoc.grame.fr/manual/osc/ for more information.

https://faustdoc.grame.fr/manual/http/

https://github.com/grame-cncm/faust/tree/ master-dev/examples/SAM/virtualAnalog

Acknowledgments

This work has been carried out in the context of the FAST ANR project 12 (ANR-20-CE38-0001) funded by the French ANR (Agence National de la Recherche).


Rita M B Alves

Claudio A O Nascimento

Luiz V Loureiro

Pascal Floquet
email: pascal.floquet@ensiacet.fr

Xavier Joulia
email: xavier.joulia@ensiacet.fr

Multi-Objective Optimization of an Industrial Isoprene Production Unit by Using Genetic Algorithm Approach

Keywords: Genetic Algorithm, Multi-Objective Optimization, Isoprene

. Then, the aim of this paper is to present and discuss the applicability of a GA as an alternative procedure for a multi-objective optimization of an industrial process that may be difficult to handle by classical methods. In this case the optimization of the entire plant involves 21 variables to be optimized. So, in order to decrease the dimensionality of the problem, the global model was divided into three sections and each one was optimized separately, but sequentially, by using the optimal conditions from previous optimization section procedure. For this, a multi-objective genetic algorithm (MOGA) based on a Pareto sort (PS) procedure was implemented to manage this specific problem.

Introduction

When an optimization problem involves multiple objective functions, case of the most real-world search and optimization problems, the task of finding one or more optimum solutions is known as multi-objective optimization. In this way, different solutions may produce conflicting scenarios among different objectives. A solution that is extreme with respect to one objective requires a compromise in others objectives [START_REF] Deb | Multi-Objective Optimization Using Evolutionary Algorithms[END_REF].

Thus, in problems with more than one conflicting objectives, there is no single optimum solution, but it exists a number of solutions that are all optimal and it is not simple to judge one set of optimal solutions better than any other. Then, it is necessary to introduce some further, non-technical and/or qualitative information and personal experience. From this way, it is possible, in a multi-objective optimization, to find multiple sets of optimal solutions by considering all the important objectives and, after, by using additional information, to choose one solution among all solutions obtained [START_REF] Deb | Multi-Objective Optimization Using Evolutionary Algorithms[END_REF]. To find multiple optimal solutions in one single simulation run makes Evolutionary Algorithm (EA) an important tool to solve multi-objective optimization problems and for this reason, over the last decade, genetic algorithms (GAs) have been extensively used as search and optimization tools in various problem domains, including the sciences, commerce and engineering. The primary reasons for their success are their broad applicability, ease using and global perspective [START_REF] Deb | Multi-Objective Optimization Using Evolutionary Algorithms[END_REF]. Moreover, GAs may find a solution near the global optimum within reasonable time and computational costs. For this, the aim of this paper is to present and discuss the applicability of a multi objective genetic algorithm (MOGA) based on Pareto sort (PS) for a multi-objective optimization of an industrial process that may be difficult to handle by classical methods and for which formal objective functions can not be applied.

Implementation of a Genetic Algorithm for Process Optimization

The scheme of optimization is shown in the Figure 1. In this work, a real-parameter coded genetic algorithm was used, so a chromosome is a vector of floating point numbers whose size is kept the same as the length of the vector, which is the solution to the problem. Random generation was the procedure chosen to create the initial population. This strategy guarantees a population able to vary enough to explore the entire range of the search space. The feasibility of each individual of this population is evaluated in order to verify constraint violations, before being integrated into the population to be used in the MOGA procedure. This population is then called feasible population. A neural network model [START_REF] Alves | Otimização de um Processo Industrial de Produção de Isopreno via Redes Neurais[END_REF], Alves et Nascimento, 2004) was previously developed in order to model and simulate the process. This work was used as reference for this study and the built model is the evaluation function used to represent the system. Once a population of solutions is created, it is necessary to evaluate the solution in the context of the underlying objective functions and a fitness value or domination value is assigned to each individual. In other words, given a particular chromosome, a solution, the fitness function returns a single numerical fitness, which is supposed to be proportional to the utility or adaptation of the solution. In this case, the Pareto domination conception was used in order to define in a way that a solution x 1 is said to dominate the other solution x 2 [START_REF] Deb | Multi-Objective Optimization Using Evolutionary Algorithms[END_REF]. Thus the feasible objective space contains Pareto-optimal solutions (the non-dominated set) and non-Pareto optimal solutions (the dominated set). Then, it is clear that in multi-objective optimization, the task is to find as many Pareto-optimal solutions as possible in a problem. In this work it was implemented the sorting procedure as proposed by [START_REF] Massebeuf | Optimisation Multicritère de Procédés Discontinus d'Homopolymérisation et de Copolymérisation en Émulsion[END_REF]. Once the best individuals, i.e., the non-dominated set, are determined, it is possible to apply the genetic operators: crossover and mutation. But before carrying out these operators, in this work, it was proposed to keep these best individuals from one generation to the next without being modified by the genetic operators. Then crossover operator was then used to create two new individuals by swapping all characters between two parents chromosomes positions. From this way, it was possible to diversify the population of the new generation. This procedure was repeated until the number of new and different individuals created achieves the size of the initial population. It is expected the new solutions or individuals generated by crossover operator will be better than both of the original individuals or parents. After the mutation operator was applied on the new population. Mutation is the occasional random alteration of the value of a chromosome position (gene) that prevents the premature convergence of GA to sub optimal solutions and ensures that the probability of reaching any point in the search space is never zero [START_REF] Herrera | Tackling Real-Coded Genetic Algorithms: Operators and Tools for Behavioural Analysis[END_REF]. The mutation rate used was 1%. Finally, the stop criterion assigns the end of the procedure. The criterion considered in this study is that all individuals of one generation will be non-dominated in the Pareto Sort procedure.

Optimization of Isoprene Production Unit

The system studied is the Isoprene Production Unit from BRASKEM, the largest Brazilian petrochemical plant. An extractive distillation process is used to perform the isoprene production. The process of isoprene production can be basically divided into three sections: feed preparation, extractive distillation and solvent recovery and fractionating. Figure 2 shows schematically this process. The Isoprene industrial process is a complex process, and it is not easy to be solved by commercial simulators mainly due to the lack of thermodynamics properties. A neural network approach has been previously developed in order to model this industrial process from historical data [START_REF] Alves | Otimização de um Processo Industrial de Produção de Isopreno via Redes Neurais[END_REF]Alves and Nascimento, 2004). The main objective of this work is to establish optimal operational conditions in order to obtain higher production of Isoprene within of the specifications defined by the costumers. The constraints of quality and safety required by the process and the variables to be optimized are shown in Table 1. All the units of the variables are arbitrary. The optimization of the entire plant involves 21 variables to be optimized.

Then the global model was divided into parts in order to decrease the problem of dimensionality. Each part of the model was optimized separately, but sequentially using the optimal conditions from the previous optimization procedure, and of course this procedure do not assure to achieve the global optimal conditions. The division corresponds to the following sections: 1-Feed Preparation; 2-Extractive Distillation and Solvent Recovery; 3-Fractionating. The optimal values generated at each step of the optimization procedure were used as input data for the next step. Using the multiobjective genetic algorithm developed carried out the optimization procedure at each step. The choice of the constraints shown in the Table 1 has the following objectives: a) to specify the composition of CPD and 2M2B at the Feed Preparation Section in order to guarantee the specification of the final product; b) to concentrate IP at the Feed Preparation Section in order to feed the Extractive Distillation Section as required; c) to specify the temperature of the bottom of the Depentanizer Column in order to avoid degradation of DCPD; d) to specify the composition of 2-Butine and CPD at the distillate of the Second Extractive Distillation Column in order to guarantee the specification of the final product and; e) to specify the composition of Water at the top of the First Column of Solvent Recovery. The content of Water in the solvent circuit is a critical point of this unit. Depending of the main objective to be achieved, others constraints could be considered.

Results and Discussion

The first step is to create randomly an initial population of the variables of the feed preparation section. The purpose is to find the operational conditions, lowest reflux flow, lowest reboiler steam flow and lowest feed temperature, which could minimize the energy costs, i.e., conditions that lead to a less expensive operation. Low feed temperature is also important because it avoids dimerization reactions. Only the solutions, which satisfy some operational conditions are accepted. These conditions are CPD outlet concentration and IP loss from the reactor; IP, CPD and 2M2B (2-Methyl-2-Butene) concentrations in the overhead product from the distillation column and the temperature of the bottom of the depentanizer column. The final population of this first step of the optimization procedure is then considered input data for the next section optimization procedure, i.e., the extractive distillation and recovery solvent sections. For this second step, only the variables that do not come from the first section are generated randomly and optimized following the same procedure previously described. The requested process conditions are the lowest reflux flow, the lowest reboiler steam flow and the lowest temperatures. They are accepted in order to find the operational conditions that lead to less operational costs or less energy consumption. Once more time, the final population or optimal solutions of the second step of the optimization procedure is considered input for the third section, i.e. the fractionating section. In this case the operational conditions that lead to less operational costs or less energy consumption are the lowest reflux flow, the lowest reboiler steam and the lowest temperatures. Following this procedure, each set of optimal conditions (final population) from the previous step provided a new set of optimal conditions for the next optimization step.

As an example of the optimization result, it is possible to compare some operational conditions and optimal conditions obtained for a given condition of feed. It is possible to obtain a reduction of 32% in the reflux flow and 26,5% in the reboiler steam at the Col-01. It is possible also a reduction of 11,5% -18% in the solvent flow and 20% -50% in the reflux flow at the Col-02.

Conclusion

GAs have had a great success in search and optimization problems. The reason is their ability to exploit the information accumulated about an initial unknown search space in order to bias subsequent searches into useful subspaces, i.e., their adaptation. This is particularly useful in large, discontinuous, complex, and poorly understood search spaces, where classical search tools are inappropriate, offering a valid approach to problems requiring efficient and effective search techniques. GAs can solve hard problems quickly and reliable and they are easy to interface to existing simulations and models. GAs do not guarantee to find the global optimum solution to problem, but they are generally good at finding acceptably good solutions near the global optimum within reasonable time and computational costs.

The case study presented shows of success the applicability of a genetic algorithm as an alternative procedure for a multi-objective optimization of industrial process that may be difficult to hand by classical methods.

Figure 1 .

 1 Figure 1. Scheme of Optimization Procedure

  c t i o n E v a lu a t i o n F e a s ib le P o p u la ti o n G e n e r a t i o n = G e n e r a ti o n + 1 F i n a l P o p u la t io n N e u r a l N e t w o r k M o d e l N e w P o p u l a ti o n

  Figure 2. Isoprene Unit

Table 1 .

 1 Variables and Constraints for the Process Optimization.

Author to whom correspondence should be addressed: rita@lscp.pqi.ep.usp.br

Acknowledgments

The authors gratefully acknowledge FAPESP and CAPES/COFECUB for their financial support and BRASKEM for providing the industrial data used in this work.


Keywords: Semi supervised domain adaptation, deep learning, contrastive learning, demography, land cover, health, malaria

Environment and demographic dynamics are strongly linked. However, relevant data to study this interaction may be scarce especially in sub-Saharan Africa where it is not always possible to perform such studies with a high temporal frequency. Satellite imagery, when linked to demographic data, can be a significant asset to estimate missing data as it covers every country with both high spatial and temporal resolution. We aim to take advantage of satellite data to characterize the environment in inter-tropical areas. This environment is regulated by the changing of two seasons that are essential to consider. We introduce a semi-supervised domain adaptation strategy for neural networks based on seasonal changes. This strategy can be used to produce land cover maps in regions of the world where limited labeled datasets are available. We apply this method to produce environmental indicators and link them to malaria rates from the Malaria Indicator Survey of Burkina Faso. We show that malaria rates are correlated not only to urbanisation but also to the environmental characterisation of studied areas.

Seasonal semi-supervised domain adaptation for linking population studies and Local Climate Zones

Basile Rousse * † , Sylvain Lobry * , Géraldine Duthé † , Valérie Golaz † ‡ , Laurent Wendling *

I. INTRODUCTION

Demographic studies often provide approximate geolocations of interviewed households which allows to link demographic data to their corresponding environment using derived spatial data. Demographic analysis would gain from comprehensive environmental descriptors. The Local Climate Zones (LCZ) classification scheme (Figure 1) can be used to describe the environment based on the surface structures, their material and human activity. It was originally designed for global-scale heat island detection, without cultural consideration [START_REF] Stewart | Local Climate Zones for Urban Temperature Studies[END_REF]. This standardized descriptor can be predicted at large scale using remote sensing images and can be linked to various demographic studies. LCZ mapping from single and multi sources spatial features is an active research topic. The So2Sat dataset is a large-scale dataset of 32× 32 Sentinel-1 and Sentinel-2 images from various parts of the world for training deep neural networks [START_REF] Zhu | So2Sat LCZ42: A Benchmark Data Set for the Classification of Global Local Climate Zones[END_REF]. LCZ maps of 1642 cities have been generated using this dataset for urban studies [START_REF] Zhu | The urban morphology on our planet -Global perspectives from space[END_REF] with a resolution of 320m. A Global LCZ map [START_REF] Demuzere | A global map of Local Climate Zones to support earth system modelling and urban scale environmental science[END_REF] was produced with a 100m resolution built from 46 spatial features, processed with random forest algorithms. Using the method developed in [START_REF] Demuzere | Global transferability of local climate zone models[END_REF] and random forests classifiers, [START_REF] Brousse | Can we use Local Climate Zones for predicting malaria prevalence across sub-Saharan African cities?[END_REF] links LCZ to Malaria prevalence in sub-Saharan cities. Considering Work supported by the Data Intelligence Institute of Paris (DiiP), and IdEx Université Paris Cité (ANR-18-IDEX-0001). This work was performed using HPC resources from GENCI-IDRIS (Grant 2021-AD011013527). Semi-Supervised Domain Adaptation (SSDA) is meant to benefit from the increasing amount of unlabeled data. SSDA methods aim to reduce the divergence between a source domain (with labeled data) and a target domain (without labeled data) which have different distributions. Among them, consistency regularization techniques force a model to predict the same class for an image from the target dataset and its perturbations. Recent developments took advantage of the contrastive loss instance representation learning for reducing the domain gap [START_REF] Singh | CLDA: Contrastive Learning for Semi-Supervised Domain Adaptation[END_REF]. Such techniques are well suited for remote sensing applications where global datasets have already been created [START_REF] Schmitt | SEN12MS -A Curated Dataset of Georeferenced Multi-Spectral Sentinel-1/2 Imagery for Deep Learning and Data Fusion[END_REF], [START_REF] Sumbul | BigEarthNet: A Large-Scale Benchmark Archive for Remote Sensing Image Understanding[END_REF] and data is produced on a regular basis. This contribution aims to provide a training strategy to produce LCZ maps of every part of the world, using Sentinel-2 products, without additional annotated data. To this end, we introduce a seasonal-SSDA (s-SSDA) approach combining supervised and contrastive learning to extract useful global and more specific local features using unlabeled data. The model is expected to transfer spatial features learnt from the source dataset as well as being robust to the target seasonal variations. The generated LCZ maps can provide useful data to contextualise localised demographic information. As a study case, we mapped the whole of Burkina Faso to link LCZ environmental descriptors to demographic indicators through the Malaria Indicator Survey (MIS) of 2017-2018 [START_REF]Enquête sur les indicateurs du paludisme au Burkina Faso[END_REF]. We show that the proposed s-SSDA improves the performances of LCZ mapping. With these results, we characterized studied areas according to their urbanization rate, their LCZ characterisation and their malaria rates.

II. METHOD

We define a neural network F (.) as our LCZ classifier which takes as input an image x and returns a vector s = [s 1 , s 2 , ..., s 17 ] T of prediction scores for each LCZ class. The prediction of the model is the class with the highest score. As mentioned in section I, existing global datasets may need to be supplemented by additional data related the country under study. This method aims to take advantage of existing labeled datasets and of the large amount of unlabeled Sentinel-2 images to produce maps at the country-level. We define D S = (x i , y i ) i∈ 1,n S as the labeled dataset where x i is a Sentinel-2 image, y i its associated label and n S the number of the samples in the dataset. The proposed method is based on seasonal perturbations to make the model robust to these seasonal changes. Then, we supplement D S with an unlabeled dataset

D T = (z s1 i , z s2 i ) i∈ 1,n T made of n T pairs of images z s1
i , z s2 i from the same area at different seasons s 1 and s 2 . These two datasets are combined using a SSDA approach and learning.

A. Contrastive learning

Contrastive learning is a machine learning technique used to teach a model features from a dataset without any labelling. At each step, the model is taught to group together similar images (two similar images are a positive pair) into the latent space by increasing similarity within positive pairs, and decreasing similarity within negative pairs though the contrastive loss:

L i,j = -log exp(sim(F (z i ), F (z j ))/τ ) 2N k=1,k̸ =i exp(sim(F (z i ), F (z k ))/τ ) (1)
where N is the size of the batch, sim(•, •) is a similarity measure, τ is the temperature, (i, j) ∈ 1, N 2 , (z l ) l∈ 1,2N samples from the batch, and (z i , z j ) a positive pair.

B. Semi-supervised domain adaptation

SSDA is based on two datasets extracted from two different domains, referred as the labeled source dataset D S and the unlabeled target dataset D T . The deep learning model F (.) will be optimized for image classification according to two simultaneous yet different processes, using D S and D T . The first process is a regular supervised training on D S in which a supervised loss L S (here the cross-entropy) should be minimized. The regularization process is similar to [START_REF] Chen | A Simple Framework for Contrastive Learning of Visual Representations[END_REF] and [START_REF] Mañas | Seasonal Contrast: Unsupervised Pre-Training From Uncurated Remote Sensing Data[END_REF], originally used for self-supervised learning. The model is fed with images from the same area but different seasons, referred as z s1 i and z s2 i . z s2 i can be considered as a seasonal perturbations of z s1 i . The regularization term is computed using the contrastive loss between the output of the model for z s1 i and z s2 i , where sim is the Cosine similarity.

L T = -log exp(sim(F (z s1 i ), F (z s2 i ))/τ ) 2N k=1,k̸ =i exp(sim(F (z s1 i ), F (z s2 k ))/τ ) (2)
The total loss used for back-propagation is a weighted sum of the supervised and unsupervised losses. The process is il-

L = α × L S + (1 -α) × L T (3)

C. Temporal regularization using Markov chains

The high availability of Sentinel-2 images enables taking into account years prior to the year of interest to ensure a consistent temporal continuity in the LCZ predictions. By assuming that LCZ classification follow a Markov process, maps from the different years and seasons can be linked using a Markov chain. Let's define:

• I N ∈ R 32×32 be the prediction of F (.) at time N . • LCZ N the LCZ class (c N ∈ 1, 17 ) of the patch at time N . • M ∈ R 17×17 a
matrix where m i,j∈ 1,17 2 is the coefficient of M at row i and column j. m i,j is the probability in the 1 st Markov process to go from LCZ N -1 = i to LCZ N = j, (i, j) ∈ 1, 17 2 . These probabilities have been set empirically according to observed changes in the region of interest during previous years. If (LCZ N ) follows a 1 st order Markov process. Then, for all N:

P (LCZ N = c N ) = m c N -1 ,c N × P (LCZ N -1 = c N -1 ) (4)
The probability of a given input to belong to the LCZ class according to the model predictions at time N is c N is p = P (LCZ N = c N |I N ). Then, according to the Bayes theorem:

p = P (I N |LCZ N = c N ) P (I N ) ×m c N -1 ,c N ×P (LCZ N -1 = c N -1 )
(5) Where P (I N |LCZ N = c N ) is the output of the model.

III. EXPERIMENTS AND RESULTS

A. Training datasets

The Sentinel-2 images from So2Sat dataset is used as a source dataset D S . Sub-Saharan countries have several dry and rainy seasons in a year that may not be included in So2Sat dataset. Land cover, especially for vegetation, may greatly vary according to this seasonal change. To build positive pairs for the contrastive loss, we adopt a strategy similar to [START_REF] Mañas | Seasonal Contrast: Unsupervised Pre-Training From Uncurated Remote Sensing Data[END_REF]: an image of a region of interest at time t + ∆t is considered as a temporal perturbation of an image of this specific region at

B. Experimental settings

In this paper, we use Resnet-50 [START_REF] He | Deep Residual Learning for Image Recognition[END_REF] as our classifier. The model was first trained on the entire So2Sat dataset. This pretraining is used to initialize weights for the semi-supervised training step. We used Adam optimizer with a learning rate of 0.001. We set the batch size to 256 for both the supervised and unsupervised phases, the temperature for the contrastive loss τ to 0.5 and the regularization term α to 0.9.

C. LCZ map generation and ablation study

We collected Sentinel-2 tiles (bands at 10m and 20m resolution) over Burkina Faso for early 2018 and early 2017 with a cloud percentage under 5%. After training our model with the training strategy described in section II, we performed a classification on each of the Sentinel tiles followed by a Markov Chain. The resulting map (resolution 320m× 320m upsampled to the image resolution, 10m×10m), in Figure 3, is a concatenation of the generated tiles using the Markov Chain. Houses surrounded by vegetation may not be detectable, especially if building materials are light and similar to the environment (e.g. wood). In that case, the type of environment structure does not change and remains very rural. Such ambiguities may not occur for larger villages and cities. To validate our method, we collected 4 early 2018 Sentinel-2 images and cropped them over Ouagadougou, Bobo-Dioulasso, Fada-Ngourma and Ouahigouya. We gridded these resulting images according to 32 × 32 pixels areas

OA

AA IoU Supervised baseline 0.245 0.270 0.175 s-SSDA 0.427 0.402 0.278 s-SSDA + Markov 0.561 0.538 0.389 and labeled them using very high resolution satellite images. Overall accuracy (OA), Average accuracy (AA) and Intersection over Union (IoU) for a model trained only on So2Sat, a model trained using the s-SSDA method and its regulation using a Markov chain are shown in Table I. Both s-SSDA models outperforms the supervised baseline in our validation set. In addition to increasing the results metrics, the temporal regularization adds continuity.

IV. APPLICATION: MALARIA INDICATOR

A. Malaria data

The objective of the MIS 2017-2018 was to estimate basic demographic and health indicators about malaria and knowledge related to this disease. Interviewed households were sampled so that results on malaria prevalence for 6-59 months old children are representative for each of the 17 study areas. As a result, 252 Enumeration Zones (EZs) were selected. 245 EZs were visited and the remaining 7 EZs could not be visited for safety reasons. In total, 6322 households were visited. Malaria rapid tests, giving results in 15 minutes were performed on children with the consent of their legal representatives. When positives, more reliable tests in laboratory were done to confirm the rapid test results and determine the specific parasite involved. We computed the malaria rate of each EZ by dividing the number of positive 6-59 months old children by the total number of 6-59 months old children.

B. Linking EZs to Local Climates Zones

Besides general information about each EZ, the survey provides the geo-location of their centroids, with a random offset added for confidentiality reasons. This displacement is randomly generated so that it is within a circle of 2 kilometers radius for urban areas, and 5 kilometers for rural EZs except for 1% of them with an offset that can reach under 10 kilometers. Within the 245 visited EZs, 224 were accurately geo-located and used to conduct the following study. Although approximate, these centroids provided with MIS data can be used to link EZs, and thus households, to their local environment using the LCZ classification, as shown in Figure 3. Each geo-location is associated to a squared area of S pixels (Sx10m x Sx10m squares). S is intentionally small against the offset considering values in a small area near the coordinates does not alter the results [START_REF] Grace | Integrating Environmental Context into DHS Analysis While Protecting Participant Confidentiality: A New Remote Sensing Method[END_REF]. We set S = 64 which corresponds to a ground resolution of 640mx640m. We characterise the environment by the counts (in the 10m×10m resolution map) of each LCZ class within this area.

C. Linking malaria to Local Climates Zones

To study the link between malaria and LCZ, we first grouped EZs in clusters according to their LCZ distributions. Mean distributions for these clusters are shown in Figure 4. They represent different types of environment, with distributions gradually shifting from rural areas to urban classes. Cluster 1 is mostly made of bush/scrub and scattered tree areas without urban areas. Cluster 2 is dominated by bush/scrub, sparsely built areas and few low plants. Cluster 3 is halfway between urban and rural areas with sparsely built areas, compact lowrise, open low-rise and also bush/scrub. Cluster 4 is mostly made of urban areas with high densities, and few rural classes. We secondly linked theses clusters with their associated malaria rates computed using MIS data. Figure 5 shows the distribution of malaria rates within each cluster of EZs, with their corresponding Built population index provided by the MIS survey. The Built population index is produced by the Global Human Settlement Layer (GHSL) from satellite image texture, morphology and patterns [START_REF] Pesaresi | GHS built-up grid, derived from Landsat,multitemporal[END_REF]. It is the ratio of occupied footprint, in each cell. As expected when only considering LCZ distributions, clusters represent environmental structures with different urbanisation rates. Interestingly, malaria rates are not equivalent for different clusters in both urban and rural areas. Bush/scrub areas have similar but lower malaria rates than mixed vegetation areas. The LCZ classification enables distinguishing different types of areas where the propagation of malaria is higher.

V. CONCLUSION

In this paper, we introduce a seasonal-SSDA strategy for mapping sub-Saharan countries using the Local Climate Zones classification scheme. This strategy is based on one supervised phase using the So2Sat dataset for training the model to classify LCZ, and a second strategy using consistency regular-ization using unlabeled images from 2 different seasons (wet and dry) and the contrastive loss. Produced maps are regularized using a Markov chain to ensure temporal continuity. This strategy enables generating maps at any time to match them with demographic surveys period. Finally, we linked the produced Burkina Faso's LCZ map of early 2018 and malaria rates. Our results allow to differentiate several environmental structures according to their malaria rates.

Fig. 1 .

 1 Fig. 1. Local Climates Zones classes local environmental characteristics for demographic analysis requires generating accurate maps of the country under study during the period of the survey. Mapping methods should also be robust to local environmental specifics and not require additional labeled data. In sub-Saharan countries, models should produce accurate maps during wet and dry seasons, that can occur several times in a year.Semi-Supervised Domain Adaptation (SSDA) is meant to benefit from the increasing amount of unlabeled data. SSDA methods aim to reduce the divergence between a source domain (with labeled data) and a target domain (without labeled data) which have different distributions. Among them, consistency regularization techniques force a model to predict the same class for an image from the target dataset and its perturbations. Recent developments took advantage of the contrastive loss instance representation learning for reducing the domain gap[START_REF] Singh | CLDA: Contrastive Learning for Semi-Supervised Domain Adaptation[END_REF]. Such techniques are well suited for remote sensing applications where global datasets have already been created[START_REF] Schmitt | SEN12MS -A Curated Dataset of Georeferenced Multi-Spectral Sentinel-1/2 Imagery for Deep Learning and Data Fusion[END_REF],[START_REF] Sumbul | BigEarthNet: A Large-Scale Benchmark Archive for Remote Sensing Image Understanding[END_REF] and data is produced on a regular basis. This contribution aims to provide a training strategy to produce LCZ maps of every part of the world, using Sentinel-2 products, without additional annotated data. To this end, we introduce a seasonal-SSDA (s-SSDA) approach combining supervised and contrastive learning to extract useful global and more specific local features using unlabeled data. The model is expected to transfer spatial features learnt from the source dataset as well as being robust to the target seasonal variations. The generated LCZ maps can provide useful data to contextualise localised demographic information. As a study case, we mapped the whole of Burkina Faso to link LCZ environmental descriptors to demographic indicators through the Malaria Indicator Survey (MIS) of 2017-2018[START_REF]Enquête sur les indicateurs du paludisme au Burkina Faso[END_REF]. We show that the proposed s-SSDA improves the performances of LCZ mapping. With these results, we characterized studied areas according to their urbanization rate, their LCZ characterisation and their malaria rates.

Fig. 2 .

 2 Fig. 2. Training procedure lustrated in figure Figure 2. With the regularization coefficient α ∈ [0, 1]:L = α × L S + (1 -α) × L T(3)

Fig. 3 .

 3 Fig. 3. Resulting LCZ map of Burkina faso and zoom on Ouagadougou (left: Supervised model, middle: s-SSDA + Markov model, right: OpenStreetMap) for February 2018. Legend is shown in Figure 1. time t. Burkina Faso experiences one dry and one wet season each year. To create the target dataset D T , regions of interest (ROIs) such as cities, lakes, industries or national parks have been selected over Burkina Faso. Images of ROIs are extracted at two different times: January to March 2022 for the dry season, and late August to November 2021 for the wet season. Input images are created by splitting ROIs from both date into 32 × 32 × 10 patches (height × width × spectral bands) to match the So2Sat template. This selection process results in 225K pair of patches used during unsupervised training.

Fig. 4 .

 4 Fig. 4. Mean LCZ distribution of clusters with clusters indices from Figure 1

Fig. 5 .

 5 Fig. 5. Malaria rates and Built population index of each cluster of EZs

TABLE I VALIDATION

 I RESULTS ON 494 MANUALLY LABELED PATCHES.