Lorenzo Civolani

Guillaume Pierre

FogDocker: Start Container Now, Fetch Image Later

Keywords: Fog computing, Docker, containers

Slow software deployment is an important issue in environments such as fog computing where this operation lies in the critical path of providing online services to the end users. The problem is even worse when the virtualized resources are made of modest machines such as single-board computers. This paper leverages the observation that, although Docker images are often very large, only a small fraction of their content is actually accessed by the containers during startup. We therefore propose to reorganize container images and download only the strictly necessary files before starting a container. The remaining image contents can then be downloaded asynchronously while the container is already running. Our performance evaluations show that FogDocker reduces container deployment times in the order of 3-5x on single-board computers and 2-3x on powerful servers, while incurring low runtime overhead and maintaining correctness even in the case a container accesses a file which was not downloaded yet.

INTRODUCTION

The popularity of container-based virtualized infrastructures makes it increasingly attractive to dynamically deploy personalized applications upon the (often implicit) request of a single end user [START_REF] Luiz | Mobility-Aware Application Scheduling in Fog Computing[END_REF]. In such scenarios, the application deployment process cannot be considered as a one-time operation that does not affect the end user's Quality of Experience. Rather, it becomes an integral part of the critical path toward providing the expected service to its end users. To ensure a satisfactory user experience it is therefore important to reduce application deployment times as much as possible.

Docker is by far the most popular container management system [START_REF] Carter | Docker Usage Report[END_REF], both in cloud [START_REF]State of the Cloud report[END_REF] and fog [START_REF] Hoque | Towards Container Orchestration in Fog Computing Infrastructures[END_REF] computing platforms. Its popularity is largely due to its lightweightness compared to virtual machines and its excellent integration with DevOps processes. However, depending on the available hardware and the nature of the deployed application, a user may need to wait up to a few minutes until an application is ready to be used [START_REF] Ahmed | Docker Container Deployment in Fog Computing Infrastructures[END_REF]. This is particularly true in fog computing infrastructures which often rely on weak hardware such as single-board computers [START_REF] Bellavista | Feasibility of Fog Computing Deployment based on Docker Containerization over RaspberryPi[END_REF][START_REF] Hajji | Understanding the Performance of Low Power Raspberry Pi Cloud for Big Data[END_REF][START_REF] Van Kempen | MEC-ConPaaS: An experimental single-board based mobile edge cloud[END_REF].

When Docker deploys a container, if the required application code and data are not already locally available, it is first necessary to pull the necessary content from a public or private image repository. This pull operation of the so-called container image constitutes the main part of the container deployment time.

To reduce the container deployment time we exploit the observation that Docker containers usually access only about 6% of their image content before being able to start useful work [START_REF] Harter | Slacker: Fast Distribution with Lazy Docker Containers[END_REF]. We therefore propose to reorganize the deployment process such that a container can be started immediately after its most essential files have been downloaded. The remaining image contents can then be downloaded asynchronously while the container has already started.

Implementing this simple idea requires one to address a number of difficult challenges. First, we need to profile a container's execution, identify the set of essential files which must be installed before starting the container, and build a special image layer with these essential files. Then, we must modify the Docker deployment process to start the container immediately after a new "base" layer has been downloaded, while the other image layers are still being retrieved asynchronously. Finally, we need to maintain application execution correctness even in the case where a started container tries to access a file which has not yet been downloaded.

We show that FogDocker reduces by an order of magnitude the amount of data which needs to be downloaded before starting the container. The pull time, measured as the duration until the container can start, is reduced by a factor between 2 (on powerful cloud computing servers) and 5 (on single-board fog computing servers). When the network bandwidth is limited, as is common in fog computing scenarios, the relative improvement grows up to 18x. At the same time, the runtime overhead remains low, between 1 and 8 ms upon every call to the open() or fopen() functions. The fact that FogDocker succeeds in such diverse environments demonstrates the general applicability of our approach in environments where container images are deployed frequently. In fog computing, for instance, the geographical properties of the workload create strong constraints on the placement of containers, and workload dynamicity may require frequent re-deployments.

This paper is organized as follows. Section 2 introduces the background and related work. Section 3 details the Overlay file system. Section 4 discusses our system design. Finally, Section 5 evaluates this work and Section 6 concludes.

BACKGROUND 2.1 Docker

Containers are standardized units of software that tie an application with the full environment it needs for execution. A container virtualizes a group of processes that share the hosts's OS kernel but operate inside an isolated environment from other processes and containers.

Although containers preexisted Docker, Docker is by far the most popular framework to build, package, and run software inside containers [START_REF] Inc | Docker: Build, Ship, and Run Any App[END_REF].

A central concept of the Docker framework is the image, a read-only template that is used as a basis to instantiate containers. Images provide a stable and reliable execution environment for the enclosed application. An image is a combination of: (1) a file system that will be exposed to future containers, usually including a full Linux distribution, software dependencies and configuration files; (2) configuration data such as environment variables; and (3) a start-up command to be executed at launch time.

A Docker image is built using a Dockerfile which specifies the sequence of actions that must be performed during the image creation process. Some crucial instructions are: FROM, to define the base image for the subsequent commands; COPY, to add new files to the container file system; ENV, to set the value of an environment variable; and CMD, to define the default execution command.

The popularity of Docker is largely due to its incremental approach for building container images: instead of requiring developers to provide a full monolithic image of each container's file system (as is commonly done with VMs), a new image can be defined by specializing an existing one thanks to the FROM instruction at the opening of a Dockerfile. A developer only needs to provide incremental changes, which at build-time create one or more additional layers containing the files that must be added, modified, or deleted with respect to the original image. As a result, Docker container images are made of a number of layers stacked on top of each other.

Container image layers are read-only so a running container cannot modify their content. Instead, when a container starts, a new writable layer is dynamically added on top of the layer stack. The purpose of this container layer is to keep track of all file system modifications made by the running processes using a copy-on-write (CoW) policy [28]. Although a container's file system is composed of a stack of multiple layers, this structure is not exposed to the container processes. File system layers remain physically separate on disk, but a "union mount" file system such as OverlayFS is used to unify all the layers and expose a single homogeneous file system to the container processes [START_REF] Szeredi | Overlay FS[END_REF].

The architecture of Docker shown in Figure 1 comprises three elements. The daemon performs the actual management of images and containers. It listens to requests issued by the client and performs the requested action. Finally, the registry stores a copy of all the container image layers, enabling image sharing between multiple daemons. By default daemons make use of the public "Docker hub" registry [START_REF] Inc | Docker Hub[END_REF].

The pull operation is performed upon every container deployment to download the necessary layers. Internally to the Docker daemon, a LayerDownloadManager object is in charge of identifying the image layers which need to be retrieved, downloading them, and registering them in the local system. The pull operation creates one separate thread per layer to download, decompress and extract them. When all the required image layers have been extracted, the pull operation terminates and Docker starts the container from a merged view of the concerned layers.

Related work

Optimizing Docker container deployment is an important problem, in particular in fog computing where container deployment is a frequent operation that often lies in the critical path of providing online services to end users [START_REF] Luiz | Mobility-Aware Application Scheduling in Fog Computing[END_REF].

The idea of prioritizing the download of files or blocks that are necessary for the execution of an application, and delaying the others until they are needed, is an old and wellstudied idea [START_REF]Lazy Loading[END_REF]. Our work however differs from lazy loading and demand paging in that the entire container image gets downloaded it its entirety shortly after the container has started, thus avoiding the cost of page faults during the container's lifetime.

One approach to accelerate the deployment of Docker containers focuses on the image registry to ensure it delivers images as quickly and efficiently as possible. CoMICon is a distributed registry which distributes the image layers across multiple nodes to speed-up deployment time and increase availability [START_REF] Nathan | CoMICon: A Co-Operative Management System for Docker Container Images[END_REF]. Similarly, Nitro uses deduplication and network-aware data transfer strategies to reduce the image transfer time over wide-area networks [START_REF] Darrous | Nitro: Network-Aware Virtual Machine Image Management in Geo-Distributed Clouds[END_REF]. Although these works result in faster image download, they do not address the performance bottlenecks in the Docker daemon itself and are therefore orthogonal to our work.

Another approach consists of shrinking the container image by removing the useless files from the image [START_REF] Dockerslim | Minify Docker Image and Generate Security Profiles[END_REF]. Similar ideas were also used in the context of disconnected operation [START_REF] James | Disconnected operation in the Coda file system[END_REF]. However, this operation modifies the Docker semantic of relying on a complete and well-defined operating system. We prefer keeping the full image content including rarely-accessed yet useful files such as as tools for debugging, performance profiling etc.

Wharf proposes to share the caches of multiple Docker servers in a distributed file system to reduce storage utilization and the number of redundant image retrievals [START_REF] Zheng | Wharf: Sharing Docker Images in a Distributed File System[END_REF]. However, it does not change the image pull process and therefore has no performance impact in the case image layers need to be pulled before starting the container.

The only work which exploits the fact that a container accesses only a fraction of its image content before producing useful work is Slacker [START_REF] Harter | Slacker: Fast Distribution with Lazy Docker Containers[END_REF]. Slacker proposes to store the Docker images in a shared NFS file server. With the use of a specialized storage driver in every Docker daemon, only the relevant parts of each image need to be downloaded from the NFS server to the Docker daemon upon every container start operation. However, this assumes that all relevant images are already stored in the NFS file server, and therefore does not impact the performance of the docker pull operation.

Finally, Docker-pi proposes to reorganize the download and extraction of image layers in the Docker server itself to better exploit hardware-level parallelism [START_REF] Ahmed | Docker Container Deployment in Fog Computing Infrastructures[END_REF]. Although this technique speeds up the image pull process, it still relies on downloading the full image before starting the container, which delays the container startup operation while many non-critical files are being downloaded and extracted to disk. We rather aim at starting the requested container as early as possible and allowing it to provide its intended functionality while the non-critical parts of its image are still being pulled.

UNDERSTANDING OVERLAYFS

One of the main challenges in this work is to precisely understand the possibilities and limits of Docker's layered file system structure. In particular, asynchronously downloading and installing content in the lower file system layers after the container has started implies that these layers cannot be considered read-only, which deviates from the canonical usage of the file system layers.

In Docker, all details about the way the layers' content is stored and managed on the disk of the host machine are handled by the storage driver. A number of storage drivers are available to support various usage scenarios. In this paper we focus on overlay2, which is the default driver for modern versions of Docker [START_REF] Inc | Docker storage drivers[END_REF].

