For Fujitsu, computational science research is one of the cornerstones of a successful IT service provider. Whether it is the development of quantum computers, new solutions for more sustainable and effective mobility, energy-saving HPC systems or the Digital Factory – alone and with international partners, Fujitsu always aims to create positive added value for society, the environment, and its customers. This is why Fujitsu regularly participates in European, more research-oriented tenders and projects with a wide range of partners.

As part of the FaaS paradigm that applies to the “PHYSICS” platform, Fujitsu has set itself the goal of contributing various optimization functions. The term optimization can be understood to cover a wide range of activities or functions: an optimized process, the provision of specific data to be able to make (optimized) decisions more quickly, the optimal use of time or the optimized packaging of content in a package. From a mathematical point of view, the latter is a real optimization problem, more precisely a problem from the field of combinatorial optimization. Combinatorial optimization problems include sequencing, assignment, grouping and selection problems. These include, for example, the traveling salesman problem, the Knapsack problem, graph similarity, portfolio optimization, (scheduling) planning, (task) assignment, software validation, AI model optimization and many others. Behind these somewhat stubborn names are everyday problems from logistics, the packaging industry, the manufacturing industry, shift planning and many others. What all these problems have in common is that there is not just one solution to them, but that there may well be many qualitatively different solutions. Furthermore, there is no known algorithm that can simply calculate these problems directly. Finding a good or the best solution in large problem spaces therefore requires an enormous amount of computing capacity and time.

As part of the “PHYSICS” project, Fujitsu has developed various optimization patterns that benefit from the performance of the quantum-inspired technology “Digital Annealer“. The Digital Annealer can solve combinatorial optimization problems particularly quickly and with particularly good results. To do this, it uses several ideas from annealing and quantum computing to solve the problems described above particularly well and quickly. But first, the problem in question is converted into a specific mathematical model, which the digital annealer can then solve. The highlight: if quantum computers are one day able to solve similarly large problems, the mathematical model already developed can simply be transferred to them and solved. The technology therefore not only provides a relevant advantage in business today, but also prepares the company in the best possible way for the age of quantum computers.

The physics project now provides two patterns for optimization problems and their solution with the help of the Digital Annealer in Node-Red. These processes can be transferred to the runtime environment with just a single click. To simplify the use of the Digital Annealer and its integration into the Node-Red ecosystem, we have implemented various backbone classes that enable the use of the Digital Annealer and the processing of optimization problems within Node-Red.

In this context, JavaScript classes were implemented that make it possible to formulate an optimization problem as a Quadratic Unconstrained Binary Optimization (QUBO) problem that can be solved on the Digital Annealer. For this purpose, various classes have been implemented that support different operating modes of the Digital Annealer. Currently, the Digital Annealer has two operating modes for solving a QUBO problem, each offering different functionalities. In addition, classes are also provided to facilitate the interpretation and presentation of the results returned by the Digital Annealer. These classes are integrated into the Node Red ecosystem and are readily available as Node Red workflow blocks. Users have the option to use both the Backbone JavaScript classes and the Node Red blocks according to their own requirements and preferences.

To demonstrate the use of the provided JavaScript classes and workflow blocks, two solution patterns are provided in Node-Red: “Two Persons Assignment” (TPA) and the “Traveling Salesman Problem” (TSP). In the classic “Two Persons Assignment Problem”, a set of items representing tasks or projects must be assigned to two persons or machines in such a way that the difference in the workload or items assigned to the two is minimized. The TSP, on the other hand, asks the following question: “What is the shortest possible route that visits each city exactly once and then returns to the starting city?”, given a list of cities and their coordinates. The TSP is an NP-hard combinatorial optimization problem that plays an important role in theoretical computer science and operations research. The enormous power of the Digital Annealer can be used by Node-Red to solve the above-mentioned problems. If you want to implement further patterns, we would also like to recommend our Digital Annealer Tutorial. However, we know that solving a specific optimization problem on quantum or quantum-inspired hardware requires a QUBO formulation, which can be a very complex task. In this regard, the Fujitsu Digital Annealer team will be happy to assist you in formulating your problem and solving it through Digital Annealer.

The post The Digital Annealer in practice: Optimizer Pattern integration. appeared first on PHYSICS.

The PHYSICS project, held its 8th General Assembly meeting on November 8th – 9th, 2023, in Florence, Italy. Hosted by GFT, the meeting provided an opportunity for partners to present updates on task progress and deliverables, as well as discuss upcoming project results. The coordinator and leaders of the work packages (WP) led discussions on any outstanding issues, fostering active participation and constructive feedback.

The meeting was conducted using a hybrid format, accommodating both in-person and remote attendees. Among the meeting’s key objectives were the status of PHYSICS’ 2nd Iteration Pilot Implementation, the finalization of the Final Review demo, and the definition of the Final Review agenda and logistics.

