<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom" xmlns:dc="http://purl.org/dc/elements/1.1/">
  <channel>
    <title>DEV Community: wanqiuxu</title>
    <description>The latest articles on DEV Community by wanqiuxu (@wanqiu_7ad7bc3efc7b7).</description>
    <link>https://dev.to/wanqiu_7ad7bc3efc7b7</link>
    <image>
      <url>https://media2.dev.to/dynamic/image/width=90,height=90,fit=cover,gravity=auto,format=auto/https:%2F%2Fdev-to-uploads.s3.us-east-2.amazonaws.com%2Fuploads%2Fuser%2Fprofile_image%2F4165323%2F5c94db0c-5d95-49e3-b22f-b28f8f1311d5.png</url>
      <title>DEV Community: wanqiuxu</title>
      <link>https://dev.to/wanqiu_7ad7bc3efc7b7</link>
    </image>
    <atom:link rel="self" type="application/rss+xml" href="https://dev.to/feed/wanqiu_7ad7bc3efc7b7"/>
    <language>en</language>
    <item>
      <title>How to Turn Per-Spectrum Fitting Into NumPy Batch Fitting — SoftwareX Accepted It in 17 Days</title>
      <dc:creator>wanqiuxu</dc:creator>
      <pubDate>Thu, 05 Nov 2026 03:48:42 +0000</pubDate>
      <link>https://dev.to/wanqiu_7ad7bc3efc7b7/how-to-turn-per-spectrum-fitting-into-numpy-batch-fitting-softwarex-accepted-it-in-17-days-18pl</link>
      <guid>https://dev.to/wanqiu_7ad7bc3efc7b7/how-to-turn-per-spectrum-fitting-into-numpy-batch-fitting-softwarex-accepted-it-in-17-days-18pl</guid>
      <description>&lt;p&gt;Lab code that fits spectra one by one in a Python loop gets slow once you have thousands of curves. SPECTROview, an open-source Python desktop app for spectroscopic processing and fitting, replaces that loop with a vectorized batch fitting (VBF) engine built on NumPy. On an Intel Core i5-8365U laptop with 16 GB of RAM, the authors report 16×–62× speedups versus lmfit one-by-one fitting, depending on dataset size and model complexity. The largest test used 16,384 spectra, with peak memory of 845 MB for under a second before returning to about 80 MB after convergence. The SoftwareX paper that describes the software was received 2026-06-17, accepted 2026-07-04, and published 2026-07-08 — a 17-day path from receipt to acceptance in CrushSCI’s SoftwareX records.&lt;/p&gt;

&lt;h2&gt;
  
  
  What SoftwareX is
&lt;/h2&gt;

&lt;p&gt;SoftwareX is published by Elsevier (ISSN 2352-7110) as an open-access (OA) journal. CrushSCI labels for the journal include: SCIE, OA, 2026 Rising Star Zone 3, 2025 CAS Zone 4, 2026 JCR Q3, with 479 articles published in 2025.&lt;/p&gt;

&lt;h2&gt;
  
  
  Scope
&lt;/h2&gt;

&lt;p&gt;Per the journal’s Aims and Scope, SoftwareX is meant to give research software academic recognition: peer-reviewed software that can be cited, inspected, and reused, with credit for developers. It is multidisciplinary — mathematics and physics, environment, medicine and biology, humanities and social sciences — and also takes software in areas such as citizen science, cybersecurity, the digital economy, and energy. Domain-independent building blocks are welcome: math libraries, image-processing libraries, visualization tools, data-management tools, and similar.&lt;/p&gt;

&lt;p&gt;A submission has two parts: a short descriptive paper of at most 4,000 words, plus an open-source software release with supporting materials. The paper is framed as documentation for software readers and potential users. Article types include Original software publication and Software update.&lt;/p&gt;

&lt;p&gt;For developers, that means the code must be open, installable, and usable; the paper should explain what problem the software solves, how it is designed, and how others can use it — not a long algorithm-theory treatise.&lt;/p&gt;

&lt;h2&gt;
  
  
  The 17-day paper
&lt;/h2&gt;

&lt;p&gt;In CrushSCI’s SoftwareX records, the shortest review cycle is 17 days:&lt;/p&gt;