The overlay2 storage driver makes use of the Overlay file system [START_REF] Szeredi | Overlay FS[END_REF] to implement Docker's layered architecture for images and containers. OverlayFS sits on top of a host file system with the aim to provide a combined view of contents belonging to multiple directories. An instance of OverlayFS, illustrated in Figure 2, contains the following elements:

• A set of immutable read-only layers, called lowerdir, containing the objects that must be joined. • A writable layer called the upperdir, used to keep track of the changes applied through the merged view. • The merged directory, providing a unified view of the lowerdirs and the upperdir. Read operations are redirected to the actual file in the lower layer; write operations are handled with a copy-on-write policy: when a container modifies a file system object, OverlayFS clones it into the upper directory, and modifies the copy.

The overlay2 storage driver makes direct use of the Over-layFS directories to implement the layered structure of the containers. In particular, when a container is launched, a new instance of the virtual file system is prepared: the directories storing the content of the underlying image layers are registered as lowerdirs; the container layer is mapped to a new dedicated directory, registered as upperdir, which records all the FS updates issued by the container while preserving the integrity of the image layers; finally, the merged directory becomes the root of the file system tree of the container.

The separation between read-only lowerdirs and the writable upperdir provides a natural way for Docker to reuse the read-only layers across multiple containers while keeping each container's file system updates separate. In our case, however, we plan to continue inserting content in the lowerdirs after container execution has started, which temporarily deviates from their self-proclaimed read-only characteristics.

OverlayFS officially does not support run-time modifications of the underlying layers. Its documentation claims that "changes to the underlying file systems while part of a mounted OverlayFS are not allowed. If the underlying file system is changed, the behavior of the Overlay is undefined, though it will not result in a crash or deadlock" [START_REF] Szeredi | Overlay FS[END_REF]. After performing an extensive set of experiments, we however found a different answer which allows us to define the behavior of OverlayFS when the lowerdirs are modified. The virtual file system actually supports certain live changes of the layers, under the following conditions:

• Files are only added into the layers. Renaming, updating or deleting files interferes with the caching mechanisms of OverlayFS and can produce incorrect results. • Directories are treated differently than files, and the dynamic addition of new directories is not always reflected in the merged directory. As a consequence it is important that the full directory tree is present across all the layers at the time a container is created. • Whenever a lookup is requested in a merged directory, the operation is redirected to each underlying directory and the results are combined and cached in the appropriate dentry ("directory entry cache" [16]) of the merged directory. For this reason, a new file inserted into alreadyexisting lower directory would not appear in the merged view. We therefore need to drop the dentry cache of the underlying file system when the run-time deployment of a lower layer is complete.

We therefore conclude that adding content in the lowerdirs after the container has started is perfectly possible. The main constraint is that the FogDocker "base layer" must contain not only the essential files, but also the whole directory structure of the original file system image. When the base layer has been deployed, the Docker daemon must then clone that directory tree across all the empty layers before mounting the virtual file system and launching the container. In this way, the content that gets injected at run time into the lower layers appears in the merged overall view and is correctly detected by the executing container. Note that, although FogDocker leverages an undocumented feature of OverlayFS, private discussions with the OverlayFS developers indicated that future versions of the file system will remain at least as consistent as in the current one.

SYSTEM DESIGN

The objective of this work is to substantially reduce the time spent during the deployment of a container until the container is ready to perform useful functionality. We present FogDocker, which leverages the fact that a container accesses only a small fraction of all its files during its startup phase. As illustrated in Figure 3, the standard Docker policy is to fully download all the container layers before starting the container. The key idea in our work is to identify the essential files, create an additional "base image layer" containing them, and start the container immediately after the base When the Docker daemon initiates the pull operation (for instance, upon a docker pull or a docker run command), the base layer is downloaded first from the registry. The other layers are created in the OverlayFS virtual file system but kept empty. At this point, the container execution can already begin. As shown in Figure 4, while the container has started running, the Docker daemon proceeds in background with the deployment of the rest of the image: the remaining archives are downloaded, extracted, and the empty layers are filled with their respective content.

To realize a concrete implementation on the basis of this simple idea, we address the following questions in turn:

(1) How can we identify the essential files needed for the execution of a container? ( § 4.1); (2) Which precise content should be included in the new base layer? ( § 4.2); (3) What is the best way to integrate the base layer in the new custom image? ( § 4.3); (4) How should we reorganize the Docker deployment process to follow this new policy? ( § 4.4); (5) How can we maintain a correct container execution, even in the case where it would try to access a file that is not present yet? ( § 4.5).

Profiling the container execution

The first challenge that must be addressed to design our solution is identifying the set of essential files that are accessed by a container during the first few dozen seconds of its execution. Naturally, precise file identification is essential for the performance of FogDocker. The authors of [START_REF] Harter | Slacker: Fast Distribution with Lazy Docker Containers[END_REF] carried out an extensive study based on 57 highly popular images from the Docker Hub. By leveraging block-level tracing they identified that, on average, only 6.4% of the image content is accessed during the container's startup phase.

To monitor the activity of the containerized process, we make use of the fanotify API provided by the Linux kernel [START_REF] Paris | fanotify: the fscking all notification system[END_REF]. This interface creates a system of interception and notification for events that occur in the file system, offering a way to detect the file system objects that a Docker container accesses during its execution. Instead of building a custom file access monitoring program we exploit the open-source fatrace (file access trace) tool [START_REF] Pitt | fatrace: report system wide file access events[END_REF]. fatrace makes use of the fanotify API and reports which files are being accessed by any running process.

We profile the container from within the container itself. To launch fatrace inside the container, the executable must be included into its file system. A simple option consists of keeping fatrace in an appropriate folder on the host machine and make its content accessible from within the container by using a bind mount [START_REF] Inc | Use bind mounts[END_REF]; we are thus able to provide the isolated process with the access to the fatrace executable without the need to create a further Docker image.

When running the container, our solution first launches fatrace in the background and then executes the actual application. Only at that point, the simulation starts. For example, to exercise a Web server container one could issue a number of HTTP requests to retrieve the content of a sample website. In general, we request the application developer -or the user who wants fast deployment for her containersto provide a script to exercise the container in a way that mirrors a typical usage scenario as closely as possible. For more complex applications, profiling may be integrated in a DevOps workflow and capture the start-up behavior of every subsequent application version. We defer this topic to future work.

After executing the container and exercising it using the developer's script we can simply retrieve the log produced by the tracing mechanism, and extract the list of files that were accessed by the containerized application.

Building the base layer

As discussed in Section 2, Docker image content is distributed across multiple layers which are retrieved over the network as compressed archives, and then extracted and installed locally by the daemon. We exploit this organization to concentrate the essential files into an additional layer which is then joined to the original stack. As a result, this new version of the image contains an additional "base layer," providing the minimal file system capable of supporting the first few stages of execution of the application.

As shown in Figure 5, building the base layer requires several operations. First, we launch a sample container from the original image and extract a copy of its entire (merged) file system into an empty folder through the docker export command. The information derived from the profiling discussed in the previous section dictates what must be included in the base layer. We copy such content into a new directory which will eventually contain the minimal file system that is needed for the container to start useful work.

Files. Obviously, all the files that have proven to be necessary for execution must be present in the base layer. We use the rsync utility [START_REF] Tridgell | The rsync algorithm[END_REF] to copy files from the source folder, holding the container original file system, to a destination one representing the minimal version of it. The rsync command can be configured to preserve all the files' metadata.

Links.

Copying just the files is not enough for the thin version of the container to work. When the monitored application opens a file through a link, only the file itself is reported by the fanotify API and therefore copied into the base layer. As a result, the application inside the thin version of its container would be unable to find what it needs to run. We must therefore also include all the links that lead (directly or indirectly) to any of the files included in the base layer.

Directory structure. As discussed in Section 3, the Over-layFS virtual file system can support the dynamic addition of files in the lowerdir after the mount only if the directory structure is present across every lowerdir. We therefore need to include the full directory structure of the container image in the base layer. This copy can again be realized with the rsync utility.

Wrapper library. As will be discussed in Section 4.5, we include a small wrapper library that intercepts calls to the open() and fopen() system calls in order to handle the case where a container accesses an object that was not downloaded yet. We also include an additional file with the list of all the file names from any of the lowerdir layers.

Once these copy operations are completed, the base layer contains all the file system objects that are necessary to let the container start and operate while the remaining files are asynchronously being downloaded and installed. Note that these objects are copied rather than moved from the main container image, thus creating a certain amount of redundancy. However, this has the advantage of keeping the original layers untouched and therefore potentially reusable in multiple independent images. Layer reusability is a key design principle in Docker that we aim to preserve in Fog-Docker as well.

Preparing the custom image

We now need to create a new custom image which integrates the original container image with the new base layer. The layered nature of the Docker images naturally suggests a possible organization for the custom image, as illustrated in Figure 6: we can place the base layer on top of the original layer stack.

Writing the Dockerfile of the new image is straightforward. The procedure boils down to the only instructions FROM and ADD (see Figure 6). Since the image is not built from scratch, it is not even necessary to specify again the procedure for the container start-up with a CMD instruction: this information will be automatically inherited from the parent's settings. Neither do we have to locally re-build the image from scratch, because a ready package can be pulled directly from a public repository.

Re-engineering the pull operation

A central part of this project concerns the idea of starting a container after just a part of its image has been installed. It is necessary to reengineer the image pull operation in order to deploy the topmost layer (i.e. the base layer) first and let the execution start right after. To do so, we implemented a number of modifications in the Docker source code. We discuss them in turn.

Topmost layer download only. The first modification is to instruct the Docker daemon to retrieve and install the topmost image layer first, whereas the others layers are kept empty. The topmost base layer contains the essential files that allow a container to start executing. Because the base layer is much smaller than the entire container image, we expect to cut the amount of data that must be transferred, extracted and installed before starting the container, thereby reducing the delay before being able to start the container.

As discussed in Section 2, the LayerDownloadManager object is in charge of retrieving the image layers. In particular, its Download method is a blocking function that ensures that all the requested layers are present in the local store. We updated this Download method to recognize whether the layer under consideration is the topmost base layer or a regular one. It then passes an extra parameter holding this information to the respective threads it launches to handle the retrieval of each image layer.

