# Intel Optane DCPMM and Serverless Computing

Ahmet Uyar1 Selahattin Akkas1 Jiayu Li1 Judy Fox2 1Indiana University
2University of Virginia<EMAIL_ADDRESS><EMAIL_ADDRESS>

###### Abstract

This report describes 1) how we use Intel’s Optane DCPMM in the memory Mode.
We investigate the the scalability of applications on a single Optane machine,
using Subgraph counting as memory-intensive graph problem. We test with
various input graph and subtemplate sizes to determine its performance for
different memory and CPU loads, as well as a comparison of performance on a
single node Optane with a distributed set of nodes in a cluster using MPI. 2)
We investigate the end-to-end execution delays in serverless computing and
study concurrent function executions with cold starts. In future work, we will
show that persistent memory machines may significantly improve concurrent
function invocations in serverless computing including Amazon Lambda,
Microsoft Azure Functions, Google Cloud Functions and IBM Cloud Functions
(Apache OpenWhisk).

##  1 Introduction

Subgraph counting is an NP-hard and memory-intensive graph problem. It is the
process of counting a given subgraph T in a large graph G. It has many use
cases in diverse domains from social network analysis [1] to bioinformatics
[2]. Since it is an NP-hard problem, several approximation algorithms have
been developed. We use the color-coding approximation algorithm [3]. In
addition, several versions of this problem have been studied in the
literature. We use the version [4] that counts tree templates in graphs.

Figure 1: Illustration of the template partitioning within a colored input
$G=(V,E)$

Intel® OptaneTM DC Persistent Memory Module is a nonvolatile storage module
supporting byte-granularity accesses and persistency [5]. It is a module that
goes into a tier in-between SSD and DRAM. It is used in either of two modes:
Memory mode or App-direct mode. In memory-mode, persistent memory module is
used as the main memory of the machine. It provides a much larger capacity
than DRAM with slightly lower performance. In this mode, DRAM functions as the
fourth level cache and no persistency provided for the data in memory. In app-
direct mode, persistent memory module functions as the byte-addressable
persistent storage device, and it provides much faster and higher bandwidth
data accesses than SSDs.

The experiments are conducted on two Optane machines. They have 2x48 core
Intel® Xeon® Platinum 8260L CPU @ 2.40GHz processors with 384GB of DRAM and
4TB of Persistent Memory. Since the subgraph counting algorithm is memory-
intensive, we use those machines in the memory mode. They provide 4TB of main
memory and 384GB of the fourth level cache. We investigate the scaling
efficiency of the subgraph counting algorithm on a single Optane machine with
an increasing number of OpenMP threads. We also compare the performance of the
multi-threaded version of the subgraph counting algorithm on a single Optane
machine to the distributed version of the same algorithm on a cluster.

Type | CPU | Frequency | Cores | DRAM | Persistent Memory
---|---|---|---|---|---
Optane | Xeon Platinum 8260L | 2.4GHz | 24 | 384GB | 4TB
Haswell | E5-2670 v3 | 2.3GHz | 12 | 128GB |
Table 1: Hardware

Serverless Computing is an emerging paradigm for cloud applications [6], [7].
It promises a simplified programming model and maintenance-free deployment.
Developers only write functions and deploy them on the cloud. Cloud providers
take care of resource provisioning, monitoring, maintenance, scalability, and
fault-tolerance. Currently, all major cloud vendors provide serverless cloud
infrastructure. Amazon provides AWS Lambda111https://aws.amazon.com/lambda/,
Google provides Google Cloud Functions222https://cloud.google.com/functions/,
Microsoft provides Azure Functions333https://azure.microsoft.com/en-
us/services/functions and IBM provides IBM Cloud
Functions444https://www.ibm.com/cloud/functions. IBM open-sourced its
serverless platform as OpenWhisk555https://openwhisk.apache.org/ and Microsoft
open-sourced its Azure Functions666https://github.com/Azure/Azure-Functions.

Serverless computing was the fastest-growing cloud service for the second year
in a row, according to Rightscale 2019 State Of The Cloud Report From Flexera
[8]. It has a wide range of use cases [9]. Some of its recommended use cases
can be listed as the following: multimedia processing, HTTP REST APIs and web
applications, event-triggered processing in databases, performing analytics on
IoT sensor inputs, handling stream processing, managing single time extract-
transform-load jobs, providing cognitive computing via chatbots, serving
machine learning and AI models, etc.

Serverless computing platforms employ containers to execute functions. A
separate container is constructed for each function. While it is very fast to
execute functions when there is a ready container, it is much slower to cold
start containers and executes the functions. We conducted tests to show the
end-to-end function execution delays and concurrent function execution delays
in OpenWhisk serverless computing system. We conducted the tests using both
HDD and SSD drives. We demonstrate the impact of faster storage on these
services. Although we have not performed these tests on the Optane machine, we
make the case that serverless computing systems would benefit significantly by
using faster and higher bandwidth persistent memory machines.

The report is organized as follows: we present the performance tests results
related to the subgraph counting algorithm on Optane machine in section 2. We
evaluate the performance of serverless computing in section 3. Conclusions and
future work are at section 4.

##  2 Performance Tests for Subgraph Counting

A parallel version of the subgraph counting algorithm has been developed at
Digital Science Center at Indiana University using OpenMP threads and AVX2
vector instructions for multi-core machines. A distributed version is also
developed using MPI to count larger subgraphs in clusters [10]. We are using
these implementations to run the subgraph counting on single and distributed
nodes.

To conduct the performance tests, we use the graph datasets shown at Table 2.
First graph dataset (nyc.graph) is a real social network graph data with 17M
vertices and 480M edges from [11]. Other two datasets are synthetic datasets
generated by RMAT graph generation algorithm [12] using PaRMAT tool
777https://github.com/farkhor/PaRMAT with a larger number of vertices and
edges. We count subgraph tree templates that have vertices ranging from 3 to
16.

o 0.8—X[l] —X[l] — X[l]— Dataset | Vertices | Edges
---|---|---
nyc.graph | 17,876,290 | 480,093,705
RMAT1 (k=3) | 30M | 800M
RMAT2 (k=1) | 40M | 1000M

Table 2: Graph datasets used in tests

###  2.1 Scaling with OpenMP Threads

We first test the scalability of the subgraph counting algorithm on a single
Optane machine with an increasing number of OpenMP threads. We conduct the
subgraph counting tests on nyc.graph dataset. We count two different input
subgraphs with different peak memory requirements. First input subgraph has 7
vertices. Counting this subgraph requires 28GB of peak memory. Therefore, all
data can fit into the DRAM of the machine easily. There is no need to move the
data between DRAM and persistent memory during the computation. Second
subgraph has 15 vertices. Counting that subgraph requires 742GB of peak
memory. This peak memory is much more than the DRAM capacity of the machine
that is 384GB. Therefore, we expect a lot of DRAM to persistent memory data
movement during the computation. We want to determine the scalability of the
subgraph counting algorithm with both types of memory loads.

Figure 2: Scaling subgraph counting with OpenMP threads on a single Optane
machine

Figure 2 shows the results of the scalability tests. In the first task, we
started with 1 thread and increased the number of threads up to 96. In the
second task, we started with 6 threads and increased it up to 96. The reason
for starting from 6 threads in the second task is twofold. First, our focus is
on the scalability of this algorithm with a higher number of threads. We focus
on speeding up this algorithm when all the resources of the machine are fully
utilized. Second, running this algorithm on 6 threads already takes 3961
seconds (66min). Running it on a single thread would have taken around 5
hours.

Both results show that the algorithm runs faster as the number of OpenMP
threads increases. However, the rate of speedup decreases as the number of
threads increases. Since the Optane machine has 48 physical cores, the
algorithm does not run any faster for 96 threads. Executions times are very
similar for 48 and 96 threads in both tasks.

