store hydrography

[vbartolino]

Where to store hydrographic variables other than temperature? Also when it comes to temperature, we may have different temperature measurements (ie bottom, water column, surface) to be stored separately.

My feeling is that in practice 'mfdb_import_survey_index' could serve approx for the purpose... What about duplicate that function with a different name?

[lentinj]

Yes, you're right on all counts. In reality temperature data is also imported with mfdb_import_survey_index, but of course the function name isn't entirely accurate.

Having multiple definitions of temperature would make sense. We could instead record the depth of the measurement at area, but I suspect that would just create more work for ourselves having to know how deep each area is, when all we really wanted to find out is "the bottom one".

I meant to ask about what GADGET requires in terms of temperature (there's no mention of where it expects the temperature measurement to take place). Do you know?

[vbartolino]

I agree, better to avoid to implement depth mfdb.

Different fish stocks may be linked to different environmental temperatures. For instance:

• Baltic cod --> near the bottom
• Baltic sprat --> water column

That's why storing different measures and pointing to variable of interest. As far as I know in Gadget the effect of temperature is implemented in some growth functions and in the consumption. But I suppose in principle we may use an external variable in many other processes (recruitment? maturation?)

My feeling is that we could store all the relevant hydrographic variables and point to the specific one of interest whenever needed.

[bthe]

Temperature measurements are used in, as @vbartolino said, in the consumption and growth. The area definition is of course abstract, i.e. depth layers within a region could be set up as different gadget areas. So in theory one could define areas in terms of depth ranges and as a collection of squares. It is therefor unclear what is required.

My problem with this is that I actually have a hard time to see how the current setup for temperature is actually useful unless processed in some form such as through averages from a oceanographic model. Consumption, for instance, would follow the temperature in the cube where the fish finds it self when it eats + the temperature the areas where it has been. The measurements of temperature are however few and far between.

I think however it is more useful as a time-series that could be added to the definition of TimeVariables in Gadget, or migration/renewal/spawning, but the use cases may vary dramatically be between models.

So in essence it is useful to store the data, but the usecases are still fairly undefined as very few have "flipped the switch" on this functionality in Gadget.

[lentinj]

@bthe resurrecting this issue to talk about adding depth to survey_index (which has also come up above, and we discounted it).

When we talked recently about it, we were wondering about using an mfdb_step_interval or somesuch to aggregate by tow_depth, and survey_index depth. I don't think this would work in reality, the join required is a bit of a headache without having to then shoehorn it through MFDB abstractions.

What would be a lot easier is if survey_index stored a depth interval rather than a single depth. Then we can use any survey_index where the tow_depth sits within their depth intervals. But could you assign intervals sensibly to source data? For atlantis-generated temperature you already have the depth boxes, so it'd work nicely there, but I'm guessing real-world data isn't quite so neat.

[bthe]

I can't see why depth intervals wouldn't work, 90% of the use cases would be a generic "bottom" and "surface" temperature. What is in between those queries we would most likely be thinking about (e.g. 50 or 100 m) depth intervals anyways.

[lentinj]

Depth intervals are definitely the way to go, but for the bottom/surface case it's easiest just to indicate that in the name and be done with it. So shall leave this until a definite use case appears (probably due to importing Atlantis data).