You may follow the PHYSICS project activities on Twitter and LinkedIn.

The post Press Release: PHYSICS 8th General Assembly appeared first on PHYSICS.

The German Research Center for Artificial Intelligence (DFKI) carried out the 3-week tests (from September 4 to 23, 2023) of the PHYSICS platform to assess the goals targeted by the Smart Manufacturing Use Cases:

1. Deployment of substitute service in the Cloud
2. High Confidence Quality Control

(see Blogpost: Industrial Use Cases of FaaS: The basics you need to know for more details)

The evaluation phase was held from 8:00 a.m. to 8:00 p.m., Monday through Saturday. The test consisted of calling the High Confidence Quality Control PHYSICS Cloud deployed function, resulting in approximately 20000 requests per week. This gave the total number of 60177 requests with 59425 successful responses (98.75%), even though PHYSICS is still in beta testing.

Only one major problem with the PHYSICS platform occurred on Monday afternoon during the first week of testing, which, once noticed, was fixed relatively quickly on Tuesday. This can be seen in the weekly results where the successful response rate was 96.47% in the first week, 99.82% in the second week and 99.96% in the third week.

Considering the first Smart Manufacturing Use Case PHYSICS Cloud Deployment is only meant to be used as a backup solution in case when the DFKI’s PHYSICS Edge Deployment goes out of service. Therefore, the availability of the PHYSICS platform (percentage of successful responses) at this stage of development was assessed as satisfactory.

In addition, for every single request the action time[1] and the total time[2] were recorded. Both Smart Manufacturing Use Cases required an average of less than 5 seconds for a Quality Check. The performance of PHYSICS fulfilled this condition which can be seen in Figure 1.

[1] only function execution time

[2] total request round-trip time

It is important to highlight that the total time for the successful request is consistent as shown in the histogram presented in Figure 2. The only outliers are the required cold starts of the functions each day after not being used overnight (not shown in the histogram, since they last longer than 10 seconds).

Because of the pay-as-you-go model of Function as a Service in general, our secondary goal of reducing costs was also achieved. About 20000 requests per week, each lasting less than 2 seconds would cost less than 1€ per month in operational costs[1]. Of course, if we need more requests or even more complex quality checks, operating time will increase, and therefore cost will scale linearly with it. Due to the simplified development and deployment, replacing our functions in the future will be straightforward, further reducing (development) costs.

To sum up, the tests conducted for Smart Manufacturing Use Cases proved the potential of the PHYSICS. Considering that the platform is still at the testing stage, its availability, performance, and chance to reduce development costs were evaluated as satisfactory.

[1] Estimated cost based on comparable FaaS platforms on the market.

The post Assessment of goals targeted by Smart Manufacturing Use Cases appeared first on PHYSICS.

Automatic understanding of patients to drive personalized interventions is becoming important in personalized healthcare, especially when patients are suffering from chronic conditions, ideally spending most of their patient journey away from clinical facilities. In most cases using models to infer on patients is a sporadic task, each patient being processed once or a few times per day. Deployed inference services are mostly inactive, occasionally serving bursts of requests. This is a clear indication of benefits that can be achieved if such services are deployed as functions. PHYSICS provides the tools for designing, testing, deploying and evaluating such Functions as a Service (FaaS). Engineers can use the provided Design Environment (DE) to first design their service. The PHYSICS DE integrates Node-RED and extends its palette of nodes, facilitating graphical service implementation as a flow. Some of the nodes do accept Javascript and Python scripts for advanced functionality. The flow can be tested locally, optimized and finalized.

The DE then provides the means to build the flow into an action that can be invoked within OpenWhisk. A Jenkins pipeline is executed, and as a result, the engineer comes up with a new action from their flow.

The deployed actions are then tested via flows dedicated to invoking deployed actions. The outputs of the deployed actions are compared to those of the local flows.

Finally, deployed actions can be evaluated under different scenarios implemented using dedicated load generator nodes.

The results of such tests can be as follows, where experiments last 2 minutes continuous requests, each request arriving at a fixed delay after the previous. As long as the delays are larger than the inference time, the achieved rate follows the increase of that of a system with infinite resources. When the delay drops below the execution time, then the achieved rate reaches a plateau. Even more frequent requests push Openwhisk beyond the accepted maximum request level, dropping the requests, resulting to a performance collapse.

The post Deploying healthcare ML functions in the PHYSICS way appeared first on PHYSICS.