Figure 3: Speedup at a single Optane machine while counting 7 vertices
subgraph in nyc.graph.

Figure 3 shows the efficiency of multi-threading for the 7 vertices input
subgraph. We divide the speedup from single-threaded version to multi-threaded
version by the number of threads. It shows the efficiency of parallel cores
with respect to the single-threaded version. The value of 1 shows that all
used cores are utilized as good as the single-threaded version. Multi-
threading efficiency decreases rapidly as the number of threads increases. The
efficiency is at 0.5 for 16 threads. It is at 0.22 for 48 threads. Although
the decrease in efficiency is expected as the number of threads increases, we
believe that better efficiency values should be attainable.

We examined various hardware performance metrics of the Optane machine using
Intel Vtune Amplifier for both subgraph counting tasks. The results are shown
in figure 4. In general, this is a memory-intensive problem, and these
hardware metrics demonstrate that.

(a) Average DRAM Bandwidth

(b) High DRAM Bandwith

(c) DRAM Bound Clockticks

(d) NUMA Remote Accesses

Figure 4: Performance metrics of Optane when counting 7 and 15 vertices
subgraphs

Figure 4a shows average DRAM bandwidth for both tasks. As the number of
threads increases, the average DRAM bandwidth also increases. Particularly
after 24 threads, the machine operates in a high bandwidth range for a
significant percentage of time as shown in Figure 4b. Figure 4c shows
percentage of DRAM bound clockticks. Both tasks have very high DRAM bound
clockticks. These values show that CPUs often stall for DRAM accesses.

This Optane machine has two CPU sockets. It has NUMA memory architecture. Both
sockets have their own DRAMs. When a thread on the first socket tries to
access the data on the DRAM of the second socket, it incurs additional delays.
It is called a NUMA remote access. Figure 4d shows the percentages of NUMA
remote accesses. In both tasks, this percentage is very high. They are around
50%. This means that executing threads are waiting longer for half of the
memory accesses. On the contrary to other metrics, this metric does not have a
clear pattern based on the number of threads. It goes up and down. This is the
result of OpenMP thread assignments to cores in two sockets by the operating
system. This assignment should be optimized to improve the performance of this
algorithm in this machine.

To improve the scalability of this problem, two types of improvements needed:
a) locality of data in DRAM should be improved and consequently the
percentages of DRAM bound instructions shall be reduced. b) Percentages of
NUMA remote accesses should be reduced by assigning threads to cores more
efficiently.

###  2.2 Scaling with MPI Processes

In this section, we test whether running distributed version of the subgraph
counting algorithm with multiple MPI processes on a single Optane machine
improves memory utilization and provides faster executions. We use Intel MPI
library to perform the tests.

We count the subgraphs with 13 and 15 vertices in nyc.graph. The first task
uses 254GB of peak memory, and the second task uses 745GB of peak memory in
distributed mode. While all the data of the first task fits into the DRAM of
the machine, the data of the second one spills over to the persistent memory.
In each run, the number of MPI processes x the number of OpenMP threads per
MPI process equals 96. So, we would like to utilize all available cores on the
machine. Figure 5 shows the test results.

Figure 5: Scaling with MPI processes at an Optane machine

First bars show the result from non-distributed version with one process and
96 threads. In this case, no MPI is involved. They are the reference execution
times for comparing to distributed versions. Other bars show the results from
distributed version with 2 or more MPI processes on the same machine. These
results indicate that using multiple MPI processes on an Optane machine
usually improves the execution times. When four MPI processes are used with 24
threads on each, the algorithm performs the best in both tasks. Compared to
the single process case, 4 MPI processes run 9% faster for 13 vertices
subgraph and 34% faster for 15 vertices subgraph. It seems that the efficiency
of the single process subgraph counting algorithm decreases as the memory
usage rate increases. The primary reason for the better performance of the
distributed version is the better memory utilization, as we will see in the
figures of performance metrics below.

We should also point out the fact that the multi-process distributed version
introduces some inter-process communication and synchronization overheads.
This is evident in counting the subgraph with 13 vertices. As the number of
MPI processes increases to 8, inter-process communication and synchronization
overheads matches the gains achieved by the better memory utilization and both
single process version and the distributed version run with similar execution
times. For 16 MPI processes, the distributed version provides slower
performance. However, when counting the subgraph with 15 vertices, even when
using 16 MPI processes, distributed version runs faster than the single
process version. In this case, the efficiency gained by better memory
utilization surpasses the costs of inter-process communication and
synchronization overheads.

(a) Average DRAM Bandwidth

(b) High DRAM Bandwidth

(c) DRAM Bound Clockticks

(d) NUMA Remote Accesses

Figure 6: Performance metrics of Optane for distributed MPI version.

We measured hardware performance metrics of the machine for distributed MPI
version, and the results are shown in Figure 6. The most important observation
is that when going from single process to two MPI processes, percentages of
NUMA remote accesses decreases sharply in Figure 6d. When counting 13 vertices
subgraph, it goes down from 51.2% to 0.1%. When counting 15 vertices subgraph,
it goes does from 43.6% to 0.2%. This implies that two MPI processes are
placed into separate CPU sockets and they almost entirely use their own local
DRAMs for data stores during the computation. This value remains very low even
for larger number of MPI processes, since all MPI processes are placed in
either one of two CPU sockets. Its maximum value is 3.5% for 16 MPI processes.
This seems to be the main reason for the better performance of the distributed
version compared to the single version. Distributed version employs much
better data locality in DRAM.

Average DRAM bandwidth is lower when counting 15 vertices subgraph as shown in
Figure 6a compared to the task for counting 13 vertices subgraph. The reason
is that this task uses more memory than the DRAM capacity of the machine.
Therefore, it uses persistent memory during computation for data stores. That
reduces the average DRAM bandwidth since the persistent memory is slower and
has less bandwidth compared to DRAM. On the other hand, 13 vertices case
achieves much higher bandwidth since its data can fit entirely to the DRAM.
This is also evident in Figure 6b. 13 vertices case operates with high DRAM
bandwidth for higher percentages of execution times.

Percentage of DRAM bound clockticks is very high for both tasks as shown in
Figure 6c. It is around 30% on the average. Although it decreases
significantly for 13 vertices case when MPI processes are used, it increases
slightly in the 15 vertices case for 2 and 4 processes. So, this metric does
not seem to be strongly correlated by MPI usage.

In summary, it is very important to minimize NUMA remote accesses in Optane
machine. In these tests, running multiple MPI processes eliminates NUMA remote
accesses and the gains from that surpasses the costs of MPI inter-process
communication and synchronization overheads.

###  2.3 Single Optane Node vs Conventional Cluster

We compare the subgraph counting execution times on a single Optane node with
a conventional cluster. The cluster nodes have 2x12-core Intel® Xeon® CPU
E5-2670 v3 @ 2.30GHz processors and 128GB of memory.

First, we compare the running times on a single Optane node with a single
cluster node. Since the cluster nodes have 24 CPU threads, we use 24 OpenMP
threads on both machines. Figure 7 shows the results. We run the algorithm on
all three graphs with subgraphs that can fit into the memory of the cluster
node with 128GB of memory.

As Figure 7 shows, both nodes provide comparable performance. Optane machine
is around 10% faster in larger subgraph counts.

Figure 7: Comparing execution times on a single Optane node to a single
cluster node Figure 8: Maximum memory usage comparison on different data sets.
Data sets that exceed the memory limit will not run on a single node.

Second, we compare the running times of the subgraph counting problem on a
single Optane node with the distributed cluster nodes. We run the program in
the cluster nodes by using the minimum number of nodes. The main limitation is
the memory usage. Since each cluster node has 128GB of memory, we allocate a
sufficient number of nodes to each run by determining the peak memory usage
from single node Optane execution. For example, when we run the program with
12 vertices subgraph on nyc.graph, its peak memory usage is 158GB of memory.
Therefore, we run it on two cluster nodes. In addition, we use the same number
of threads in both environments. Since Optane has 96 threads, we use at most
96 threads in the cluster also.

