batch running with wave spectrum

[andermi]

• the seed parameter is now connected to the IncWaveSeed

• you can specify an array of battery states as either
  battery_soc: [0.25, 0.5, 0.75, 1.0] in the range of 0.0 to 1.0 or
  battery_emf: [282.5, 295.0, 307.5, 320.0] in the range of 270V to 320V

• may specify physics parameters: step size as array as part of test matrix, and real-time factor as scalar for all tests physics_step = [0.001, 0.01, 0.1] and physics_rtf = 11

• you may now specify any number of incident wave spectra in the yaml as a list under the key IncidentWaveSpectrumType:

  - MonoChromatic:
      A: 1.0
      T: 12.0

  - Bretschneider:
      Hs: 3.0
      Tp: 14.0

  - Custom:
      w: [0.0, 0.2, 0.4, 0.6, 2.0]
      Szz: [0.0, 0.4, 1.0, 1.0, 0.0]

  you may also leave off the parameters from the spectrum type and just use defaults in sdf

  - MonoChromatic

  - Bretschneider

  - Custom

  An example to just enable default Bretschneider waves might be:

  IncidentWaveSpectrumType:
  - Bretschneider

  Or, to try a series of MonoChromatic:

  IncidentWaveSpectrumType:
  - MonoChromatic:
      A: 0.5
      T: 11.0
  - MonoChromatic:
      A: 1.0
      T: 12.0
  - MonoChromatic:
      A: 1.5
      T: 13.0
  - MonoChromatic:
      A: 2.0
      T: 14.0

  or all three:

  IncidentWaveSpectrumType:
  - MonoChromatic:
      A: 1.0
      T: 12.0
  - Bretschneider:
      Hs: 3.0
      Tp: 14.0
  - Custom:
      w: [0.0, 0.2, 0.4, 0.6, 2.0]
      Szz: [0.0, 0.4, 1.0, 1.0, 0.0]

• may now also specify MonoChromatic or Bretschneider in vectorized form

  IncidentWaveSpectrumType:
  - MonoChromatic:
    A: [1.0, 2.0, 3.0]
    T: [12.0, 14.0, 15.0]

  taking pairs of values of a, t in A, T

[hamilton8415]

Very nice, working for me as expected. I will try harder to break it though still. :)

Is it reasonable to define parameters for more than instance of a wave-type together? i.e.

• MonoChromatic: A: [1.0, 2.0, 3.0] T: [12.0, 14.0, 15.0]

Not required, but would be concise...

Also, I haven't checked, but is the real-time factor maxed out when running in batch mode? Seems like perhaps we could have it default to 1.0 when running with the gui, but "set it to 11" in batch mode.

I will make a tutorial for this, I think we have a blank one on the list for this sort of thing.

[andermi]

define parameters for more than instance of a wave-type together?

So, I thought about this, but it wouldn't be possible to do the Custom Spectrum like this in yaml. So, I made them all the same format. If you like, I can let MonoChromatic and Bretschneider be formatted this way, and Custom will need multiple entries.

[andermi]

but is the real-time factor maxed out when running in batch mode?

That would be in the world file along with the timestep, which I have been trying to avoid making a template. But, maybe the more the merrier?

[hamilton8415]

I know, you've been doing an admirable job of avoiding templating that one! But, I'm afraid the timestep is going to be a requirement in all of this...

Yes, I do remember realizing the custom spectrum is an off-case that can't be done that way. But, I think the convenience of listing the other two this way outweighs the lack of consistency. Unless it's a pain, what you have certainly works...

[andermi]

Unless it's a pain

Nope! Already done!

[andermi]

I'm afraid the timestep is going to be a requirement in all of this...

Ok, no prob! I'll add timestep and RTF to the batching...

[andermi]

@hamilton8415 are you going to want to test multiple physics steps? or is a scalar ok?

[hamilton8415]

Multiple probably, that'd be done to test convergence with smaller time-steps. Let me know if it adds complexity though.

[andermi]

Multiple probably

Done!

@hamilton8415 let me know if there's any other nice-to-haves or if you break anything :)

[hamilton8415]

This is awesome,. Runs nicely for me, but have a couple of ideas for consideration:

• [x] For my testing I re-arranged your example file to have the single-valued items at top, should we consider calling these values out in sections: i.e. "# Batch Specific Parameters" and "# Run Specific Parameters". Just a matter of comments in the example really...

• [x] should we put some field delineations in the batch_results filename, so it's easier to see which the most recent is. i.e 2023-02-28-15:57:59 Might cause filename issues outside of Linux of cousre, and would have to then consider doing it for the rosbags in the directories, etc. Another simpler idea would be to create a sym-link called latest_results that get set to the most recent when that is formed. Along the same lines, perhaps name the log file in each directory as just batch_runs.log, that way one can do a "tail -f latest_results/batch_runs.log" and keep track of how things are going for a specific. I'd keep the other time-stamps inside the batcresults* directory to keep those unique...

