Add grib_tree method #399

emfdavid · 2023-11-24T18:02:52Z

Add an method to map grib2 data model to zarr hierarchy & xarray datatree

The method is opinionated about how to do this - there are many possible ways. I hope the is generally useful enough that it is worth adding to the kerchunk library.

See examples in Colab

Here is an example of the hierarchical structure for the eastward wind velocity variable which has been aggregated by step, time and level (isobaricInhPa).

martindurant

Do I understand that:

each branch of the tree is combined as usual
the branches have their keys copied into the right place in the overall output
special renaming of grib keys is going on

kerchunk/grib2.py

martindurant · 2023-11-27T21:28:14Z

kerchunk/grib2.py

+    # Hard code the filters in the correct order for the group hierarchy
+    filters = ["stepType", "typeOfLevel"]
+
+    zarr_store = {}


Allow for parquet/bring-your-own output?

Actually, we need to figure out how parquet works at all for deep nested data like this.

Since the hierarchy in zarr is just a path embedded in the key... it might must work.
If I want to add more tests, should I checkin some json output from scan_grib for a few variables?

martindurant · 2023-11-27T21:29:22Z

kerchunk/grib2.py

+
+    unknown_counter = 0
+    for msg_ind, group in enumerate(message_groups):
+        if "version" not in result:


Have you tested with zarr v3?

Is there a way to run scan_grib using zarr v3? As implemented, grib_tree is pretty tightly coupled on the output of scan_grib. I see you can set an ENV var to allow access to the experimental API...

Right, so version should always be 2? Or is this not the zarr version?

Ah - you are right - this is the kerchunk version, not the zarr version anyway.

martindurant · 2023-11-27T21:30:35Z

kerchunk/grib2.py

+            # https://confluence.ecmwf.int/display/UDOC/Creating+your+own+local+definitions+-+ecCodes+GRIB+FAQ
+            # If you process the groups from a single file in order, you can use the msg# to compare with the
+            # IDX file.
+            logger.warning(


Why not include the message about what to do in the logging?

Happy to put more of the answer in the log message - though I have not been successful in doing it myself... yet.
So far I have used the idx file to confirm that I am unlikely to need these unknown variables in my use case with HRRR and GFS grib2 files.

Example: gs://high-resolution-rapid-refresh/hrrr.20230928/conus/hrrr.t01z.wrfsfcf05.grib2
Msg # indexed from zero

Found unknown variable in msg# 1... it will be dropped Found unknown variable in msg# 2... it will be dropped Found unknown variable in msg# 37... it will be dropped Found unknown variable in msg# 38... it will be dropped Found unknown variable in msg# 42... it will be dropped Found unknown variable in msg# 44... it will be dropped ...

IDX file entries (messages indexed from 1)
Example: gs://high-resolution-rapid-refresh/hrrr.20230928/conus/hrrr.t01z.wrfsfcf05.grib2.idx

1:0:d=2023092801:REFC:entire atmosphere:5 hour fcst: 2:375155:d=2023092801:RETOP:cloud top:5 hour fcst: 3:517041:d=2023092801:var discipline=0 center=7 local_table=1 parmcat=16 parm=201:entire atmosphere:5 hour fcst: 4:889615:d=2023092801:VIL:entire atmosphere:5 hour fcst: 5:1157550:d=2023092801:VIS:surface:5 hour fcst: ... 37:24333077:d=2023092801:VGRD:1000 mb:5 hour fcst: 38:24956531:d=2023092801:MAXUVV:100-1000 mb above ground:4-5 hour max fcst: 39:25687250:d=2023092801:MAXDVV:100-1000 mb above ground:4-5 hour max fcst: 40:26410531:d=2023092801:DZDT:0.5-0.8 sigma layer:4-5 hour ave fcst: 41:27042519:d=2023092801:MSLMA:mean sea level:5 hour fcst: 42:27650201:d=2023092801:HGT:1000 mb:5 hour fcst: 43:28342907:d=2023092801:MAXREF:1000 m above ground:4-5 hour max fcst: 44:28588455:d=2023092801:REFD:263 K level:4-5 hour max fcst: 45:28736498:d=2023092801:MXUPHL:5000-2000 m above ground:4-5 hour max fcst: 46:28789333:d=2023092801:MNUPHL:5000-2000 m above ground:4-5 hour min fcst: ...

The metadata in the NOAA EMC generated idx files suggests we are missing local definitions for a number of variables that represent min, max or avg values over a layer. I have asked NOAA-EMC for help with decoding these properly.

OK, we can leave this for future improvement

Crickets over at NOAA-EMC... I think we might have a working rust gribberish reader before we get a clear answer on how to build the ecCodes tables for these unknown properties.
🤞 @mpiannucci

Yeah the tables are annoying, need to figure that out in rust too to be fully comprehensive

martindurant · 2023-11-27T21:31:10Z

kerchunk/grib2.py

+                    vname,
+                    msg_ind,
+                )
+                # Use unknown as a group or drop it?


