Hi everyone, welcome back to our weekly POSM Lab update.
This week, a lot of our work focused on improving both the simulation side and the experimental analysis side of our recoil project. As a reminder, our broader goal is to understand how soft materials recoil after being stretched and released. We’re trying to connect what we see in high-speed videos, what we measure with the force sensor through recoil and our dynamic mechanical analyzer through DMA, and what our simulations predict, so we can better understand how material properties, load mass, and geometry affect elastic recoil.
One major thing we worked on this week was refactoring the simulation code workflow. Previously, a lot of the simulation process was bundled together, which made it harder to debug and harder to compare different simulation settings. So we split the workflow into clearer stages: one part runs the simulation, one part plots the results, and one part compares multiple simulations. This makes the code much easier to troubleshoot, because if something looks wrong in the final plots, we can now isolate whether the issue came from the simulation itself, the plotting code, or the comparison step.
We also built tools to test simulation convergence. Basically, when we run a numerical simulation, we have to choose how many position intervals and time intervals to use. If those intervals are too large, the simulation might be too coarse and give unreliable results. But if we make them too small, the simulation becomes much more expensive to run. So we updated a MATLAB helper function that can run simulations with increasing spatial and temporal resolution, compare neighboring runs, and report percent differences in important outputs like final recoil displacement, maximum kinetic energy, and maximum power. This helps us check whether our simulation results are actually stable, or whether they are still changing significantly depending on the resolution we choose.
Another big theme this week was reorganizing how files and analyses are saved. This is not the flashiest part of research, but it is really important. We standardized filenames, added a README with a specific data-processing pipeline, and started using experiment-prefixed names for figures and results. That way, when we look back at an analysis file or a plot, we know exactly which experiment it came from. This should make it much easier for us, and for future lab members, to onboard, rerun analyses, compare experiments, and avoid losing track of which files belong to which trial.
On the experimental analysis side, we spent a lot of time working on reanalysis because some of our kinetic energy curves were not behaving the way we expected. For example, in an ideal recoil experiment of a purely elastic material, the kinetic energy should reach a clean maximum around the time when the force sensor reaches zero. Physically, that zero force point is important because it roughly marks the transition when the stretched material is no longer pulling strongly on the force sensor and the system begins to enter the buckling phase.
But in real data for quasi-linear viscoelastic materials, things are messier. The force sensor and the high-speed camera are not always perfectly synchronized, and the release process can introduce friction, vibration, or timing offsets. The wavespeed of the material and the viscoelastic nature also introduces other factors. Because of that, we had to isolate the recoil more carefully through data processing and include some slightly negative force sensor values. That gives us enough room to account for imperfect synchronization between the force sensor and the camera. This matters because metrics like resilience depend on the maximum kinetic energy. If the kinetic energy curve never reaches a clean maximum, then any resilience value we calculate from it might not be physically meaningful.
A major technical discussion this week centered around position smoothing and the lambda parameter. In our analysis, we track dots on the material in the high-speed video, and then fit those dot positions using a free-knot spline approximation. Lambda is a smoothing parameter in that fitting process. If lambda is too small, the fitted curve follows the raw tracking data too closely, which means it may overfit noise. But if lambda is too large, the curve becomes too smooth and can erase important behavior in the actual recoil motion.
This is especially important because we do not just use position directly. We take derivatives of position to get velocity and acceleration, and then use those to calculate kinetic energy and other metrics. Derivatives tend to amplify noise, so small errors in position tracking can become much larger errors in velocity or acceleration. To study this, we did a lambda sweep across ten logarithmic scales for several experiments. We wanted to see how the mean squared error of the position fit changed, and whether the residuals looked random rather than systematic. Ideally, once lambda is chosen well, the remaining fitting error should behave more like random noise instead of showing a clear pattern that means the model is missing something important.
This also led us to think more carefully about the limitations of the camera itself. The quality of the position fit is not just a coding problem; it is also limited by the video data. For the Chronos high-speed camera we use, there is a tradeoff between frame rate and pixel resolution. A higher frame rate lets us capture fast recoil motion more clearly in time, but it may reduce spatial resolution. On the other hand, higher pixel resolution can give us better dot positions, but may make it harder to capture very fast motion. So changing lambda may sometimes only change how we fit imperfect data, rather than revealing the true physical motion.
We also characterized camera lens distortion this week. We found that zooming can introduce distortion, which affects the apparent dot positions. Our current working solution is to avoid zooming too much and instead place the camera at a more ideal distance. A to-do item for next week is to try subpixel tracking. Right now, dot tracking is limited by pixels, but subpixel tracking would treat each dot more like a Gaussian distribution of intensity. That means the center of a dot could be estimated more precisely than just choosing the nearest pixel, which could improve the quality of our position data.
Another experimental task this week was trying to laser cut bands from our neoprene material. We tested different speed, power, and current settings, and while some settings worked better than others, laser cutting became both a safety and practicality issue. Even if the material does not visibly melt, the heat from the laser could still change the chemical or mechanical properties of the polymer near the edges. That would be hard for us to characterize, and it could affect our experiments. To test this, we plan to compare loading and unloading behavior between laser-cut and knife-cut materials. But for now, we will most likely stick with cutting the bands by hand with a knife.
For our fun fact of the week, I want to talk briefly about fractional viscoelasticity, which came up in our journal discussion. In soft materials, we often describe mechanical behavior using quantities like storage modulus, loss modulus, relaxation modulus, and creep compliance. A simple elastic spring has stress that depends on strain. A dashpot, which represents viscous behavior, has stress that depends on strain rate, or the first derivative of strain. Traditional viscoelastic models, like Maxwell or Kelvin-Voigt models, combine springs and dashpots in series or parallel to create more complex material behavior.
The challenge is that if we want to describe very complicated viscoelastic behavior, we may need many springs and dashpots, which can become computationally expensive. Fractional viscoelasticity introduces the idea of a springpot, which behaves somewhere between a spring and a dashpot. Instead of stress depending only on strain or only on the first derivative of strain, it can depend on a fractional derivative of strain. This gives us a more flexible way to describe materials that are neither purely elastic nor purely viscous, without always needing a huge number of Maxwell elements.
Sam also made major progress on his project this week. He successfully wrote an algorithm that can create a master curve from a set of DMA data using the principle of time-temperature superposition. The idea behind time-temperature superposition is that material behavior at different temperatures can be shifted to form one larger curve, which represents behavior over a much wider range of timescales. Using this master curve, Sam is now writing an algorithm to fit a generalized Maxwell model. From that fit, we can gain insight into the viscoelastic properties of the material and use the fit parameters to predict how the material might respond in other regimes.
Finally, every Friday in the POSM Lab is Friday Funday. This week, we went to Sanamluang, a Thai restaurant, then headed to 85°C Cafe for our journal discussion on fractional viscoelasticity, and finished the day with an escape room. So overall, this week was a mix of code refactoring, simulation convergence testing, experimental debugging, viscoelastic theory, and a little bit of Friday fun.