Figure 9 shows the results. The label of each bar shows the program features:
number of vertices in the subgraph template, peak memory usage, total number
of threads used in both Optane and the cluster nodes, and the number of
cluster nodes used.

(a) NYC

(b) RMAT1

(c) RMAT2

Figure 9: Comparing execution times on a single Optane node to many cluster
nodes

As the figures show, the distributed version that runs in the cluster with MPI
provides much better performance. As the peak memory usage increases, the
difference between cluster version and the Optane single node version also
increases. For example, while counting 15 vertex subgraph on nyc.graph is 3.8
times faster in the cluster than the Optane one, counting 16 vertex subgraph
in the cluster is 5.8 times faster. The same pattern exist in all three graph
tests. For the largest subgraph tests, counting 15 vertices subgraph in RMAT1
graph is 4 times faster and counting it in RMAT2 graph is 7 times faster in
the cluster.

As the memory requirement increases, Optane machine is using persistent memory
more and more. Its DRAM capacity is 384GB. When data can not entirely fit into
this DRAM, it needs to move the data back and forth between the DRAM and the
persistent memory. Since the persistent memory has both larger latency and
smaller bandwidth, this results in slower performance for test cases that
require larger memory footprints. On the contrary, in the distributed version,
all data resides in DRAM of cluster nodes. Therefore, it is faster. The
communication and synchronization overheads in the distributed version seem to
be much less than the overhead of persistent memory in Optane machine.

##  3 Serverless Computing and Persistent Memory

Serverless computing platforms provide separate container images for each
supported language. They use these images as the basis when constructing
containers for functions. A separate container is created for processing each
function. A function container goes through following life cycle stages.

Figure 10: The structure of serverless computing.[20]

  * •

Cold starting the container: A new container is created and initialized for
the language of the function. For example, if the function is written in Java,
a Java container is started. After this stage has completed, the container
becomes prewarmed.

  * •

Warming up the container: The function code is transferred to the container,
dependencies are gathered, and any necessary initializations are performed. If
the function code has not been compiled, it is compiled. The container is
dedicated to this function from now on. The container becomes ready or warmed.

  * •

Executing the function: Input parameters are transferred to the container, the
function code is executed and the result is transferred back to the user.

  * •

Deleting the container: If no function requests arrive for a predetermined
amount of time, the container is deleted.

Serverless computing systems use caching methods to improve end-to-end
execution delays [13]. They have two levels of container caching. First, when
a function is executed, its container is kept in memory in ready state for
some period of time, before deleting it. It is assumed that subsequent
requests are more likely for recently executed functions. Second, for some
frequently used languages, a set of prewarmed containers are kept in memory
for upcoming function requests. This avoids cold starting containers and
reduces end-to-end execution delays. When a function request arrives, only
warming up and function execution are performed. However, like in all caches,
there are always cache misses and cold starting of a container is a serious
issue in serverless computing systems [14].

Language and Version |  Container Image Name
---|---
Node.js 10 |  openwhisk/action-nodejs-v10:nightly
Ruby 2.5 |  openwhisk/action-ruby-v2.5:nightly
PHP 7.3 |  openwhisk/action-php-v7.3:nightly
Python 3.6 |  openwhisk/python3action:nightly
Java 8 |  openwhisk/java8action:nightly
DotNet 2.2 |  openwhisk/action-dotnet-v2.2:nightly
Go 1.11 |  openwhisk/actionloop-golang-v1.11:nightly
Swift 4.2 |  openwhisk/action-swift-v4.2:nightly
Table 3: Used languages and container image names

We performed the tests using OpenWhisk serverless computing system. We used 8
languages listed at Table 3. The table also shows the container image names
for each language.

We performed the tests on this section on a Linux machine with 2x12-core
Intel® Xeon® CPU E5-2670 v3 @ 2.30GHz processors and 128GB of memory. It has
both an HDD and an SSD drive. We configured Docker to store all container
images either in HDD or SSD drives when conducting the tests. Docker used
overlay2 storage driver for both cases. We performed each test 5 times and
averaged the results to minimize the effects of system performance variations.

###  3.1 Single Function Executions using HDD or SSD

We measured end-to-end single function execution delays using cold started,
prewarmed and ready containers. The results are shown in Fig 11. We used a
simple Hello World function in 8 different languages to demonstrate the delays
introduced by the system components. We sent a parameter to the function and
received a response. The function code execution is not supposed to introduce
any meaningful delays.

Figure 11a shows end-to-end function execution delays when there is a ready
container for the requested function. This shows the delays introduced mostly
by OpenWhisk system components. Average execution delay is 153ms with SSD and
156ms with HDD excluding the Ruby function. Surprisingly a simple function
takes a few hundred milliseconds in Ruby. Function execution delays are almost
the same for both storage types. As we expected, this implies that there is
not enough storage activity during these function executions to make a
difference in end-to-end delays.

(a) Execution Delay on Ready

(b) Prewarm to Ready Delay

(c) Cold to Prewarm Delay

(d) SSD Delay for stages

Figure 11: Stages of single function execution delays in OpenWhisk for 8
languages

Figure 11b shows prewarmed-to-ready delays; the time it takes to warm up
containers. We measured end-to-end function execution delays on prewarmed
containers and subtracted the end-to-end execution delays on ready containers.
Prewarmed-to-ready delays show significant differences for these languages.
While Python container is the fastest, Go and Swift are the slowest. There is
no meaningful time differences for 5 languages based on the storage type. This
implies that those containers do not perform much storage activity during this
stage. For the remaining three containers (DotNet, Go, Swift), they perform
significantly faster with SSD. The results imply that these 3 containers are
performing a considerable amount of storage activity during this time. When we
averaged the prewarmed-to-ready delays for all 8 languages, it is 551ms with
SSD and 729ms with HDD. Therefore, depending on the container type, using
faster storage may help readying prewarmed containers faster.

Figure 11c shows cold-to-prewarmed delays. We measured end-to-end function
execution delays on cold started containers and subtracted the end-to-end
execution delays on prewarmed containers. This is the most significant delay
introduced when executing serverless functions. It includes starting
containers from scratch. Read-only container layers are loaded and the
writeable container layer is created on top of the other layers. Therefore,
this is the stage with most storage activity. On the average, it takes 1346ms
to prewarm a container with SSD and 2084ms with HDD. Therefore, on the
average, cold starting containers are 35% faster when SSD storage is used.

Figure 11d shows end-to-end function execution delays with stages, combining
all these three delays. Left bars of each pair show the delays with SSD and
right bars show the delays with HDD. Average function execution delay for 8
functions is 2095ms with SSD and 3012ms with HDD for cold starts. Functions
are on the average executed 30% faster on cold containers when SSD drives are
used. This is a very significant improvement for serverless computing. It
would improve the responsiveness of the system considerably. Using persistent
memory would increase the end-to-end execution delays even further, since they
provide much faster storage access rates with higher bandwidth.

###  3.2 Concurrent Function Executions using HDD or SSD

We test the performance of OpenWhisk for executing many functions at once. We
would like to see how much difference does it make to use a faster storage
system in case of bursty traffic. While the system is initially free without
any running containers, we send many function execution requests in parallel.
Each function is different and only one request is submitted for each
function. Therefore, each function initiates a cold start of its container. We
measure the total execution times for these functions using SSD or HDD drives.

Figure 12: Concurrent function executions with cold starts using SSD or HDD
drives in OpenWhisk

