-
Notifications
You must be signed in to change notification settings - Fork 7
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Started batch run tutorial #31
Conversation
|
- **Simulation duration**: How long the simulation will run for (simulation time) in seconds. | ||
- **Time-step size**: The simulation proceeds at a fixed time-step size, and this can be specfied for each run. | ||
- **Heave cone door-state**: Simulations can be done with the heave-cone doors either opened or closed, the door position can not be chanced during a simulation, so this is a parameter that must be specified at start-up. | ||
- **Sea-State**: Incomping waves can be specified as a monochromatic wave with a specified amplitude and period, a Bretschieder spectrum of waves described by significant wave-height and the peak period, or by a custom wave-spectrum defined by a curve of wave-energy versus frequency. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
- **Sea-State**: Incomping waves can be specified as a monochromatic wave with a specified amplitude and period, a Bretschieder spectrum of waves described by significant wave-height and the peak period, or by a custom wave-spectrum defined by a curve of wave-energy versus frequency. | |
- **Sea-State**: Incoming waves can be specified as a monochromatic wave with a specified amplitude and period, a Bretschneider spectrum of waves described by significant wave-height and the peak period, or by a custom wave-spectrum defined by a curve of wave-energy versus frequency. |
|
||
the simulation uses a number of defaults for a range of parameters. In most cases, one may want to run the simulator with different values for these parameters, and/or run a number of simulations that iterate across a range of values for particular parameters. For instance, one may want to run the simulator in a batch mode that runs the same buoy and controller set-up in a range of sea-states. | ||
|
||
To facilitate this, a batch tool is provided that allows one to specify ranges for a number of parameters, and then run a number of simulations for all combinations of parameters, saving the results seperately. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
To facilitate this, a batch tool is provided that allows one to specify ranges for a number of parameters, and then run a number of simulations for all combinations of parameters, saving the results seperately. | |
To facilitate this, a batch tool is provided that allows one to specify ranges for a number of parameters, and then run a number of simulations for all combinations of parameters, saving the results separately. |
|
||
- **Simulation duration**: How long the simulation will run for (simulation time) in seconds. | ||
- **Time-step size**: The simulation proceeds at a fixed time-step size, and this can be specfied for each run. | ||
- **Heave cone door-state**: Simulations can be done with the heave-cone doors either opened or closed, the door position can not be chanced during a simulation, so this is a parameter that must be specified at start-up. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
- **Heave cone door-state**: Simulations can be done with the heave-cone doors either opened or closed, the door position can not be chanced during a simulation, so this is a parameter that must be specified at start-up. | |
- **Heave cone door-state**: Simulations can be done with the heave-cone doors either opened or closed, the door position can not be changed during a simulation, so this is a parameter that must be specified at start-up. |
- **Sea-State**: Incomping waves can be specified as a monochromatic wave with a specified amplitude and period, a Bretschieder spectrum of waves described by significant wave-height and the peak period, or by a custom wave-spectrum defined by a curve of wave-energy versus frequency. | ||
- **Wave phase random seed**: The phases of each wave-component are randomly assigned, if a seed is specified, the phases will be the same for each run of a simulation. This is useful for comparing simulations for which one wants the same wave-excitation. If the seed value is set to zero, or ommitted, a different random phase assignment will be made for each simulation run. | ||
- **Physics Real-Time Factor (RTF)**: This parameter sets the maximum speed the simulation will be allowed to run, in terms of a multiple of real-time. i.e. a Real-Time factor of 2.0 will limit the simulation to only running twice as fast as real-time. As described below, for single runs for which one may want to monitor the motion as it occurs, a Real-Time Factor of 1.0 is appropriate. For batches of runs one wants to complete as fast as possible, a large RTF (i.e. 100) will let the simulation run as fast as the processing resources allow. | ||
- **Heave-cone door position**: The simulation can be run with the heave-cone doors either open, or closed. This can not be changed while the simulation is running. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
- **Heave-cone door position**: The simulation can be run with the heave-cone doors either open, or closed. This can not be changed while the simulation is running. |
- **Heave-cone door position**: The simulation can be run with the heave-cone doors either open, or closed. This can not be changed while the simulation is running. | ||
- **Battery State-of-Charge**: The starting battery state of charge can be specified between 0 (empty) and 1 (full). A full battery can't absorb energy so more of the generated power will be diverted to the load-dump in the simulation. An empty battery will allow most or all of the generated energy to flow to the battery. This does not effect the physical behavior of the simulated buoy, but does effect the battery voltages and currents as the simulation progresses. | ||
- **Battery EMF**: As an alternative to specifying the battery state of charge as a percentage, the zero-load battery voltage can be specfied, between 270V (empty battery), and 320V (full battery). | ||
- **Scale Factor**: The buoy (and simulator) implements a default control algoritm in which the current in the motor windings is set as a function of motor RPM, with the resulting torque opposing the rotors motion. The approximately implements a linear damping behavior and the specified Scale Factor is multiplied by the default Winding-Current/RPM relationship before being applied. Allowable values are from 0.5 to 1.4, and the result is a simple way to change the damping the power-takeoff device is applying to the system. As discussed in a later tutorial, this relationship can be over-ridden with external code, so this Scale Factor only applies to the default behavior of the system. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
- **Scale Factor**: The buoy (and simulator) implements a default control algoritm in which the current in the motor windings is set as a function of motor RPM, with the resulting torque opposing the rotors motion. The approximately implements a linear damping behavior and the specified Scale Factor is multiplied by the default Winding-Current/RPM relationship before being applied. Allowable values are from 0.5 to 1.4, and the result is a simple way to change the damping the power-takeoff device is applying to the system. As discussed in a later tutorial, this relationship can be over-ridden with external code, so this Scale Factor only applies to the default behavior of the system. | |
- **Scale Factor**: The buoy (and simulator) implements a default control algorithm in which the current in the motor windings is set as a function of motor RPM, with the resulting torque opposing the rotor's motion. This approximately implements a linear damping behavior and the specified Scale Factor is multiplied by the default Winding-Current/RPM relationship before being applied. Allowable values are from 0.5 to 1.4, and the result is a simple way to change the damping the power-takeoff device is applying to the system. As discussed in a later tutorial, this relationship can be over-ridden with external code, so this Scale Factor only applies to the default behavior of the system. |
|
||
The remaining run-specific parameters can be specified as arrays, and the batch-run tool then executes simulations for all possible combinations of these values. Note that some values are specified in pairs. For instance, three mono-chromatic waves are specified by this file with a specification of (A=1.0m, T=12s), (A=2.0m, T=14s), and (A=3.0m, T=15s), not nine runs that include all possible combinations of the specified amplitude and periods. | ||
|
||
Obviously it would be very easy to write a batch file specification that incluces thousands of runs, more practical usage will most likely iterate over a small number of parameters at at a time. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Obviously it would be very easy to write a batch file specification that incluces thousands of runs, more practical usage will most likely iterate over a small number of parameters at at a time. | |
Obviously, it would be very easy to write a batch file specification that includes thousands of runs, but more practical usage will most likely iterate over a small number of parameters at at a time. |
$ ros2 launch buoy_gazebo mbari_wec_batch.launch.py sim_params_yaml:=IrregularWaves.yaml | ||
``` | ||
|
||
Running these commands will run the simulation, all output is stored in a directory named similar to `batch_results_20230228210735', the trailing numbers indicate a timestamp. Inside this diretory the yaml file is repeated, along with a log file 'batch_results.log' that lists all of the simulation runs that were performed. Alongside that are specific directories that hold output from each run. For convenience, a symbolic link is formed that points at the most recent batch output directory. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Running these commands will run the simulation, all output is stored in a directory named similar to `batch_results_20230228210735', the trailing numbers indicate a timestamp. Inside this diretory the yaml file is repeated, along with a log file 'batch_results.log' that lists all of the simulation runs that were performed. Alongside that are specific directories that hold output from each run. For convenience, a symbolic link is formed that points at the most recent batch output directory. | |
Running these commands will run the simulation, all output is stored in a directory named similar to `batch_results_20230228210735`, the trailing numbers indicate a timestamp. Inside this directory the yaml file is repeated, along with a log file 'batch_results.log' that lists all of the simulation runs that were performed. Alongside that are specific directories that hold output from each run. For convenience, a symbolic link is formed that points at the most recent batch output directory. |
|
||
Running these commands will run the simulation, all output is stored in a directory named similar to `batch_results_20230228210735', the trailing numbers indicate a timestamp. Inside this diretory the yaml file is repeated, along with a log file 'batch_results.log' that lists all of the simulation runs that were performed. Alongside that are specific directories that hold output from each run. For convenience, a symbolic link is formed that points at the most recent batch output directory. | ||
|
||
Within the output directory, there is a file named 'batch_runs.log' that shows each individual run that was performed, and the associated parametesr. In this case it has the following contents: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Within the output directory, there is a file named 'batch_runs.log' that shows each individual run that was performed, and the associated parametesr. In this case it has the following contents: | |
Within the output directory, there is a file named `batch_runs.log` that shows each individual run that was performed, and the associated parameters. In this case, it has the following contents: |
For simulations that take longer to run, it can be convenient to tail this log file from the terminal to keep track of progress. i.e. From the directory the batch was started from: | ||
|
||
``` | ||
$ tail -f tail -f latest_batch_results/batch_runs.log |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
$ tail -f tail -f latest_batch_results/batch_runs.log | |
$ tail -f latest_batch_results/batch_runs.log |
Just some minor edits Looks great so far! |
Thanks for these, I did not mean for you to have to spell check. I found a good spell-checker for vscode so should be in better shape now. Another suggestion, we may want to make the rosbag directory be within a Results_20230228... directory, such that we can put other outputs like the .csv output files alongside them and there's one directory for all results. I imagine you're already thinking of this... Another question is if it's possible/practical to tell it to turn on the GUI in the yaml. Or perhaps, run the GUI in the case a single run results. Not sure if this makes sense... Working nicely. |
Starting a tutorial to illustrate how to use the batch run facilities