The PHYSICS project’s 7th General Assembly meeting was held on July 4th – 5th, 2023, in Pafos, Cyprus. The meeting was hosted by Innov-Acts LTD. During the GA the consortium partners presented their updates on the progress of different tasks and deliverables and discussed current and upcoming project results. The coordinator and leaders of the work packages (WP) facilitated discussions on any remaining issues, promoting active participation and constructive feedback. To accommodate both in-person and remote attendees, the meeting was conducted using a hybrid format.

We eagerly anticipate the upcoming meeting!

You may follow the PHYSICS project activities on Twitter and LinkedIn.

The post Press Release: PHYSICS 7th General Assembly appeared first on PHYSICS.

The 6th General Assembly meeting of the PHYSICS project took place on March 6th – 7th, 2023, in Munich, Germany, and was hosted by Fujitsu TDS GmbH.
The event provided a platform for the consortium partners to report on the status of various tasks and deliverables. The coordinator and work package (WP) leaders led discussions on any outstanding matters, fostering engagement and collaboration. The meeting was conducted using a hybrid format, blending in-person and virtual participation.

Looking forward to the next one!

You may follow the PHYSICS project activities on Twitter and LinkedIn.

The post Press Release: PHYSICS 6th General Assembly appeared first on PHYSICS.

The 5th PHYSICS project General Assembly meeting was held on November 15th – 16th, 2022 in Madrid, Spain and was hosted by ATOS.
Partners had the opportunity to update the consortium on the progress of different tasks and deliverables, and further discuss any open issues. Led by the coordinator and WP leaders, the consortium also discussed feedback generated by the project’s review and future plans regarding the third and final year of the PHYSICS project. The meeting was organized in a hybrid mode.

You may follow the PHYSICS project activities on Twitter and LinkedIn.

The post Press Release: PHYSICS 5th General Assembly appeared first on PHYSICS.

It is commonly known that Serverless Computing has emerged as an agile environment of alternate execution while having many inherent scaling capabilities. The Function as a Service [1] approach, aims to apply the serverless scope also in the way application logic is created, embedded and executed. Currently though, the size of FaaS applications is rather small, indicating that approximately 82% of them have only up to 5 functions in the workflow [2], while at the same time native orchestration mechanisms of FaaS toolkits typically present significant limitations.

PHYSICS platform doesn’t only utilize Node-Red visual-flow tool for its orchestration needs but also OpenWhisk’s ( open-source FaaS platform ) built-in sequence operator. This gave us the trigger to investigate and measure the performance overheads that derive from each orchestration strategy of PHYSICS platform but also to calculate the percentage of useful computational time for each scenario. We created 3 different cases (modes) that apply to PHYSICS’s needs for orchestration:

Mode1: The first observed mode is the Sequence Operator for OpenWhisk runtime functions, meaning both executions and orchestrations of function-sequences we created are located on OpenWhisk exclusively.

Mode2: The second observed mode is a variation of the first, where this time function workflow is created in Node-RED and deployed within a custom Docker function image. The executions as well as the orchestration, are handled by Node-RED, while all functions execute and reside in the same container.

Mode3: The third and finally observed mode derives from the parallelization needs of PHYSICS platform. In this scenario Orchestration flow that is inside Node-RED invokes functions deployed on the OpenWhisk environment, which consequently means the flow acts as a generic orchestrator while the external containers are the main execution environment.

As for the experiment itself:

• We created the artificial delay functions a priori, already knowing their delay, which was 1000ms. Those Functions created sequences with range varying from 1-25 with a step of 5.

• We used warm containers to avoid cold start latency

• One client request was active per time

• Actions were exposed as web actions

• Each measurement was performed with 40 repetitions

The measured time was the inter-function communication delay or orchestration delay, which is the pure baseline delay from a hop of one function to the next in the sequence.

• For OW-OW we can use the average overhead time per function, given that this is independent of the number of functions used
• For NR-NR and OW-NR the initialization time significantly affects the average produced, as the number of functions grows

In order to be more precise we created a mathematical model to describe each mode, with GNU Octave’s Ordinary Least Squares function. The functions that derived from that analysis are the following:

As a next step, we created parametrized plots that arise from the previous mathematical equations, for different function sequences and inner function delays, in order to observe how the estimated total execution differs for different function numbers and delays.

The 40 functions is considerably high in cold start case, though NR-NR in warm executions is always better

• The NR-NR mode presents the greatest benefits, having under 10% from as low as 10 functions in the sequence and even for small function delays of 100 and 200 milliseconds, with a minimum of 0.29% for 100 functions in the 1000 millisecond case

By dealing with the problem of Orchestration Overheads both theoretically and practically we concluded to the following:

1. OpenWhisk’s Orchestration Time is primarily due to warm container reuse time and this delay is unavoidable since in this mode we are not able to implement both orchestration and function logic in the execution container
   
