rename simulation output files versus default timestamp

[t-osu]

Hi, where are the output file names determined in the code? Is it possible to change to a custom name or using variables defined in the startup batch file?

I'm looking to find a way to change this before a simulation so that instead of defaulting to e.g. batch_results_20230228210735/results_run_0_20230301200627/pblog/results_run_0_20230301200627.csv
it could be, e.g.:
batch_amp1_per6_results/amp1_per6_results/pblog/amp1_per6_results.csv
?

Would just make it easier to sort through when post-processing later
Thanks!

[andermi]

This is not currently possible using the batch script. The complication is that the batch processing was set up to run multiple cases (matrix of tests) and the logs for each case are placed in a folder with a name based on its run number.

If you wanted to have a custom name for each run, this would require the addition of an input list of filenames for every case.

An undocumented feature of the main launch file ros2 launch buoy_gazebo mbari_wec.launch.py is that you could specify each set of parameters and log file names manually (not as a batch). The supported parameters are listed here.
These parameters would be input to the launch file as:

ros2 launch buoy_gazebo mbari_wec.launch.py param:=value

The tricky one is the inc_wave_spectrum parameter. The format for that one is (for example):

inc_wave_spectrum:="inc_wave_spectrum_type:MonoChromatic;A:1.0;T:6.0"

and of course there's a typo in the description of input parameter for inc_wave_spectrum on line 239. The text there should be:

                                             + 'inc_wave_spectrum_type:type;p1:v1:v2;p2:v1:v2'}

And, the output file could be placed in a specific folder by the arguments:

pbloghome:=. pblogdir:=amp1_per6_results

The pblog node was designed to produce csv log files exactly like the physical buoy, so those are currently generated by timestamp.

[andermi]

I'm happy to work with you to make your QoL easier. Please, let me know if the above doesn't work for you.

[andermi]

We also have a set of matlab scripts for post-processing that I'm partway through porting to python. We have talked about making those accessible. We've taken care of much of the file crawling overhead there.

[hamilton8415]

As it is, @andermi is working on the Python side, and I'm working on the Matlab/Octave side of the post-processing. All I need to do is clean things up a bit to include in the repository, I will do this asap if it's likely to be helpful (I think it will be for Matlab users).

[t-osu]

Thanks @andermi and @hamilton8415. It's not creating a large difficulty, but would definitely make cases easier to keep track of instead of having to reference the batch_log.

@andermi, instead of the batch we can manually input parameters, good to know.
If I wanted to add parameters, they would as you said be input as param:=value, with the exception of defining the sea state?
So below, I have a scale factor of 1.0, closed doors, monochromatic wave, and my custom defined folder. Is this correct, or are quotation marks required for the other parameters?
ros2 launch buoy_gazebo mbari_wec.launch.py scale_factor:=1.0 door_state:=closed inc_wave_spectrum:="inc_wave_spectrum_type:MonoChromatic;A:1.0;T:6.0" pbloghome:=. pblogdir:=amp1_per6_results

But doing so this way would only allow you to run one case at a time, right?

You also stated that one could include an input list of filenames for every case. Are you referring to when running simulations using the batch file?
Thanks

[andermi]

input as param:=value, with the exception of defining the sea state?

Correct.

are quotation marks required for the other parameters?

No, the quotations are only escaping the special characters.

But doing so this way would only allow you to run one case at a time, right?

Yes, one case at a time.

You also stated that one could include an input list of filenames for every case. Are you referring to when running simulations using the batch file?

Something like this would have to be added to the code, but yes, for the batch.

[andermi]

osrf/mbari_wec_gz#158

will allow you to specify parameters in a vectorized mode rather than matrix (meshgrid) using the option in the yaml file matrix_mode: False. If the parameter arrays are not the same size, shorter arrays will be padded by repeating the last value (e.g. a single value will be repeated to match the length of the longest array).

In this way, you could know the parameters by the run number (as an index to each parameter array).