MDF/MOSAiC forcing options #500

davidclemenssewall · 2024-09-24T20:24:48Z

For detailed information about submitting Pull Requests (PRs) to the CICE-Consortium,
please refer to: https://github.com/CICE-Consortium/About-Us/wiki/Resource-Index#information-for-developers

PR checklist

Observational data presents the following complications:

Missing values. Real observational datasets almost always have missing values (power loss, radiometer dome iced over, etc...). Furthermore, future versions of the observational datasets may fill some of these missing values (e.g., by reprocessing data that previously failed qc).
Variable frequencies. Different data streams may be measured at different sampling frequencies. Data might be measured more often than the model's timestep (thus requiring aggregation) or less often (thus requiring interpolation).
Different start and end time points. Different data streams may have different start or end times, and updated versions of datasets may extend the time domain.
Merged observational datasets are a work-in-progress. The 3 challenges above all touch on the fact that for sea ice field campaigns, it can take years from the end of the campaign until a truly finalized observational dataset is available to force Icepack with (e.g., MOSAiC is 4 years and counting, SHEBA still does not have such a dataset). We still want to be able to use campaign data to support Icepack development during this time, without having to change the Icepack driver every time the forcing dataset is updated.

Additionally, for comparing with field data it is very useful to be able to easily adjust:

The initial state of the sea ice and ocean mixed layer.
Fixed values for the oceanic heat flux convergence (qdp) and sea surface salinity (sss).

To address these challenges the PR provides the following features:

Precalculate the forcing values at each timestep on initialization (in init_forcing). The current paradigm for forcing data in Icepack is that when init_forcing is called, a subroutine for the specific dataset (e.g., atm_CFS) stores the forcing data in the *_data in essentially the same format that the raw data is present in, without timestamp information. It also hardcodes the maximum size that a forcing dataset can be to 8760. Then, at each timestep the get_forcing subroutine has a code block for each forcing dataset that contains the timestamp information and interpolates the forcing data to the given timestep. Under this paradigm, I could not figure out a graceful way to handle missing values, nor forcing data with higher sampling frequency than the Icepack timestep, nor changing start times of the forcing dataset. This PR adds a new option, precalc_forc, for use with the MOSAiC forcing. When precalc_forc = .true., the forcing data is aggregated/interpolated to the Icepack timestep in the call to init_forcing and stored the the *_data arrays. Then, the get_forcing subroutine merely indexes into the *_data arrays.
Read forcing data from MDF-formatted netCDF files (Uttal et al. 2024; https://doi.org/10.5194/gmd-17-5225-2024, https://gitlab.com/mdf-makers/mdf-toolkit). I chose this format because its framework seemed well-aligned, but it is still in development so we can add variables to it that we need for the ice model (e.g., mixed layer depth).
To handle variable frequencies and missing data, forcing data are first temporally-averaged for each timestep and then interpolated. For a give data variable (var_data), The MOSAiC_average subroutine takes the average of all forcing datapoints within each timestep +- 0.5 dt excluding missing values and stores the results in var_data. If there is no valid data within 0.5 dt of a given timestep (e.g., most timesteps if the model timestep is much smaller than the sampling period) then a missing value is placed in var_data(timestep). Then, the MOSAiC_interpolate subroutine linearly interpolates missing values in var_data.
The option to explicitly set in the namelist the initial ice and snow thicknesses for the slab and ITD grid cells and the SST for the 3 ice grid cells.
The option to explicitly set in the namelist fixed ocean mixed layer conditions qdp_fixed, sss_fixed, and hmix_fixed. These are overwritten by forcing data.

Outstanding issues:

~~Automatically detect cadence of the inputs and adjust accordingly (currently the code requires that the atmospheric forcing is at 1 minute cadence and that the oceanic forcing is at daily cadence)~~
~~It is not obvious to a user that setting the atmospheric forcing (atm_data_type = 'clim') can overwrite the oceanic heat flux convergence.~~
~~The atm_MOSAiC and ocn_MOSAiC subroutines are nearly identical except for the data variables. It would probably be cleaner to combine them into a single subroutine.~~
~~Perhaps input checking should be added to prevent users from setting precalc_forc = .true. with non MOSAiC forcings.~~
~~Update documentation to include:~~
- ~~How driver handles MDF formatted forcing~~
- ~~MOSAiC forcing~~
- ~~Initial ice and SST conditions in namelist~~
- ~~Fixed ocean mixed layer conditions in namelist~~
~~Add warning in log for if MOSAiC time domain includes leg 4-5 transition (observatory relocation)~~
Add MOSAiC test case
Add link to MOSAiC forcing data to wiki

…gfault

Just updating for_igs to consortium main. Only conflict was in icedrv_init use section

…onsortium main

…names

…in filenames

davidclemenssewall · 2024-09-24T21:14:24Z

@apcraig When I try running the base_suite on Windows Subsystem for Linux (-m conda -e linux), I fail the run stage for the conda_linux_smoke_col_1x1_alt03_debug_run1year and conda_linux_smoke_col_1x1_alt04_debug_run1year tests due to a floating-point exception. I've copied the relevant sections from the runlog below. Strangely, this error does not arise in the GH macos-testing. It also does not occur when I run these tests with the main branch locally on WSL. So it seems to be some combination of the platform and the code changes, although I cannot see how these code changes in the driver cause this error in the atmospheric stability. I was hoping you might have a suggestion on how I can fix this. Thanks!

Tail from the icepack runlog:

  Initial forcing data year =         2015
  Final   forcing data year =         2015
 Reading /root/icepack-dirs/input/Icepack_data/forcing/SHEBA/open_clos_lindsay.dat                                      


Program received signal SIGFPE: Floating-point exception - erroneous arithmetic operation.

Backtrace for this error:
#0  0x7f05dd5e951f in ???
#1  0x557a0eb656c2 in compute_stability_parameter
        at /root/code/CICE/Icepack/columnphysics/icepack_atmo.F90:992
#2  0x557a0eb67de2 in atmo_boundary_layer
        at /root/code/CICE/Icepack/columnphysics/icepack_atmo.F90:276
#3  0x557a0eb65d98 in __icepack_atmo_MOD_icepack_atm_boundary
        at /root/code/CICE/Icepack/columnphysics/icepack_atmo.F90:954
#4  0x557a0eaf4c59 in __icedrv_step_MOD_ocean_mixed_layer
        at /root/code/CICE/Icepack/configuration/driver/icedrv_step.F90:1251
#5  0x557a0ea69c25 in coupling_prep
        at /root/code/CICE/Icepack/configuration/driver/icedrv_RunMod.F90:303
#6  0x557a0ea6d57b in __icedrv_runmod_MOD_ice_step
        at /root/code/CICE/Icepack/configuration/driver/icedrv_RunMod.F90:221
#7  0x557a0ea6d6dc in __icedrv_runmod_MOD_icedrv_run
        at /root/code/CICE/Icepack/configuration/driver/icedrv_RunMod.F90:57
#8  0x557a0ea6944d in icedrv
        at /root/code/CICE/Icepack/configuration/driver/icedrv_MAIN.F90:51
#9  0x557a0ea69753 in main
        at /root/code/CICE/Icepack/configuration/driver/icedrv_MAIN.F90:28

…orcing

dabail10 · 2024-10-09T14:19:29Z

HI all. Let's discuss this at the meeting tomorrow. I can understand that it would be nice to have this as a part of the Icepack forcing dataset on zenodo. However, the National Science Foundation requires the datasets be put somewhere like the Arctic Data Center where they do reside currently. This would mean duplicating the data on zenodo. Is there a way to have a "link" from zenodo to the ADC?

anton-seaice

Thanks for doing this David! This will be super useful

As Elizabeth noted, it needs some documentation.

And when adding the link to the forcing data to the wiki, I think the DOI link is best:

e.g. https://doi.org/10.18739/A2GX44W6J

anton-seaice · 2024-10-10T20:34:20Z

configuration/driver/icedrv_forcing.F90

      character(char_len), public :: &
         atm_data_format, & ! 'bin'=binary or 'nc'=netcdf
         ocn_data_format, & ! 'bin'=binary or 'nc'=netcdf
         bgc_data_format, & ! 'bin'=binary or 'nc'=netcdf
-         atm_data_type,   & ! 'default', 'clim', 'CFS'
-         ocn_data_type,   & ! 'default', 'SHEBA'
+         atm_data_type,   & ! 'default', 'clim', 'CFS', 'MOSAiC'


I think we could use a more general name than MOSAIC for the new data type - its supports any 'MDF' file right ?

Thanks for the suggestions Anton! @eclare108213 and @apcraig, what would you think about making the atm_data_type and ocn_data_type for this 'MDF' instead of 'MOSAiC'? Then I would also propose that we make the default path for these forcing data: /icepack-dirs/input/Icepack_data/forcing/MDF.

MDF works for me. But how will you distinguish between MOSAiC MDF data and some other kind of MDF data?

I believe the only place where it matters to the code that this is MOSAiC MDF data is when we check if the simulation time includes the MOSAiC leg 4 to leg 5 ship repositioning. For that check, we can check whether the forcing filename contains the string 'MOSAiC'.

Gah - thats an annoying quirk. I don't have a straightforward answer to that. This sounds like a different measurement site though? So should the experiment start again at that point with different inititial conditions ?

Should we have two different mosaic options. MOSAIC123 and MOSAIC45 for instance or some other name. These would be two separate forcing/ic options?

I think that's a good idea. I have not worked much with the leg 5 (August-September near the North Pole) data but I will inquire about how we could have an appropriate initial condition.

Based on this discussion, I think it would be cleanest if the data archive contained separate files for legs 1-4 (October-July along transpolar drift) and leg 5 (August-September near the North Pole). I will inquire within the MOSAiC Model Forcing Dataset working group to see whether others agree and if we can update the data archive.

anton-seaice · 2024-10-10T20:35:59Z

configuration/driver/icedrv_flux.F90

+      ! fixed ocean mixed layer properties (are overwritten by forcing data)
+      real (kind=dbl_kind), public :: &
+         sss_fixed   , & ! Sea surface salinity (PSU)
+         qdp_fixed   , & ! Deep ocean heat flux (negative upward, W/m^2)
+         hmix_fixed      ! Mixed layer depth (m)
+


My preference would be to do this in a different PR, so its clear what the scope of the change is (i.e. its not related to MOSAIC forcing data)

I totally agree that this would be best practice. But I admit that I'm loath to do so because the branch I originally made these modifications on is a bit stale and it doesn't feel like a productive use of time to sort through the merge conflicts and do all of the testing if the ultimate outcome for the code is the same. If others feel strongly about it I will try to get to it sometime next week. @apcraig @eclare108213 @dabail10 What do you think?

I don't think it's worth the extra work at this point, to make a separate PR.

anton-seaice · 2024-10-10T20:42:01Z

configuration/driver/icedrv_forcing.F90

+         call icedrv_system_abort(string=subname//&
+         ' ERROR: only NetCDF input implemented for atm_MOSAiC', &
+         file=__FILE__,line=__LINE__)


I think it's clearer if you put this at line 1087, if:

if (atm_data_format != 'nc') then ... abort

Done. This will be fixed in the next push.

…s not run

davidclemenssewall · 2024-10-11T17:13:49Z

Outstanding issues:

Automatically detect cadence of the inputs and adjust accordingly (currently the code requires that the atmospheric forcing is at 1 minute cadence and that the oceanic forcing is at daily cadence)

If this is easy to implement, let's do it. Otherwise I'd rather merge the PR earlier and improve it later.

It is not obvious to a user that setting the atmospheric forcing (atm_data_type = 'clim') can overwrite the oceanic heat flux convergence.

This could be noted in the documentation and also as a warning in the diagnostics log file when namelist values are written out.

The atm_MOSAiC and ocn_MOSAiC subroutines are nearly identical except for the data variables. It would probably be cleaner to combine them into a single subroutine.

Your choice.

Perhaps input checking should be added to prevent users from setting precalc_forc = .true. with non MOSAiC forcings.

Definitely.

I also recommend adding the forcing to our datasets and creating a few options for testing, including one that represents a 'production' configuration. I will still recommend that our codes be used in coupled configurations to capture important feedbacks, but we can adjust our stern warnings in the Icepack docs to acknowledge the MOSAiC configuration as a tool to be used thoughtfully.

Latest commit addresses these with the exception of the ~~warnings~~, documentation updates, and MOSAiC testing. Working on those currently...

…nic heat flux convergence

…leg 4-5 transition

…ed documenting MOSAiC in ug_running

apcraig · 2024-10-13T21:57:07Z

Looks like this is going forward nicely. I am mostly comfortable with the proposals thus far. But I think it's a mistake to have a feature that works if "MOSAIC" is in the filename. Please don't implement something like that. We should create a new namelist option if we need to. For now, we can use MDF. If something comes along later that's MDF but not Mosaic, we'll create a new option for it called "BLAHBLAH" or "BBMDF" or something. Or if what we have now is specific to mosaic even though it's MDF, lets call it MOSAIC or MosaicMDF or something. If the implementation is general for MDF, lets use MDF. How general or specific is the current implementation, that should drive the name we pick for the namelist setting.

davidclemenssewall · 2024-10-15T15:04:12Z

Looks like this is going forward nicely. I am mostly comfortable with the proposals thus far. But I think it's a mistake to have a feature that works if "MOSAIC" is in the filename. Please don't implement something like that. We should create a new namelist option if we need to. For now, we can use MDF. If something comes along later that's MDF but not Mosaic, we'll create a new option for it called "BLAHBLAH" or "BBMDF" or something. Or if what we have now is specific to mosaic even though it's MDF, lets call it MOSAIC or MosaicMDF or something. If the implementation is general for MDF, lets use MDF. How general or specific is the current implementation, that should drive the name we pick for the namelist setting.

I think that the right approach here is to break the MOSAiC forcing data into separate MDF files for legs 1-4 and leg 5. Then the forcing code can remain totally general for MDF, and we have two different set_env options for initializing the different legs as you suggested.

…te and fixed mixed layer properties

xcwang2019 · 2024-12-18T02:28:48Z

@davidclemenssewall @eclare108213 @dabail10 Sorry to reply the PR so late. Our group has constructed atmopheric and oceanic forcing files for Icepack using MOSAiC observations. The hourly forcing file is separated into two periods. The format is txt. Should I attach these files here or should I put it on zenodo and provide a link here? These forcing files were used on Icepack 1.1.0 and there is no code change involved. Thanks.

eclare108213 · 2024-12-18T16:43:15Z

@xcwang2019 Let's move discussion of your forcing data to issue #488.
@davidclemenssewall is this PR ready for review or are you still working on it?

davidclemenssewall · 2024-12-18T22:51:10Z

@eclare108213 apologies for the delay here. I am waiting on some additional processed precipitation data that I would like to include in the next version of the MOSAiC forcing data. Once I have the updated dataset released I will request review here.

davidclemenssewall · 2025-02-17T17:10:38Z

Hi all,

This is almost ready for review but I'm running into two issues on testing:

When I attempt to run the smoke test using the MOSAiC forcing with the debug flag set, I receive a floating point exception when I try to open the netcdf file (nf90_open(...). I've copied the error below It appears that this might be an issue with the underlying netcdf fortran library (I found another thread on this here: https://support.unidata.ucar.edu/archives/netcdf/msg15037.html). When I run without the debug flag the test passes fine. I've contacted the person who asked that support question to see if there was a resolution, but I was curious if anyone here has run into a similar issue?
The standard restart test doesn't work for the MOSAiC forcing because drift 1 of the MOSAiC campaign only ran from October 2019 to July 2020. Would it be reasonable to change the restart test such that the restart point is at some point within npt (e.g., the restart point could be halfway through the length of the full run)? Or perhaps we should have a third test option (like 'restart_half') that would do this and leave the current restart test alone.

The ReadTheDocs build also failed on this push, but I think that was just a hiccup from the RTD server. The documentation builds fine when I restarted it. See here: https://davidclemenssewall-icepack.readthedocs.io/en/mosaic_forcing_clean/.

I have uploaded version 2 of the MOSAiC Model Forcing Datasets, including the changes requested by the consortium, to the Arctic Data Center. In case you want to test them before they are published, I've put them in a google drive folder here: https://drive.google.com/drive/folders/1xGAeCJDwbvkXJkA-3DZXyr75GOGnoZa4?usp=sharing. Just let me know if you need access.

Cheers,
David

Error when attempting to open netcdf file in debug mode:

Program received signal SIGFPE: Floating-point exception - erroneous arithmetic operation.

Backtrace for this error:
#0  0x7fc0a1b4951f in ???
        at ./signal/../sysdeps/unix/sysv/linux/x86_64/libc_sigaction.c:0
#1  0x7fc0a18b1b72 in ???
#2  0x7fc0a1840cba in ???
#3  0x7fc0a18d01e2 in ???
#4  0x7fc0a1627a22 in ???
#5  0x7fc0a16c4385 in ???
#6  0x7fc0a21a0b9f in ???
#7  0x7fc0a21a952d in ???
#8  0x7fc0a2124213 in ???
#9  0x7fc0a2126359 in ???
#10  0x7fc0a21264d4 in ???
#11  0x7fc0a202ea7b in ???
#12  0x7fc0a20d5fd7 in ???
#13  0x559b0715f35b in atm_mdf
        at /root/code/CICE/icepack/configuration/driver/icedrv_forcing.F90:1097
#14  0x559b07174ed6 in __icedrv_forcing_MOD_init_forcing
        at /root/code/CICE/icepack/configuration/driver/icedrv_forcing.F90:195
#15  0x559b071347c2 in __icedrv_initmod_MOD_icedrv_initialize
        at /root/code/CICE/icepack/configuration/driver/icedrv_InitMod.F90:137
#16  0x559b071348dd in icedrv
        at /root/code/CICE/icepack/configuration/driver/icedrv_MAIN.F90:45
#17  0x559b07134be8 in main
        at /root/code/CICE/icepack/configuration/driver/icedrv_MAIN.F90:28

anton-seaice · 2025-02-17T21:54:10Z

When I attempt to run the smoke test using the MOSAiC forcing with the debug flag set, I receive a floating point exception when I try to open the netcdf file (nf90_open(...). I've copied the error below It appears that this might be an issue with the underlying netcdf fortran library (I found another thread on this here: https://support.unidata.ucar.edu/archives/netcdf/msg15037.html). When I run without the debug flag the test passes fine. I've contacted the person who asked that support question to see if there was a resolution, but I was curious if anyone here has run into a similar issue?

If this is using a netcdf4 file, there was an issue with the underlying hdf5 library in some versions last year that caused this sort of error. I think it only occurred in hdf5 versions 1.14.3 and was also patched in the spack build. See HDFGroup/hdf5#3831

davidclemenssewall · 2025-02-20T15:04:30Z

When I attempt to run the smoke test using the MOSAiC forcing with the debug flag set, I receive a floating point exception when I try to open the netcdf file (nf90_open(...). I've copied the error below It appears that this might be an issue with the underlying netcdf fortran library (I found another thread on this here: https://support.unidata.ucar.edu/archives/netcdf/msg15037.html). When I run without the debug flag the test passes fine. I've contacted the person who asked that support question to see if there was a resolution, but I was curious if anyone here has run into a similar issue?

If this is using a netcdf4 file, there was an issue with the underlying hdf5 library in some versions last year that caused this sort of error. I think it only occurred in hdf5 versions 1.14.3 and was also patched in the spack build. See HDFGroup/hdf5#3831

Updating hdf5 worked, the smoke test now passes. Thanks @anton-seaice!

davidclemenssewall and others added 28 commits May 8, 2023 13:55

up to reading time01

f61b4b1

ran into ntime /= npt issue

8d0eb98

made *_data arrays allocatable to solve ntime issue, now getting a se…

92b7cf3

…gfault

forgot to allocate open_data and clos_data, fixed and solved seg fault

52af4e1

averaging function runs

4c9fed7

Now working for Tair

8c99a08

works okay, qa/1000 and fsnow and frain set to 0

e9cac2d

dummy ocean forcing and initial conditions closer to mosaic

3409f42

fixed istep /= istep1 issue, now can start at times other than Jan. 1

7055333

Merge branch 'main' into for_igs

312b24c

Just updating for_igs to consortium main. Only conflict was in icedrv_init use section

updated forcing code now that MDF doesn't write calendar

c97bc56

added functionality for precipitation and ocean mixed layer forcing

c69f403

partially through changes to add ice thickness init options

71a176c

init ice thickness complete and checked that results match

78f761c

set initial sst working

9db2ef6

removed setting sst from icedrv_flux

9f297c1

fixed sss, qdp, and hmix all working

f00f46b

Merge branch 'main' into mosaic_ocn_forcing to stay up to date with c…

5a6ae48

…onsortium main

Merge branch 'init_options' into mosaic_ocn_forcing

6219577

change atmmosaic options

397e09a

updated atmmosaic and ocnmosaic to new forcings

dd92954

updated names for downwelling radiation fields in forcing to correct …

2c8195a

…names

updated mosaic settings to account for fact that ADC converts - to _ …

e6c0dce

…in filenames

Merge branch 'main' into mosaic_forcing_clean

6be69b0

Merge branch 'main' into mosaic_forcing_clean

ac5ad88

Cleaned up extraneous comments and renamed precalc_forc

c3a815d

added check for standard calendar and leap years

946fbcb

Merge branch 'main' into mosaic_forcing_clean

38995e7

davidclemenssewall mentioned this pull request Sep 24, 2024

MOSAiC forcing from Xiaochun Wang #488

Open

davidclemenssewall added 2 commits September 30, 2024 12:54

Merge branch 'main' into mosaic_forcing_clean

0b4b404

added check to ensure that precalc_forc is only used for the MOSAiC f…

b47d4c8

…orcing

anton-seaice reviewed Oct 10, 2024

View reviewed changes

davidclemenssewall added 3 commits October 10, 2024 16:34

forcing refactoring and flexible cadence code complete, compiles, doe…

7d88cbf

…s not run

fixed typo, now runs successfuly

d93b3fc

reorganized data format checks for clarity

b15d4d5

davidclemenssewall added 4 commits October 11, 2024 15:35

added warning for MOSAiC leg 4-5 transition

429e824

added warning for impact of climatological atmosphere forcing on ocea…

358896d

…nic heat flux convergence

Changed forcing name from MOSAiC to MDF and updated check for MOSAiC …

5f36f94

…leg 4-5 transition

Updating documentation, MDF forcing added to ug_implementation, start…

9cf540f

…ed documenting MOSAiC in ug_running

davidclemenssewall added 3 commits October 18, 2024 18:20

partway through doc update

c738251

Merge branch 'main' into mosaic_forcing_clean

8f9b081

finished documentation update

8ceed76

davidclemenssewall changed the title ~~Mosaic forcing clean~~ MDF/MOSAiC forcing options Nov 11, 2024

updated documentation to include namelist options for initial ice sta…

fdafc83

…te and fixed mixed layer properties

davidclemenssewall added 5 commits January 13, 2025 16:24

Merge branch 'main' into mosaic_forcing_clean

eb2fa72

updated MOSAiC settings for v2 of forcing dataset

dfa2e9b

Merge branch 'main' into mosaic_forcing_clean

d593f8e

added optional precipitation handling

ec00d95

removed the MOSAiC drift 1-2 transition warning

826bfc5

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

MDF/MOSAiC forcing options #500

MDF/MOSAiC forcing options #500

davidclemenssewall commented Sep 24, 2024 •

edited

Loading

davidclemenssewall commented Sep 24, 2024

dabail10 commented Oct 9, 2024

anton-seaice left a comment

anton-seaice Oct 10, 2024

davidclemenssewall Oct 11, 2024

eclare108213 Oct 12, 2024

davidclemenssewall Oct 13, 2024

anton-seaice Oct 14, 2024

apcraig Oct 15, 2024

davidclemenssewall Oct 15, 2024

anton-seaice Oct 10, 2024

davidclemenssewall Oct 11, 2024

eclare108213 Oct 12, 2024

anton-seaice Oct 10, 2024

davidclemenssewall Oct 11, 2024

anton-seaice Oct 14, 2024

davidclemenssewall commented Oct 11, 2024 •

edited

Loading

apcraig commented Oct 13, 2024

davidclemenssewall commented Oct 15, 2024

xcwang2019 commented Dec 18, 2024

eclare108213 commented Dec 18, 2024

davidclemenssewall commented Dec 18, 2024

davidclemenssewall commented Feb 17, 2025

anton-seaice commented Feb 17, 2025

davidclemenssewall commented Feb 20, 2025

MDF/MOSAiC forcing options #500

Are you sure you want to change the base?

MDF/MOSAiC forcing options #500

Conversation

davidclemenssewall commented Sep 24, 2024 • edited Loading

PR checklist

davidclemenssewall commented Sep 24, 2024

dabail10 commented Oct 9, 2024

anton-seaice 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

davidclemenssewall commented Oct 11, 2024 • edited Loading

apcraig commented Oct 13, 2024

davidclemenssewall commented Oct 15, 2024

xcwang2019 commented Dec 18, 2024

eclare108213 commented Dec 18, 2024

davidclemenssewall commented Dec 18, 2024

davidclemenssewall commented Feb 17, 2025

anton-seaice commented Feb 17, 2025

davidclemenssewall commented Feb 20, 2025

davidclemenssewall commented Sep 24, 2024 •

edited

Loading

davidclemenssewall commented Oct 11, 2024 •

edited

Loading