The results are shown in Fig 12. First pair of bars show the total time spent
executing 8 functions; one function for each language. Second pair of bars
show the total delay for executing 16 functions; two functions for each
language, etc. As the results show, serverless system performs much better
with SSD storage. As the number of concurrent requests increase, the advantage
of SSD grows further. When 8 concurrent requests processed, it takes 4.5
seconds with SSD and 7.3 seconds with HDD. Therefore, processing 8 functions
with HDD takes almost two times longer. However, when 48 concurrent functions
are processed, it takes 19.1 seconds with SSD and 59.2 seconds with HDD.
Therefore, processing 48 requests with HDD takes more than 3 times longer.

These results show that higher bandwidth SSD storage improves serverless
system responsiveness significantly in the case of heavy traffic with cold
starts. Running serverless systems on persistent memory machines may improve
further the quality of concurrent function executions with their higher
bandwidth capacity.

###  3.3 Related Work

Performance of serverless computing systems have been investigated by some
recent papers. Lloyd et al. investigated serverless function performances on
AWS Lambda and Azure Functions [14]. They examined response times with cold
and warm containers, the impact of load balancing, container caching policies,
and memory reservation sizes on performance. Lee et al. investigated the
performance of concurrent execution of functions in AWS Lambda, Azure
Functions, Google Functions and IBM OpenWhisk [15]. They examined concurrent
function throughput, concurrency of CPU intensive, disk I/O intensive, and
network I/O intensive functions. Klimovic et al. designed an elastic,
distributed data store for serverless computing systems [16]. They leveraged
multiple storage technologies such as DRAM, SSD, and HDD to minimize the cost
while ensuring optimized I/O performance. They tested the designed system on
AWS cloud using EC2 instances.

Intel® OptaneTM DC Persistent Memory Module is a new storage technology with
great promise to improve many aspects of applications in servers. It provides
larger memory capacities and much faster persistent storage. There have been
many recent studies investigating various aspects of this new technology.
Izraelevitz et al. performed an in-dept performance review of this module with
its capabilities as main memory and a persistent storage device [5]. They
compared its latency and bandwidth characteristics to DRAM values. Gill et
all. investigated the performance of a single Optane machine for massive
graphs analytics [17]. They compared the performance of a single Optane
machine with a distributed set of cluster nodes for graph analytics. Mahapatra
et al. designed efficient data structures such as Doubly Linked List, B+Tree
and Hashmap for persistent memory machines by removing redundant fields [18].
Van Renen et al. conducted performance evaluations of persistent memory in
terms of bandwidth and latency, and developed guidelines for efficient
persistent memory usage for two essential I/O primitives in disk-based
database systems: log writing and block flushing [19].

Our planned work is distinct from above-mentioned studies. We plan to
investigate the performance improvements in serverless computing systems by
using faster and higher bandwidth persistent storage.

##  4 Conclusions

Our results for subgraph counting show that a single Optane machine can
conveniently run a multi-threaded memory-intensive application with terabytes
of memory usage. However, to get the best performance out of Optane machine,
multi-threaded programs need to be NUMA aware. The impact of NUMA remote
accesses is significant on execution times. The results in section 2.2 show
that the distributed version of the subgraph counting algorithm on Optane may
run 34% faster, despite the fact that it additionally introduces some inter-
process communication and synchronization overheads. The main reason for this
is the fact that the distributed version has much lower NUMA remote access
rates.

Our results for serverless computing tests show that using SSD drives improves
the end-to-end execution delays of single functions with cold starts
significantly. While on the average, executing a simple function takes 2.1
seconds with SSD, the same function takes 3 seconds with HDD. Therefore, using
SSD improves the responsiveness of the serverless computing system
considerably. In addition, when SSD drives are used, concurrent functions are
executed much faster. When 48 concurrent function requests are submitted, they
are processed 3 times faster with SSD. Therefore, using faster storage systems
significantly improve the end-to-end delays of single function executions and
provide much better handling of heavy function loads. These tests demonstrate
that using Optane persistent memory machine for serverless computing will
provide even faster end-to-end function executions and much faster processing
of bursty function requests.

###  4.1 Future Work

We are planning to test various OpenMP thread binding methods to reduce NUMA
remote accesses in the single process version. Further we will look into the
performance metrics of the memory hierarchy in more detail and perform roof-
line modeling analysis to see whether we can reduce the percentages of DRAM
bound clockticks. We are also planning to test with other memory-intensive
problems with different distributed communication and load sharing features.
Our overall objective is to determine the most important factors when running
memory-intensive applications on a single Optane machine.

To serverless computing tests on Optane machine using persistent memory in
app-direct mode, We would like to investigate the impact of faster and higher
bandwidth persistent memory on these systems. We plan to investigate the
performance improvements when cold starting and concurrently initializing
Docker containers; executing simple functions, fat functions with larger
memory footprints, I/O intensive functions, many concurrent functions, and
sequence of functions in serverless systems. We want to compare their
performance on HDD, SSD, and persistent memory.

## References

  * [1] X. Chen and J. C. S. Lui, “Mining graphlet counts in online social networks,” in ICDM, 2016, pp. 71–80.
  * [2] R. Milo, S. Shen-Orr, S. Itzkovitz, N. Kashtan, D. Chklovskii, and U. Alon, “Network motifs: simple building blocks of complex networks,” Science, vol. 298, no. 5594, p. 824, 2002.
  * [3] Alon, Noga, Raphael Yuster, and Uri Zwick. ”Color-coding.” J. ACM 42, no. 4 (1995): 844-856.
  * [4] M. Bressan, F. Chierichetti, R. Kumar, S. Leucci, and A. Panconesi, “Counting Graphlets: Space vs Time,” in WSDM, 2017, pp. 557–566.
  * [5] Izraelevitz, Joseph, Jian Yang, Lu Zhang, Juno Kim, Xiao Liu, Amirsaman Memaripour, Yun Joon Soh et al. ”Basic performance measurements of the intel optane DC persistent memory module.” arXiv preprint arXiv:1903.05714 (2019).
  * [6] Baldini, Ioana, Paul Castro, Kerry Chang, Perry Cheng, Stephen Fink, Vatche Ishakian, Nick Mitchell et al. ”Serverless computing: Current trends and open problems.” In Research Advances in Cloud Computing, pp. 1-20. Springer, Singapore, 2017.
  * [7] Hendrickson, Scott, Stephen Sturdevant, Tyler Harter, Venkateshwaran Venkataramani, Andrea C. Arpaci-Dusseau, and Remzi H. Arpaci-Dusseau. ”Serverless computation with openlambda.” In 8th USENIX Workshop on Hot Topics in Cloud Computing (HotCloud 16). 2016.
  * [8] ”Rightscale 2019 State Of The Cloud Report From Flexera.” Online Resource. https://info.flexerasoftware.com/SLO-WP-State-of-the-Cloud-2019. Accessed on August 25th, 2019.
  * [9] Allen, Sarah, Chris Aniszczyk, Chad Arimura, Ben Browning, Lee Calcote, Amir Chaudhry, Doug Davis, Louis Fourie, Antonio Gulli, Yaron Haviv, Daniel Krook, Orit Nissan-Messing, Chris Munns, Ken Owens, Mark Peek, and Cathy Zhang. ”CNCF Serverless Whitepaper v1.0.” Online Resource. https://github.com/cncf/wg-serverless/blob/master/whitepapers/serverless-overview/cncf_serverless_whitepaper_v1.0.pdf. Accessed on August 25th, 2019.
  * [10] Submitted to SC19, ”SubGraph2Vec: Highly-Vectorized Tree-like Subgraph Counting”.
  * [11] Yang, Jaewon and Jure Leskovec. 2012. Defining and evaluating network communities based on ground-truth. Knowledge and Information Systems 42, 1 (2012), 181–213.
  * [12] Chakrabarti, Deepayan, Yiping Zhan, and Christos Faloutsos. 2004. R-MAT: A recursive model for graph mining. In Proceedings of the 2004 SIAM International Conference on Data Mining. SIAM, 442–446.
  * [13] Markus Thommes. ”Squeezing the milliseconds: How to make serverless platforms blazing fast!.” Online Resource. https://medium.com/openwhisk/squeezing-the-milliseconds-how-to-make-serverless-platforms-blazing-fast-aea0e9951bd0. Accessed on August 14th, 2019.
  * [14] Lloyd, Wes, Shruti Ramesh, Swetha Chinthalapati, Lan Ly, and Shrideep Pallickara. ”Serverless computing: An investigation of factors influencing microservice performance.” In 2018 IEEE International Conference on Cloud Engineering (IC2E), pp. 159-169. IEEE, 2018.
  * [15] Lee, Hyungro, Kumar Satyam, and Geoffrey Fox. ”Evaluation of production serverless computing environments.” In 2018 IEEE 11th International Conference on Cloud Computing (CLOUD), pp. 442-450. IEEE, 2018.
  * [16] Klimovic, Ana, Yawen Wang, Patrick Stuedi, Animesh Trivedi, Jonas Pfefferle, and Christos Kozyrakis. ”Pocket: Elastic ephemeral storage for serverless analytics.” In 13th USENIX Symposium on Operating Systems Design and Implementation (OSDI 18), pp. 427-444. 2018.
  * [17] Gill, Gurbinder, Roshan Dathathri, Loc Hoang, Ramesh Peri, and Keshav Pingali. ”Single Machine Graph Analytics on Massive Datasets Using Intel Optane DC Persistent Memory.” arXiv preprint arXiv:1904.07162 (2019).
  * [18] Mahapatra, Pratyush, Mark D. Hill, and Michael M. Swift. ”Don’t Persist All: Efficient Persistent Data Structures.” arXiv preprint arXiv:1905.13011 (2019).
  * [19] van Renen, Alexander, Lukas Vogel, Viktor Leis, Thomas Neumann, and Alfons Kemper. ”Persistent Memory I/O Primitives.” arXiv preprint arXiv:1904.01614 (2019).
  * [20] Apache OpenWhisk by Animesh Singh and John Zaccone https://www.youtube.com/watch?v=phsSvI7JB48


