castro.change_max = 1.0 means that the timestep can only ever stay the same or decrease relative to its initial value. I think we should disallow this value, I have a hard time imagining a use case for this (if you want a fixed timestep, use fixed_dt, and if you want a timestep cap but still allow the timestep to decrease, use max_dt). It causes problems with the retry functionality.
I am working on a specific type of ocean wave energy technology. I came across, Capytaine, which is a great and very user-friendly package.
I am using the code to get some specific outputs to be used as inputs for a different code (wecSim: http://wec-sim.github.io/WEC-Sim/overview.html) to simulate an ocean wave energy harvester. When I use Nemoh, I can get those outputs which i
Something that would make for a great first issue is to download and compile SWIFT, and then check out the examples and try running a few. The majority of these examples currently use python2 scripts for initial conditions generation and analysis; it would be great if you could upgrade these to use python3 instead.
A CUDA project for Molecular Dynamics, Brownian Dynamics, Hydrodynamics... intended to simulate a very generic system constructing a simulation with modules.
castro.change_max = 1.0means that the timestep can only ever stay the same or decrease relative to its initial value. I think we should disallow this value, I have a hard time imagining a use case for this (if you want a fixed timestep, use fixed_dt, and if you want a timestep cap but still allow the timestep to decrease, use max_dt). It causes problems with the retry functionality.