faq

Differences

This shows you the differences between two versions of the page.


Previous revision
faq [2023/12/07 12:02] (current) – [Using SCONE] thomas
Line 1: Line 1:
 +====== Frequently Asked Questions ======
 +
 +==== General ====
 +<accordion collapsed="true">
 +
 +<panel type="default" title="What does SCONE stand for?">
 +SCONE is a tasty acronym for **S**imulated **C**ontroller **O**ptimizatio**N** **E**nvironment.
 +</panel>
 +
 +</accordion>
 +
 +==== Prerequisites ====
 +
 +<accordion collapsed="true">
 +
 +<panel type="default" title="Do I need programming skills to use SCONE?">
 +No, SCONE provides an integrated Graphical User Interface (GUI) that allows simultaneous development, optimization, and analysis of predictive simulations. Control strategies are defined through a user-friendly configuration script -- check out the [[tutorials:start]] to learn more!
 +</panel>
 +
 +<panel type="default" title="What kind of hardware do I need to run SCONE?">
 +It depends on how many optimizations you want to run simultaneously. SCONE allows you to run as many as you like, but at some point your optimizations will slow down. A single optimization will use as much as ~15 different parallel threads, so the more cores you have on your machine, the better SCONE will run.
 +
 +Memory-wise, SCONE optimizations have relatively low demands. For example, the gait optimization from the tutorial requires +/- 50 MB per optimization, so it will take a while before you run out of memory. Storage-wise, it's highly recommended to always use a Solid State Drive (SSD).
 +
 +Here is an overview of recommended specifications:
 +^ Machine specification ^ Number of cores ^ Memory ^ Storage ^ Typical use case ^
 +| Minimum | 2 (dual-core) | 4 GB | SSD | Reasonable performance, one or two optimizations at a time |
 +| Good | 4 (quad-core) | 8 GB | SSD | Decent performance, up to three optimizations at a time |
 +| High-end | 8 | 8+ GB | SSD | Good performance, up to six optimizations at a time |
 +| Super high-end | 16 | 16+ GB | SSD | Great performance, up to twelve optimizations at a time |
 +| Epic | 32+ | 16+ GB | SSD | Awesome performance, lots of simulations at a time |
 +</panel>
 +
 +<panel type="default" title="Can SCONE be used for robotics research?">
 +Absolutely; even though SCONE has a focus on neuromuscular control, it can just as easily be used to optimize torque-based controllers found in robotics. All that is required is a supported [[doc:model|Model]] of your robot or device. SCONE especially shines when robotic assistive devices are simulated together with musculoskeletal models.
 +</panel>
 +
 +<panel type="default" title="Does SCONE work with both 2D and 3D models?">
 +SCONE can be used with [[doc:model|any model]] -- both 2D and 3D. However, since 3D models are considerably more difficult to control, it's usually best to start by using a 2D model and extend to 3D later.
 +</panel>
 +
 +<panel type="default" title="Does SCONE only work with OpenSim as a simulator?">
 +SCONE is simulator-agnostic, meaning it can be used with any musculoskeletal dynamics simulation software package, [[doc:api|after implementing a set of interface classes in C++]]. By default, SCONE supports OpenSim 3, OpenSim 4 and [[Hyfydy|Hyfydy]].
 +</panel>
 +
 +<panel type="default" title="What kind of parameters can I optimize using SCONE?">
 +SCONE allows you to simultaneously optimize [[doc:parameters|both model and control parameters]], according to any [[doc:objective|user-defined objective function]].
 +</panel>
 +
 +<panel type="default" title="What kind of optimization method does SCONE use?">
 +SCONE support shooting based optimization methods, as well as Reinforcement Learning methods via the [[sconepy|SCONE Python interface]]. Out-of-the-box, [[doc:optimizer|SCONE Optimizers]] support different flavors of Covariance Matrix Adaptation [Hansen 2006].
 +</panel>
 +
 +</accordion>
 +
 +==== Using SCONE ====
 +<accordion collapsed="true">
 +
 +<panel type="default" title="Why does my model fall at the end of a gait simulation?">
 +Gaits are typically optimized for minimal effort or cost-of-transport, and it so happens that falling right at the end can be slightly more energy efficient than walking normally. To prevent this from happening, you can choose from a number of strategies:
 +  * Increase the simulation time. By increasing the ''max_duration'' parameter, you reduce the chance of the model falling over, because at some point it will become impossible for the controller to exactly time the fall at the end. If you set the simulation time to 30s or more, the controller will be robust enough to go on indefinitely.
 +  * Disable the [[ref:effort_measure]] before the end of the simulation. You can add an ''end_time'' statement to the [[ref:effort_measure]] to stop measuring e.g. 1 second before the end of the simulation, removing the benefit of falling over right at the end. Falling even earlier will result in a penalty in the [[ref:gait_measure]], so this won't be an alternative.
 +  * Adding motor noise via the [[ref:noise_controller]]. Controllers are forced to choose a more robust control strategy when motor noise is added to the system. This is likely to result in more robust controllers that don't fall over at the end.
 +</panel>
 +
 +<panel type="default" title="Why do I get different results on different machines?">
 +This can indeed happen as a the result of hardware or OS-specific differences in floating point calculations. Even though these differences are minuscule, errors accumulate in a predictive simulation, so a result that works on machine my not work on another machine or OS. You have a number of options to get around this:
 +  * Restart the simulation using the previous result as ''init_file'' or the [[ref:par_init_settings|init]] setting. After one or two iterations you will find a result that is stable and very similar to the previous result.
 +  * Find a ''.par'' file that works on both machines. If you go slightly back in your results history, it should be possible to find a ''.par'' file that works on both machines. If not, you can generate more results using the method described above.
 +  * Adding motor noise via the [[ref:noise_controller]]. Controllers are forced to choose a more robust control strategy when motor noise is added to the system, causing the results to be less sensitive to hardware differences.
 +</panel>
 +
 +<panel type="default" title="Can the optimization of a scenario be resumed if aborted before convergence?">
 +At the moment, optimizations cannot be resumed directly once aborted. However, it is possible to use the result of a previous optimization as input for a new optimization. For more information, see the [[ref:Optimizer|reference manual]] on ''init_file'' or the [[ref:par_init_settings|init]] setting.
 +</panel>
 +
 +<panel type="default" title="Can I use scripting to create custom controllers or objectives?">
 +SCONE provides support for scripting to define custom controllers or objective functions, through [[ref:script_controller]] and [[ref:script_measure]]. SCONE scripts are based on the [[http://lua.org|Lua programming language]]. See Tutorial 6 for example scripts.
 +</panel>
 +
 +<panel type="default" title="Why use Lua for scripting and not Python?">
 +SCONE includes a [[sconepy|Python interface]] that can be used for scripting machine learning applications, but for scripting custom Controllers or Measures you should use the Lua scripting language. The reason behind this choice is that using Python would result in terrible optimization performance.
 +
 +During a SCONE optimization, multiple simulations are evaluated concurrently, using separate threads -- each of which continually evokes custom scripts to update the controller output or the objective function. Python has extremely poor performance in this situation, as it only allows a single thread to access the Python interpreter at a time -- even though the scripts are fully independent. [[http://lua.org|Lua]], on the other hand, is much more flexible and allows controllers and measures to run in parallel, which is much better for performance.
 +</panel>
 +
 +</accordion>
 +
 +==== License and Contribution ====
 +<accordion collapsed="true">
 +
 +<panel type="default" title="Can I use SCONE for my own project? What license is it published under?">
 +**SCONE** is licensed under the [[https://www.apache.org/licenses/LICENSE-2.0|Apache License, Version 2.0]]. **SCONE Studio** is licensed under the [[https://www.gnu.org/licenses/gpl-3.0.en.html|GNU Public License
 +3.0]]. You are free to use SCONE for whatever you want, as long as you adhere these licenses.
 +
 +If your publication uses SCONE, please cite the following paper:
 +
 +  @article{ Geijtenbeek2019,
 +    author = {Thomas Geijtenbeek},
 +    title = {SCONE: Open Source Software for Predictive Simulation of Biological Motion},
 +    journal = {Journal of Open Source Software}
 +    year = {2019},
 +    volume = {4},
 +    number = {38},
 +    pages = {1421},
 +    publisher = {The Open Journal},
 +    doi = {10.21105/joss.01421},
 +    url = {https://doi.org/10.21105/joss.01421},
 +  }
 +
 +In addition, if you use [[Hyfydy|Hyfydy]], please include the following citation:
 +
 +  @misc{Geijtenbeek2021Hyfydy,
 +    author = {Geijtenbeek, Thomas},
 +    title = {The {Hyfydy} Simulation Software},
 +    year = {2021},
 +    month = {11},
 +    url = {https://hyfydy.com},
 +    note = {\url{https://hyfydy.com}}
 +  }
 +</panel>
 +
 +<panel type="default" title="How can I contribute to SCONE?">
 +Thank you for considering! There are many ways in which you can contribute, please follow [[license#contributing_to_scone|this link]] for details.
 +</panel>
 +
 +</accordion>