# A time-dependent SEIR model to analyse the evolution of the Sars-CoV-2
epidemic outbreak in Portugal

Pedro Teles
Departamento de Física e Astronomia
Faculdade de Ciências da Universidade do Porto
Rua do Campo Alegre s/n, 4169-007 Porto
<EMAIL_ADDRESS>

###### Abstract

Background: The analysis of the Sars-CoV-2 epidemic is of paramount importance
to understand the dynamics of the coronavirus spread. This can help health and
government authorities take the appropriate measures and implement suitable
politics aimed at fighting and preventing it.
Methods: A time-dependent dynamic SIR model inspired in a model previously
used during the MERS outbreak in South Korea was used to analyse the time
trajectories of active and hospitalized cases in Portugal.
Results: The time evolution of the virus spread in the country was adequately
modelled. The model has changeable parameters every five days since the onset
of mitigation measures. A peak of about 19,000 active cases is estimated.
Hospitalized cases could reach a peak of about 1,250 cases, of which 200-300
in ICU units.
Conclusion: With appropriate measures, the number of active cases in Portugal
can be controlled at about 19,000 people, of which about 1,250 hospitalized
and 200-300 in ICU units. This seems manageable by the country’s national
health service with an estimated 1,140 ventilators.

##  1 Introduction.

There is already abundant information on Sars-CoV-2[1, 2, 3, 4, 5]. In the
most severe cases, the virus Sars-CoV-2 infection can lead to the development
of acute respiratory distress syndrome (ARDS) causing respiratory failure,
septic shock, multiorgan failure, and even death [6]. Studies suggest that the
case fatality rate of the virus is of about 3.5% in mainland China [7].
However, this value seems to be much higher in Italy [8], suggesting its
strong dependence on demographics [9]. The WHO declared Europe as the new
epicentre of the disease on the 13th of March of 2020[[10]. The rapid growth
of the number of active cases presenting severe symptoms has saturated the
health services in most countries in the continent, especially in Italy [11].
Governments throughout Europe have implemented severe measures to prevent and
mitigate the spread of the virus. Yet, as of the 6th of April there were as
many as 646,340 confirmed cases on the European continent, resulting in 49,227
deaths[2, 3].

In this study, a time-dependent SEIR model [12, 13] was used to analyse the
evolution of current active and hospitalised cases in Portugal. The model
takes into account mitigation and self-protective measures implemented by the
government and the population, from the 18th of March 2020 onwards. The use of
time-dependent models has been proposed before as they provide a chance to
readjust the parameters as time passes and the conditions in which the
epidemic is spreading change[14].

This study shows that although sometimes blunt[15], an SEIR model can
accurately predict the trajectory of the curve of infected and hospitalized
cases, and may be suitable to be used in the future for a consistent analysis
of the data, and the repercussions of mitigation and control measures, which
can be taken into account in these models.

##  2 Methodology.

A time-dependent SEIR model inspired by a model developed by Xia et al[12, 13]
was used, which can be understood by the flow diagram shown in figure 1. This
is an update from a previously used preliminary version [13], in which all
infected cases ended up hospitalized. Given how unrealistic that sounds, the
model now considers that 13% of infected cases are hospitalized, and 87% are
recovered through the normal recovery rate (these proportions were taken from
Portuguese data [16]. Furthermore, the model considers only one transmission
coefficient, one government measure coefficient, and one self-protective
measure coefficient.

In this model, S corresponds to the number of susceptible individuals; E, the
number of exposed individuals; A, the number of asymptomatic cases; I, the
number of mild-to-severe infected cases; H, the number of hospitalized cases;
R, the number of removed cases, and finally N, the total population of
Portugal.

The model is time-dependent, because $\beta(t)$, the transmission coefficient
of the asymptomatic, symptomatic, and hospitalized cases to the susceptible,
can vary with time. Although this variation is not continuous. This will be
explained later.

Figure 1: Flow chart of the SEIR model used in this work.

$\sigma^{-1}$ is the mean incubation period, $\lambda^{-1}$ is the mean time
between symptom onset to hospitalization, $k^{-1}$ is the mean
infectious/recovery period, $\delta^{-1}$ is the mean time from
hospitalization to death, $\gamma$ is the clinical outbreak rate, $l$
represents the self-protective measures taken by individuals, and $d$ the
mitigation measurements taken by the government. Of the symptomatic (I) cases
13% need hospitalization, whereas 87% heal without the need to be
hospitalized. The time unit is 1 day. The set of differential equations can
then be written as:

$\systeme{\frac{\mathrm{d}S(t)}{\mathrm{d}t}=-l\cdot\beta(t)\cdot(\frac{S(t)\cdot
A(t)}{N}+\frac{S(t)\cdot I(t)}{N}+\frac{S(t)\cdot
H(t)}{N}),\frac{\mathrm{d}E(t)}{\mathrm{d}t}=l\cdot\beta(t)\cdot(\frac{S(t)\cdot
A(t)}{N}+\frac{S(t)\cdot I(t)}{N}+\frac{S(t)\cdot H(t)}{N})-(\sigma+d)\cdot
E(t),\frac{\mathrm{d}A(t)}{\mathrm{d}t}=(1-\gamma)\cdot\sigma\cdot
E(t)-(k+d)\cdot A(t),\frac{\mathrm{d}I(t)}{\mathrm{d}t}=\gamma\cdot\sigma\cdot
E(t)-0.13\lambda\cdot I(t)-0.87(k+d)\cdot
I(t),\frac{\mathrm{d}H(t)}{\mathrm{d}t}=0.13\lambda\cdot I(t)-k\cdot
H(t)-(\delta+d)\cdot
H(t),\frac{\mathrm{d}R(t)}{\mathrm{d}t}=k\cdot[A(t)+H(t)+0.87I(t)]+d[A(t)+I(t)+H(t)+E(t)]+\delta\cdot
H(t)}$ (1)

The only parameter considered to be known was the mean incubation time, which
was taken as $\sigma^{-1}=5.1$ days from the literature (here using the median
as equal to the mean) [17]. From the previous work, determined from the
Italian recovery data [18], a mean infectious/recovery period of about
$k^{-1}\approx$ 11 days was used, and taken to be the same in all cases. The
clinical outbreak rate which was taken to be $\gamma\approx$ 7%, a mean value
from values reported for attack rates [19], in a first approximation, and
again, this is an approximate value. The epidemic starts at the 15th of
February (the day of the first reported case in Europe) with only one person
infected ($I_{0}=1$), being the rest of the values 0, except for $S_{0}$ which
is simply N-1. See table 1 for a breakdown of the different parameters of this
model. To solve this system of differential equations the Mathematica code
[20] was used, using the function “NonLinearModelFit”[21].

Table 1: The different parameters of the model described by Eq. 1 parameter | Previous work [13] | This work
---|---|---
$\sigma^{-1}$ | 5.1 (days) | 5.1 (days)
$\lambda^{-1}$ |  $\sim$4 (days) | To be fitted
$\delta^{-1}$ |  $\sim$59 (days) | To be fitted
$k_{1}^{-1}$ | 1/14 | 0.088 (now k)
$k_{2}^{-1}$ | 0.088 (days-1) | 0.088 (now k)
$\beta$ | 1.16$\pm$0.033) (days-1) | To be fitted (time-dependent)
$\gamma$ | 0.0158$\pm$0.034) (days-1) | 0.07
l | Time-dependent | To be fitted (time-dependent)
d | Time-dependent | To be fitted (time-dependent)
N | 10,290,000 | 10,290,000
$S_{0}$ | 10,289,999 | 10,289,999
$E_{0}$ | 0 | 0
$A_{0}$ | 0 | 0
$I_{0}$ | 1 | 1
$H_{0}$ | 0 | 0
$R_{0}$ | 0 | 0