&lt;ul&gt;
&lt;li&gt;Received: 2026-06-17&lt;/li&gt;
&lt;li&gt;Accepted: 2026-07-04&lt;/li&gt;
&lt;li&gt;Published: 2026-07-08&lt;/li&gt;
&lt;/ul&gt;

&lt;p&gt;Those dates match the paper PDF: Received 17 June 2026, Received in revised form 28 June 2026, Accepted 4 July 2026, Available online 8 July 2026.&lt;/p&gt;

&lt;h2&gt;
  
  
  What the paper covers
&lt;/h2&gt;

&lt;p&gt;Title: &lt;em&gt;SPECTROview: An open-source application for interactive spectroscopic data processing, fitting, and visualization&lt;/em&gt;. Sole author: Van Hoan Le (CEA / LETI, Grenoble). Published in SoftwareX volume 35, article 102862.&lt;/p&gt;

&lt;p&gt;&lt;strong&gt;Problem.&lt;/strong&gt; Raman, photoluminescence, and similar experiments produce large numbers of spectra — a 2D scan or wafer map can hold tens of thousands. A common Python approach is lmfit curve fitting inside a per-spectrum loop. That becomes slow at scale, and Python’s GIL limits CPU-bound parallelism.&lt;/p&gt;

&lt;p&gt;&lt;strong&gt;Software.&lt;/strong&gt; SPECTROview is Python with a PySide6 UI and three workspaces: Spectra (single spectrum), Maps (2D maps), Graphs (statistical plots). The pipeline covers import from multiple instrument formats, baseline correction, multi-peak fitting, and export of publication-ready figures. It is GPL-3.0 on GitHub and installable with &lt;code&gt;pip install spectroview&lt;/code&gt;.&lt;/p&gt;

&lt;p&gt;&lt;strong&gt;Method: vectorized batch fitting (VBF).&lt;/strong&gt; Instead of fitting spectra one by one, the engine stacks N spectra into an N×M matrix (M = points per spectrum), builds the Levenberg–Marquardt Jacobian as an N×M×K tensor (K = number of fit parameters), and solves all equations in one vectorized LAPACK call. Two further choices: closed-form analytic Jacobians for each peak shape (not numerical differences), and a convergence mask that drops already-converged spectra from later iterations.&lt;/p&gt;

&lt;p&gt;The paper also states why the authors did not reuse batch LM implementations from PyTorch or TensorFlow: those rely on autodiff aimed at neural-net training, not closed-form peak shapes such as Gaussians and Lorentzians, and they do not conveniently handle spectra that converge on different iteration steps.&lt;/p&gt;

&lt;p&gt;&lt;strong&gt;Results.&lt;/strong&gt; On an Intel Core i5-8365U, 16 GB laptop, four representative datasets were run 10 times each. Versus lmfit one-by-one fitting, VBF speedups were between 16× and 62×, depending on data scale and model complexity. The largest dataset had 16,384 spectra; peak memory was 845 MB for under a second, then about 80 MB after convergence.&lt;/p&gt;

&lt;p&gt;&lt;strong&gt;Limits.&lt;/strong&gt; The authors note that VBF uses one fit model for every spectrum in a batch; with many overlapping peaks (for example more than 20–30), results grow more sensitive to initial parameters and constraints. For inhomogeneous data such as composites or layered structures, the user must define a single model that covers every peak that may appear. Speedups were measured on one laptop against lmfit one-by-one fitting only. Full vectorization trades memory for speed: memory grows linearly with N×M×K.&lt;/p&gt;

&lt;p&gt;&lt;strong&gt;Takeaway for developers.&lt;/strong&gt; The contribution is not a new mathematical method; it is rewriting a common slow path (nonlinear fitting in a Python loop) as batched tensor work, then shipping it as an installable tool with a UI and documentation — the kind of research software SoftwareX’s scope describes.&lt;/p&gt;

&lt;h2&gt;
  
  
  Source
&lt;/h2&gt;

