Fill alerts with (nonphysical) data to allow performance benchmarking

[mef51]

Hello,

I needed schema-compliant alerts with data in them for testing and performance benchmarking a database that stores LSST alerts, but the simulate.py in this package was defaulting to the 'null' type while parsing the schema. The result of this was alerts were generated essentially empty.

In order to make the simulated alerts useful for benchmarking I modified simulate_alert to default to non-null types and fill the alerts with essentially random data.

Another issue was the prvDiaSources array was always empty, and the arrayCount argument that simulate_alert accepts has no effect (actually, it causes a crash). So I've added an implementation that respects the arrayCount argument and fills the prvDiaSources array.

The last change was to add a min_bytes option to randomBytes and increase the max_bytes default for larger cutout sizes.

Our fork of this repo is used as a subcomponent in a broader tool for simulating alerts, but these changes may be useful upstream as well. If so, let me know if you'd like additional changes before merging.

Thanks for your time!

[bsmartradio]

Hi Mohammed,

Thank you for your interest in the alerts! At this time we are not actively developing the alert simulator, and were actually potentially going to retire it. Now that real alerts are available via the brokers, we encourage folks to use those alerts for testing and performance benchmarking. They will be far more representative than the simulated alerts.

You are welcome to continue developing the simulator if you feel like there is something else you need that you can't yet get from the brokers, but we aren't looking to add to the simulator at this time.

Cheers,
Brianna

[mef51]

Hi Brianna, okay, thank you for the info! Beyond benchmarking we are finding uses for simulated alerts in creating training sets for classifiers and testing pipelines that process the alert stream, so we will most likely keep maintaining our fork with these features. Thanks again.

[ebellm]

Hi @mef51, since simulator.py doesn't have any external dependencies on the package, you might find it easier to simply copy your own version rather than maintain a fork. As Bri noted, we prefer to use actual alert data for our sizing estimates at this point so we're likely to remove the simulator in the future.

[mef51]

Hi @ebellm, that makes sense, thanks for the tip. Will probably re-arrange things in that case