In order to determine the parameters $\lambda$, and $\delta$, the number of
hospitalized cases and deaths, respectively, as reported by the Portuguese
Directorate-General of Health (DGS in Portuguese) and available online, were
used [16]. Fits were made on the 27th of March. After determining the values
for these parameters, they were used to fit the curve of infected cases in
Portugal, where the values of $\beta(t)$, $d$ and $l$ were fitted in seven
different periods:

  * •

Period 0, from the 15th of February to the 18th of March (5 days after the
government decreed a State of Emergency, giving the virus another incubation
period),

  * •

Period 1, from the 19th to the 24th of March,

  * •

Period 2, from the 25th to the 30th of March,

  * •

Period 3, from the 31st of March to the 4th of April,

  * •

Period 4, from the 5th to the 10th of April,

  * •

Period 5, from the 10th to the 15th of April,

  * •

Period 6, from the 15th to the 20th of April (prediction).

The three parameters $\beta$, $l$, and $d$ were fitted for each of these five
periods. All other parameters were fixed.

##  3 Results.

###  3.1  Adjusting parameter $\lambda$.

The number of deaths in Portugal was taken from [16], and the set of
differential equations described in eq. 1 fitted to obtain the best possible
fit for $\delta$. An $R^{2}$ value of $\sim$0.99 was obtained with the fit.
The rest of the parameters are presented in table 2 . Results are shown in
figure 2.

Table 2: Table of fitted parameters $\lambda$ and $\delta$ as obtained using “NonLinearCurveFit” in Mathematica parameter | estimate | standard error | t-statistic | p-value
---|---|---|---|---
$\delta$ | 0.0681 | 0.00219 | 28 | 2.75$\times 10^{-9}$
Figure 2: Graphical representation of the adjusted model to the Portuguese
official death toll.

###  3.2 Adjusting parameter $\lambda$.

Now, using the value for $\delta$ found in 3.1, parameter $\lambda$ was
obtained with a new fit of Eq. 1 to the number of hospitalized cases in
Portugal, which again was taken from [16]. The best possible fit gave an
$R^{2}$ value of $\sim$0.98. The rest of the parameters are presented in table
3, and shown in figure 3.

Table 3: Table of fitted parameter $\lambda$ as obtained using “NonLinearCurveFit” in Mathematica parameter | estimate | standard error | t-statistic | p-value
---|---|---|---|---
$\lambda$ | 0.285 | 0.0141 | 20.07 | 2.98$\times 10^{-12}$
Figure 3: Graphical representation of the adjusted model to the hospitalized
cases in Portugal.

###  3.3 Fitting of parameter $\beta$ in period 0

The parameters needed to fit Eq. 1 to the number of Portuguese active cases
until the 18th of March, in order to determine the value of $\beta$, were
obtained in 3.1, and 3.2. The number of Portuguese active cases was taken from
[16]. The fit was obtained with an $R^{2}$ of 0.99. The other parameters for
$\beta$ are given in table 4. In this period, no measures were being taken so,
$l=1$; and $d=0$.

Table 4: Table of fitted parameters $\lambda$ and $\delta$ as obtained using “NonLinearCurveFit” in Mathematica parameter | estimate | standard error | t-statistic | p-value
---|---|---|---|---
$\beta$ | 1.023 | 0.00263 | 388.7 | 5.19$\times 10^{-35}$

A graphical depiction of the fitted model is given in figure 4.

Figure 4: Graphical representation of the adjusted model to the Portuguese
government official active cases.

###  3.4 Discussion of the obtained values for $\lambda$, $\delta$, and
$\beta$ for period 0

According to the obtained values of $\lambda$, $\delta$, and $\beta$, the mean
time between onset of symptoms and hospitalization (for the 13% of cases that
need to be hospitalized) is of $\lambda^{-1}=3.51\pm 0.17$ days, and the mean
time of those hospitalized until death is of $\delta^{-1}=14.6\pm 0.45$days.
Unfortunately, I did not find any official data about these numbers in order
to establish a comparison to ascertain their adequacy.

Also, the model assumes that all symptomatic and no asymptomatic cases are
being tested, which may not reflect a realistic situation. This is probably
very conditional to the number of tests being performed by the country and may
also vary with time.

Table 5: The obtained parameters of the model described in the previous sections parameter | this work ($days^{-1}$)
---|---
$\lambda$ | 0.285$\pm$0.00141
$\delta$ | 0.0681$\pm$0.0002
$\beta$ | 1.023$\pm$0.00263

##  4 Time evolution of Sars-CoV-2 in Portugal, considering time adjustable
parameters.

In an epidemic outbreak such as the current one, governments and the
population take protective measures to attempt to contain the spread of the
virus. In this paper, parameters l and d, inspired by the paper from Xia et
al[12, 13] , are introduced as explained in section 3. These parameters are
meant to take into account two things:

  * •

Isolation and monitoring measures taken by the government (parameter $d$);

  * •

Self-protection measures taken by the population (parameter $l$).

In a previous study, four different scenarios in addition to an “out-of-
control” scenario, were devised. To note that we are currently working with
$d_{1}=d_{2}=d_{3}=d_{4}=d$ and $l_{1}=l_{2}=l_{3}=l$.

The day considered for the initiation of these measures is day 33
corresponding to the 19th of March 2020 which is 5 days after the government
implemented the measures, giving the virus another cycle of infection before
the measures take effect.

###  4.1 Implementing a dynamic model to follow the trajectory of the curve.