Any cases like this?

From the same HRRR SFCF grib2 files discussed above re: unknown variables, here are two examples of unknown levels:
Example logs

Found 'unknown' attribute value for key typeOfLevel in var gh of msg# 161 Found 'unknown' attribute value for key typeOfLevel in var layth of msg# 164

Corresponding idx file entries.

162:129396944:d=2023092801:HGT:level of free convection:5 hour fcst: 165:135154615:d=2023092801:LAYTH:261 K level - 256 K level:5 hour fcst:

Are you saying that we should be able to decode them? The grib object has many many possble attributes, so this seems solvable. Not needed for this PR.

Yes - I believe these are just more custom codes, similar to the unknown variables above.
I think they are all documented and verifiable by reading the idx files, but implementing the tables for ecCodes to read them is more than I can take on right now...

Co-authored-by: Martin Durant <martindurant@users.noreply.github.com>

emfdavid

Thanks for diving in - I hope this can be useful.

each branch of the tree is combined as usual

Yes - each variable can have different level values so only the branches can be combined in general

the branches have their keys copied into the right place in the overall output

Yes - similar to what you do in scan_grib, I am just adding a path for the zarr hierarchy.

special renaming of grib keys is going on

I did make copies of some attributes (name, stepType and typeOfLevel) to help users understand the hierarchy. I don't think I actually renamed any existing metadata. The implementation is opinionated about the grib level and grib step attributes as well as the coordinate names.

I would love to have more ECMWF data to test generality with.

emfdavid · 2023-11-27T22:23:30Z

kerchunk/grib2.py

+            # https://confluence.ecmwf.int/display/UDOC/Creating+your+own+local+definitions+-+ecCodes+GRIB+FAQ
+            # If you process the groups from a single file in order, you can use the msg# to compare with the
+            # IDX file.
+            logger.warning(


Happy to put more of the answer in the log message - though I have not been successful in doing it myself... yet.
So far I have used the idx file to confirm that I am unlikely to need these unknown variables in my use case with HRRR and GFS grib2 files.

Example: gs://high-resolution-rapid-refresh/hrrr.20230928/conus/hrrr.t01z.wrfsfcf05.grib2
Msg # indexed from zero

Found unknown variable in msg# 1... it will be dropped Found unknown variable in msg# 2... it will be dropped Found unknown variable in msg# 37... it will be dropped Found unknown variable in msg# 38... it will be dropped Found unknown variable in msg# 42... it will be dropped Found unknown variable in msg# 44... it will be dropped ...

IDX file entries (messages indexed from 1)
Example: gs://high-resolution-rapid-refresh/hrrr.20230928/conus/hrrr.t01z.wrfsfcf05.grib2.idx

1:0:d=2023092801:REFC:entire atmosphere:5 hour fcst: 2:375155:d=2023092801:RETOP:cloud top:5 hour fcst: 3:517041:d=2023092801:var discipline=0 center=7 local_table=1 parmcat=16 parm=201:entire atmosphere:5 hour fcst: 4:889615:d=2023092801:VIL:entire atmosphere:5 hour fcst: 5:1157550:d=2023092801:VIS:surface:5 hour fcst: ... 37:24333077:d=2023092801:VGRD:1000 mb:5 hour fcst: 38:24956531:d=2023092801:MAXUVV:100-1000 mb above ground:4-5 hour max fcst: 39:25687250:d=2023092801:MAXDVV:100-1000 mb above ground:4-5 hour max fcst: 40:26410531:d=2023092801:DZDT:0.5-0.8 sigma layer:4-5 hour ave fcst: 41:27042519:d=2023092801:MSLMA:mean sea level:5 hour fcst: 42:27650201:d=2023092801:HGT:1000 mb:5 hour fcst: 43:28342907:d=2023092801:MAXREF:1000 m above ground:4-5 hour max fcst: 44:28588455:d=2023092801:REFD:263 K level:4-5 hour max fcst: 45:28736498:d=2023092801:MXUPHL:5000-2000 m above ground:4-5 hour max fcst: 46:28789333:d=2023092801:MNUPHL:5000-2000 m above ground:4-5 hour min fcst: ...

The metadata in the NOAA EMC generated idx files suggests we are missing local definitions for a number of variables that represent min, max or avg values over a layer. I have asked NOAA-EMC for help with decoding these properly.

emfdavid · 2023-11-27T22:25:59Z

kerchunk/grib2.py

+                    vname,
+                    msg_ind,
+                )
+                # Use unknown as a group or drop it?