&lt;p&gt;Receipt, acceptance, and publication dates above come from CrushSCI’s paper records for SoftwareX and were checked against the Received / Accepted / Available online dates on the paper PDF. SoftwareX on CrushSCI: &lt;a href="https://www.crushsci.com/journal/26" rel="noopener noreferrer"&gt;https://www.crushsci.com/journal/26&lt;/a&gt;&lt;/p&gt;

</description>
      <category>python</category>
      <category>opensource</category>
      <category>research</category>
      <category>datascience</category>
    </item>
    <item>
      <title>VM Placement Is a Moving Target: Reading the IDEAL SDN Paper</title>
      <dc:creator>wanqiuxu</dc:creator>
      <pubDate>Tue, 06 Oct 2026 04:31:24 +0000</pubDate>
      <link>https://dev.to/wanqiu_7ad7bc3efc7b7/vm-placement-is-a-moving-target-reading-the-ideal-sdn-paper-14jn</link>
      <guid>https://dev.to/wanqiu_7ad7bc3efc7b7/vm-placement-is-a-moving-target-reading-the-ideal-sdn-paper-14jn</guid>
      <description>&lt;p&gt;A VM scheduler changes the system it is trying to optimize. Place one workload, and the remaining CPU capacity, host utilization, and available network paths all change. The next placement decision now has a different input.&lt;/p&gt;

&lt;p&gt;That feedback loop is the central idea in &lt;strong&gt;IDEAL: Impact-Aware Virtual Data Center Embedding With Incremental Analysis for SDN-Controlled Networks&lt;/strong&gt;, by N. Preetham, Sourav Kanti Addya, T. G. Keerthan Kumar, and Saumya Hegde. The paper appears in &lt;a href="https://ieeeaccess.ieee.org/" rel="noopener noreferrer"&gt;IEEE Access&lt;/a&gt;; its &lt;a href="https://doi.org/10.1109/ACCESS.2026.3711709" rel="noopener noreferrer"&gt;DOI record&lt;/a&gt; identifies the published article. The authors' &lt;a href="https://www.researchgate.net/publication/408680095_IDEAL_Impact-Aware_Virtual_Data_Center_Embedding_With_Incremental_Analysis_for_SDN-Controlled_Networks" rel="noopener noreferrer"&gt;public manuscript&lt;/a&gt; provides the algorithm, experimental setup, and results discussed here.&lt;/p&gt;

&lt;h2&gt;
  
  
  The request includes a network
&lt;/h2&gt;

&lt;p&gt;Virtual Data Center Embedding, or VDCE, allocates both compute and communication resources.&lt;/p&gt;

&lt;p&gt;A request contains virtual machines plus virtual links between them. Each VM needs compute capacity. Each virtual link needs bandwidth along a physical route. A placement is successful when the infrastructure can satisfy both sets of demands.&lt;/p&gt;

&lt;p&gt;This coupling matters. Two hosts can have enough spare compute capacity while the path between them lacks the bandwidth required by the application. A compute-only placement decision can therefore leave an otherwise promising request impossible to complete.&lt;/p&gt;

&lt;p&gt;The paper represents compute demand using Computational Resource Blocks, or CRBs. In its model, one CRB corresponds to one CPU core and 512 MB of memory. Virtual links carry explicit bandwidth demands in Mbps.&lt;/p&gt;

&lt;h2&gt;
  
  
  Evaluate the change caused by a placement
&lt;/h2&gt;

&lt;p&gt;IDEAL evaluates candidate hosts using two quantities:&lt;/p&gt;

&lt;ul&gt;
&lt;li&gt;
&lt;strong&gt;Marginal energy increment:&lt;/strong&gt; the additional host-side energy associated with placing the next VM on a candidate host.&lt;/li&gt;
&lt;li&gt;
&lt;strong&gt;Incremental load-balance distortion:&lt;/strong&gt; the change in the distribution of residual resources across active hosts after that tentative placement.&lt;/li&gt;
&lt;/ul&gt;

&lt;p&gt;The second quantity helps explain why maximizing consolidation alone can produce poor allocations. Concentrating workloads can reduce host activation, while leaving an uneven distribution of spare capacity for later requests. Spreading workloads widely can improve balance while increasing the number of active hosts.&lt;/p&gt;

