Propagation Frequencies

[Tibonium]

When a sensor receives an update it then calls run_wave_generator() and within this call it creates a wavefront and propagates it. At this time, the sensor passes in the _source->frequencies() as the wavefront frequencies. What happens for the following:

1) _source is not defined, ie the sensor is a receiver only 2) when the sensor is a receiver only what are the correct frequencies to use for propagation?

[campreilly]

That is an excellent question; clearly something that we missed.

I was confused at first because I forgot that _source is a reference to source_params and that _receiver is a reference to _receiver_params.

[campreilly]

Here are my notes from this morning discussion of a long term solution.

• Move the frequencies property from the sensor_params class to the sensor_model class.
  • Use this as the frequency for generating eigenrays and eigenverbs in wavefront_generator.
  • The sensor_model object is responsible for creating and destroying the memory for its frequencies property. The wave_queue will no longer destroy this memory on behalf of the caller. Most users of this data can use a simple pointer instead of cloning the frequencies.
  • Use a this as the frequency axis when creating beam_pattern_grid objects for this asset.
  • Use this as the frequency for determining frequency overlap when creating sensor_pair objects. Assume that the first frequency in the sensor is the low end of the spectrum and that the last frequency is the high end of the spectrum.
  • When creating sensors from EVAR assets, manipulate the frequencies property such that the band is limited by [MinActiveFreq,MaxActiveFreq]. If [MinActiveFreq,MaxActiveFreq] is larger than the the define frequency band, the band is extended to cover [MinActiveFreq,MaxActiveFreq].
  • Avoid using seq_data for this frequency property. The seq_linear and seq_log perform interpolation much faster. Adding additional smarts at creation time could save a lot of computing in highly multistatic scenarios.
• Add a frequency property to sensor_pair.
  • At the time that the sensor_pair is created, define its frequency property as the intersection of the source and receiver frequency properties.
  • The sensor_model object is responsible for creating and destroying the memory for its frequencies property. The wave_queue will no longer destroy this memory on behalf of the caller. Most users of this data can use a simple pointer instead of cloning the axis.
  • Use this as the frequency for generating envelopes in envelope_generator.
  • During envelope generation, the source and receiver's eigenverbs will need to be interpolated onto the sensor_pair's list of frequencies.
  • When fathometers are received from either sensor_model, they will need to be interpolated onto the sensor_pair's list of frequencies. We'll need to be very clever to understand how to optimize this interpolation.
  • When a request for reverberation fathometers or eigenverbs comes in from the sonar_training_system, the values stored in the sensor_pair will need to be interpolated onto the frequency axis defined in the request. This axis may not be the same as the one stored in the sensor_pair. We'll need to be very clever to understand how to optimize this interpolation.
  • Avoid using seq_data for this frequency property. The seq_linear and seq_log perform interpolation much faster. Adding additional smarts at creation time could save a lot of computing in highly multistatic scenarios.
• Add the ability to cache the beam level, as a function of frequency, for each eigenverb.
  • Using the frequencies stored in each sensor_model.
  • This prevents us from recomputing beam levels in highly multistatic scenarios.

[campreilly]

Re-reading the EVA spec indicates that

• The frequencies for the sensor_pair should be those source frequencies that are inside the frequency band of the receiver.
• These are the frequencies used to return reverberation envelopes and fathometers to the sonar training system.
• There is no requirement to interpolate reverberation envelopes and fathometers to frequencies other than those defined when the sensor_pair was created.
• The EVA specification includes the ability to support multiple source beams. I made a mistake and we'll need to fix that.

[Tibonium]

So should the "frequencies" part of the wavefront be the intersection of every frequency band of the "targets" and the "source"? And then when the eigenrays are passed to the pair, we cherry-pick the intensities and phases that are valid for this pair?

[campreilly]

The wavefront will only knows the frequencies for one sensor. The sensor_pair starts with a copy of the source frequencies, but then deletes frequencies that are out of the receiver ban. That trimming should effect the sensor_pair's fathometers and envelopes, but not the sensor_model's eigenrays and eigenverbs.

[Tibonium]

I believe we have found out that the above comment is actually in reverse? The source frequencies are clipped to the receiver?

[campreilly]

Based on the emails with John P. today, the source frequencies should be clipped to the receiver.

[islanderjtn]

Pull Request #173 Relocate Frequencies closes all the following:

• Added seq_linear frequencies property to sensor_model manipulated by min/max active frequencies.
• Added beam_list to source_params.
• Changed sensor_pair to hold fathometer_model vs eigenrays.
• Added std::vector frequencies property to sensor_pair based on the intersection of receiver frequencies and source frequencies.
• Added to sensor_manager_test to verify changes. Opened new issue #174 Interpolate Frequencies for items that were not addresses by Pull Request #173.