Our Work

Paper-polymer composites (PPCs) are increasingly applied as sustainable ion-conducting membranes in modern energy storage systems. Their recycling, circularity, and optimization, however, require a mo…

Paper-polymer composites (PPCs) are increasingly applied as sustainable ion-conducting membranes in modern energy storage systems. Their recycling, circularity, and optimization, however, require a more detailed understanding of local structures and dynamics at a molecular level influencing macroscopic properties such as stability and ion conduction. Solid-state nuclear magnetic resonance (ssNMR) spectroscopy has evolved into a powerful tool for studying paper and cellulosic materials, but its application to PPCs, particularly in membrane technology, is still limited. This study demonstrates the power of ssNMR spectroscopy combined with dynamic nuclear polarization (DNP) to investigate dynamics and interactions via selective signal enhancement in PPCs featuring ionic conductivity. The results reveal changes in molecular mobility after polymerization, allowing for distinguishing overlapping components with different mobilities.

Huzzah! v0.14.0 is finally here! :tada: Almost two years since v0.13.2, and eight betas later. This is a big one: faster, steadier, a new desktop app, and an Android app that has caught up. And syncin…

Huzzah! v0.14.0 is finally here! :tada: Almost two years since v0.13.2, and eight betas later. This is a big one: faster, steadier, a new desktop app, and an Android app that has caught up. And syncing between your devices works, local-first, with whatever sync tool you already use: it's still early and opt-in, with a few rough edges (see Sync below, or the announcement). More than 30 people contributed. Since the last stable release, ActivityWatch also passed 1 million downloads, and it's now downloaded over 10,000 times a week. Thank you! Read more: the announcement · the full changelog (about 1,000 changes, too long for this page) Summary ⚡ Much faster, especially once you have years of data: dashboards load day by day and cache finished days, so long ranges no longer time out and repeat visits are near instant 🐛 Steadier all round: crashed watchers restart on their own, a macOS memory leak and crash are fixed, and a long tail of annoyances is gone 🔄 Sync between your devices works. It is local-first: no ActivityWatch server, no account. Point it at a folder you already sync with Syncthing, Dropbox or anything else, and each device's data shows up on the others. It is still rough in places (it takes more disk space than it should, and setup is manual), so it is opt-in (how to set it up) 👀 See all your devices together: the Activity view can now merge any set of devices into one view 📱 Android caught up: ActivityWatch for Android 0.14 shipped last month, its first stable release since 2023, with far fewer crashes and the same sync built in 🖥️ A new desktop app built on Tauri: same features as the classic one and lighter, but less battle-tested so far, so the classic app ships too and stays the default 🌐 A refreshed web UI: a better timeline, custom date ranges, a work-time report, billable hours export, and category sets for switching between rule profiles 🌍 ActivityWatch now speaks Swedish, German, Ukrainian, Russian and Chinese 🔒 More control over what gets stored: filter sensitive window titles before they ever reach the database 🛡️ For those who want it: put an API key on the server 🍎 macOS: signed and notarized builds for Apple Silicon and Intel, and browser URLs are tracked properly again 🐧 Linux: Wayland support out of the box in the new app, and arm64 builds 🤖 For the AI crowd: one canonical query that returns clean, categorized events, so an assistant can answer questions about your time without a custom integration (agents and AI) And a lot more... Honorable mentions Many of this release's features came from the community. Thank you: @0xbrayo for aw-tauri, from prototype to a release-ready app, and for aw-notify-rs and the Rust side of Android sync @BohdanRykush for the Ukrainian, German and Russian translations, and the original i18n setup and language picker (ActivityWatch/aw-webui#855) @JhihJian for the Simplified Chinese translation (ActivityWatch/aw-webui#865) @NickWick13 for the Swedish translation (ActivityWatch/aw-webui#947) @BelKed for rewriting the browser extension for Manifest V3 (ActivityWatch/aw-watcher-web#152), plus theme detection and top browser titles in the web UI @2e3s for awatcher, which gives the new app native Wayland support @nerumo for timeline swimlanes and the duration filter (ActivityWatch/aw-webui#679) @rrogerc for capturing URLs from Firefox-based browsers on macOS (ActivityWatch/aw-watcher-window#134) @hawai-i for the macOS Apple Events entitlement, which brought native browser URL capture back (#1411) @FractalMachinist for browser tracking on Android (ActivityWatch/aw-android#151) @Lorite for fixes to Android's folder-picker sync (ActivityWatch/aw-android#221, ActivityWatch/aw-android#222) @wind-mask for the Tauri app's headless --daemon and --mini modes @Q-Ze for fixing the multi-device view with synced data (ActivityWatch/aw-webui#969) @RTnhN for the universal columns visualization (ActivityWatch/aw-webui#733) @behdadmansouri for clearer import feedback (ActivityWatch/aw-webui#874) @fanxing11 for a string of fixes across the watchers, client and notifications Installation See the getting started guide in the documentation. Downloads Classic distribution Windows (.exe installer) macOS: Intel | Apple Silicon (.dmg) Linux: .zip | .AppImage | .deb Tauri distribution (experimental — native Wayland support on Linux) Windows (.exe installer) macOS: Intel | Apple Silicon (.dmg) Linux: .AppImage | .zip Contributors Thanks to everyone who contributed to this release: @0xbrayo, @2e3s, @almirb, @amsam0, @BelKed, @deancureton, @erikbjare, @fanxing11, @Game4Move78, @hawai-i, @HomeArchbishop, @istudyatuni, @kenoma-hld, @luisgerhorst, @matt-seb-ho, @MBK-fr, @moodyhunter, @musicinmybrain, @nerumo, @NickWick13, @Noorts, @petrroll, @powellnorma, @Q-Ze, @reddaisyy, @rrogerc, @RTnhN, @Senophyx, @TiberiusNemesis, @TimeToBuildBob, @vdonich, @yuhldr More detail Faster Measured on a real 9-year database (9.2 million events, 1.8 GB) on an M2 Mac, with each version's own dashboard queries. The new dashboard asks for long ranges one day at a time, so the servers are compared on that same workload: | Year view, 365 daily queries | v0.13.2 | v0.14 first load | v0.14 repeat load | |---|---:|---:|---:| | Classic app (Python server) | 120 s | 41 s | 0.6 s | | Tauri app (Rust server) | 139 s | 32 s | 0.2 s | The v0.13.2 dashboard fetched a Year as a single request instead. That took 120 s on the Python server (past the default 30 s timeout, so it failed) and 19 s on the Rust server. Asking day by day is what makes caching, progress and per-day charts possible. All time across nine years reopens in 5 s on the classic app; the Tauri app doesn't cache All time yet (aw-server-rust#784). Under the hood: new database indexes, SQLite WAL mode, cached category rules (categorizing a year of window titles went from 53 s to 10 s) and streaming exports. Sync aw-sync copies each device's data into a sync folder (~/ActivityWatchSync by default). You choose how that folder moves between devices: Syncthing, Dropbox, a network drive, anything that syncs files. Your data never touches a server of ours. Each device only writes its own files and opens everyone else's read-only, so devices can't corrupt each other, and synced data shows up as -synced-from- buckets that you can query, merge in the Activity view, or ignore. This cycle we ran it on our own desktops and phones and fixed what we hit: duplicate events after a resume, one broken device aborting a whole sync, phone data not being picked up, and a new aw-sync status that tells you what each device has synced. Known rough edges: every device keeps a full copy of every other device's data, so it uses more disk than it should (a much more compact format is in the works), settings and deletions don't sync, and setup is manual. It isn't started by default: turn it on in the app's modules menu, or run aw-sync. Android ActivityWatch for Android 0.14 (v0.14.0 to v0.14.2, September) is the first stable Android release since 2023. User-perceived crashes went from about 7.8% to under 1%. It adds alerts, a home-screen widget, Firefox and Chrome tracking, CSV and JSON export, and the same sync: pick a folder, and your phone's data shows up on your desktop. More reliable Crashed watchers restart automatically, with crash logs, in both apps; only one instance runs at a time macOS window watcher: fixed a crash on unusual window titles and a leak of up to ~359 MB of memory per day on busy machines AFK: locking the screen counts as AFK on macOS, held keys count once, gamepads count on Linux, recovery after an X server restart, and a Windows idle-time overflow after 49.7 days is fixed Data safety: heartbeats are rejected cleanly under load instead of risking corruption, a damaged database recovers on startup, and imports merge into existing buckets instead of failing The Python and Rust servers now return the same query results, checked by a new parity test suite (server comparison) The new app (Tauri) aw-tauri ships alongside the classic aw-qt app for Windows, macOS (Apple Silicon and Intel) and Linux (x86_64 and arm64). It has its own window, runs the Rust server inside the app, is smaller to download, supports Wayland on Linux, and updates itself on macOS and Linux (on Windows, install new versions manually for now). The story: A lighter, faster ActivityWatch with Tauri. Also new Web UI: timeline swimlanes and AFK/category/duration filters, "merge by app", keyboard and scroll panning, rule priority and field-scoped regex rules, top browser titles, top stopwatch events, CSV export that streams large buckets, and bulk delete of a device's buckets Browsers: Arc, Dia, Zen, Helium, Floorp, Firefox ESR and more Chromium variants; URLs from Firefox-based browsers on macOS Notifications rewritten in Rust (aw-notify-rs), with a settings panel. They are now off until you enable them Start at login is a toggle in the app iOS: Screen Time data imported with aw-import-screentime shows up correctly Upgrade notes The first start after upgrading updates the database indexes once. Your data isn't changed. On large databases this takes a while (about 30 s for the classic app and a minute for the Tauri app on a 1.8 GB database), and the dashboard may not connect until it's done. Leave ActivityWatch running and reload. Notifications (aw-notify) are now opt-in. Enable them in Settings if you used them before. macOS 12 or newer is required. Supporting ActivityWatch ActivityWatch has no ads, no venture funding and no data business. It is maintained by a tiny team, and ActivityWatch Pro, our patronage subscription, keeps releases like this coming. From $5/month, and it doesn't unlock anything: nothing is locked. Prefer a one-time contribution? See Donate, or sponsor us on GitHub. Full changelog About 1,000 changes across 13 repositories, too long for this page: see the v0.14.0 changelog in the documentation, or compare v0.13.2...v0.14.0. Announcement: ActivityWatch v0.14.0: faster, steadier, synced, and a new app

Catalogue of seismicity of the aftershock sequence of the M7.1 2003 Miyagi earthquake, completed using Template matching from the original JMA catalogue. Associated paper : Costes, L., Gardonio, B., M…

Catalogue of seismicity of the aftershock sequence of the M7.1 2003 Miyagi earthquake, completed using Template matching from the original JMA catalogue. Associated paper : Costes, L., Gardonio, B., Marsan, D. (2026, JGR). Measuring the strength of an intraslab fault (I): seismicity-based estimates for the 2003 M7.1 Miyagi sequence. See README.md for details.

Overview Please visit Github for the latest version and the compiled binaries! Gatekeeper is a lightweight, resource-efficient daemon written in Rust designed to curb unregulated bot traffic. It …

Overview Please visit Github for the latest version and the compiled binaries! Gatekeeper is a lightweight, resource-efficient daemon written in Rust designed to curb unregulated bot traffic. It is engineered to operate seamlessly alongside NGINX in Linux environments, running locally on the reverse proxy server. Communication between NGINX and Gatekeeper is handled via a high-performance Unix Domain Socket. Gatekeeper is not a full security suite. Its sole objective is to neutralize low-cost scraping, shielding downstream application servers and databases from resource exhaustion. Specifications Licence Apache 2.0 Tech Stack Rust (Axum, Tokio), Python for helper scripts Integration systemd service unit Binary Size ~4.1 MB (optimized release build) Memory Footprint ~5 MB RAM NGINX Connection auth_request over Unix Domain Socket Mechanism Client connection fingerprint stored in a cryptographic HMAC cookie Data Management Stateless in-memory operation (no database required) Metrics Lock-free atomic counters (AtomicU64), asynchronous retrieval via helper script, intranet dashboard Privacy Compliance 100% GDPR / TDDDG compliant (privacy-by-design) SEO Compatibility Automated IP/CIDR whitelisting for Google, Bing, and DuckDuckGo On-Failure Mode Fail-open (ensures zero downtime for backend services) Architecture & Request Flow Unlike traditional Web Application Firewalls (such as Cloudflare or Anubis-Techaro), Gatekeeper does not attempt to categorize every visitor as "human or bot" through intrusive CAPTCHAs or behavioral heuristics. Instead, Gatekeeper operates on cryptographic connection fingerprinting. From stable request headers and the TLS handshake, Gatekeeper constructs an individual, signed HMAC cookie (gk_verified_user). Traditional, low-cost stateless scrapers cannot acquire this cookie because they do not execute JavaScript or manage persistent cookie jars. Conversely, cookies harvested by expensive headless browser instances cannot be transferred to cheaper scraping networks because the network and TLS fingerprints between the two setups differ. If this mitigation alone is insufficient, server administrators can enforce rate limiting directly on the Gatekeeper cookie within NGINX, completely eliminating the advantage of rotating residential proxy IPs.   SEO-Friendly: Search engine crawlers that publish verified IP ranges (Googlebot, Bingbot, DuckDuckBot) are explicitly whitelisted and bypass verification. Nonetheless, we recommend applying Gatekeeper specifically to locations typically excluded in `robots.txt` or to resources that cannot be effectively cached (e.g., faceted searches and complex database aggregations) to maintain maximum accessibility. 100% GDPR-Compliant: The verification cookie is fully anonymized, serves a legitimate interest, and is set only after affirmative action by the user (§ 25 (2) No. 2 TDDDG / Art. 6 (1) (f) GDPR). Gatekeeper does not retain persistent request logs; it records only aggregate, anonymous access counters per domain. Is Gatekeeper Right for My Use Case? The answer depends on your available resources and the level of protection you need. Gatekeeper is primarily designed for smaller infrastructure where aggressive bot traffic is not just an annoyance, but a critical threat to server uptime—yet established solutions like Cloudflare or Anubis are not an option (whether due to cost, privacy compliance, or infrastructure constraints). This scenario is typical across the GLAM sector (Galleries, Libraries, Archives, Museums) and the digital humanities. To deploy Gatekeeper, root/admin access to the reverse proxy server (or its container) is required. The protected resources should inherently be public open-access data: Gatekeeper does not secure confidential assets; its sole purpose is to preserve infrastructure performance by shedding unmanaged, low-cost bot requests. Gatekeeper is not suitable for websites that explicitly want or need to be indexed by unknown or long-tail crawlers, nor is it a replacement for API key management. Even though major search engines (Google, Bing, DuckDuckGo) are whitelisted, presence in smaller search indices and accessibility for third-party aggregators may be reduced. As a general rule, Gatekeeper should only protect endpoints where application- or server-level caching cannot be reasonably implemented. Background & Philosophy Rising automated bot traffic has been a known challenge for academic infrastructure. Historically, we managed traffic spikes at the Berlin-Brandenburg Academy of Sciences and Humanities (BBAW) with standard tools. Since late 2025, however, bot volumes have escalated dramatically. Academic infrastructure is fundamentally not provisioned for the extreme request volumes we now observe. We evaluated existing solutions like Anubis, but integrating them into our existing NGINX topology would have introduced significant configuration complexity and a new potential bottleneck by routing all production traffic through container networks. Our resources are Open Access: we want humans, search engine crawlers, and AI agents to access our public scholarly data freely. What we cannot support are aggressive gray-market data harvesters that ignore robots.txt and disregard rate limits. These operators trigger millions of automated requests using spoofed User-Agents across residential proxy networks—rendering traditional IP- or User-Agent-based blocking ineffective.   Gatekeeper was built out of pure pragmatism to achieve maximum protective impact with minimal operational overhead. We have run Gatekeeper in continuous production since mid-2026. Across the first 100 days on two production domains, it successfully deflected over 150 million bot requests. Gatekeeper is not designed to be an impenetrable fortress, nor does it need to be. The scraper economy relies on marginal costs near zero. Scrapers will not rewrite custom scraping infrastructure for academic repositories, and headless browser pipelines remain constrained by their steep compute costs. AI Disclosure Gatekeeper was developed with AI assistance (Gemini in Google Antigravity). Human prompts, design decisions, and architectural iterations are documented in /docs/intents. Portions of the documentation were initially drafted in German and subsequently translated, or developed collaboratively with AI tooling. DISCLAIMER OF WARRANTIES AND LIMITATION OF LIABILITY THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.

Release Notes: Collects all breaking changes for Event-Generator version 2. Larger changes include: Bugfix for time window exclusions More specific version control of models Shift cascade vertex now …

Release Notes: Collects all breaking changes for Event-Generator version 2. Larger changes include: Bugfix for time window exclusions More specific version control of models Shift cascade vertex now part of the model itself Added option to compute DOM angular acceptance as input parameter Overall restructuring of code Mixture models of arbitrary components for time PDF and mixture of Poisson/Neg. Binomial for charge PDF via LatentToPDF Support for Gamma functions as part of the time PDF MPE likelihood added Addition of inf Track Sources and track/cascade Multi-Sources Stabilization of model training and numerical issues Cleanup of v1 configs Commits and PRs Bug fix/time window exclusions by @mhuen in https://github.com/icecube/event-generator/pull/8 Add version check when loading component by @mhuen in https://github.com/icecube/event-generator/pull/24 Move shift cascade vertex by @mhuen in https://github.com/icecube/event-generator/pull/25 Dom angular acceptance by @mhuen in https://github.com/icecube/event-generator/pull/27 Dom angular acceptance by @mhuen in https://github.com/icecube/event-generator/pull/28 Snow storm labels by @mhuen in https://github.com/icecube/event-generator/pull/30 Merge back branches: LatentToPDF, MPE, Track Sources/Multi-Sources by @mhuen in https://github.com/icecube/event-generator/pull/42 Optional data trafo by @mhuen in https://github.com/icecube/event-generator/pull/44 Collect breaking changes for v2 by @mhuen in https://github.com/icecube/event-generator/pull/43 Full Changelog: https://github.com/icecube/event-generator/compare/v1.0.4...v2.0.1

The DESYSubmitter can now do manual submission (see this). Also revamped the documentation.

Release Notes This is a major release that changes the internal structure of dnn-reco from usage of tf.compat.v1 symbols to native tensorflow 2. This required a major restructuring of the code. Any mo…

Release Notes This is a major release that changes the internal structure of dnn-reco from usage of tf.compat.v1 symbols to native tensorflow 2. This required a major restructuring of the code. Any models created prior to this version will be incompatible. Some of the larger changes are listed below. Notes on how to port old configuration files for model training to dnn-reco v2.0.1 are provided below. Major changes and added functionality: Removal of tf.compat.v1 symbols Class-based NN architecture via tf.Module Added support for automatic data_settings extraction for training data generated with the processing framework ic3-processing Updated documentation and tutorial to reflect these changes and shift to ic3-processing Save/load of complete state including optimizer is now supported during training. In version 1, the optimizer state nor the global training step counter were saved Added version check for restoring models: requires major version number to match, warning if different version but compatible Modules defined in configuration file (labels, misc, filter, weighting, loss, model architecture) are now defined via a full import string instead of requiring these to be part of dnn-reco itself. This now allows for more flexible usage of dnn-reco as individual components can now easily be used from external python packages. Porting v1 configs to v2 As much of the underlying code has changed, some necessary changes to the configuration file format and keys were applied. Some examples for v2 configs are provided in the configs directory. A list of necessary updates are listed below Change to full class/function import string: 'model_file' : 'general_IC86_models' 'model_name' : 'general_model_IC86_opt4' --> model_class: 'dnn_reco.modules.models.general_IC86_cnn.GeneralIC86CNN' 'data_handler_label_file': 'default_labels' 'data_handler_label_name': 'simple_label_loader' --> data_handler_label_class: dnn_reco.modules.data.labels.default_labels.simple_label_loader 'data_handler_misc_file': 'default_misc' 'data_handler_misc_name': 'general_misc_loader' --> data_handler_misc_class: dnn_reco.modules.data.misc.default_misc.general_misc_loader 'data_handler_filter_file': 'default_filter' 'data_handler_filter_name': 'general_filter' --> data_handler_filter_class: dnn_reco.modules.data.filter.default_filter.general_filter 'event_weight_file': 'event_weights' 'event_weight_name': 'clipped_astroness_weights --> event_weight_class: dnn_reco.modules.data.event_weights.event_weights.clipped_astroness_weights 'evaluation_file': default_evaluation 'evaluation_name': eval_direction --> evaluation_class: dnn_reco.modules.evaluation.default_evaluation.eval_direction 'loss_file': 'default_loss', 'loss_name': 'mse_and_cross_entropy', --> 'loss_class': 'dnn_reco.modules.loss.default_loss.mse_and_cross_entropy', 'loss_file': 'default_loss', 'loss_name': 'gaussian_likelihood', --> 'loss_class': 'dnn_reco.modules.loss.default_loss.gaussian_likelihood', 'model_checkpoint_path' : "../checkpoints/nn_model/\ {model_file}__\ {model_name}/\ {unique_name}/model" --> 'model_checkpoint_path' : "../checkpoints/nn_model/{unique_name}/model" 'log_path' : "../logs/\ {unique_name}/\ {model_file}__\ {model_name}" --> 'log_path' : "../logs/{unique_name}" Changes for optimizer settings The keys clip_gradients_value and remove_nan_gradients are now explicitly required to be defined in the model_optimizer_dict. Previously their definition in the configuration file was optional. Changes to checkpoint creation A tf.train.CheckpointManager object is now used to write checkpoints. The manager is configured with the defined keyword arguments in the required key model_checkpoint_manager_kwargs. Example to retain the latest 3 checkpoints: 'model_checkpoint_manager_kwargs': { 'max_to_keep': 3, } NN architecture settings All settings for the NN architecture must now be in a separate dictionary of the name model_kwargs. These were typically all keys defined below the # NN Model Architecture header in the standard configuration files. Some name changes include: conv_upper_DeepCore_settings -> conv_upper_deepcore_settings conv_lower_DeepCore_settings -> conv_lower_deepcore_settings conv_IC78_settings -> conv_ic78_settings Additional model settings that were previously defined elsewhere: tf_random_seed is now defined in model_kwargs under the key random_seed Previously there was a general_model_IC86 and general_model_IC86_opt4 model. These are now a single model and one can choose the same functionality by setting the add_prediction_to_unc_input key (True for old general_model_IC86, False for old general_model_IC86_opt4) model gets its own dtype key to specify the float precision keep_probability_list was changed to individual keys added to the model_kwargs (see below) The setting for the convolution layers must now define the convolution type via the method_list key. Additionally the keep rates for dropout layers must now be provided explicitly in addition to random_seed, is_training and dtype. An example: model_class: 'dnn_reco.modules.models.general_IC86_cnn.GeneralIC86CNN' model_kwargs: { is_training : True, random_seed: 42, dtype: 'float32', enforce_direction_norm: False, add_prediction_to_unc_input: False, keep_prob_dom: 0.95, keep_prob_conv: 1.0, keep_prob_flat: 1.0, keep_prob_fc: 1.0, # 2D convolutional layer of upper DeepCore conv_upper_deepcore_settings: { ... 'method_list': 'convolution', }, # 2D convolutional layer of lower DeepCore conv_lower_deepcore_settings: { ... 'method_list': 'convolution', }, # 3D hexagonal convolution over main IceCube array (IC78) conv_ic78_settings : { ... 'method_list': 'hex_convolution', }, # Fully connected layer settings (Combine results from convolutions) fc_settings: {...}, # Fully connected layer settings for uncertainty subnetwork fc_unc_settings: {...}, } Full Changelog: https://github.com/icecube/dnn_reco/compare/v1.0.2...v2.0.1

updated the code to remove an old section of models that were used before we incorporated the random slope structure employed in the paper