&lt;p&gt;Consider a hypothetical choice between an already active host and an idle host. The active host has enough capacity for the next VM, but little capacity would remain afterward. The idle host offers more room but adds activation overhead. The scheduler needs to compare the consequences of both choices against the current infrastructure state.&lt;/p&gt;

&lt;p&gt;IDEAL uses the Analytic Hierarchy Process, or AHP, to weight its criteria and VIKOR to rank the candidate hosts. These are decision-support tools. The repeated calculation of placement impact, followed by immediate state updates, gives the ranking its current meaning.&lt;/p&gt;

&lt;p&gt;After a placement, the scheduler evaluates the candidates again for the next VM.&lt;/p&gt;

&lt;h2&gt;
  
  
  Treat admission as a transaction
&lt;/h2&gt;

&lt;p&gt;The embedding procedure has two stages: place the VMs, then map their virtual links onto physical paths.&lt;/p&gt;

&lt;p&gt;Its control flow can be read as a resource transaction:&lt;/p&gt;

&lt;ol&gt;
&lt;li&gt;Identify feasible hosts for the next VM.&lt;/li&gt;
&lt;li&gt;Estimate each candidate's energy and balance impact using the current state.&lt;/li&gt;
&lt;li&gt;Rank the candidates, place the VM, and reserve its compute resources.&lt;/li&gt;
&lt;li&gt;Repeat the evaluation for the next VM using the updated state.&lt;/li&gt;
&lt;li&gt;Map the virtual links using bandwidth-feasible paths and reserve their bandwidth.&lt;/li&gt;
&lt;li&gt;Accept the complete request, or release its reservations if any VM or link fails to map.&lt;/li&gt;
&lt;/ol&gt;

&lt;p&gt;For link mapping, physical links with insufficient residual bandwidth are excluded from the candidate graph. The implementation uses a Dijkstra-based K-shortest-path search with &lt;strong&gt;K = 5&lt;/strong&gt;.&lt;/p&gt;

&lt;p&gt;The rollback behavior is especially useful to examine as an engineer. A failed request should leave the infrastructure state as it was before the admission attempt. IDEAL keeps a request-level reservation log covering placed VMs and reserved physical links, then restores those resources on failure.&lt;/p&gt;

&lt;p&gt;That makes the bookkeeping part of the algorithm. A good ranking function still needs correct reservation and release behavior to produce reliable subsequent decisions.&lt;/p&gt;

&lt;h2&gt;
  
  
  What the experiment actually measures
&lt;/h2&gt;

&lt;p&gt;The authors evaluate IDEAL in a Mininet and Ryu SDN emulation environment using Python and OpenFlow. The physical network has &lt;strong&gt;54 hosts and 222 physical links&lt;/strong&gt;, arranged as three spine switches, six leaf switches per spine, and three hosts per leaf.&lt;/p&gt;

&lt;p&gt;Each virtual data center request contains 2-10 VMs. Five workload scenarios contain 200, 400, 600, 800, and 1,000 requests, with ten runs per scenario.&lt;/p&gt;

&lt;p&gt;The comparison uses five heuristic baselines: CEVNE, DROI, SCA-R, LitE, and First-Fit. The authors report an average &lt;strong&gt;48.70% reduction in active-host energy consumption&lt;/strong&gt; across those baseline comparisons.&lt;/p&gt;

&lt;p&gt;The accounting boundary matters here. The manuscript reports a much smaller reduction, around &lt;strong&gt;3-4%&lt;/strong&gt;, for total physical-network host energy, because that calculation includes the baseline power consumed by idle hosts. Consolidating workloads changes active-host energy more dramatically than it changes the modeled energy of the whole host fleet.&lt;/p&gt;

&lt;p&gt;For infrastructure work, both measurements are useful: one describes the placement policy's effect on the active set, and the other describes its effect on all modeled hosts.&lt;/p&gt;

&lt;h2&gt;
  
  
  The ablation shows the trade-off
&lt;/h2&gt;

&lt;p&gt;Table 6 of the manuscript compares energy-only selection, balance-only selection, and the full framework. The following values are reported means and standard deviations across the evaluated load scenarios:&lt;/p&gt;