When the base layer is being downloaded, the operation proceeds normally, since its content is required for the execution. Conversely, when dealing with regular layers, the thread skips the download of the respective tarballs and simply replaces them with empty ones. In this way, the daemon creates and configures the appropriate image data structure and the container can in principle be immediately started.

Disabling integrity control. Unfortunately, deactivating the retrieval of a layer content is prone to generate runtime errors. Docker verifies the integrity of all layers by computing a hash of their content and comparing it with metadata present in the image manifest. Besides the base layer, which gets downloaded normally, all other layers remain empty and therefore are most likely to fail the integrity test thus aborting the container deployment. We address this issue by disabling the integrity test: we override the calculated hash with the expected value.

An obvious drawback of this solution is that corrupt layers cannot be reliably detected any more. We plan in future work to reinstate integrity checks at the end of the asynchronous layer download phase.

Cloning the directory structure. Once the minimal image has been deployed, the complete directory tree must be cloned from the base layer into the lower ones. This operation must be completed before the daemon mounts the layers together into a unified view through a new instance of OverlayFS. In this way, run-time changes in the lower layers, taking place while their content is being retrieved in the background, will be made visible in the unified directory serving as the root of the container's file system.

To do so, once again we modify the Download method of the LayerDownloadManager. Once the threads which download the base layer and create the empty ones have finished executing, we retrieve the paths in the host file system where each layer has been stored. We then iterate over the lower layers and clone the directory tree of the base layer inside each of them by using the rsync utility.

Asynchronously downloading the rest of the image. Once the base layer has been downloaded, extracted and installed, and its directory tree has been replicated across all the underlying empty layers, the pull operation can return and the execution of the container can begin. However, before returning, it is necessary to schedule the asynchronous download and installation of the other layers. Since the directory tree is already present in all the layers, the newly-added content will gradually appear in the file system of the running container.

The Go language in which Docker is implemented offers a feature called goroutine which allows to execute code in the background. Launching goroutines is simple: one just needs to add the keyword go in front of a function invocation. This feature helps implementing concurrent applications in a straightforward way.

In FogDocker we use goroutines to schedule the asynchronous download and installation of the original image layers. The code is set in the same loop that we described in the previous step of our solution: for each layer involved by the iteration, in addition to copying the directory tree, we also set up a goroutine with the aim of asynchronously downloading, extracting and installing the layer data in the appropriate directory.

Handling early access to delayed files

Although the base layer contains all the files that are necessary for a container to start for the first few dozen seconds, one cannot exclude the possibility that during this time the container tries to access a file which has not been installed yet. For example, the user of a redis database may request an unexpected operation needing a resource which was not triggered by the script used to profile the container. Without special measures, in these cases the file access operation would fail with a "file not found" error, making the container's execution incorrect.

To maintain correctness even in this scenario, we transparently intercept all the file-system calls such as open and fopen issued by the container: if the requested file is part of the full container image but it not been downloaded yet, the call gets blocked until the requested file becomes available. In the worst case the container gets blocked until the full image is installed. However, assuming that this event is rare thanks to an accurate profiling, in most cases the container will start much faster than regular Docker.

Whenever the container attempts to open a file, we need to distinguish three possible conditions:

• If the requested file is already present, then we want to allow the open() and subsequent operations on that file to execute normally; • If the requested file is not present but we know it will be part of the container image after all the layers have been downloaded, then we need to block the system call until the requested file has arrived locally; • Finally, if the requested file is not present nor does it belong in the container image, then we want to let the call execute and eventually fail.

To transparently intercept system calls, we use a technique inspired by Cooperman and Rieker [START_REF] Cooperman | Transparent adaptive library-based checkpointing for master-worker style parallelism[END_REF][START_REF] Rieker | Transparent User-Level Checkpointing for the Native Posix Thread Library for Linux[END_REF]. We created a shared library which redefines the open(), fopen(), and similar functions from the C library with exactly the same signature as the original functions. Thanks to the LD_PRELOAD environment variable we can instruct the operating system to load our custom library before any other dynamic library, including the original C library. Any call to one of these functions therefore executes our wrapper function rather than the actual C-library function.

Figure 7 shows a simplified extract from our wrapper library. The exists() function verifies the existence of a file. If the file exists, then no waiting is needed and we can call the "real" open() function (found thanks to a call to dlsym()). Otherwise, the delayed() function determines whether the file belongs to the list of objects that are supposed to be downloaded asynchronously at run time. This list is created when building the base layer, and included at a well-known path within the base layer. If the required file does not exist because it is yet to be deployed, a call to wait_avail() makes the process iteratively wait for a fixed amount of time and then recheck if the file has arrived; when the file becomes available, the procedure lets the call proceed.

This technique allows us to remain totally transparent to the application running inside the container. From the container perspective, open(), fopen() and similar functions are regular system calls that simply occasionally take longer than usual to complete.

Statically-linked executables. We assume that every executable within the container is dynamically linked with the C library. For statically-linked executables a one may either replace them with dynamically-linked alternatives, or recompile them statically with our wrapper library.

Concurrent container deployments. The wrapper library also maintains correctness in the case where multiple containers sharing some or all of their image layers are concurrently deployed. In such cases, Docker will mount the same empty layers as part of multiple instances of OverlayFS. The only requirement is that all the involved images include a base layer with our wrapper library so execution correctness can be maintained when a required file is yet to arrive.

EVALUATION 5.1 Experimental setup

We implemented FogDocker as a modified version of Docker CE version 18.01. We therefore compare its performance against that of the same unmodified Docker version. We perform experiments on two different types of machines which represent two extremes in terms of hardware configurations:

• A Raspberry Pi 3 Model B+ is representative of a typical fog computing server [START_REF] Bellavista | Feasibility of Fog Computing Deployment based on Docker Containerization over RaspberryPi[END_REF][START_REF] Hajji | Understanding the Performance of Low Power Raspberry Pi Cloud for Big Data[END_REF][START_REF] Van Kempen | MEC-ConPaaS: An experimental single-board based mobile edge cloud[END_REF]. It has a quad-core 1.4 GHz ARMv8 processor, 1 GB of RAM, a 32 GB micro-SD card, and a Gigabit Ethernet interface connected to a high-speed academic network. In this setup we use the standard Docker hub as registry. • Although we designed FogDocker mostly for fog computing environments, we also evaluate it using a powerful server representative of a typical cloud computing environment. It has two Intel Xeon X5570 CPUs, with 4 cores per CPU running at 2.93 GHz, 24 GB of RAM, a 500 GB HDD and 1 Gbps Ethernet connection to a high-speed dedicated network. In this setup we use a private registry located in a separate cluster to ensure that the connection to the registry does not constitute a performance bottleneck.

We evaluate FogDocker based on the custom version of three popular images: httpd [START_REF]The Apache HTTP Server Project[END_REF], nginx [START_REF]Official build of Nginx[END_REF] and redis [START_REF]An open source key-value store[END_REF] are the official Docker images respectively containing the Apache web server, the Nginx web server and the Redis keyvalue store. To profile the web servers, we sent a number of sample HTTP requests; for redis, instead, we issued all the commands that are part of the official tutorial. We also set up a custom image, called glife, containing a simple application written in Go. In this case, we simply executed the enclosed application.

Image layer sizes

We first evaluate the respective sizes of the base layers for all four images. This size indicates the volume of data which needs to be downloaded before a container starts. Figure 8(a) compares the base layer sizes with those of the corresponding original images. The reduction of necessary download size between regular Docker and FogDocker is evident. The size of the base layer represents between 3% (for glife) and 13% (for redis) of the original image. This is consistent with the results from [START_REF] Harter | Slacker: Fast Distribution with Lazy Docker Containers[END_REF], and confirms the performance improvement potential of FogDocker compared to regular Docker.

Although FogDocker drastically reduces the volume of data to be downloaded ahead of the container launch, the total image size ends up being larger than the original one because the base layer introduces redundancy. Figure 8(b) compares the full image sizes in both versions of Docker. The total data volume to be downloaded by FogDocker exhibits a modest overhead compared to the original images.

Container startup times

We now evaluate the container startup times in Docker and FogDocker. In the case of FogDocker we measure two delays: "FogDocker minimal" represents the delay from the container launch instruction until the container is ready to start; on the other hand, "FogDocker total" represents the overall duration until the full image has been downloaded and installed.

Figure 9(a) reports the container deployment times for our four images in the fog computing server scenario. In this and the subsequent experiments, every measure reports the mean and standard deviation out of 5 identical executions. The performance difference between Docker and FogDocker is crisp: Docker requires between 30 s and 50 s to deploy the different images whereas FogDocker needs only about 10 s before the container can start operating. This represents a speedup between 3x and 5x. Figure 9(b) reports the results of the same experiment on the powerful cloud computing server.

Although the performance difference is less spectacular, here as well we observe speedups between 1.8x and 3x. Note that we report the "total" container deployment time only for reasons of completeness. FogDocker uses the full available bandwidth to download the remaining layers after the base layer has been deployed. However, in many scenarios system administrators may prefer to throttle or postpone this asynchronous image download to reserve more bandwidth for other applications and/or the container itself (e.g., to communicate with clients), at the expense of a slightly longer "total" pull time.

Performance in resource-constrained networks

The previous experiments were conducted using machines connected to a high-quality academic network. However, in fog computing scenarios, servers may need to be connected to the Internet using various types of commodity networks [START_REF] Bellavista | Feasibility of Fog Computing Deployment based on Docker Containerization over RaspberryPi[END_REF][START_REF] Van Kempen | MEC-ConPaaS: An experimental single-board based mobile edge cloud[END_REF]. In low-bandwidth environments, reducing the volume of data which needs to be downloaded before container startup becomes even more important. Figure 10 shows the speedup observed between Docker and FogDocker in the fog computing server with increasingly strict network bandwidth limitations. As expected, the speedup grows as the available bandwidth decreases. With a 5 Mbps bandwidth cap the speedups grow up to 12x; with a 1 Mbps the gain reaches 18x for the glife application.

We also observe considerable speedup differences between the four available images. These differences are related to the amount of reduction of necessary download sizes, as previously highlighted in Figure 8(a). The glife image, which exhibits the greater size ratio between the full image and its base layer, benefits the most from FogDocker; on the other hand, redis, which has the largest relative base layer size, benefits "only" from a 5x performance improvement in constraint network conditions.

Performance overhead of wrapped system calls

