140 research outputs found
Scattering-based super-resolution optical fluctuation imaging
No full textSuper-resolution optical imaging has become a prominent tool in life and material sciences, allowing one to decipher structures at increasingly greater spatial detail. Among the utilized techniques in this field, super-resolution optical fluctuation imaging (SOFI) has proved to be a valuable approach. A major advantage of SOFI is its less restrictive requirements for generating super-resolved images of neighboring nano-structures or molecules, as it only assumes that the detected fluctuating light from neighboring emitters is statistically uncorrelated, but not necessarily separated in time. While most optical super-resolution microscopies depend on signals obtained from fluorescence, they are limited by photobleaching and phototoxicity. An alternative source for optical signals can be acquired by detecting the light scattered from molecules or nanoparticles. However, the application of coherent scattering-based imaging modalities for super-resolution imaging has been considerably limited compared to fluorescence-based modalities. Here, we develop scattering-based super-resolution optical fluctuation imaging (sSOFI), where we utilize the rotation of anisotropic particles as a source of fluctuating optical signals. We discuss the differences in the application of SOFI algorithms for coherent and incoherent imaging modalities and utilize interference microscopy to demonstrate super-resolution imaging of rotating nanoparticle dimers. We present a theoretical analysis of the relevant model systems and discuss the possible effects of cusp artifacts and electrodynamic coupling between nearby nano-scatterers. Finally, we apply sSOFI as a label-free novelty filter that highlights regions with higher activity of biomolecules and demonstrates its use by imaging membrane protrusions of live cells. Overall, the development of optical super-resolution approaches for coherent scattering-based imaging modalities, as described here, could potentially allow for the investigation of biological processes at temporal resolutions and acquisition durations previously inaccessible in fluorescence-based imaging
sj-pdf-1-tag-10.1177_17562848241227037 – Supplemental material for The association between psoriasis, psoriasis severity, and inflammatory bowel disease: a population-based analysis
No full textSupplemental material, sj-pdf-1-tag-10.1177_17562848241227037 for The association between psoriasis, psoriasis severity, and inflammatory bowel disease: a population-based analysis by Uria Shani, Niv Ben-Shabat, Roula Qassem, Adi Lahat, Mahmud Omar, Einat Savin, Arad Dotan, Yonatan Shneor Patt, Lior Fisher, Galia Zacay, Howard Amital, Abdulla Watad and Kassem Sharif in Therapeutic Advances in Gastroenterology</p
Twico Control Engine
No full text
Twico Control Engine
Twico Control Engine
Twico Control is a Flask-based orchestration engine for digital materialisation /
digital twin workflows.
It coordinates virtual actors (software representations) and their paired
physical actors (robots, tools, sensors), executes tasks in a controlled order,
forward information to external services, and optionally synchronises state of the local DB with a
cloud database via REST API.
A web UI is included for managing actors, tasks, jobs, and monitoring execution.
Status: research / prototyping-friendly codebase. Contributions and issues are welcome.
What problem it solves
In a typical digital materialisation process you have:
Tasks to execute (move, read data, fabricate, etc.)
Physical actors that do the work (robots, PLCs, devices)
Virtual actors that encapsulate communication + pre/post-processing
Services that generate tasks or react to task completion
Twico Control acts as the execution core: it keeps a local “authoritative” state,
dispatches tasks to actors, listens for events, and updates external systems.
Key concepts
Actor (Virtual Actor): a Python class that implements a standard interface
(actors/ActorBase.py) and handles: connection, task preparation (preSend), task dispatch,
completion monitoring, and response handling (postSend).
Task: an executable unit that is assigned to a main_actor with extra per-actor
parameters under actors_data.
Engine: a Flask server that runs the UI + API endpoints and coordinates task execution.
RabbitMQ: optional event bus for “task received” / “task complete” style workflows.
Execution model (high level)
The engine runs continuously and coordinates execution across actors:
Ensure all required virtual actors are registered and connected.
For each available actor:
fetch the next task from the local DB (or tasks queue)
call preSend(task) then send the task to the paired physical actor
wait for completion / acknowledgements (depending on your communication pattern)
call postSend(response) and log results
trigger any linked services
In parallel, background listeners can:
ingest new tasks (e.g. via RabbitMQ)
propagate task completion updates to a cloud DB (if REST API is configurated)
Project structure
TWICO_Release/
├── actors/
│ ├── __init__.py
│ ├── ActorBase.py
│ ├── RMQ_setup.py
│ ├── DemoActor/
│ │ ├──__init__.py
│ │ └── DemoActor.py
│ ├── ServiceConnectedActor/
│ │ ├──__init__.py
│ │ └── ServiceConnectedActor.py
│ └── TaskInjectingActor/
│ │ ├──__init__.py
│ └── TaskInjectingActor.py
├── apps/
│ ├── actors/
│ │ ├──__init__.py
│ │ ├── forms.py
│ │ ├── model.py
│ │ ├── routes.py
│ │ └── services.py
│ ├── authentication/
│ │ ├──__init__.py
│ │ ├── forms.py
│ │ ├── model.py
│ │ ├── routes.py
│ │ └── services.py
│ ├── home/
│ │ ├──__init__.py
│ │ ├── forms.py
│ │ ├── routes.py
│ │ └── services.py
│ ├── Logger/
│ │ ├──__init__.py
│ │ ├── logs/
│ │ ├── Logger.py
│ ├── RabbitMQ/
│ │ ├──__init__.py
│ │ └── listener.py
│ ├── run/
│ │ ├──__init__.py
│ │ ├── routes.py
│ │ └── services.py
│ ├── static/
│ │ └── assets/
│ ├── tasks/
│ │ ├──__init__.py
│ │ ├── forms.py
│ │ ├── model.py
│ │ ├── routes.py
│ │ └── services.py
│ ├── templates/
│ │ ├── actors/
│ │ ├── auth/
│ │ ├── dashboard/
│ │ ├── includes/
│ │ ├── layouts/
│ │ ├── run/
│ │ └── tasks/
│ ├── .env.example
│ ├── __init__.py
│ └── config.py
├── Examples/
│ ├── Basic/
│ │ ├── basic_tasks.py
│ ├── Parallel_actors/
│ │ ├── parallel_actors_tasks.py
│ ├── Self_injecting_actor/
│ │ ├── self_injecting_actor_tasks.py
│ ├── Task_injecting_service/
│ │ ├── task_injecting_service.py
│ │ ├── task_injecting_service_tasks.py
│ └── tasks_builder.py
├── .gitignore
├── CHANGELOG.md
├── CONTRIBUTING.md
├── docker-compose.yml
├── LICENSE
├── README.md
├── requirements.txt
└── run.py
Notable folders
actors/ — Virtual actor implementations (your integration layer)
ActorBase.py defines the interface for all actors
DemoActor/ provides an example actor
apps/ — Flask application code (blueprints, models, services)
apps/authentication/ login + license gating
apps/tasks/ task models, services, and UI routes
apps/actors/ actor registration/management in the UI
apps/RabbitMQ/ RabbitMQ listener
apps/Logger/ logging utilities
apps/templates/ HTML templates for the UI
apps/static/backups folder that save current state of tasks in the DB after execution or when
clearing tasks from DB.
Examples/ — example scripts and task JSON
Requirements
Python 3.10+
A virtualenv or conda environment (recommended)
Optional but recommended:
RabbitMQ server (local, Docker, or remote)
A REST API backend for cloud synchronisation (if you use that workflow)
Quick start (local)
1) Create and activate an environment
Using conda:
conda create -n Twico python=3.10
conda activate Twico
Or with venv:
python -m venv .venv
# Windows
.venv\Scripts\activate
2) Install dependencies
pip install -r requirements.txt
3) Configure environment variables
Create a .env in the project root (do not commit it) based on
.env.example.
AUTHOR_NAME=Your Name
APP_VERSION=0.1.0
SERVER_NAME=127.0.0.1:5000
SECRET_KEY=change-me
API_URL=
ASSETS_ROOT=/static/assets
DB_ENGINE=sqlite
DB_NAME=db.sqlite3
RABBIT_MQ_HOST=localhost
RABBIT_MQ_PORT=5672
RABBIT_MQ_USER=guest
RABBIT_MQ_PASS=guest
RABBIT_MQ_VH=/
4) Run
python run.py
Open the UI at:
http://127.0.0.1:5000
Working with tasks
Tasks can be loaded from:
the cloud REST API (if configured)
a local JSON file (see Examples folder)
A task have the following structure:
{
"name": "A_temp_0",
"type": "Move",
"main_actor": "DemoActor_A",
"description": "",
"message": "Moving DemoActor to position",
"job": 1,
"level": 1,
"index": 0,
"element_id": [],
"actors_data": {
"DemoActor_A": {
"X": 1,
"Y": 2,
"Z": 3,
"Speed": 0.2
}
}
}
where the actors_data feild can contain any key-value pair.
Adding a new actor
Create a new folder under actors/ (e.g. actors/MyRobotActor/)
Implement the interface in ActorBase (connect, send, monitor, etc.)
Make sure the file name and the class name are the same as the folder name.
Ensure the actor is importable (package with __init__.py)
Register/configure it via the UI (apps/actors/) or your project-specific bootstrap code
RabbitMQ (optional)
If you use RabbitMQ, you can run a local instance with Docker:
docker compose up -d rabbitmq
See docker-compose.yml in this repo for a ready-to-use configuration.
Documentation
This repository is compatible with Sphinx autodoc (docstrings → HTML docs).
If you add a docs/ folder, you can build API docs automatically.
Docs for the folder can be found in apps/static/docs or under the docs in the UI navigation sidebar.
Author / Maintainers
Lior Skoury (original author)
</html
Digital-Twin Data for Large-Scale 3D Printing
No full text
MTRL_DATASET - Material Analysis Tools
body {
font-family: Arial, sans-serif;
line-height: 1.6;
padding: 20px;
}
pre {
background-color: #f4f4f4;
padding: 10px;
overflow-x: auto;
}
code {
font-family: Consolas, monospace;
}
table {
border-collapse: collapse;
width: 100%;
margin-bottom: 20px;
}
table, th, td {
border: 1px solid #ccc;
}
th, td {
padding: 8px;
text-align: left;
}
h1, h2, h3, h4 {
margin-top: 1.2em;
}
Overview
This project contains a dataset from research on a data-informed digital twin for large-scale 3D printing. The data was collected through a series of experiments using two machines: (i) a Kuka KR50R2500 industrial robot and (ii) a MAI® MULTIMIX-3D mortar mixing pump. Additionally, measurements of the printed object's width were recorded during the experiments.
The dataset has been used to explore correlations between machine performance, material behavior, and the final printed structure. The accompanying codebase enables replication of the study’s results, offering tools for data processing, clustering, visualization, and the analysis of various material properties and printing parameters.
The experiments in this study were conducted in two phases:
Correlation Analysis: The first phase focused on exploring the relationships between machine performance, material behavior, and the resulting printed object. Data from these experiments was then used to develop a clustering-based prediction model and a set of feedback control services to automate the operation of the Kuka robot and the mortar mixing pump.
Evaluation of Feedback Control: In the second phase, the feedback control services were implemented in a new set of experiments to assess their effectiveness in optimizing the 3D printing process.
Project Structure
MTRL_DATASET/
│
├── Data/
│ ├── Block_Tests/
│ │ ├── BlockTasks.json - Tasks data for block (evaluation ) tests
│ │ └── BlockMeasurements.json - Width measurements for different block types
│ │
│ └── Mixture_Experiments/
│ ├── PumpResponse_Clean.json - Clean pump response data for mixture experiments (used for clustering)
│ ├── PumpTasks.json - Task data for pump operations
│ └── WidthCorrelationTests.json - Data for width correlation tests
│
├── Clusters/ - Directory for saved ML models
│ ├── kmeans.pkl - Trained KMeans model
│ └── scaler.pkl - Fitted StandardScaler
|
├── Figs/ -Directory of all plots from the code
|
├── Blocks.py - Block data analysis and visualization
├── BlockMeasurements.py - Analysis of block measurement data
├── Clusters.py - Machine learning clustering of pump data
├── PumpData.py - Pump data analysis utilities
├── WidthCorrelations.py - Analysis of correlations between printed object width, Kuka robot velocity and pump reqeuncy
└── README.md - This file
Data Description
01_Mixture Experiments Data
The experiments in this section were done with 4 types of mixtures as follows:
Mix
Clay (kg)
Sand (kg)
Water (kg)
Flow Table (mm)
Density (g/L)
M1
5.00
7.50
3.00
169
2080
M2
5.00
7.50
2.75
163
2100
M3
5.00
7.50
2.50
147
2140
M4
5.00
7.50
2.25
127
2196
PumpResponse_Clean.json
Contains cleaned pump response data including:
Pump output power and current measurements
Mortar temperature readings
Pump pressure readings
Temporal data for pump operations
PumpTasks.json
Contains task information related to pump operations:
Task details for mixture experiments
Timing information for pump actions
Operational parameters and settings
WidthCorrelationTests.json
Contains test data for analyzing correlations between:
Width measurements
Pump frequency
Robot velocity
02_Block Tests Data
The experiments in this section were conducted on 3 block types with the following features:
Block
Velocity (m/s)
Frequency (Hz)
B1
0.11
17
B2
Adaptive
17
B3
0.11
Adaptive
BlockMeasurements.json
Contains width measurements (in mm) for three different blocks. This data is used for comparing width consistency across different block printing strategies.
BlockTasks.json
Contains detailed task data from the pump and the robot for block printing processes, including:
Task IDs and names
Task types (ReadData, Read, SetValue)
Actors (KukaPassiveRead, MaiPrinter)
Timestamps for start and end times
Job identification (e.g., "BLOCK1")
Processing levels and indices
The file contains over 2300 task entries.
03_Features
Within both the BlockTasks.json and PumpTask.json files, every data point adheres to a standardized Task Data Schema that includes the following fields:
_id: A unique identifier for this record.
task_id: A unique identifier for the specific task or operation.
name: The name assigned to the task or process.
type: The category or type of operation (e.g., a data reading action).
main_actor: The primary machine or module responsible for carrying out the task.
description: A brief textual description of the task.
message: A log message or status note associated with the operation.
element_id: A list of identifiers for related design elements (if any).
actors_data: Contains information for the actors involved in the task (nested details are omitted).
job: The job or process identifier associated with this record.
level: The hierarchical level or depth in a process, indicating its relative position.
index: A numerical order or position indicator for the task.
start_time: The timestamp marking the start of the task or operation.
end_time: The timestamp marking when the task was completed.
response: Contains the outcome or data returned by the task (nested details are omitted).
versions: Version control or metadata information regarding this record.
project: The identifier for the project to which this record belongs.
author: The user or entity that created or is responsible for this record.
04_Scripts
PumpData.py
Analyzing and visualising pump tasks data for the 4 mixtures.
WidthCorrelations.py
Analyzes and visualises correlations between width measurements, robot velocity, and pump frequency.
Clusters.py
Implements machine learning clustering on pump data and visualises the results.
Blocks.py
Analyzes task data for different block types, calculates timing metrics, and visualises the results.
BlockMeasurements.py
Analyzes and visualises block width measurement data.
05_Usage
Dependencies
This project requires the following Python packages:
pandas
numpy
matplotlib
scikit-learn
joblib
Install dependencies with:
pip install pandas numpy matplotlib scikit-learn joblib
Run the code
To generate the full analysis and plots from the dataset, simply execute the main.py file. Open your terminal, navigate to the code directory, and run:
cd path/to/your/code/directory
python main.py
For a more detailed overview of available parameters, run each of the individual Python files separately.
</html
Errol Morris y los misterios de la fotografía
No full textLa relación entre fotografía y memoria suele establecerse como una relación natural. Sin embargo, al profundizar en el análisis de dicha relación surgen diferentes problemáticas. El propósito del artículo reside en estudiar algunas de éstas a partir de las observaciones sobre la fotografía del documentalista Errol Morris. Tomaremos como ejemplo algunos de los casos analizados por dicho autor -la guerra de Crimea y la última invasión estadounidense en Irak. Si la fotografía actúa como memoria visual, como memoria de la guerra, veremos cómo surgen ciertas complicaciones al momento de tomar a las fotografías como huellas de los conflictos, al analizar las intenciones del fotógrafo o las ambigüedades que florecen al estudiar la circulación de las imágenes.The relationship between photography and memory is usually set up as a natural relationship. However, various problems arise when we analyze this relationship. The purpose of the article lies in studying some of these problems from the observations on photography by the filmmaker Errol Morris. We will take as an example some of the cases analyzed by the author —the war of Crimea and the last American invasion in Iraq—. If the picture acts as visual memory, as the memory of the war, we will see how certain complications arise when taking pictures as traces of conflicts, when we try to analyze the intentions of the photographer or the ambiguities that emerge to study the circulation of images.Fil: Zylberman, Lior Alejandro. Consejo Nacional de Investigaciones Científicas y Técnicas; Argentina. Universidad de Buenos Aires. Facultad de Ciencias Sociales; Argentina. Universidad Nacional de Tres de Febrero. Centro de Estudios sobre Genocidio; Argentin
Photometric study of a marginal contact binary SY Hor
No full text32nd International Physics Congress of Turkish-Physical-Society (TPS) -- SEP 06-09, 2016 -- Bodrum, TURKEYIn this study, we present light curve analysis of a southern contact binary SY lior. Photometric parameters of the system and its components are derived using the Wilson and Devinney code based on the data taken from the SuperWASP public data archive. Photometric solutions indicate that SY Hai is a marginal contact binary system with a mass ratio of q = 1.59 and a contact degree of f = 6%.Turkish Phys So
Adaptive Trust Region Policy Optimization: Global Convergence and Faster Rates for Regularized MDPs
No full textTrust region policy optimization (TRPO) is a popular and empirically successful policy search algorithm in Reinforcement Learning (RL) in which a surrogate problem, that restricts consecutive policies to be ‘close’ to one another, is iteratively solved. Nevertheless, TRPO has been considered a heuristic algorithm inspired by Conservative Policy Iteration (CPI). We show that the adaptive scaling mechanism used in TRPO is in fact the natural “RL version” of traditional trust-region methods from convex analysis. We first analyze TRPO in the planning setting, in which we have access to the model and the entire state space. Then, we consider sample-based TRPO and establish Õ(1/√N) convergence rate to the global optimum. Importantly, the adaptive scaling mechanism allows us to analyze TRPO in regularized MDPs for which we prove fast rates of Õ(1/N), much like results in convex optimization. This is the first result in RL of better rates when regularizing the instantaneous cost or reward
- …