&lt;div class="table-wrapper-paragraph"&gt;&lt;table&gt;
&lt;thead&gt;
&lt;tr&gt;
&lt;th&gt;Metric&lt;/th&gt;
&lt;th&gt;IDEAL-E: energy only&lt;/th&gt;
&lt;th&gt;IDEAL-B: balance only&lt;/th&gt;
&lt;th&gt;Full IDEAL&lt;/th&gt;
&lt;/tr&gt;
&lt;/thead&gt;
&lt;tbody&gt;
&lt;tr&gt;
&lt;td&gt;Active-host energy, Wh&lt;/td&gt;
&lt;td&gt;3,180 ± 126&lt;/td&gt;
&lt;td&gt;4,875 ± 184&lt;/td&gt;
&lt;td&gt;2,605 ± 96&lt;/td&gt;
&lt;/tr&gt;
&lt;tr&gt;
&lt;td&gt;Total physical-network host energy, Wh&lt;/td&gt;
&lt;td&gt;9,038 ± 142&lt;/td&gt;
&lt;td&gt;9,526 ± 168&lt;/td&gt;
&lt;td&gt;8,790 ± 121&lt;/td&gt;
&lt;/tr&gt;
&lt;tr&gt;
&lt;td&gt;Hosts used&lt;/td&gt;
&lt;td&gt;23.6 ± 1.4&lt;/td&gt;
&lt;td&gt;31.4 ± 1.8&lt;/td&gt;
&lt;td&gt;13.8 ± 0.9&lt;/td&gt;
&lt;/tr&gt;
&lt;tr&gt;
&lt;td&gt;Load-balancing efficiency&lt;/td&gt;
&lt;td&gt;0.41 ± 0.03&lt;/td&gt;
&lt;td&gt;0.68 ± 0.04&lt;/td&gt;
&lt;td&gt;0.73 ± 0.03&lt;/td&gt;
&lt;/tr&gt;
&lt;/tbody&gt;
&lt;/table&gt;&lt;/div&gt;

&lt;p&gt;Energy-only selection consumes less active-host energy than balance-only selection, but its load-balancing score is lower. The full framework combines the two criteria and achieves better values on both metrics in this experiment.&lt;/p&gt;

&lt;p&gt;The evaluation covers a 54-host topology with synthetic arrivals and heuristic baselines. Testing the approach on a larger or production-oriented workload means measuring the repeated ranking cost, routing cost, and resulting allocations under that workload.&lt;/p&gt;

&lt;h2&gt;
  
  
  What to carry into a scheduler design
&lt;/h2&gt;

&lt;p&gt;Three engineering ideas are particularly useful beyond this paper:&lt;/p&gt;

&lt;ul&gt;
&lt;li&gt;
&lt;strong&gt;Re-evaluate after reservation.&lt;/strong&gt; An accepted placement changes the inputs to the next decision.&lt;/li&gt;
&lt;li&gt;
&lt;strong&gt;Keep compute and network feasibility connected.&lt;/strong&gt; Host capacity and path bandwidth belong to the same admission decision.&lt;/li&gt;
&lt;li&gt;
&lt;strong&gt;Make resource changes reversible.&lt;/strong&gt; A reservation log supports complete rollback when a multi-resource request fails.&lt;/li&gt;
&lt;/ul&gt;

&lt;p&gt;These ideas also suggest practical checks: a host's rank should be allowed to change after a reservation; a bandwidth failure should release the request's compute allocations; and an energy comparison should state whether idle hosts are included.&lt;/p&gt;

&lt;p&gt;For the publication trail, the &lt;a href="https://www.crushsci.com/en/journal/8" rel="noopener noreferrer"&gt;IEEE Access paper records on CrushSCI&lt;/a&gt; include this title and its DOI and publisher links, alongside the recorded receipt and acceptance dates. I maintain CrushSCI; the technical discussion here is based on the authors' manuscript.&lt;/p&gt;

&lt;p&gt;&lt;em&gt;This research explainer was prepared with AI assistance. Numerical results are attributed to the authors' experiments.&lt;/em&gt;&lt;/p&gt;

</description>
      <category>cloud</category>
      <category>networking</category>
      <category>computerscience</category>
      <category>algorithms</category>
    </item>
  </channel>
</rss>