From the same HRRR SFCF grib2 files discussed above re: unknown variables, here are two examples of unknown levels:
Example logs

Found 'unknown' attribute value for key typeOfLevel in var gh of msg# 161 Found 'unknown' attribute value for key typeOfLevel in var layth of msg# 164

Corresponding idx file entries.

162:129396944:d=2023092801:HGT:level of free convection:5 hour fcst: 165:135154615:d=2023092801:LAYTH:261 K level - 256 K level:5 hour fcst:

emfdavid · 2023-11-27T22:32:46Z

kerchunk/grib2.py

+
+    unknown_counter = 0
+    for msg_ind, group in enumerate(message_groups):
+        if "version" not in result:


Is there a way to run scan_grib using zarr v3? As implemented, grib_tree is pretty tightly coupled on the output of scan_grib. I see you can set an ENV var to allow access to the experimental API...

emfdavid · 2023-11-27T22:50:23Z

kerchunk/grib2.py

+    # Hard code the filters in the correct order for the group hierarchy
+    filters = ["stepType", "typeOfLevel"]
+
+    zarr_store = {}


Since the hierarchy in zarr is just a path embedded in the key... it might must work.
If I want to add more tests, should I checkin some json output from scan_grib for a few variables?

emfdavid · 2023-11-27T23:00:12Z

kerchunk/grib2.py

