33 research outputs found
Replication Data for: Efficient Application of Accelerator Cards for the Coupling Library preCICE
No full textThis dataset contains all testcase setup files and result files for the measurements presented in the Master's thesis with the title "Efficient Application of Accelerator Cards for the Coupling Library preCICE" (Author: Timo Pierre Schrader).
Furthermore, it contains the version of preCICE used throughout this thesis.
The thesis revolves around GPU acceleration of RBF data mapping in preCICE. See the README for more information how to build and run the testcase
PENDIDIKAN KARAKTER BERBASIS PESANTREN: STUDI KASUS DI SMP PUNCAK DARUS SALAM PAMEKASAN
Get PDFThis article attempts to examine the implementation of pesantren-based character education with a locus of Junior High School Puncak Darus Salam located in Potoan, Palengaan, Pamekasan, Madura. In his analysis,the author uses a qualitative-phenomenological approach in which the data is based on the model of Miles and Huberman by interpreting the data interactively and continouesly. This research found that the cultivation of character education in SMP Puncak Darus Salam is the implementation of its vision and mission, which is to generate generation with the Qur’an and Sunnah-based special characters. The success of the character education implemented at the school is mainly supported by the integration of the school and pesantren curriculum. This article will elaborate further the character education focusing on three aspects: affective, cognitive, and psychomotor.Keywords: Pendidikan Karakter, Afektif, Kognitif, Psikomotori
Replication data for: Voronoi Cell Interface-Based Parameter Sensitivity Analysis for Labeled Samples
No full textThis dataset contains the data and code for the publication: Voronoi Cell Interface-Based Parameter Sensitivity Analysis for Labeled Samples.
Code Repository
A dynamic version of the code repository can be found at https://github.com/rbnbr/VoroParaSense.
The version presented in this dataset corresponds to the version used in the corresponding paper (referenced as v1.0.0) and does not contain post-publication changes to the repository.
Figures
Some of the figures contained in the Jupyter Notebooks were used to generate the CC BY 4.0 licensed figures in https://doi.org/10.1111/cgf.70122. The figures here are the raw .png figures. The published figures are mostly vector graphics and were slightly modified compared to the figures rendered in the Jupyter notebooks.
Author: Ruben Bauer
Source: https://doi.org/10.1111/cgf.70122
License: CC BY 4.0
The figures of the main paper are:
examples\notebooks\plot_examples\two_d_clipping_and_distribution.ipynb used to generate Figure 2
examples\notebooks\plot_examples\three_dimensional_case.ipynb used to generate Figure 3
examples\notebooks\plot_examples\two_d_clipping_and_distribution.ipynb used to generate Figure 4
examples\notebooks\plot_examples\two_d_major_transition_directions.ipynb used to generate Figure 5
examples\notebooks\single_dataset_convenience_plots\iris_conv_plot.ipynb used to generate Figure 6, 7, 8, 9, 10, 12
examples\notebooks\plot_examples\space_dividing_line.ipynb used to generate Figure 11
examples\notebooks\single_dataset_convenience_plots\semiconductor_conv_plot.ipynb used to generate Figure 14
examples\notebooks\single_dataset_convenience_plots\droplet_impact_conv_plot.ipynb used to generate Figure 15, 16
For the supplemental material:
examples\notebooks\plot_examples\normal_vectors_angle_vis.ipynb used to generate Figure 1
examples\notebooks\plot_examples\plane_plane_distance.ipynb used to generate Figure 2
examples\notebooks\plot_examples\runtime_experiments_2.ipynb used to generate Figure 3, 4
examples\notebooks\plot_examples\bandwidth_experiments.ipynb used to generate Figure 5 - 15
Install
Tested with Python 3.12.3.
Setup virtual environment with Python: python -m venv .venv
Activate the environment, then install the requirements via: pip install -r requirements.txt
Run python ./main.py to run the main example.
</ol
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
PENGEMBANGAN BUKU AJAR KIMIA SMA/MA PADA MATERI TERMOKIMIA UNTUK MENINGKATKAN PEMAHAMAN PESERTA DIDIK
No full textABSTRACT PENGEMBANGAN BUKU AJAR KIMIA SMA/MA PADA MATERI TERMOKIMIA UNTUK MENINGKATKAN PEMAHAMAN PESERTA DIDIKBerdasarkan hasil penelitian terhadap hasil pembelajaran, diperoleh fakta bahwa peserta didik mengalami kesulitan belajar dan miskonsepsi pada materi termokimia. Hal ini dibuktikan dengan hasil penelitian sebelumnya yang menunjukkan bahwa, peserta didik kesulitan tentang kalor, kapasitas kalor, energi ikatan, dan Hukum Hess.Salah satu penyebab kesulitan dan miskonsepsi tersebut adalah bahan ajar. Bahan ajar yang selama ini digunakan hanya berupa susunan definisi dan ringkasan materi yang tidak memperhatikan kesulitan yang dialami peserta didik. Salah satu bahan ajar yang telah dapat mengatasi kesulitan belajar adalah buku ajar. Oleh karena itu, dibutuhkan buku ajar yang dapat mengatasi kesulitan belajar dan miskonsepsi, sehingga dapat membantu meningkatkan pemahaman peserta didik pada materi termokimia. Berdasarkan masalah tersebut, penelitian dan pengembangan ini bertujuan untuk menghasilkan buku ajar pada materi termokimia untuk meningkatkan pemahaman peserta didik dan mengetahui kelayakannya dengan menggunakan validasi isi dan uji keterbacaan.Pada pengembangan buku ajar ini, model pengembangannya mengadaptasi model penelitian dan pengembangan pembelajaran menurut Thiagarajan (1974) dengan modifikasi, namun dibatasi hanya sampai tahap 3 yaitu tahap develop (tahap pengembangan). Data yang diperoleh adalah data kuantitatif dan data kualitatif. Data kuantitatif berdasarkan skor angket yang disusun dalam skala Likert untuk menentukan kelayakan buku ajar. Kelayakan buku ajar dianalisis dengan cara menghitung persentase data kuantitatif. Data kualitatif berdasarkan komentar dan saran perbaikan (revisi) oleh validator ahli yaitu dosen kimia dan guru kimia terhadap buku ajar yang dikembangkan. Buku ajar disempurnakan dengan memperbaiki bagian-bagian yang perlu diperbaiki berdasarkan komentar dan saran para validator serta peserta didik. Hasil validasi buku ajar oleh seorang dosen dan dua guru kimia SMA menunjukkan rata-rata persentase kelayakan sebesar 90% (sangat valid). Hasil uji keterbacaan oleh sepuluh peserta didik menghasilkan persentase kelayakan sebesar 86% (sangat valid). Hasil validasi isi dan uji keterbacaan menunjukkan bahwa buku ajar termokimia sangat layak digunakan sebagai sumber belajar, baik dalam pembelajaran di kelas maupun secara mandiri. Pengembangan buku ajar termokimia untuk meningkatkan pemahaman peserta didik hanya mengadaptasi model 4-D sampai tahap ketiga. Tahap keempat yaitu penyebarluasan (disseminate) belum dilakukan. Oleh karena itu, disarankan untuk melakukan disseminate untuk membuktikan kefektifan buku ajartermokimia untuk meningkatkan pemahaman peserta didik
Second Hankel determinant for the class of analytic functions defined by new differential operator
No full textMa‘had 'Aly and the Challenge of Modernizing Islamic Education in Indonesia
Get PDFThis paper discovers one of the pesantren models in Indonesia that is considered understudied, the University Level of Pesantren (Ma‘had ‘Aly), pesantren which santris are the university students. Particularly, this paper explains the struggle of Pondok Pesantren Darus Sunnah in facing the challenges of modernizing Islamic Education in Indonesia. Over time, the majority of pesantren adopted modernization to meet the demands from the society and to gain broader recognition from the government. However, the Pondok Pesantren Darus Sunnah is one of the pesantrens that delay the modernization. This paper aims at explaining the reasons for the reluctance of Pondok Pesantren Darus Sunnah to respond to the modernization. To answer the above question, this study employs a qualitative approach with auto-ethnography as the main data-collection tool. The author takes the advantage of the author's experience while being a santri and ustadz at the Darus Sunnah Islamic Boarding School with observations as additional data collection methods. In brief, this study suggests that the Pondok Pesantren Darus Sunnah currently rejects modernization because it reduces the authority and traditional identity of the pesantren. Pondok Pesantren Darus Sunnah prefers to keep the traditional pesantren in line with the advice of the charismatic founder of the pesantren. The traditional model of pesantren has been proven to have produced qualified alumni who play significant role both at national and international levels. This paper also proposes degree equivalence as a solution to this issue of modernizing Islamic education institution.Paper ini menjelaskan salah satu model pesantren di Indonesia yang cukup jarang dibahas, Ma‘had ‘Aly, pesantren yang santrinya adalah mahasiswa. Secara khusus paper ini menjelaskan pergulatan Pondok Pesantren Darus Sunnah dalam menghadapi tantangan modernisasi Pendidikan Islam di Indonesia. Sejalan dengan waktu, mayoritas pesantren mengadopsi modernisasi demi memenuhi tuntutan masyarakat dan pengakuan yang lebih luas dari pemerintah. Namun demikian, Pondok Pesantren Darus Sunnah adalah salah satu pesantren yang masih belum bisa menerima tawaran modernisasi pesantren tersebut secara menyeluruh. Paper ini bertujuan untuk menjelaskan alasan keengganan Pondok Pesantren Darus Sunnah dalam merespons modernisasi. Untuk menjawab pertanyaan di atas, penelitian ini menggunakan pendekatan kualitatif dengan metode pengambilan data auto-ethnography. Penulis memanfaatkan pengalaman penulis selama menjadi santri dan pengajar di Pondok Pesantren Darus Sunnah dengan dilengkapi observasi dan wawancara. Secara singkat penelitian ini mengisyaratkan bahwa Pondok Pesantren Darus Sunnah menolak modernisasi dari segi kurikulum karena hal tersebut mereduksi otoritas dan identitas tradisional pesantren. Pondok Pesantren Darus Sunnah lebih memilih untuk menjaga ke-tradisional-an pesantren sesuai dengan dawuh dari pendiri pesantren. Model Pesantren Tradisional yang selama ini dijaga terbukti telah melahirkan alumni yang berkualitas dan memainkan peran yang besar baik di level nasional maupun internasional. Paper ini juga mengajukan penyetaraan ijazah setingkat strata satu sebagai salah satu solusinya
Majorization for certain classes of meromorphic functions associated with a family of integral operator
No full text