2. The proposed Node-RED orchestration aids in minimizing the needed containers which is basically the biggest part of the delay
   
3. The third mode (hybrid) is only suitable for parallelization needs
   
4. The artificial sleep functions we created, can be replaced with more complex workflows since the baseline time is around the same
   
5. Enabling easier orchestration both functionally and performance-wise can help increase the observed number of functions

All the data and links used for the experiment can be found in the following links:

• https://physics-faas.eu/
• https://hub.docker.com/r/pekoto/noderedaction
• https://flows.nodered.org/flow/f0795ad9f25ad2affcadb8deb305fdf3/in/VOf-0UrN5e2j
• https://hub.docker.com/r/pekoto/owmode3
• https://github.com/pekoto4349/measurements

For more information, please refer to the following publication:
George Kousiouris, Chris Giannakos, Konstantinos Tserpes and Teta Stamati, 2022, Measuring Baseline Overheads in Different Orchestration Mechanisms for Large FaaS Workflows. In Companion of the 2022 ACM/SPEC International Conference on Performance Engineering, April 9–13, 2022, Bejing, China, DOI: 10.1145/3491204.3527467

The post Performance overheads arising by orchestration strategies in the PHYSICS platform appeared first on PHYSICS.

Personalized healthcare requires decision support systems that can help healthcare professionals to manage large volumes of patients. Care for chronic conditions requires doing so for patients at their everyday setting, outside the clinical environment. These needs can only be addressed with AI systems, at the core of which models trained by ML can be found. Such systems are deployed to offer diverse services, such as model inference for patient outcomes’ prediction, patient clustering into phenotypes and dataset augmentation with synthetic arms.

The traditional deployments of such systems in healthcare suffer from scaling. Deployment is a lengthy procedure, certainly aided by modern CI/CD pipelines, but the resulting systems are quite static in terms of resources, while occupying them even during quiet times.

PHYSICS facilitates the design and deployment of these services. It provides a design environment to implement and deploy the services. The starting point is an AI function implemented in Python at the core, which constitutes a node in complete Node-RED flows built around it using more (Javascript) functions and PHYSICS patterns to handle input and output.

Node-RED offers developers the means to locally test the flow, using additional nodes for user input, and invocation. Local testing is handy during the implementation phase.

Still using the design environment, locally tested flows are then deployed as functions to expose the health care services. PHYSICS annotation nodes control the deployment options at the flow level.

Thus, the flows employed for defining testing and deploying healthcare services are usually split in three sections. The endpoints definition section defines two POST endpoints, the /run with the service core, and the /init for any initialization. The manual invocation section facilitates local testing by sending a request to the /run endpoint. Finally, the annotations section controls the deployment options. The sections are shown in the flow depicted below:

The healthcare services being implemented in the PHYSICS FaaS way are:

• Predictive model inference: Load feature vectors and a predictive model into an inference engine to get inference results.
• Patient phenotyping: Load feature vectors and a set of generative models (describing patient clusters) into a system that return the model best describing each vector.
• Data synthesis: Load a set of generative models and a model transition probability matrix into a system that draws vectors from the generative models, following a model activation pattern as described by the transition probability.

Currently, the first flow is implemented, tested and deployed. It is now undergoing testing to showcase the benefits of the PHYSICS approach in terms of handling rapid small requests by merging them into larger ones. The rest of the flows are under initial implementation. Stay tuned for more news on our progress!

The post FaaS-ification in Health Care appeared first on PHYSICS.

Abstract

Serverless environments have attracted significant attention in recent years as a result of their agility in execution as well as inherent scaling capabilities as a cloud-native execution model. While extensive analysis has been performed in various critical performance aspects of these environments, such as cold start times, the aspect of workflow orchestration delays has been neglected. Given that this paradigm has become more mature in recent years and application complexity has started to rise from a few functions to more complex application structures, the issue of delays in orchestrating these functions may become severe. In this work, one of the main open source FaaS platforms, Openwhisk, is utilized in order to measure and investigate its orchestration delays for the main sequence operator of the platform. These are compared to delays included in orchestration of functions through two alternative means, including the execution of orchestrator logic functions in supporting runtimes based on Node-RED. The delays inserted by each different orchestration mode are measured and modeled, while boundary points of selection between each mode are presented, based on the number and expected delay of the functions that constitute the workflow. It is indicative that in certain cases, the orchestration overheads might range from 0.29% to 235% compared to the beneficial computational time needed for the workflow functions. The results can extend simulation and estimation mechanisms with information on the orchestration overheads.

Authors

• George Kousiouris
• Chris Giannakos
• Konstantinos Tserpes
• Teta Stamati

The post Measuring Baseline Overheads in Different Orchestration Mechanisms for Large FaaS Workflows appeared first on PHYSICS.