`FieldSet.from_copernicusmarine()` and non-advection kernels

[j-atkins]

cc @erikvansebille

I've started experimenting with the new from_copernicusmarine() functionality in v4-dev (#2230) and realised that in its current implementation it does not support non-advection kernels.

To elaborate, from_copernicusmarine()detects U and V variables. However, in use cases such as a CTD_BGC instrument in VirtualShip there are no advection kernels. This raises the potential issue that from_copernicusmarine() is assuming that all users will be advecting their particles. Whereas it's possible that this won't always be the case?

@VeckoTheGecko 's suggestion is that the method is renamed to something like from_copernicusmarine_currents() to be explicit about what this specific function does.

Alternatively, is there scope to handle non-advection scenarios in from_copernicusmarine() or a new method? I'd be happy to help out with this but also appreciate there could be more pressing jobs in the v4 pipeline, especially considering this could be solved for now by simply renaming the method.

[VeckoTheGecko]

is there scope to handle non-advection scenarios in from_copernicusmarine() or a new method?

The main thing this would do is still discover lon, lats, depth and time from CF convention naming. I do wonder in the future though how (if at all) this would differ from .from_a_grid_dataset or something similar

[erikvansebille]

Yes, we could rename to from_copernicusmarine_currents(), but users may then assume they can only load currents.

The alternative is to only add the U and V fields when they are present. So

diff --git a/parcels/fieldset.py b/parcels/fieldset.py
index 1dec1dd3..28c2e907 100644
--- a/parcels/fieldset.py
+++ b/parcels/fieldset.py
@@ -229,17 +229,14 @@ class FieldSet:
             )
         )
 
-        U = Field("U", ds["U"], grid)
-        V = Field("V", ds["V"], grid)
-
-        U.units = GeographicPolar()
-        V.units = Geographic()
-
-        fields = {"U": U, "V": V}
+        fields = {}
         for varname in set(ds.data_vars) - set(fields.keys()):
             fields[varname] = Field(varname, ds[varname], grid)
 
         if "U" in fields and "V" in fields:
+            fields["U"].units = GeographicPolar()
+            fields["V"].units = Geographic()
+
             if "W" in fields:
                 fields["UVW"] = VectorField("UVW", fields["U"], fields["V"], fields["W"])
             else:

Since v4 also (should) support Fieldsets without U and V, the only thing that would happen to a user is that they can't run the built-in the advection kernels. But maybe we should leave that responsibility with them?

Or, if we want to help them, we could provide an info message that there are no U and V in the copernicusmarine dataset?

[VeckoTheGecko]

The alternative is to only add the U and V fields when they are present

This sounds good

we should leave that responsibility with them?

Yes :)

As another note, @j-atkins I think its worth suppressing these sort of logging messages within VirtualShip as they are not useful to the user - instead having your own logging. On error, the full logs can be printed in case the parcels ones are of interest. Happy to discuss more - let's track it in VirtualShip