+        if "step/.zarray" not in group["refs"]:
+            group = copy.deepcopy(group)
+            logger.warning("Adding missing step variable to group path %s", path)
+            group["refs"]["step/.zarray"] = (


Can I put this in scan_grib where the cfgrib WrongStepUnitError is handled?
I don't like doing this here. Another alternative would be to use the preprocess hook in MultiZarrToZarr?
We should be able to calculate the correct step value by subtracting the valid_time from the time (reference time).
That requires decoding those values though and then encoding the step correctly...

In the HRRR SubHF dataset, even the step values that are decoded (don't raise an exception) are wrong.

scans = scan_grib("gs://high-resolution-rapid-refresh/hrrr.20210928/conus/hrrr.t00z.wrfsubhf01.grib2") dsets = [] zsets = [] vname = "dswrf" for gg in scans: if f"{vname}/.zattrs" in gg['refs']: fs = fsspec.filesystem("reference", fo=gg) dsets.append(xr.open_dataset(fs.get_mapper(""), engine="zarr", consolidated=False)) zsets.append(zarr.open_group(fs.get_mapper(""))) for ds, zs in zip(dsets, zsets): print( f"{ds[vname].attrs['GRIB_stepType']}, zs units {zs.step.attrs['units'] if 'step' in ds else None}: " f"ds step - {ds.step.values[()].astype('timedelta64[h]') if 'step' in ds else None}, zs step - {zs.step[()] if 'step' in zs else None};" f" valid_time - {ds.valid_time.values[()]}; time - {ds.time.values[()]}" )

avg, zs units None: ds step - None, zs step - None; valid_time - 2021-09-28T00:15:00.000000000; time - 2021-09-28T00:00:00.000000000 instant, zs units hours: ds step - 15 hours, zs step - 15.0; valid_time - 2021-09-28T00:15:00.000000000; time - 2021-09-28T00:00:00.000000000 avg, zs units hours: ds step - 30 hours, zs step - 30.0; valid_time - 2021-09-28T00:30:00.000000000; time - 2021-09-28T00:00:00.000000000 instant, zs units hours: ds step - 30 hours, zs step - 30.0; valid_time - 2021-09-28T00:30:00.000000000; time - 2021-09-28T00:00:00.000000000 avg, zs units hours: ds step - 45 hours, zs step - 45.0; valid_time - 2021-09-28T00:45:00.000000000; time - 2021-09-28T00:00:00.000000000 instant, zs units hours: ds step - 45 hours, zs step - 45.0; valid_time - 2021-09-28T00:45:00.000000000; time - 2021-09-28T00:00:00.000000000 avg, zs units hours: ds step - 60 hours, zs step - 60.0; valid_time - 2021-09-28T01:00:00.000000000; time - 2021-09-28T00:00:00.000000000 instant, zs units hours: ds step - 1 hours, zs step - 1.0; valid_time - 2021-09-28T01:00:00.000000000; time - 2021-09-28T00:00:00.000000000

The values are in floating point minute but the units are specified as hours.
Only the stepType instant for the end of the forecast is correct - 1 hour.

emfdavid · 2023-11-29T04:34:44Z

Not sure how to fix the Docs check but I think the rest of this is in pretty good shape!

TomNicholas · 2023-11-29T21:13:39Z

@jthielen you might be interested in this

martindurant · 2023-11-30T15:52:20Z

kerchunk/combine.py

+            if "fill_value" not in kw:
+                if data.dtype.kind == "i":
+                    kw["fill_value"] = None
+                elif k in z:


How can this be true when we create the dataset in a couple of lines below?

This is getting the fill_value attribute from the coordinate zarr array instance.
Without the if clause I got errors on some existing tests I think... so I copied the if clause used for copying the attributes (new line 329).
The change is important because timedeltas stored as float are given a default fill_value of 0.0 without this change which becomes NaT when read with xarray. Meaning you can't have a zero timedelta.

martindurant · 2023-11-30T15:54:08Z

kerchunk/grib2.py

+
+    unknown_counter = 0
+    for msg_ind, group in enumerate(message_groups):
+        if "version" not in result:


Right, so version should always be 2? Or is this not the zarr version?

martindurant · 2023-11-30T15:55:02Z

kerchunk/grib2.py

+            # https://confluence.ecmwf.int/display/UDOC/Creating+your+own+local+definitions+-+ecCodes+GRIB+FAQ
+            # If you process the groups from a single file in order, you can use the msg# to compare with the
+            # IDX file.
+            logger.warning(


OK, we can leave this for future improvement

martindurant · 2023-11-30T15:56:08Z

kerchunk/grib2.py

+                    vname,
+                    msg_ind,
+                )
+                # Use unknown as a group or drop it?


Are you saying that we should be able to decode them? The grib object has many many possble attributes, so this seems solvable. Not needed for this PR.

kerchunk/grib2.py

Co-authored-by: Martin Durant <martindurant@users.noreply.github.com>

emfdavid

@martindurant Thanks for taking a pass on this.
Do you want to add xarray_datatree as a dev dependency for kerchunk so we can make some additional tests?
Thank you for your work on datatree @TomNicholas any thoughts on how I am using or abusing datatree here?

emfdavid · 2023-11-30T16:08:57Z

kerchunk/combine.py

+            if "fill_value" not in kw:
+                if data.dtype.kind == "i":
+                    kw["fill_value"] = None
+                elif k in z:


This is getting the fill_value attribute from the coordinate zarr array instance.
Without the if clause I got errors on some existing tests I think... so I copied the if clause used for copying the attributes (new line 329).
The change is important because timedeltas stored as float are given a default fill_value of 0.0 without this change which becomes NaT when read with xarray. Meaning you can't have a zero timedelta.

kerchunk/grib2.py

emfdavid · 2023-11-30T16:10:55Z

kerchunk/grib2.py

+
+    unknown_counter = 0
+    for msg_ind, group in enumerate(message_groups):
+        if "version" not in result:


Ah - you are right - this is the kerchunk version, not the zarr version anyway.

emfdavid · 2023-11-30T16:13:20Z

kerchunk/grib2.py

+            # https://confluence.ecmwf.int/display/UDOC/Creating+your+own+local+definitions+-+ecCodes+GRIB+FAQ
+            # If you process the groups from a single file in order, you can use the msg# to compare with the
+            # IDX file.
+            logger.warning(


Crickets over at NOAA-EMC... I think we might have a working rust gribberish reader before we get a clear answer on how to build the ecCodes tables for these unknown properties.
🤞 @mpiannucci

emfdavid · 2023-11-30T16:16:00Z

kerchunk/grib2.py

+                    vname,
+                    msg_ind,
+                )
+                # Use unknown as a group or drop it?


Yes - I believe these are just more custom codes, similar to the unknown variables above.
I think they are all documented and verifiable by reading the idx files, but implementing the tables for ecCodes to read them is more than I can take on right now...

martindurant · 2023-11-30T16:40:05Z

Do you want to add xarray_datatree as a dev dependency for kerchunk so we can make some additional tests?

That's fine, add it to the CI envs. Having it in the optional package requirements is fine too, but not necessary (this is experimental, after all).

emfdavid · 2023-11-30T17:29:34Z

this is experimental, after all

Isn't it all experimental, after all?

martindurant · 2023-11-30T18:34:13Z

Isn't it all experimental, after all?

Some bits are more experimental than others :)

emfdavid · 2023-11-30T19:04:29Z

@martindurant Still not sure what do about the docs build failure here?
https://github.com/fsspec/kerchunk/actions/runs/7050805133/job/19192272139?pr=399

martindurant · 2023-11-30T19:08:03Z

the docs build failure

I don't know either, except that the install raises a number of incompatibility warnings from pip. ammaraskar/sphinx-action@master doesn't appear to have changed, but it is somewhat dated - perhaps we need a concrete environment and run sphinx ourselves.

emfdavid · 2023-11-30T21:42:58Z

Interesting... if I try to access the valid time coordinates from a non square aggregation e.g.

sfcf_scans = scan_grib("testdata/hrrr.t00z.wrfsfcf00.grib2")
sfcf_scans += scan_grib("testdata/hrrr.t00z.wrfsfcf01.grib2")
sfcf_scans += scan_grib("testdata/hrrr.t01z.wrfsfcf00.grib2")

That is two forecast reference times, one of which as two steps and the other only has one step... we get some bad missing values in the valid time.

Where as if I combine outputs for two steps from each reference time...

sfcf_scans = scan_grib("testdata/hrrr.t00z.wrfsfcf00.grib2")
sfcf_scans += scan_grib("testdata/hrrr.t00z.wrfsfcf01.grib2")
sfcf_scans += scan_grib("testdata/hrrr.t01z.wrfsfcf00.grib2")
sfcf_scans += scan_grib("testdata/hrrr.t01z.wrfsfcf01.grib2")

Maybe this is a behavior we could fix in MultiZarrToZarr to fill in NaN or NaT missing coordinate? I think the order in which you aggregate can also be important, but I am not sure why?

andreall · 2023-12-01T09:42:56Z

Hi! I'm just getting started in the kerchunk and fsspec world and wanted to do fsspec on our grib files from WRF model. I was having a look at the colab notebook but I'm not sure how to implement it in my files...do I need to implement the correct_hrrr_subhf_step for my structure? Is there a docs I am missing? Thanks!!!

emfdavid · 2023-12-01T14:36:49Z

do I need to implement the correct_hrrr_subhf_step for my structure?

@andreall hopefully that is only required for the quirky bad step values in the HRRR Subhourly 2D Surface data. I don't think you will have this problem.

I suggest you try it for one grib file and see what you get - look at the valid_time, step and time coordinates as and see if it is working properly.

something like this...

scans = scan_grib("myfile.grib2")
ref_store = grib_tree(scans)
fs = fsspec.filesystem("reference", fo=ref_store)
zg = zarr.open_group(fs.get_mapper(""))
dt = datatree.open_datatree(fs.get_mapper(""), engine="zarr", consolidated=False)

The colab and the code comments are all I have for docs right now, but if this PR is merged I will help support it.

martindurant · 2023-12-01T14:39:01Z

Question: xarray now supports engine="kerchunk" (plugin in this repo) which would combine the equivalent of the last three lines above. Is there some plugin point like that for datatree too?

emfdavid · 2023-12-01T16:03:42Z

Is there some plugin point like that for datatree too?

Looks like not yet?

martindurant · 2023-12-01T16:05:14Z

I'm sure we could suggest it

emfdavid · 2023-12-01T17:45:37Z

@martindurant pushed one more commit
Ran into issues using/testing the reference spec stores with byte values inside.
If there is a reason we need bytes I can roll this back, but I think you get back string anyway if you write/read it as json anyway?
If there is a way to fix this so the values are not created as bytes in the first place that would be ideal... it seems like the store data created by zarr with create_group and attr setter end up as binary consistent with the zarr spec but we end up with a mix of string/bytes in kerchunk - all string values, once you write/read it as json.

martindurant · 2023-12-01T18:07:11Z

In JSON, the values are indeed strings on-disk, which become bytes when read by the filesystem: either as ascii, or base64 encoded. In memory (dicts), bytes, ascii strings or base64 strings should all work. Parquet, by contrast, stores bytes only.

keewis · 2023-12-04T10:22:45Z

I'm sure we could suggest it

See pydata/xarray#7437 (on the xarray repo because we've been thinking of merging datatree into xarray for quite a while now)

martindurant · 2023-12-04T16:40:27Z

Merging this now, let's see what use it gets. We can always fix things for cases of gribs that are just a bit different from those trialed.

Add grib_tree method

cee6410

emfdavid mentioned this pull request Nov 24, 2023

add prototype code asascience-open/nextgen-dmac#56

Closed

martindurant reviewed Nov 27, 2023

View reviewed changes

Update kerchunk/grib2.py

8c2ba42

Co-authored-by: Martin Durant <martindurant@users.noreply.github.com>

emfdavid commented Nov 27, 2023

View reviewed changes

emfdavid added 2 commits November 28, 2023 04:21

Improve log message

a91a1ca

Fix hrrr subhf step and add tests

3f6b93c

emfdavid force-pushed the grib_tree branch from 5809526 to 3f6b93c Compare November 29, 2023 04:10

emfdavid added 3 commits November 29, 2023 04:19

Fix docs

6e0eac3

Remove debug logging

52fdcef

Add todo for passing out argument

0b22a2d

emfdavid requested a review from martindurant November 29, 2023 04:32

martindurant reviewed Nov 30, 2023

View reviewed changes

Update kerchunk/grib2.py

7f17999

Co-authored-by: Martin Durant <martindurant@users.noreply.github.com>

emfdavid commented Nov 30, 2023

View reviewed changes

add xarray-datatree and test

37c65ce

emfdavid requested a review from martindurant November 30, 2023 17:15

Fix asserts

cf63ed4

Decode all stored bytes as string. Assert ref spec version 1.

229c3da

martindurant merged commit 37d7526 into fsspec:main Dec 4, 2023
4 of 5 checks passed

emfdavid deleted the grib_tree branch December 4, 2023 16:40

This was referenced Feb 2, 2024

Add dynamic_zarr_store module asascience-open/nextgen-dmac#57

Merged

Kerchunk enhancements for Fast NODD Grib Aggregations ioos/gsoc#42

Open

TomNicholas mentioned this pull request Mar 8, 2024

datatree backend for opening grib files zarr-developers/VirtualiZarr#11

Open

nishadhka mentioned this pull request May 8, 2024

Intitial condition data from open data buckets and using Kerchunk/Dynamic zarr method secondlaw-ai/skyrim#11

Open

Add grib_tree method #399

Add grib_tree method #399

Conversation

emfdavid commented Nov 24, 2023 • edited Loading

Add an method to map grib2 data model to zarr hierarchy & xarray datatree

martindurant left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

emfdavid left a comment • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

emfdavid commented Nov 29, 2023

TomNicholas commented Nov 29, 2023

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

emfdavid left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

martindurant commented Nov 30, 2023

emfdavid commented Nov 30, 2023

martindurant commented Nov 30, 2023

emfdavid commented Nov 30, 2023

martindurant commented Nov 30, 2023

emfdavid commented Nov 30, 2023

andreall commented Dec 1, 2023 • edited Loading

emfdavid commented Dec 1, 2023

martindurant commented Dec 1, 2023

emfdavid commented Dec 1, 2023

martindurant commented Dec 1, 2023

emfdavid commented Dec 1, 2023

martindurant commented Dec 1, 2023

keewis commented Dec 4, 2023

martindurant commented Dec 4, 2023

emfdavid commented Nov 24, 2023 •

edited

Loading

emfdavid left a comment •

edited

Loading

andreall commented Dec 1, 2023 •

edited

Loading