We finish the evaluation by measuring the overhead of the wrappers which intercept calls to the open() and fopen() functions. These wrappers are necessary to maintain correctness in case a container deviates from its profiled behavior and tries to access a file which was not downloaded yet. We prepare a text file containing the paths of 6000 files representing the list of lowerdir files that FogDocker is supposed to download asynchronously at run time. Then, we enable the wrapper by setting the LD_PRELOAD environment variable and configure it to perform lookups in our mentioned list. To evaluate the overhead produced by the wrapper, we measure how long it takes to execute a custom program that repeatedly opens and closes a given file.

Figure 11 reports the execution times of the open() and fopen() calls. The measurements have been done on a slow Raspberry Pi with the aim to evaluate a worst-case scenario. We execute each function call 20 times, and report the mean and standard deviation. When the requested file already exists, the wrapper immediately issues a call to the actual open() or fopen() functions. The performance overhead introduced by the wrapper, compared to when the library gets called directly, is negligible.

If the requested file does not exist, then the wrapper function also needs to check if it belongs to the full image (in which case the call must be delayed until the file arrives), or if it does not belong to the image (in which case the call can be immediately passed to the actual open() or fopen() function). We do not compare the delays in the case where the file belongs to the image, as the execution time here does not reflect an overhead of the wrapper library but rather the delay until the requested file has been downloaded. We however do measure the delay in case the file does not belong to the image. In this case the wrapper must check the path of the requested file against each entry of the list, just to find out that it is not part of it. Here we observe that the presence of the wrapper introduces a tolerable overhead (between 7 and 8 ms) to the time it usually takes to perform the system call.

Note that, once a file has been opened, the subsequent file system operations such as read(), write(), lseek() and close() are not wrapped so they do not experience any performance overhead. Furthermore, once the full image deployment is over, FogDocker could be instructed to remove the list of delayed files. In this way, the wrapper would forward all system calls to the standard library, reducing the overhead almost to zero.

CONCLUSION

Slow container deployment is an important issue in environments such as fog computing where this operation lies in the critical path of providing online services to the end users. The problem is even worse when the virtualized resources are made of modest machines such as single-board computers. We presented FogDocker which significantly reduces the time until a container is ready to operate by identifying the core set of files that are necessary to start, and by deploying these files first. FogDocker reduces the container startup time by 3-5x on limited fog computing servers, and 1.8-3x on powerful cloud computing servers while experiencing only modest runtime performance overhead when the container opens a file. When the available network bandwidth is restricted, as is often the case in fog computing, the achieved speedup grows up to 5-18x. At the same time, FogDocker maintains the Docker philosophy of image layer reusability and it requires only minor modifications in the Docker code.

Future improvements of FogDocker include the reintroduction of layer integrity control. A straightforward way to do so is to verify each layer as soon as its download has terminated. In case of failure, we can envision two potential strategies: either deleting the current layer and scheduling a new attempt, or throwing an error and stopping the execution of the container.

Figure 1 :

 1 Figure 1: Docker's architecture.

Figure 2 :

 2 Figure 2: An instance of OverlayFS.

Figure 3 :

 3 Figure 3: FogDocker's container start operation.

Figure 4 :

 4 Figure 4: Filling image layers at run time.

Figure 5 :

 5 Figure 5: Steps to build the base layer.

Figure 6 :

 6 Figure 6: The custom container image and its associated Dockerfile.

Figure 7 :

 7 Figure 7: Wrapper open() function to delay access in case the requested file is not present yet.

  Data volume to be transferred before container start-up. Overall image size on disk.

Figure 8 :

 8 Figure 8: Comparison of image sizes.

  (a) Fog computing scenario. (b) Cloud computing scenario.

Figure 9 :Figure 10 :

 910 Figure 9: Container startup times.

File

  With the fopen() function.

Figure 11 :

 11 Figure 11: System call wrappers' overhead.


Aleksandr N Vasiliev

Nidhu L Banik

Remi Marsac

Stepan Kalmykov

Christian M Marquardt
email: christian.marquardt@kit.edu

Rémi Marsac

Stephan N Kalmykov

Determination of complex formation

Keywords: Np(V), Complexation, Complex formation constant, Lactate, Propionate, Solvent extraction

Determination of complex formation constants of neptunium(V) with propionate and lactate in 0.5 -2.6 m NaCl solutions at 22-60 °C using a solvent extraction technique † Introduction High level nuclear waste in deep nuclear repositories contains considerable amounts of the radionuclide 237 Np. The combination of its relatively high occurrence, its long half-life (T 1/2 = 2.14•10 6 years) and high radiotoxicity makes this radionuclide environmentally important. While Np can exist in several oxidation states (IV, V and VI) under geological repository conditions depending on the redox conditions, Np(IV) and Np(V) are the most stable oxidation states of neptunium under circumneutral pH conditions. Np(V) is formed under oxidizing conditions and is considered to be mobile in the environment due to its relatively high solubility and low sorption affinity towards surrounding rocks and soil components [START_REF] Kim | Chemical behaviour of transuranic elements in natural aquatic systems[END_REF]. The neptunyl ion (NpO 2 + ) is a linear dioxo cation with an effective charge on the Np atom of about +2.2 [START_REF] Choppin | Complexation of pentavalent and hexavalent actinides by fluoride[END_REF]. It forms complexes with penta-, hexa-and trigonal bipyramidal structures and the axial positions occupied by neptunyl oxygens [START_REF] Forbes | Neptunyl compounds: polyhedron geometries, bondvalence parameters, and structural hierarchy[END_REF]. The commonly adopted approach for nuclear wastes disposal is the isolation in deep geological formations. Clay rock is considered as a potential host rock for such deep geological repositories [START_REF]ONDRAF/NIRAS, SAFIR 2: Safety assessment and feasibility interim report[END_REF][START_REF]OECD: Safety of geological disposal of high-level and longlived radioactive waste in France -an international peer review of the[END_REF][START_REF] Hoth | Endlagerung radioaktiver Abfälle in tiefen geologischen Formationen Deutschlands -Untersuchung und Bewertung von Tongesteinsformationen[END_REF].

The migration of high level waste components and neptunium in particular will depend on the sorption reactions of the surrounding geological matter and on complexation with various ligands present in the near-field or far-field environment. In addition to inorganic ligands commonly found in the environment (e.g. CO 3 2-, OH -), organic complexing ligands like high-molecular weight clay organics (e.g. humic substances-like compounds) and low-molecular weight organics (lactate, propionate, acetate, etc.) have been found in clay pore waters such as the Opalinus clay (OPA, Switzerland) and the Callovo-Oxfordian argillite (COx, France). The pore water samples from COx contains 1865 μM acetate, 127 μM propionate and 8 μM lactate [START_REF] Courdouan | Isolation and characterization of dissolved organic matter from the Callovo-Oxfordian formation[END_REF], for OPA the similar proportions have been measured [START_REF] Courdouan | Characterization of dissolved organic matter in anoxic rock extracts and in situ pore water of the Opalinus Clay[END_REF]. The complexation with these ligands may enhance the neptunium mobility, a property, which is important for safety aspects of a repository. Due to the radioactive decay of radionuclides in the waste, the temperature in the near-field of the repository is likely to be increased up to about 100 °C or higher depending on the repository design and the type of the host-rock [START_REF]DOE: The 1995 baseline environmental management report[END_REF] in the early post closure phase. The temperature will remain significantly higher than ambient temperature during thousands of years. In addition, porewaters in clay rocks exhibit high ionic strength (I) conditions, e.g. in Northern Germany (I > 3.5 M) or for OPA (I = 0.3-0.5 M) [START_REF] Courdouan | Isolation and characterization of dissolved organic matter from the Callovo-Oxfordian formation[END_REF]. It was shown earlier [START_REF] Courdouan | Characterization of dissolved organic matter in anoxic rock extracts and in situ pore water of the Opalinus Clay[END_REF][START_REF] Askarieh | Complexation of Np (V) in aqueous solutions[END_REF] that increase of temperature and ionic strength may have a significant influence on the complexation processes under the near-field conditions and thus change the retardation efficiency of clay rock formations. In light of the foregoing, it is necessary to outline the lack of information about the thermodynamic data of neptunium complex formation with ligands present in clay rocks. A recent study [START_REF] Vasiliev | Np(V) complexation with propionate in 0.5-4 M NaCl solutions at 20-85 °C[END_REF] investigated Np(V)-propionate complexation by spectroscopy and delivered related thermodynamic parameters. In [START_REF] Vasiliev | Np(V) complexation with propionate in 0.5-4 M NaCl solutions at 20-85 °C[END_REF], a solvent extraction method has been applied to determine the thermodynamic parameters for the Np(V)-propionate complexes at various I and T. The complexation of NpO 2 + with lactate has been studied previously at room temperature using solvent extraction technique [START_REF] Moore | Thermodynamic modeling of actinide complexation with acetate and lactate at high ionic strength[END_REF][START_REF] Tochiyama | Complex formation of Np(V) with various carboxylates[END_REF][START_REF] Eberle | Stabilitätskonstanten der Komplexe des Neptunyl(V)-lons mit α-Hydroxykarbonsäuren[END_REF]. The present paper is aiming to complete these data with complexation data at high temperatures that correspond to the HLW repositories conditions. Information on the temperature effect of the Np(V) complexation with low-molecular weight organic substances might also be useful to estimate the behavior of macromolecular organics such as humic substances [START_REF] Carbonaro | Linear free energy relationships for metal-ligand complexation[END_REF], that also were found at some potential repository sites [START_REF] Claret | Differences in properties and Cm(III) complexation behavior of isolated humic and fulvic acid derived from Opalinus clay and Callovo-Oxfordian argillite[END_REF]. In the present work, the complexation of Np(V) with propionate and lactate was studied by using a solvent extraction as a function of NaCl concentration, ligand concentration, and temperature. The specific ion interaction theory (SIT) was used for correlation of ionic strength effects and the temperature dependent thermodynamic stability constants as well as the standard molar reaction enthalpy Δ r H°m and the standard molar reaction entropy Δ r S°m of the complexation reactions are determined. Surface complexation modelling was applied to appraise the influence of Np(V) complexation with low-molecular weight organics on clay minerals retention of Np(V). Such studies render possible to assess the behavior of NpO 2 + in the environment and compare its properties with similar data for other actinides.

Experimental

Materials and Methods

