Add water mass tracking support to DVL

[hidmic]

A bottom tracking DVL sensor was introduced by #213, and now we need water mass tracking capabilities.

[hidmic]

@arjo129 @caguero @braanan @adityapande-1995 our current model for underwater currents is somewhat simplistic: a global constant velocity by default, can be modified globally during simulation. Science data includes water speed measurements we could reuse, though I'm not sure if these measurements get us full water column data.

How shall we go about this? If we go with science data (ie. the path of least resistance):

• Should we split data lookup functionality out of the science data plugin for reuse first?
• Should we use chlorophyll concentration to model beam reflectivity? Another step function would be fine, at least for starters.

[arjo129]

I guess we use the same method as our sensors. I'm leaning towards some form of refactor of the CTD sensors. My proposal is that we would put parsing logic in `gz-common` and reuse `VolumetricGridLookupField`. I also think we should implement a `TimeVaryingVolumetricGridLookupField` using `VolumetricGridLookUpField`. We should find a way of centralizing all the data as I suspect the in-memory format might get quite big and hosting multiple copies of it would be highly inefficient.

our current model for underwater currents is somewhat simplistic: a global constant velocity by default, can be modified globally during simulation.

This is not exactly true. The hydrodynamics plugin supports a per-model current. This means that we can modify the current on the fly for each vehicle based on the vehicle's position.

…

On Tue, 5 Jul 2022, 01:09 Michel Hidalgo, ***@***.***> wrote: @arjo129 <https:/arjo129> @caguero <https:/caguero> @braanan <https:/braanan> @adityapande-1995 <https:/adityapande-1995> our current model for underwater currents is somewhat simplistic: a global constant velocity by default, can be modified globally during simulation. Science data includes water speed measurements we could reuse, though I'm not sure if these measurements get us full water column data. How shall we go about this? If we go with science data (ie. the path of least resistance): - Should we split data lookup functionality out of the science data plugin for reuse first? - Should we use chlorophyll concentration to model beam reflectivity? Another step function would be fine, at least for starters. — Reply to this email directly, view it on GitHub <#223 (comment)>, or unsubscribe <https:/notifications/unsubscribe-auth/AAEEMQEQ3TFNJIX64ILLKNTVSMLDJANCNFSM52TYGG7A> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[hidmic]

My proposal is that we would put
parsing logic in gz-common and reuse VolumetricGridLookupField. I also
think we should implement a TimeVaryingVolumetricGridLookupField using
VolumetricGridLookUpField.

Sounds like a plan.

We should find a way of centralizing all the
data as I suspect the in-memory format might get quite big and hosting
multiple copies of it would be highly inefficient.

Agreed. Perhaps as a component?

The hydrodynamics plugin supports a per-model
current. This means that we can modify the current on the fly for each
vehicle based on the vehicle's position.

Ah, good point. I was thinking of a single vehicle. Either way, for the purposes of a DVL, my point is that we don't model the physics of the entire water column and thus there's nothing the sensor can retrieve.

[arjo129]

Agreed. Perhaps as a component?

In my mind a component works as long as we dont serialize the component along with the data. Serializing the data would be ☠️ . We will need to get all of these pieces in as draft PRs before jul 27th. While Im officially on reservist the next 3 weeks I can probably manage it.

[hidmic]

Done as of #241.