• [x] As I understand it, the following values are single-valued for the whole batch run (seed, physics_rtf, duration). The rest can be multi-valued. I tested entering a range of values for seed and it complained sensibly, for physics_rtf though, an array of [11, 12] didn't give an error but instead tried to interpret "[11, 12]" and made a mess of errors.

• Perhaps unrelated to this effort, there's this error at each run for me: [mbari_wec_batch-1] [ERROR] [robot_state_publisher-4]: process has died [pid 1898367, exit code -6, cmd '/opt/ros/humble/lib/robot_state_publisher/robot_state_publisher --ros-args -r __node:=robot_state_publisher --params-file /tmp/launch_params_l2a3d3a7 --params-file /tmp/launch_params_6nsi2q86'].

Edit (andermi): made checkboxes for updates

[andermi]

Perhaps unrelated to this effort, there's this error at each run for me: [mbari_wec_batch-1] [ERROR] [robot_state_publisher-4]: process has died [pid 1898367, exit code -6, cmd '/opt/ros/humble/lib/robot_state_publisher/robot_state_publisher --ros-args -r __node:=robot_state_publisher --params-file /tmp/launch_params_l2a3d3a7 --params-file /tmp/launch_params_6nsi2q86'].

Yes, unrelated. Has been happening for a while now. It came about when we added support to view the buoy in RVIZ. This needs some attention in another PR. @quarkytale can you fix this?

[hamilton8415]

Don't know if it's practical, but an alias of some sort that hides the ros launch, etc.. stuff might be welcome by some. i.e. "RunBatch foo.yaml", or some better name.

[andermi]

alias of some sort that hides the ros launch

I might leave that as an exercise for the user :stuck_out_tongue_winking_eye:

[andermi]

Incidently, if you'd like to skip the ros2 launch stuff, you could simply run $ ./install/buoy_gazebo/lib/buoy_gazebo/mbari_wec_batch foo.yaml

[hamilton8415]

alias of some sort that hides the ros launch I might leave that as an exercise for the user 😜

I like it.

[andermi]

You may now up-arrow-enter tail -f latest_batch_results/batch_runs.log to your heart's content!

[hamilton8415]

I'll be the judge of that, remember the centipede issue... :)

[andermi]

@hamilton8415 fixed the template defaults after batch messes them up

[hamilton8415]

Latest leaves me with a bit of an error. Rebuilt from scratch, sourced etc... Not sure quite what it means.

hamilton@NDH:~/FOO$ ros2 launch buoy_gazebo mbari_wec_batch.launch.py sim_params_yaml:=foo.yaml [INFO] [launch]: All log files can be found below /home/hamilton/.ros/log/2023-02-28-19-42-11-966636-NDH-1935258 [INFO] [launch]: Default logging verbosity is set to INFO [INFO] [mbari_wec_batch-1]: process started with pid [1935259] [mbari_wec_batch-1] [INFO] [1677642132.444011643] [mbari_wec_batch]: Creating batch results directory: batch_results_20230228194212 [mbari_wec_batch-1] [INFO] [1677642132.447155861] [mbari_wec_batch]: Generated 32 simulation runs [mbari_wec_batch-1] [INFO] [1677642132.448303914] [mbari_wec_batch]: Creating log file: batch_results_20230228194212/batch_runs.log [mbari_wec_batch-1] [INFO] [1677642132.449438061] [mbari_wec_batch]: [mbari_wec_batch-1] [mbari_wec_batch-1] Sim run [0] for 6.0 seconds: door state='closed', scale factor=0.5, battery state=0.25, IncidentWaveSpectrumType=MonoChromatic;A:1.0;T:12.0 [mbari_wec_batch-1] [mbari_wec_batch-1] Traceback (most recent call last): [mbari_wec_batch-1] File "/home/hamilton/buoy_ws/install/buoy_gazebo/lib/buoy_gazebo/mbari_wec_batch", line 468, in [mbari_wec_batch-1] generate_simulations(args.sim_params_yaml) [mbari_wec_batch-1] File "/home/hamilton/buoy_ws/install/buoy_gazebo/lib/buoy_gazebo/mbari_wec_batch", line 403, in generate_simulations [mbari_wec_batch-1] f' --iterations {iterations}') [mbari_wec_batch-1] UnboundLocalError: local variable 'iterations' referenced before assignment

[andermi]

oops... fixed now

[hamilton8415]

Below is a comment I put in the tutorial pull-request, repeating here...

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.

[andermi]

tell it to turn on the GUI in the yaml

done!

[andermi]

make the rosbag directory be within a Results_20230228... directory

and done!