Chemicals and Np(V) stock solution All chemicals were of p.a. quality or higher and were obtained from Merck (Darmstadt, Germany) or Riedel de Haen (Seelze, Germany). All experiments were conducted using de-ionized "MilliQ" water (ρ = 18.2 MΩ cm -1 ). A well characterized 237 Np(V) stock solution (50 µM) in 0.01 M HCl was used for all complexation experiments. Np(V) purity was verified by UV-Vis/NIR spectroscopy [START_REF] Sjoblom | Spectrophotometry of neptunium in perchloric acid solutions[END_REF]. 237 Np concentration was determined by liquid scintillation counting (LSC) with α/β-discrimination of the 233 Pa daughter nuclide, using the scintillation cocktail Ultima Gold XR (Packard Instruments Co., USA) and the liquid scintillation counter (LSC) Tri-Carb (Packard Instruments Co., USA). The α/βdiscrimination procedure is given in detail in Marsac et al. [START_REF] Marsac | Neptunium redox speciation at the illite surface[END_REF].

Complexation experiments

All concentrations given in mol L -1 (molarity, M) were corrected to mol kg -1 H 2 O (molality, m) for later calculations to avoid changes in the concentration because of variations in the solution density with temperature and ionic strength. Also the SIT (specific ion interaction theory) which was used for ionic strength correction to deduce complex stability constant at ionic strength zero, is based on the molal scale. The concentration of Np(V) was held at 3×10 -6 M in all extraction experiments. A first set of samples was prepared at different NaCl concentrations (I = 0.5-2.6 m) with total propionate concentration ([prop] tot ) being varied from 0.005 to 0.33 M and lactate concentration ([lac] tot ) from 0.01 to 0.13 M to determine the ionic strength dependence of Np(V)-propionate/lactate complexation at room temperature. Furthermore, additional series were prepared at a constant ionic strength of 0.5 m with varying the ligand concentration in the same ranges and different temperatures from 22°C up to 60 °C. To maintain constant temperature, a water thermostat was used. Ligand (prop, lac) concentrations were set by adding aliquots of a 1.0 M solution of propionic acid or a 0.5 M solution of sodium lactate. The pHc (molality of the proton; -log [H + ]) in each experimental batch was adjusted to a desired value of 7.0±0.1 at room temperature with 0.01 M HCl or 0.01 M NaOH and stabilized with 5•10 -3 M piperazine-N,N′-bis(2-ethanesulfonic acid) (PIPES) as buffer. 2-thenoyltrifluoroacetone (TTA) and 1,10phenanthroline (1,10-phen) were used without purification. A 1•10 -3 M TTA + 5•10 -4 M 1,10-phen solution in isoamyl alcohol [START_REF] Inoue | Solvent extraction of neptunium(V) by thenoyltrifluoroacetone and 1,10-phenanthroline or tri-n-octylphosphine oxide[END_REF] was prepared and used as an organic phase for the extraction of NpO 2

+ .

Solvent extraction

The solvent extraction experiments were conducted following the well-known procedure [START_REF] Choppin | Complexation of Am(III) by oxalate in NaClO 4 media[END_REF]. The organic solution containing 1•10 -3 M of TTA and 5•10 -4 M of 1,10-phen in isoamyl alcohol was preequilibrated with the aqueous stock solutions. For each extraction experiment 2.0 ml of aqueous solution containing the ligand, background electrolyte, PIPES buffer solution (5•10 -3 M) and 237 Np(V) tracer at pH c 7.0±0.1 was mixed with an equal volume of organic solution. The tubes were inserted into the holes of the temperature-controlled shaker for 3 hours at desired temperature. According to the kinetic studies this time is enough to reach the extraction equilibrium [START_REF] Choppin | Variation of stability constants of thorium citrate complexes with ionic strength[END_REF]. Afterwards the tubes were centrifuged and 0.5 ml aliquots were taken from both phases for 237 Np determination by LSC. No quenching effects were observed either in aqueous or organic phases under the experimental conditions. In the remaining aqueous phase pH exp was determined and pH c was calculated as described below. The hydrolysis of NpO 2 + is not significant at pH c < 9 at the present temperature range 22-60 °C [START_REF] Rao | Hydrolysis of neptunium(V) at variable temperatures (10-85°C)[END_REF]. At room temperature Np(V) carbonate complexation is negligible for pH c < 7.5 [START_REF] Maya | Hydrolysis and carbonate complexation of dioxoneptunium(V) in 1.0 M NaClO 4 at 25 °C[END_REF]. To our knowledge, there is no study on Np(V) carbonate complexation at elevated temperature. By comparison, Am(III) and U(VI) complexation by carbonate marginally increases and decreases, respectively, with temperature ranging between 22 and 60 °C [START_REF] Wruck | A study of americium(III) carbonate complexation at elevated temperatures by pulsed laser photoacoustic spectroscopy[END_REF][START_REF] Götz | The influence of the temperature on the carbonate complexation of uranium(VI) -a spectroscopic study[END_REF]. In addition, CO 2(g) solubility in water decreases with temperature. Since this work was carried out at pH c = 7.0±0.1, the hydrolysis and carbonate complexation reactions are not taken into account. Note also that the effect of TTA complexation with Np(V) in the aqueous phase as well as Np(V) Cl -complex formation were found to be negligible at the presently investigated conditions [START_REF] Inoue | Solvent extraction of neptunium(V) by thenoyltrifluoroacetone and 1,10-phenanthroline or tri-n-octylphosphine oxide[END_REF]. This was confirmed in our experiments where we clearly did not see a difference in the extraction of Np(V) with TTA between I = 0.5 m and I = 2.5 m NaCl in the absence of complexing ligands.

pH measurements

In the present study, operational pH values (pH exp ) were measured with an Orion 2 Star Benchtop pH meter using an Orion 8103SC combination pH electrode. Commercial pH Titrisol buffer concentrates (Merck p.a.) were used to calibrate the setup at room temperature. For pH measurements at I > 0.1 m NaCl, the pH exp was converted to the thermodynamically well-defined proton concentration pH c (-log [H + ]) according to equation 1 and 2 [START_REF] Altmaier | Solid-liquid equilibria of Mg(OH) 2 (cr) and Mg 2 (OH) 3 Cl•4H 2 O(cr) in the system Mg-Na-H-OH-Cl-H 2 O at 25°C[END_REF]:

pH c = pH exp + A NaCl (1) (2)
The empirical correction coefficient (A NaCl ) depends on the background electrolyte composition and concentration. For that we have accurately measured the A NaCl for the aqueous NaCl systems at room temperature. m NaCl is the molality of the background electrolyte. pH c was only determined at room temperature. The apparent proton dissociation constant of propionate/lactate (pK a ) is below 5 within the range of [NaCl] and T investigated [START_REF] Vasiliev | Np(V) complexation with propionate in 0.5-4 M NaCl solutions at 20-85 °C[END_REF][START_REF] Moore | Thermodynamic modeling of actinide complexation with acetate and lactate at high ionic strength[END_REF]. For pH c = 7 (i.e. > pK a + 2), both ligands can be considered as fully unprotonated. PIPES was chosen as a buffer, because it shows maximum water solubility, minimum solubility in all other solvents (i.e. during the extraction experiment), minimal salt effects and minimal change in pK a with temperature [START_REF] Good | Hydrogen ion buffers for biological research[END_REF]. Hence, pH c is not expected to be significantly affected when varying the temperature. For the calculations the total ligand concentration ([Prop] tot or [Lac] tot ) is considered to be equal to the free ligand concentration ([Prop] eq or [Lac] eq ).

Results and Discussions

Determination of the distribution ratio (D 0 ) in absence of a ligand

The complexation reaction of Np(V) with a ligand L -can be expressed as:

(

with the conditional stability constant (β c , in (kg•mol -1 ) n ) defined as: [START_REF] Zolotov | Investigation of the chemistry of pentavalent neptunium[END_REF]. To enhance the extraction efficiency, the synergetic extraction by the mixture of 2-thenoyltrifluoroacetone (TTA) and 1,10-phenanthroline (1,10-phen) was used [START_REF] Inoue | Solvent extraction of neptunium(V) by thenoyltrifluoroacetone and 1,10-phenanthroline or tri-n-octylphosphine oxide[END_REF].

(4) 0988 . 0 1715 . 0 ) ( 0013 . 0 2      NaCl NaCl NaCl m m A n n n c L NpO L NpO ] [ ] [ ] [ 2 ) 1 ( 2       ) 1 ( 2 2 n n L NpO L n NpO       Neptunium (V) is a difficult ion to extract
The extraction reaction can be written as follows: [START_REF]OECD: Safety of geological disposal of high-level and longlived radioactive waste in France -an international peer review of the[END_REF] where (o) or (a) refers to the species in the organic or aqueous phase, respectively. B refers either to 1,10-phen or TTA. Extraction is characterized by a distribution ratio (D) of Np(V) between the organic and aqueous phase: Where Σ[M] o is the total concentration of metal ion in the organic phase and Σ[M] a is the total concentration of metal ion in the aqueous phase. D depends on various factors like pH, T, I, etc. Assuming the presence of various species in the aqueous phase and D o as a distribution ratio in the absence of a ligand L in the aqueous phase, equations ( 4) and ( 6) can be combined to: [START_REF] Courdouan | Isolation and characterization of dissolved organic matter from the Callovo-Oxfordian formation[END_REF]

n n n c k k L D D ] [ 1 / , 0      a o M M I T pH D ] [ ] [ ) , , (            ) ( ) ( 2 ) ( ) ( ) ( 2 a o o o a H nB L NpO B n HL NpO
where k is a serial number of a given experiment. In the particular case of a 1:1 Np-ligand complexation, as observed in the present study for both propionate and lactate (as shown later), equation [START_REF] Courdouan | Isolation and characterization of dissolved organic matter from the Callovo-Oxfordian formation[END_REF] could be simplified to: [START_REF] Courdouan | Characterization of dissolved organic matter in anoxic rock extracts and in situ pore water of the Opalinus Clay[END_REF] and the slope of D k 0 /D k versus [L] corresponds to the conditional stability constant. To use the liquidliquid extraction method according to equation [START_REF] Courdouan | Characterization of dissolved organic matter in anoxic rock extracts and in situ pore water of the Opalinus Clay[END_REF] it is necessary to obtain D 0 values for all the investigated conditions namely pH c , ionic strength and temperature at fixed concentrations of extractants (TTA and 1,10-phen) and Np(V) ions. Figure 1 shows the results of synergistic extraction of Np(V) as a function of pH c in the absence of aqueous ligand at two ionic strengths (0.5 and 2.6 m). The slope of the linear part of this curve is equivalent to 0.74 that well fits to the literature data [START_REF] Inoue | Solvent extraction of neptunium(V) by thenoyltrifluoroacetone and 1,10-phenanthroline or tri-n-octylphosphine oxide[END_REF]. No significant influence of ionic strength on D 0 values was observed. By contrast, D 0 decreases with increasing temperature (Fig. 1-B). Third order polynomials were used to fit D 0 versus pH c at different temperature and the corresponding parameters are listed in Table 1. These equations were used to calculate the D 0 value corresponding to the exact measured pH c value of each extraction experiment in presence of aqueous ligand.

Figure 2 shows typical plots of the experimental values of D 0 /D as a function of propionate or lactate concentrations. 2 summarizes the presently determined β c values at 25 °C for Np(V) lactate and Np(V) propionate complexation from this work and from literature. For both ligands, β c values slightly increase with increasing I and T. Effect of ionic strength Several equations can be used to extrapolate conditional stability constants to infinite dilution such as the specific ion interaction theory (SIT) and Pitzer approach [START_REF] Bromley | Thermodynamic properties of strong electrolytes in aqueous solutions[END_REF]. SIT is applicable up to 3-4 m as recommended by NEA-TDB [START_REF] Guillaumont | Update on the chemical thermodynamics of uranium, neptunium, plutonium, americium and technetium[END_REF] and can be used in the present study. SIT is applied to estimate single-ion activity coefficients (γ i ) in solutions by taking into consideration the so called specific interaction coefficient (ε) between various ions in solution.

This procedure allows evaluation of equilibrium constants (β °) at infinite dilution:

With SIT, activity coefficients can be expressed as: [START_REF] Askarieh | Complexation of Np (V) in aqueous solutions[END_REF] where m k is the molality of the aqueous species k; ε(i,k) is the specific ion interaction coefficient between species i and k; D is the Debye-Hückel term; A(T) is the Debye-Hückel equation slope, that depends on temperature: [START_REF] Vasiliev | Np(V) complexation with propionate in 0.5-4 M NaCl solutions at 20-85 °C[END_REF] where N is the Avogadro number, e stands for absolute electronic charge, ε d is the dielectric constant of water at the given temperature, ρ is the pure water density, k is the Boltzmann constant, and T is temperature (K). Combination of equations 9 and 10 gives:

where Δz 2 = Σz 2 (products) -Σz 2 (reactants) = -2 for the reaction given in eq. ( 3), involving one propionate or lactate ion in the complex, and Δε = ε(Na + + Cl -; NpO 2 L) -ε(Na + ; L -) -ε(Cl -; NpO 2 + ). Figure 3 presents the plot of log β с + 2D versus I (m). According to eq. 13, the intercept and the slope of the linear regression correspond to log β ° and to -Δε, respectively. From the data in Figure 3, Δε is -0.14 ± 0.02 for propionate and -0.13 ± 0.03 for lactate and the log β ° values are 1.19 ± 0.03 and 1.96 ± 0.05, respectively. These values are shown in Table 4 and are compared with literature data. Log β ° and Δε values are in excellent agreement with a previous spectroscopic study of Np(V) propionate complexation (log β ° = 1.26 ± 0.03) [START_REF] Vasiliev | Np(V) complexation with propionate in 0.5-4 M NaCl solutions at 20-85 °C[END_REF]. Solvent extraction is a technique from which log β is calculated by using the total complexed metal species, including outer and inner sphere complexes, whereas

           k k k k i m k i D z m k i I I T A z ) , ( ) , ( 5 . 1 1 ) ( log 2 2    3 3 ) ( 100 2 ) ( T k N e T A d     I D z с            log log 2 ) ( ) ( ) ( 2 2      L NpO L NpO c      
spectroscopic technique takes into account only inner sphere species and might possibly result in understated β values [START_REF] Choppin | Inner vs outer sphere complexation of f-elements[END_REF]. The fact that both spectroscopic and solvent extraction methods provide similar thermodynamic parameters suggest that the NpO 2 Prop complex is formed mainly via inner sphere complexation, as previously shown for Eu [START_REF] Choppin | Inner vs outer sphere complexation of f-elements[END_REF]. Literature data are also available for Np(V) complexation with acetate (Acet) [START_REF] Rao | Spectrophotometric and calorimetric studies of Np(V) complexation with acetate at various temperatures from T=283 to 343 K[END_REF]. The authors obtained log β ° and Δε values for the 1:1 NpO 2 Acet complex similar to the values for propionate derived in this work using NaCl as background electrolyte (log β ° = 1.28 ± 0.04 and Δε = -0.24 ± 0.02). Moore et al. [START_REF] Moore | Thermodynamic modeling of actinide complexation with acetate and lactate at high ionic strength[END_REF] previously studied Np(V) complexation with acetate and lactate by liquid-liquid extraction (LLE) at 25°C and various ionic strengths (0 ≤ I ≤ 5 m). Experimental β c values are reported, but not the SIT parameters because the Pitzer model was used for ionic strength correction. For comparison purpose the original data from [START_REF] Moore | Thermodynamic modeling of actinide complexation with acetate and lactate at high ionic strength[END_REF] were evaluated with eq. 12 to get log β and Δε values. The thus obtained values are in relatively good agreement with the present work (s. Table 4).

In the present study no hints of a chloride complexation of NpO 2 + could be found, because the chloride concentration was too small [START_REF] Neck | Thermodynamics of neptunium(V) in concentrated salt solutions: chloride complexation and ion interaction (Pitzer) parameters for the NpO 2 ion[END_REF]. This confirms, that the chloride complexation of Np(V) is very weak and can be neglected to describe the studied system. In that case the interaction of NpO 2 + with the chloride ion can be regarded as an ion-ion interaction to be included in the specific interaction coefficients [START_REF] Neck | Thermodynamics of neptunium(V) in concentrated salt solutions: chloride complexation and ion interaction (Pitzer) parameters for the NpO 2 ion[END_REF].

The stability constants log β ° of NpO 2 Acet and NpO 2 Prop are similar with values between 1.19 and 1.29, suggesting that the extension of the carbon chain by one -CH 2 group does not affect significantly the log β ° value. It should be mentioned that for the Np(V) lactate complexation, the formation of a 1:2 complex was observed at larger lactate concentrations (0.1-1 M NaClO 4 ) by Tochiyama et al. [START_REF] Tochiyama | Complex formation of Np(V) with various carboxylates[END_REF]. However, in the same publication Tochiyama et al. report a slightly smaller experimental log β c1 value (1.40 ± 0.02) for the first lactate complex than the one obtained in the present paper (logβ c1 1.75 ± 0.03).

Effect of temperature

Effect of temperature on Np(V)-L complexation was investigated at T = 22, 40, 50, and 60 °C and [NaCl] = 0.51 m (Table 3). Conditional log β c values were corrected to stability constant log β °(T) at infinite dilution for each temperature using SIT approach as described above. As suggested by previous work, variation of ε(i,k) with T (< ±0.05 kg•mol -1 ) can be neglected [START_REF] Froehlich | A spectroscopic study of Cm (III) complexation with propionate in saline solutions at variable temperatures[END_REF][START_REF] Silva | Chemical thermodynamics Vol. 2, Chemical thermodynamics of americium[END_REF]. With the hypothesis that the molal standard reaction enthalpy Δ r H°m and entropy Δ r S°m are not changing with temperature (i.e. that heat capacity is constant) under the experimental conditions, it is possible to determine these thermodynamic parameters from an Arrhenius plot on the basis of the van't Hoff equation:

log 𝛽(𝑇) = - ∆ 𝐻 °𝑅𝑇 𝑙𝑛10 + ∆ 𝑆 °𝑅 𝑙𝑛10 ( 13
)
where R is the ideal gas constant. 4 with literature data for comparison. Presently determined parameters for propionate are consistent with a previous study on Np(V) propionate complexation by spectroscopy [START_REF] Vasiliev | Np(V) complexation with propionate in 0.5-4 M NaCl solutions at 20-85 °C[END_REF]. For [NaClO 4 ] = 1.05 m, Rao et al. [START_REF] Rao | Spectrophotometric and calorimetric studies of Np(V) complexation with acetate at various temperatures from T=283 to 343 K[END_REF] determined Δ r H°m = 18.1 ± 1.8 kJ•mol -1 and Δ r S°m = 75 ± 6 J•mol -1 •K -1 , which are comparable to our present results for the propionate system. Molar standard reaction enthalpy for NpO 2 Prop (Δ r H°m = 16.3±3.0 kJ•mol -1 ) is positive, which indicates that complexation of Np(V) with propionate is an endothermic reaction. In general, positive Δ r H°m and Δ r S°m are found for actinide complexes with monocarboxylic ligands, for example, Cm(III)Prop 2+ (Δ r H°m = 5.7 ± 1.8 kJ•mol -1 and Δ r S°m = 84 ± 5 J•mol -1 •K -1 [START_REF] Froehlich | A spectroscopic study of Cm (III) complexation with propionate in saline solutions at variable temperatures[END_REF]; or UO 2 Acet + (Δ r H°m = 14.5 ± 1.5 kJ•mol -1 and Δ r S°m = 104 ± 6 J•mol -1 •K -1 [START_REF] Jiang | Complexation of uranium(VI) with acetate at variable temperatures[END_REF]. The energy effect of the complexation process is composed of (i) dehydration energy, which contributes to the positive enthalpy by removing of water molecules from the first hydration sphere of the cation and (ii) the energy of the metal-ligand interaction, which contributes to the negative enthalpy. The Δ r H°m > 0 indicates that dehydration energy is required for complex formation and supports the model of inner sphere binding [START_REF] Ahrland | How to distinguish between inner and outer sphere complexes in aqueous solution. Thermodynamic and other criteria[END_REF]. For both, NpO 2 Prop and NpO 2 Acet, the molar standard reaction entropy is positive indicating that the formation of these complexes is entropy driven. Relatively high values of Δ r S°m (75±6 J•mol -1 •K -1 [START_REF] Rao | Spectrophotometric and calorimetric studies of Np(V) complexation with acetate at various temperatures from T=283 to 343 K[END_REF] and 77±9 J•mol -1 •K -1 for acetate and propionate, respectively) suggest a bidentate coordination mode of NpO 2 -OOC binding for acetate and propionate both with replacement of two water molecules from the inner sphere of Np(V), as previously confirmed by X-ray absorption spectroscopy [START_REF] Vasiliev | Np(V) complexation with propionate in 0.5-4 M NaCl solutions at 20-85 °C[END_REF]. Table 4: Thermodynamic parameters of neptunium (V) complex formation.

Reaction (method) log β ° (25°C) Δ r H°m (kJ•mol -1 ) Δ r S°m (J•K -1 •mol -1 )
Δε Ref.

NpO

Nd 3+ + Lact -↔ NdLact 2+ (spec, cal) -2.02±0.22 (I = 1.05m) 43±1 (I = 1.05m) - [38]
*the values were calculated using eq. 13 on the basis of published conditional stability constants.

For lactate, Δ r H°m is negative (Δ r H°m = -5.4±1.4 kJ•mol -1 ). No stability constants at elevated temperature are available in the literature for Np(V) lactate complexation. However, a previous study of Nd(III) lactate complexation also showed a negative Δ r H°m [START_REF] Tian | Complexation of lactate with neodymium(III) and europium(III) at variable temperatures[END_REF]. The lactate contains a hydroxyl group beside the carboxyl group, which can participate in the formation of chelate structures. Lactate can either coordinate 'end-on' through the carboxylic group only or 'side-on' through both, the carboxylic and the hydroxyl group. It was shown earlier that lactate binds 'side-on' to Am(III) [START_REF] Fröhlich | An EXAFS spectroscopic study of Am(III) complexation with lactate[END_REF] as well as to Eu(III) [START_REF] Barkleit | Americium(III) and europium(III) complex formation with lactate at elevated temperatures studied by spectroscopy[END_REF]. A similar coordination can be expected for Np(V) lactate complexation. Indeed, similar observations to the present ones for Np(V) were made for lanthanide complexation by Choppin and Friedmann [START_REF] Choppin | Complexes of trivalent lanthanide ions. III. Bidentate chelates[END_REF]. The enthalpies of lanthanide complexation were found to be exothermic for αhydroxycarboxylate ligands while they were endothermic for their simpler analogs like acetate and propionate. The entropy of complexation, though still positive, was likewise smaller for αhydroxycarboxylate ligands than for carboxylate ones.

Np(V)-complexation with small organics at environmentally relevant concentrations

The Np(V) propionate complexation parameters determined in the present paper by solvent extraction technique are in a good agreement with the values obtained by UV-Vis/NIR spectroscopy earlier [START_REF] Vasiliev | Np(V) complexation with propionate in 0.5-4 M NaCl solutions at 20-85 °C[END_REF].

In the same publication the authors state that propionate has a minor impact on the Np(V) speciation at propionate concentrations found in natural clay . However, the relevance of lactate as a ligand that can increase Np mobility in natural clay formations should also be discussed. Simulations were made with the geochemical speciation program PHREEQC [START_REF] Parkhurst | User's guide to PHREEQC (Version 2) -a computer program for speciation, batch reaction, one-dimensional transport and inverse geochemical calculation[END_REF] for pH c = 7, with 0.1 and 3 m NaCl and at T = 20 and 85°C using the presently obtained Np(V) lactate complexation parameters. The percentage of Np(V) complexed to lactate versus log [Lact] tot is shown in Fig. 5 ([Np(V)] tot = 10 -10 m). Np(V) lactate complexation slightly increases with I between 0.1 and 3 m for a given T, and slightly decreases with T between 20 and 85°C for a given I because of the exothermic effect of complexation. According to our calculations, at [Lact] = 10 -3 m, only about 5% of Np(V) is bound to the ligand. At log [Lact] tot higher than 0.1 M formation of a 1:2 Np(V) lactate complex becomes significant [START_REF] Tochiyama | Complex formation of Np(V) with various carboxylates[END_REF], but for small lactate concentrations even the NpO 2 Lac complex plays a minor role for the Np(V) speciation. We never observed any hints of a 1:2 Np(V) lactate complex at our experimental conditions of [Lact] tot < 0.1 M. If we consider OPA and COx as representatives for clay formations designated to be a host rock for nuclear repository sites, the lactate concentrations in the pore water were found to be lower than 10 μM [START_REF] Courdouan | Isolation and characterization of dissolved organic matter from the Callovo-Oxfordian formation[END_REF][START_REF] Courdouan | Characterization of dissolved organic matter in anoxic rock extracts and in situ pore water of the Opalinus Clay[END_REF]. This suggests that the influence of Np(V) lactate complexation is small under these conditions.

To get an overall picture of the influence of the low-molecular weight organic ligands acetate, propionate, and lactate on Np(V) speciation at COx conditions (1865 μM acetate, 127 μM propionate and 8 μM lactate [START_REF] Courdouan | Isolation and characterization of dissolved organic matter from the Callovo-Oxfordian formation[END_REF]), the speciation was calculated using previous (for acetate, [START_REF] Rao | Spectrophotometric and calorimetric studies of Np(V) complexation with acetate at various temperatures from T=283 to 343 K[END_REF]) and presently determined parameters (for lactate and propionate) at the same fixed I and T as studied in Figure 5 for various lactate concentrations. The results are plotted in Figure 6 for the three organic ligands. Although the total amount of Np(V) bound to these small organic molecules globally increases with temperature and salinity, it remains below 6% (in 3 m NaCl for T = 85°C). Therefore, these calculations suggest that small clay organic ligands have only little influence on Np(V) speciation in the aquatic solution at conditions relevant to clay pore waters of OPA and COx.

Fig. 6: Calculated Np(V) speciation in pore water of COx (1865 μM acetate, 127 μM propionate and 8 μM lactate at pH c = 7 [START_REF] Courdouan | Isolation and characterization of dissolved organic matter from the Callovo-Oxfordian formation[END_REF]) versus I and T.

Surface complexation modeling

PHREEQC [START_REF] Parkhurst | User's guide to PHREEQC (Version 2) -a computer program for speciation, batch reaction, one-dimensional transport and inverse geochemical calculation[END_REF] was applied to evaluate the impact of small organics on Np(V) sorption to illite. Indeed, illite is the most important adsorbent for radionuclides in OPA and COx [START_REF] Bradbury | Predictive sorption modelling of Ni(II), Co(II), Eu(IIII), Th(IV) and U(VI) on MX-80 bentonite and Opalinus clay, a "bottom-up" approach[END_REF]. PHREEQC can perform aqueous speciation calculations under dilute to highly saline conditions with SIT, and has previously been applied in surface complexation modeling studies at various ionic strengths [START_REF] Marsac | Modeling metal ion-humic substances complexation in highly saline conditions[END_REF][START_REF] Marsac | Sorption and redox speciation of plutonium on illite under saline conditions[END_REF][START_REF] Banik | Neptunium sorption and redox speciation at the illite surface under highly saline conditions[END_REF]. The 2-site protolysis non-electrostatic surface complexation and cation exchange model (2SPNE SC/CE model [START_REF] Bradbury | Sorption modeling on illite. Part II: Actinide sorption and linear free energy relationships[END_REF]) was used to simulate Np sorption to illite. The cation exchange capacity (CEC) of the illite was set to 0.225 eq•kg -1 . In PHREEQC, the Gaines and Thomas convention [START_REF] Gaines | Adsorption studies on clay minerals. II. A formulation of the thermodynamics of exchange adsorption[END_REF] can be used, whereby cation exchange reactions, the thermodynamic exchange constant (K exch ), and selectivity coefficient ( 𝐾 ) are expressed as follows:

Here, N i are equivalent fractions, f i are surface activity coefficients and brackets denote activities in solution. 2SPNE SC/CE model accounts for the presence of abundant weak and few strong sites for the surface complexation of cations at illite edges.

Only the strong sites of the 2SPNE SC/CE model were considered in the adsorption calculations with a site density of 2×10 -3 mol•kg -1 of illite, since the weak sites are irrelevant at trace levels of Np [START_REF] Marsac | Neptunium redox speciation at the illite surface[END_REF][START_REF] Banik | Neptunium sorption and redox speciation at the illite surface under highly saline conditions[END_REF]. Strong sites undergo protonation (log K a,1 = 4) and deprotonation reactions (log K a,2 = -6.2). Np(V) binding to these sites is written as follows:

≡SOH + NpO 2 + + I H 2 O ↔ ≡SONpO 2 (OH) i -i + (i+1)H + ; log K i (16)
with i = 0 or 1. Bradbury and Baeyens [START_REF] Bradbury | Sorption modeling on illite. Part II: Actinide sorption and linear free energy relationships[END_REF] determined a NpO 2 + -Na + selectivity coefficient (K c = 1) for illite as well as Np(V) surface complexation constants for illite within the 2SPNE SC/CE model (log K 0 = -2 ; log K 1 = -10.3). Simulations were made at pH c = 7 in 0.1 and 3m NaCl, at 25 and 85°C. Adsorption of small organics and ternary illite-Np-organic complexes were neglected. Surface complexation modeling was used to compute Np solid-liquid distribution ratios (R d , in L/kg): [START_REF] Claret | Differences in properties and Cm(III) complexation behavior of isolated humic and fulvic acid derived from Opalinus clay and Callovo-Oxfordian argillite[END_REF] where [Np] aq and [Np] tot (mol•L -1 ) are the dissolved (final) equilibrium and total (initial) concentrations of Np in solution, respectively. The term V/m corresponds to the aqueous solution volume to illite mass ratio (L•kg -1 ). Note that calculations based on R d values are independent of V/m values used for the calculations. Because temperature dependent Np(V) adsorption to illite is unknown, the temperature effect on sorption is neglected in the modeling and only temperature dependence of the aqueous

       Na NpO Exch NpO Na Exch 2 2 Na Np c Np Na Na Np Na Np exch f f K NpO Na f f N N K       ] [ ] [ 2 m V Np Np R aq tot d / ) 1 ] /[ ] ([   
speciation is considered. The results of the modeling are presented in Figure 7 as the variation of log R d (Δlog R d ) versus ligand concentration: [START_REF] Sjoblom | Spectrophotometry of neptunium in perchloric acid solutions[END_REF] This allows visualizing only effects of small organic molecules on Np(V) adsorption. An uncertainty of ±0.3 is commonly associated with log R d determination for radionuclide sorption to clay minerals [START_REF] Bradbury | Sorption modeling on illite. Part I: Titration measurements and the sorption of Ni, Co, Eu and Sn[END_REF], hence no significant effects of ligands on Np(V) adsorption on illite can be expected for Δlog R d ≤ 0.3. Decreasing of log R d at relevant concentrations of small clay organic ligands found in COx pore water (1865 μM acetate, 127 μM propionate and 8 μM lactate [START_REF] Courdouan | Isolation and characterization of dissolved organic matter from the Callovo-Oxfordian formation[END_REF]) were also calculated for high temperature and ionic strength (in 3 m NaCl for T = 85°C) and plotted in Figure 7.

According to modeling results, the expected influence of Np(V) complexation with small organic molecules even at higher temperature and ionic strength is several times smaller than the uncertainty on log R d determination for radionuclide sorption to clay minerals [START_REF] Bradbury | Sorption modeling on illite. Part II: Actinide sorption and linear free energy relationships[END_REF]. This suggests no significant influence of small organic molecules on Np(V) retention on clay minerals at OPA and COx conditions, even at elevated temperatures. Note that ternary clay-Np-organic complexes formation, omitted in these calculations because unknown, should further decrease the negative effect of small organic ligands on Np adsorption. Hence, these calculations correspond to an upper limit scenario related to the Np(V) complexation with small organic ligands. This is corroborated by Fröhlich et al. [START_REF] Fröhlich | Influence of temperature and background electrolyte on the sorption of neptunium(V) on Opalinus clay[END_REF], which show that the sorption of Np(V) on OPA (OPA contains illite as the main clay mineral phase) increases with increasing temperature. From this work we can conclude, that Np(V)-clay adsorption increases more strongly with increasing temperature than Np(V) complexation with small organics.

Conclusions

In the present study, liquid-liquid extraction was successfully applied and distribution ratios for Np(V) propionate and Np(V) lactate solutions were calculated. The present study clearly identifies the 1:1 NpO 2 + propionate and lactate complexes as the dominant species under the investigated conditions with log β ° (25°C) = 1.19 ± 0.03 for propionate and log β ° (25°C) = 1.96 ± 0.05 for lactate. Both stability constants increase with increasing ionic strength (0.5 < NaCl < 2.6 m) and with increasing temperature (22 < T < 60°C). The complex formation reaction is endothermic for propionate complexation and entropy driven, as evidenced by Δ r H°m = 16.3 ± 3.0 kJ•mol -1 and Δ r S°m = 77 ± 9 J•mol -1 •K -1 . The magnitude of Δ r S°m is consistent with an inner sphere bidentate coordination mode of the carboxylate, as previously observed by spectroscopy [START_REF] Vasiliev | Np(V) complexation with propionate in 0.5-4 M NaCl solutions at 20-85 °C[END_REF]. The results are in a good agreement with literature [START_REF] Vasiliev | Np(V) complexation with propionate in 0.5-4 M NaCl solutions at 20-85 °C[END_REF][START_REF] Moore | Thermodynamic modeling of actinide complexation with acetate and lactate at high ionic strength[END_REF]. However, formation reaction is exothermic for lactate complexation. It is both enthalpy and entropy driven, as evidenced by Δ r H°m = -5.4 ± 1.4 kJ•mol -1 and Δ r S°m = 19 ± 4 J•mol -1 •K -1 , which supports the formation of a chelate structure involving the carboxylate and the hydroxyl group of the lactate ligand. These derived thermodynamic data (Δ r H°m, Δ r S°m, log β °(T)) for Np(V)-propionate and lactate complexation complements the thermodynamic databases for modeling of environmentally significant processes which is relevant for safety assessment of nuclear waste disposal scenarios. Using the present data it is possible to assess the impact of complexation processes on the geochemical behavior of Np(V). According to the obtained results small clay organic molecules (acetate, lactate, propionate) have only little influence on Np(V) retention under the conditions that were found for OPA and COx pore waters.

( 6 )Fig. 1 :

 61 Fig. 1: Distribution ratios of Np(V) upon extraction by 1•10 -3 M TTA and 5•10 -4 M 1,10-phen in the absence of complexing ligands: A: At 23 °C with two ionic strengths 0.5 m and 2.6 m NaCl; B: At varying temperature and at 0.5 m NaCl.

Fig. 2 :

 2 Fig. 2: Representative plot of D 0 /D versus free ligand concentration. Aqueous phase: 0.5 m NaCl. Organic phase: 0.001 M TTA + 0.0005 M 1,10-phen.

Fig. 3 :

 3 Fig. 3: SIT plot of the equilibrium reaction NpO 2 + + L -⇌NpO 2 L in NaCl, yielding log β ° = 1.19 ± 0.03 for propionate and log β ° = 1.96 ± 0.05 for lactate.

Figure 4

 4 plots log β(T) versus the reciprocal temperature (K) 1/T. The linear dependences on temperature of log β °(T) validates our hypothesis. Calculated values of Δ r H°m and Δ r S°m are listed in the Table

Fig. 4 :

 4 Fig. 4: Np(V) complexation constants corrected to zero ionic strength (log β °) versus the reciprocal of the temperature (K -1 ).

Fig. 5 :

 5 Fig. 5: Chemical equilibrium diagram for Np(V) complexed species present in solutions consisting lactate (0-0.1 m).

Fig. 7 :

 7 Fig.7: Variations of Np(V) sorption (Δlog Rd) on Na-illite at different concentrations of small organics, T and I in comparison with variation of sorption at pore water conditions of COx (1865 μM acetate, 127 μM propionate and 8 μM lactate at pH = 7[START_REF] Courdouan | Isolation and characterization of dissolved organic matter from the Callovo-Oxfordian formation[END_REF]).

Table 1 :

 1 Experimentally obtained equations log (D 0 ) = f(pH с ) for I = 0.5-2.6 m.

	T (°C)	log (D 0 ) = f(pH c )
	26 ± 1	-0.1535(pH с )3+2.7991(pH с )2-16.178 pH с +29.137
	40 ± 1	-0.0983(pH с )3+1.7022(pH с )2-8.9916 pH с +13.594
	50 ± 1	-0.1103(pH с )3+1.9015(pH с )2-10.094 pH с +15.548
	60 ± 1	-0.1162(pH с )3+2.0174(pH с )2-10.837 pH с +16.979

Table 2 :

 2 Conditional stability constants of neptunium (V) complex formation at 25±1 °C.

	Complex 1	[NaCl]	pH	Method 2	log β c
		(m)
	NpO 2 Acet 0.30	6.0-7.2 e, [13]	1.05±0.04
		1.00	dto.	dto.	1.13±0.05
		2.00	dto.	dto.	1.25±0.05
		3.00	dto.	dto.	1.55±0.05
		4.00	dto.	dto.	1.70±0.20
		5.00	dto.	dto.	1.80±0.02
		1.05 *	7.0	e, cal, [32]	0.74±0.04
	NpO 2 Prop 0.51	7.0±0.5 e, p.w.	0.99±0.03
		0.83	dto.	dto.	1.01±0.03
		1.67	dto.	dto.	1.14±0.03
		2.50	dto.	dto.	1.14±0.04
		0.51	7.0±0.5 sp, [11]	0.99±0.07
		0.51	dto.	dto.	1.04±0.12
		1.03 l	dto.	dto.	1.01±0.07
		2.10	dto.	dto.	1.15±0.19
		3.20	dto.	dto.	1.34±0.15
		4.38	dto.	dto.	1.51±0.16
	NpO 2 Lact 0.51	7.0±0.5 e, p.w.	1.75±0.05
		0.83	dto.	dto.	1.75±0.03
		1.67	dto.	dto.	1.76±0.02
		2.50	dto.	dto.	1.84±0.02
		0.30	6.0-7.2 e, [13]	1.78±0.03
		1.00	dto.	dto.	1.43±0.04
		2.00	dto.	dto.	1.48±0.05
		3.00	dto.	dto.	1.76±0.02
		4.00	dto.	dto.	1.93±0.06
		5.00	dto.	dto.	1.95±0.04
	1 Complexation reaction: NpO 2 + + Ligand = NpO 2 Ligand

2 p.w. -present work, e -liquid-liquid extraction, sp -absorption spectroscopy, cal -calorimetry.; * the medium is NaClO 4

Table 3 :

 3 Conditional stability constants of neptunium (V) complex formation at different temperatures.

	Complex 1	T, °C	I (m)	log β c	Method 4
	NpO 2 Acet	25	1.04 2	1.05±0.04*	sp,cal [32]
		40	dto.	1.11±0.03*	dto.
		55	dto.	1.19±0.03*	dto.
		70	dto.	1.34±0.05*	dto.
	NpO 2 Prop	25	0.51 3	0.99±0.03	e, p.w.
		40	dto.	1.15±0.01	dto.
		50	dto.	1.29±0.10	dto.
		60	dto.	1.36±0.06	dto.
		20	dto.	1.07±0.10	sp [11]
		23	dto.	0.99±0.07	dto.
		23	dto.	1.04±0.06	dto.
		40	dto.	1.13±0.10	dto.
		60	dto.	1.19±0.10	dto.
		70	dto.	1.27±0.10	dto.
		85	dto.	1.36±0.13	dto.
	NpO 2 Lact	25	0.51 3	1.75±0.05	e, p.w.
		40	dto.	1.77±0.03	dto.
		50	dto.	1.71±0.02	dto.
		60	dto.	1.69±0.02	dto.

* In this work results of log β(T) were presented at zero ionic strength applying the SIT approach. 1 Complexation reaction: NpO 2 + + Ligand -= NpO 2 Ligand. 2 NaClO 4 ; 3 NaCl. 4 p.w. -present work; e -liquid-liquid extraction; sp -spectroscopy; cal -calorimetry.

[START_REF] Sjoblom | Spectrophotometry of neptunium in perchloric acid solutions[END_REF]

[START_REF] Sjoblom | Spectrophotometry of neptunium in perchloric acid solutions[END_REF]

[START_REF] Sjoblom | Spectrophotometry of neptunium in perchloric acid solutions[END_REF]

[START_REF] Sjoblom | Spectrophotometry of neptunium in perchloric acid solutions[END_REF]

Acknowledgements. Günter Herrmann was my (C.M. Marquardt) doctoral thesis supervisor. In those days he gave me the oportunity to work in the framework of a R&D Programme of the European Commission on Management of Radioactive Waste and Storage. The here presented work shows that this scientific issue is still up-to-date and that I remained true to this branch of science to date. This work has been supported by the German Federal Ministry of Economic Affairs and Energy (BMWi) under Contract No. 02E10206 and German Academic Exchange Service (DAAD).