In the current analysis, instead of using set values from educated guesses as
done in my previous work, the values of $\beta$, $d$ and $l$ are adjustable to
the curve. In order to fit the results, four periods of five days each, from
the 19th of March, were considered. In the first three periods, the same
official data to fit the results was used. Initial conditions were taken from
the previous period, and equation 1 was solved for the trajectory of the curve
in the remainder of days in the same period. This procedure was performed for
each period. This allowed for a dynamic follow-up of the trajectory, adjusting
the parameters to the best possible fit to the curve in each period. The
obtained results are summarized in table 6. A graphical depiction of the
evolution of the obtained curve for infected cases is given in 5. For
hospitalized cases, this is provided in figure 6.

Figure 5: Graphical representation of official active cases in Portugal and the model. Blue dots represent official data, the orange line the model.  Table 6: Obtained parameters for each of the periods considered  period |  $\beta$ (days-1) |  $l$ (no units) |  $d$ (days-1) | $R^{2}$
---|---|---|---|---
Period 1 (19th to 24th March 2020) | 1.101$\pm$0.0167 | 0.641$\pm$0.009 | 0.0353$\pm$.0816 | 0.999
Period 2 (25th to 30th March 2020) | 1.052$\pm$0.0315 | 0.379$\pm$0.011 | 0.0100$\pm$0.105 | 0.999
Period 3 (31th March to 4th April 2020) | 0.509$\pm$0.001 | 0.489$\pm$0.009 | 0.0100$\pm$0.033 | 0.999
Period 4 (5th to 10th April 2020) | 0.571$\pm$0.008 | 0.521$\pm$0.006 | 0.0453$\pm$0.022 | 0.999
Period 5 (10th to 15th April 2020) | 0.227$\pm$0.017 | 0.569$\pm$0.043 | 0.0100$\pm$0.046 | 0.999
Figure 6: Graphical representation of hospitalized cases in Portugal. Blue
dots represent official data, the orange line the model.

As is clear from the figures, the number of active and hospitalized cases was
reached between the 10th and the 15th of April at around 1,250 cases, below
the predictions of the model. In fact the number of hospitalized cases has
reached a plateau. Current active cases are around $\sim$19,000. Considering
that the number of ICU cases has been between 20-30% of the total of
hospitalized cases (see data), this would mean a number of about 200 300 cases
in ICU.

Figure 7: Graphical representation of $R_{0}$ for each time period.

The last period corresponds to a prediction of the values for the five days
following period 5 (10th to the 15th of April 2020). Both $l$ and $\beta$ were
extrapolated using a polinomial function, which enables the estimation of
their value for the next period, as can be seen in table 7:

Table 7: Obtained parameters for each of the periods considered  period |  $\beta$ (days-1) |  $l$ (no units) |  $\beta_{eff}$ (days-1
---|---|---|---
Period 0 (2nd to 19th March 2020) | 1.023$\pm$0.0026 | 1 | 1.023$\pm$0.0026
Period 1 (19th to 24th March 2020) | 1.101$\pm$0.0167 | 0.641$\pm$0.009 | 0.706$\pm$.00146
Period 2 (25th to 30th March 2020) | 1.052$\pm$0.0315 | 0.379$\pm$0.011 | 0.399$\pm$0.0166
Period 3 (31th to 4th April 2020) | 0.509$\pm$0.001 | 0.489$\pm$0.009 | 0.249$\pm$0.005
Period 4 (5th to 10th April 2020) | 0.571$\pm$0.008 | 0.521$\pm$0.006 | 0.297$\pm$0.005
Period 4 (10th to 15th April 2020) | 0.227$\pm$0.017 | 0.569$\pm$0.043 | 0.129$\pm$0.014
Period 6 (15th to 20th April 2020) | 0.301 | 0.450 | 0.136

In this table, we are already considering the effective value of the
transmission rate, $\beta_{eff}(t)$:

$\beta_{eff}(t)=l\cdot\beta(t)$ (2)

###  4.2 Estimating $R_{0}$ for this model.

The obtained values for $\beta$, allow for an estimate of the basic
reproduction number for all considered periods.

Following the formalism proposed by Van der Driessche and Watmough[22], and
$\alpha=0.13$ we can define $\mathscr{F}$ and $\mathscr{V}$, that the
equilibrium state is given by $(S_{0},0,0,0)$:

$\mathscr{F}=\begin{pmatrix}l\frac{S\beta}{N}(A+I+H)\\\ 0\\\ 0\\\ 0\\\
\end{pmatrix}\quad\textrm{and}\quad\mathscr{V}=\begin{pmatrix}(\sigma+d)E\\\
-(1-\gamma)\sigma E+(k+d)A\\\ -\gamma\sigma E+\alpha\lambda
I+(1-\alpha)(k+d)I\\\ -\alpha\lambda I+kH+(\delta+d)H\\\ \end{pmatrix}$ (3)

We can then determine the Jacobian matrices:

$F=\begin{pmatrix}0&l\frac{S\beta}{N}&l\frac{S\beta}{N}&l\frac{S\beta}{N}\\\
0&0&0&0\\\ 0&0&0&0\\\ 0&0&0&0\\\ \end{pmatrix}\quad\textrm{and}\quad
V=\begin{pmatrix}\sigma+d&0&0&0\\\ -(1-\gamma)\sigma&k+d&0&0\\\
-\gamma\sigma&0&\scriptstyle\alpha\lambda+(1-\alpha)(k+d)&0\\\
0&0&-\alpha\lambda&\scriptstyle k+(\delta+d)\\\ \end{pmatrix}$ (4)

We also need $V^{-1}$:

$V^{-1}=\begin{pmatrix}\frac{1}{\sigma+d}&0&0&0\\\
\frac{(1-\gamma)\sigma}{(\sigma+d)(k+d)}&\frac{1}{k+d}&0&0\\\
\scriptstyle\frac{\gamma\sigma}{(\alpha\lambda+(1-\alpha)(k+d))(\sigma+d)}&0&\scriptstyle\frac{1}{\alpha\lambda+(1-\alpha)(k+d)}&0\\\
\frac{\alpha\lambda\gamma\sigma}{(k+(\delta+d))(\alpha\lambda+(1-\alpha)(k+d))(\sigma+d)}&0&\frac{\alpha\lambda}{k+(\delta+d)}&\scriptstyle-\frac{1}{k+(\delta+d)}\\\
\end{pmatrix}$ (5)

And $R_{c}$ will simply be

$R_{c}=\rho(FV^{-1})=l\frac{S\beta}{N}\left(\frac{(1-\gamma)\sigma}{(\sigma+d)(k+d)}+\frac{\gamma\sigma}{(\alpha\lambda+(1-\alpha)(k+d))(\sigma+d)}\right)+\frac{\alpha\lambda\gamma\sigma}{(k+(\delta+d))(\alpha\lambda+(1-\alpha)(k+d))(\sigma+d)}$
(6)

For $R_{0}$, $l=1$, and $d=0$, and so:

$R_{0}=\rho(FV^{-1})=\frac{S_{0}\beta}{N}\left(\frac{1-\gamma}{k}+\frac{\gamma}{\alpha\lambda+(1-\alpha)k}+\frac{\alpha\lambda\gamma}{(k+\delta)(\alpha\lambda+(1-\alpha)k)}\right)$
(7)

This gives a value of $R_{0}=11.77$, indicating a very active spread of the
virus in this first stage, although this value seems higher than most studies.
In this model, given that cases will only resolve after a period of about
$k^{-1}\sim 10$ days, during which time they will be able to infect another
individual. Also, there is a very high uncertainty for the appropriate
incubation time of this virus, which some authors claim can be of up to 27
days [23, 24]. This is still something that needs to be analysed in more
detail.

This permits us to estimate the value for the evolution of the basic
reproduction number $R_{c}$ with time, as can be seen in figure 7.

As can be seen the value of $R_{0}$ is diminishing with time, with a predicted
value already very close to $1$ for the period of the 20th to the 25th of
April 2020, although the value has clearly increased from a minimum in the
week from the 10th to the 15th of April.

##  5 Conclusions

SEIR models, although sometimes blunt in their deterministic approach, are
valuable tools to model epidemic outbreaks. If used carefully and dynamically
(i.e. with adjustable parameters on given periods) it is possible to
accurately predict the trajectory of an epidemic curve within a five to ten-
day period. Protective and isolation measures are currently the only weapon at
our disposal to control this epidemic. SEIR models are effective in taking
these measures into account by the insertion of one or two extra parameters.
Variation of such parameters can be demonstrative of the power of any given
measure, be it in terms of self-protection (washing hands frequently, social
isolation, etc.) or community measures (closing down schools, parks, etc.).

##  6 Limitations of this study and scope of application

This study is intended for academic purposes only and should not be used in
any other way. It intends to provide tools for scientists to model the
trajectory of active and hospitalized cases in the current pandemic. With this
model, and although in earlier predictions the values were of $\sim$13,000
active cases and $\sim$2,500 hospitalized cases, it seems now that a maximum
of $\sim$19,000 active cases and $\sim$1,250 hospitalized cases will or has
already been reached in this period. The value of $R_{eff}$ is now approaching
one which means that in the next few days we will see the number of active
cases starting to finally diminish. This model assumes that only symptomatic
cases are being tested. Given that the number of tests in Portugal is now one
of the highest in the World, it is very likely that non priority cases are
also being tested now, which means that the model is starting to fail, as
asymptomatic cases begin being tested. This could explain the plateau reached
in the number of hospitalized cases, which, as we know represent 13% of the
total number of symptomatic cases. If this hypothesis is proven to be correct,
the country may have already reached the peak of active cases (both
symptomatic and asymptomatic), but is simply testing asymptomatics now leading
to an increase in the number of confirmed cases, but a constant number of
hospitalized and ICU cases.

## References

  * [1] Novel Coronavirus (2019-nCoV) situation reports - World Health Organization (WHO) https://www.who.int/emergencies/diseases/novel-coronavirus- 2019/situation-reports/ accessed 6th April 2020
  * [2] Worldometer (https://www.worldometers.info/coronavirus/) accessed 6th April 2020
  * [3] Coronavirus Disease (COVID-19) – Research and Statistics, Max Roser, Hannah Ritchie and Esteban Ortiz-Ospina (2020), ourworldindata.org/coronavirus, accessed 6th April 2020
  * [4] The species Severe acute respiratory syndrome-related coronavirus: classifying 2019-nCoV and naming it SARS-CoV-2, Gobalenya AE, Baker SC, Baric RS, et al. (March 2020). Nature Microbiology: 1–9. doi:10.1038/s41564-020-0695-z. PMID 32123347.
  * [5] Epidemiological and clinical characteristics of 99 cases of 2019 novel coronavirus pneumonia in Wuhan, China: a descriptive study Chen N, Zhou M, Dong X, et al (February 2020). Lancet. 395 (10223): 507–13. doi:10.1016/S0140-6736(20)30211-7. PMID 32007143
  * [6] COVID-19: what is next for public health?. Heymann DL, Shindo N, et al. (WHO Scientific and Technical Advisory Group for Infectious Hazards) (February 2020). Lancet. Elsevier BV. 395 (10224): 542–545. doi:10.1016/s01406736(20)30374-3. PMID 32061313.
  * [7] Case-fatality estimates for COVID-19 calculated by using a lag time for fatality Wilson N, Kvalsvig A, Telfar Barnard L, Baker MG. Emerg Infect Dis. 2020 Jun [date cited]. https://doi.org/10.3201/eid2606.200320
  * [8] Case-Fatality Rate and Characteristics of Patients Dying in Relation to COVID-19 in Italy Onder G, Rezza G, Brusaferro S.. JAMA. Published online March 23, 2020. doi:10.1001/jama.2020.4683
  * [9] The Epidemiological Characteristics of an Outbreak of 2019 Novel Coronavirus Diseases (COVID-19) in China. Zhonghua Liu, Xing Bing, Xue Za Zhi. 2020;41(2):145–151. DOI:10.3760/cma.j.issn.0254-6450.2020.02.003.
  * [10] WHO Director-General’s opening remarks at the media briefing on COVID-19 - 13 March 2020 World Health Organization https://www.who.int/dg/speeches/detail/who-director-general-s-openingremarks-at-the-mission-briefing-on-covid-19—13-march-2020 accessed 18 March 2020
  * [11] The Extraordinary Decisions Facing Italian Doctors, Yascha Mounk, The Atlantic, 11 March 2020 https://www.theatlantic.com/ideas/archive/2020/03/who-gets-hospitalbed/607807/ accessed 18 March 2020
  * [12] Modeling the Transmission of Middle East Respirator Syndrome Corona Virus in the Republic of Korea Xia Z-Q, Zhang J, Xue Y-K, Sun G-Q, Jin Z(2015). PLoS ONE 10(12): e0144778. doi:10.1371/ journal.pone.0144778
  * [13] Predicting the evolution Of Sars-CoV-2 in Portugal using an adapted SIR Model previously used in South Korea for the MERS outbreak P Teles - arXiv preprint arXiv:2003.10047, 2020
  * [14] A Time-dependent SIR model for COVID-19, Yi-Cheng Chen, Ping-En Lu, Cheng-Shang Chang arXiv:2003.00122v1 (28 Feb 2020)
  * [15] Planning as Inference in Epidemiological Models rank Wood, Andrew Warrington, Saeid Naderiparizi, Christian Weilbach, Vaden Masrani, William Harvey, Adam Scibior, Boyan Beronov, Ali Nasseri
  * [16] Ponto da Situação atual em Portugal, Direcção Geral de Saúde (in Portuguese), https://covid19.min-saude.pt/ponto-de-situacao-atual-emportugal/ accessed 5th April 2020
  * [17] The incubation period of coronavirus disease 2019 (COVID-19) from publicly reported confirmed cases: Estimation and application. Lauer SA et al. Ann Intern Med 2020 Mar 10; [e-pub]. (https://doi.org/10.7326/M20-0504)
  * [18] Dipartimento della Protezione Civile COVID-19 Italia - Monitoraggio della situazione (in Italian) http://tiny.cc/zv3slz accessed 18 March 2020
  * [19] Epidemiology and Transmission of COVID-19 in Shenzhen China: Analysis of 391 cases and 1,286 of their close contacts Qifang Bi, Yongsheng Wu, Shujiang Mei, Chenfei Ye, Xuan Zou, Zhen Zhang, Xiaojian Liu, Lan Wei, Shaun A Truelove, Tong Zhang, Wei Gao, Cong Cheng, Xiujuan Tang, Xiaoliang Wu, Yu Wu, Binbin Sun, Suli Huang, Yu Sun, Juncen Zhang, Ting Ma, Justin Lessler, Teijian Feng medRxiv 2020.03.03.20028423; doi: https://doi.org/10.1101/2020.03.03.20028423
  * [20] Wolfram Research, Inc., Mathematica, Version 12.1, Champaign, IL (2020).
  * [21] NonLinearModelFit http://tiny.cc/pw3slz accessed 18 March 2020
  * [22] Driessche, P. van den and J A Watmough. “Reproduction numbers and sub-threshold endemic equilibria for compartmental models of disease transmission.” Mathematical biosciences 180 (2002): 29-48 .
  * [23] Coronavirus incubation could be as long as 27 days, Chinese provincial government says - Reuters, Feb. 22, 2020
  * [24] Presumed Asymptomatic Carrier Transmission of COVID-19. JAMA. Bai Y, Yao L, Wei T, et al., JAMA. Published online February 21, 2020. doi:10.1001/jama.2020.2565